Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Stéphane Ducasse

Hi doru while reloading/retrying I looked the generated spec and I noted some points that may reveal missing dependencies * #('Famix-Tests-C-AndreHora.6.mcz' 'http://www.smalltalkhub.com/mc/Moose/Moose/main/' 'Famix-Tests-C' ) #('Famix-Tests-Extensions-TudorGirba.23.mcz' 'http://www.smalltalkhub.com/mc/Moose/Moose/main/' 'Famix-Tests-Extensions' ) #('Dynamix-Tests-Core-TudorGirba.17.mcz' 'http://www.smalltalkhub.com/mc/Moose/DynaMoose/main/' 'Dynamix-Tests-Core' ) arrive quite earrly even before magritte fame…. Now I found some bugs in Moose configurations: Problem 1 -------------- * Moose-Hismo arrives before FAMIX-Core. And this is false. This package depends on the following classes: FAMIXPackage FAMIXEntity FAMIXInheritance You must resolve these dependencies before y So I cannot reload our application (our application is simple is basically only depend on Moose and PetitParser. I checked all the configurations and they are simple and small. I saw that Moose defines package: 'Moose-Hismo' with: [spec requires: 'Moose-Core']; so may be this should be FAMIX-Core? Or the extensions should be moved to another package but it will complexify the system. I modified the moose configuration and the order looks better to me. #('Moose-GenericImporter-Nicolasanquetil.47.mcz' 'http://www.smalltalkhub.com/mc/Moose/Moose/main/' 'Moose-GenericImporter' ) #('Famix-Core-TudorGirba.222.mcz' 'http://www.smalltalkhub.com/mc/Moose/Moose/main/' 'Famix-Core' ) #('Famix-SourceAnchor-TudorGirba.38.mcz' 'http://www.smalltalkhub.com/mc/Moose/Moose/main/' 'Famix-SourceAnchor' ) #('Moose-Hismo-JurajKubelka.69.mcz' 'http://www.smalltalkhub.com/mc/Moose/Moose/main/' 'Moose-Hismo' ) #('Famix-File-NicolasAnquetil.40.mcz' 'http://www.smalltalkhub.com/mc/Moose/Moose/main/' 'Famix-File' ) #('Famix-Java-TudorGirba.74.mcz' 'http://w Problem 2 -------------- Now I found another problem Algo-Clustering MalArrayVector MalVectorDecorator MalSymetricMatrix MalVector arrives before LinearAlgebra package: 'Moose-Algos-Clustering' ; package: 'Moose-Algos-LinearAlgebra'; So I moved package: 'Moose-Algos-LinearAlgebra'; before and I added a dependency package: 'Moose-Algos-Clustering' with: [spec requires: 'Moose-Algos-LinearAlgebra'] ; Of course the feedback loop is quite long…. So testing until the next problem. I think that we should build a tool that check dependencies. could you change this information or do I do it? Stef

11 years, 8 months

Build failed in Jenkins: moose-latest-dev-4.8 #887

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/887/> ------------------------------------------ Started by upstream project "gtoolkit" build number 253 originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on moose-ubuntu1204-dualproc-i386 in workspace <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> Deleting project workspace... done [moose-latest-dev-4.8] $ /bin/sh -xe /tmp/hudson8606449502973630000.sh + wget --quiet -O - http://get.pharo.org/20+vmLatest + bash Downloading the latest 20 Image: http://files.pharo.org/image/20/latest.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/latest.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/sources//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/sources//PharoV20.sources.zip Creating starter scripts pharo and pharo-ui + ./pharo Pharo.image save moose-latest-dev-4.8 + REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main + ./pharo moose-latest-dev-4.8.image config http://www.smalltalkhub.com/mc/Moose/Moose/main ConfigurationOfMoose --install=development [31m[33m =============================================================================== Notice: Installing ConfigurationOfMoose development =============================================================================== [0m[0m[31m==== Startup Error: Error: Could not load Moose-TestResources-PackageBlueprint-P1-NicolasAnquetil.2.mcz: ConnectionTimedOut: Data receive timed out. [0mMCHttpRepository(Object)>>error: MCHttpRepository>>readStreamForFileNamed:do: in Block: [:exception | self error: 'Could not load ' , aStr...etc... BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [self exceptionHandlerBlock cull: exception] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ConnectionTimedOut(Exception)>>pass ZnClient>>executeWithRetriesRemaining: in Block: [:exception | retryCount > 0... BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [self exceptionHandlerBlock cull: exception] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: ConnectionTimedOut(Exception)>>signal ConnectionTimedOut(Exception)>>signal: ConnectionTimedOut class(Exception class)>>signal: Socket>>waitForDataFor: in Block: [ConnectionTimedOut signal: 'Data receive timed ou...etc... Socket>>waitForDataFor:ifClosed:ifTimedOut: Socket>>waitForDataFor: Socket>>receiveDataSignallingTimeout:into:startingAt: SocketStream>>receiveData SocketStream>>next ZnLineReader>>processNext ZnLineReader>>nextLine ZnStatusLine>>readFrom: ZnStatusLine class>>readFrom: ZnResponse>>readHeaderFrom: ZnResponse(ZnMessage)>>readFrom: ZnResponse class(ZnMessage class)>>readFrom: [0m[31mGot startup errors: [0m[31m Error: Could not load Moose-TestResources-PackageBlueprint-P1-NicolasAnquetil.2.mcz: ConnectionTimedOut: Data receive timed out. [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

11 years, 8 months

thanks for the new configuration

by Stéphane Ducasse

I will try when the jenkins buils decide to see the new moose version…. And I do not have the rigth accesses :( Stef

11 years, 8 months

inria jenkins got much faster

by Tudor Girba

Hi, I just noticed that the Jenkins jobs got much faster. For example, the Moose job went from 36 minutes to 6 minutes. Or the Glamour job went from 11 minutes to 3 minutes. This is fantastic, but I do not know why the difference occurs. It seems that the difference started yesterday before 15:00: https://ci.inria.fr/moose/job/moose-latest-dev-4.8/871/ (15:49 -- 6 min) https://ci.inria.fr/moose/job/moose-latest-dev-4.8/870/ (02:49 -- 36 min) As it affected multiple jobs, I suspect it has to do with the infrastructure. Anyone has any idea as to why this happens? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

11 years, 8 months

Missing change in latest Moose

by Stéphane Ducasse

MooseAlgos-Clustering is depending on MalArrayVector so I suggested to do spec package: 'Moose-Algos-Graph' ; package: 'Moose-Algos-LinearAlgebra'; package: 'Moose-Tests-Algos-Graph' ; package: 'Moose-Algos-HierarchicalGraph' with: [spec requires: 'Moose-Algos-Graph']; package: 'Moose-Tests-Algos-HierarchicalGraph' ; package: 'Moose-Tests-Algos-LinearAlgebra' ; package: 'Moose-Tests-Algos-Clustering' ; package: 'Moose-Tests-Algos-InformationRetrieval' ; package: 'Moose-Tests-Algos-FormalConceptAnalysis'; package: 'Moose-Tests-Algos-Lattice'; package: 'Moose-Algos-Clustering' with: [spec requires: 'Moose-Algos-LinearAlgebra'] ; package: 'Moose-Algos-FormalConceptAnalysis'; package: 'Moose-Algos-Lattice'; package: 'Moose-Algos-InformationRetrieval'; package: 'Moose-Algos-Kontractor'; package: 'Moose-Tests-Algos-Kontractor' ; should I commit this changes? > Problem 2 > -------------- > Now I found another problem > > Algo-Clustering > > MalArrayVector MalVectorDecorator MalSymetricMatrix MalVector > arrives before > LinearAlgebra > > > package: 'Moose-Algos-Clustering' ; > package: 'Moose-Algos-LinearAlgebra'; > > So I moved package: 'Moose-Algos-LinearAlgebra'; before > and I added a dependency > > > package: 'Moose-Algos-Clustering' with: [spec requires: 'Moose-Algos-LinearAlgebra'] ; > > > Of course the feedback loop is quite long…. > So testing until the next problem. I think that we should build a tool that check dependencies. > > could you change this information or do I do it? > > > Stef

11 years, 8 months

Issue 965 in moose-technology: ParameterizedType should have same stub status as their ParameterizableClass

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 965 by anquetil...(a)gmail.com: ParameterizedType should have same stub status as their ParameterizableClass http://code.google.com/p/moose-technology/issues/detail?id=965 All ParameterizedTypes are created with isStub=true If the parameterizableClass is not stub, its ParameterizedTypes should not be either -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

11 years, 8 months

Issue 966 in moose-technology: doItContext: in text presentations

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 966 by chisvasi...(a)gmail.com: doItContext: in text presentations http://code.google.com/p/moose-technology/issues/detail?id=966 Text presentations should have an option for specifying the context (doItContext:) just like doItReceiver:, otherwise instance variables and parameters cannot be inspected from editors. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

11 years, 8 months

Issue 888 in moose-technology: MondrianViewBuilder should support a better zOrder

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Roassal New issue 888 by tu...(a)tudorgirba.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888 Here is a little example: view shape label text: #yourself. view nodes: (1 to: 20). view edges: (1 to: 20) from: [:x | x // 2] to: 1. view edges: (1 to: 20) from: [:x | x // 3] to: 2. view edges: (1 to: 20) from: [:x | x // 5] to: #yourself. view edges: (1 to: 20) from: [:x | x // 7] to: #yourself. view dominanceTreeLayout Open this one is Mondrian and then in the Roassal Easel. Then, try to select 1. In Roassal, you cannot select 1 because of the edges that go on top of it. What is more, you also can barely see it. This situation will always appear in graphs with edges that cross the nodes. Given that at least the MondrianViewBuilder should be about mapping domain models onto graphs, having a sensible zOrder, at least in the MondrianViewBuilder is important.

11 years, 8 months

Build failed in Jenkins: moose-latest-dev-4.8 #865

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/865/> ------------------------------------------ Started by upstream project "roassal" build number 383 originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on moose-ubuntu1204-dualproc-i386 in workspace <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> Deleting project workspace... done [moose-latest-dev-4.8] $ /bin/sh -xe /tmp/hudson1290826081779860701.sh + wget --quiet -O - http://get.pharo.org/20+vmLatest + bash Downloading the latest 20 Image: http://files.pharo.org/image/20/latest.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/latest.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/sources//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/sources//PharoV20.sources.zip Creating starter scripts pharo and pharo-ui + ./pharo Pharo.image save moose-latest-dev-4.8 + REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main + ./pharo moose-latest-dev-4.8.image config http://www.smalltalkhub.com/mc/Moose/Moose/main ConfigurationOfMoose --install=development [31m[33m =============================================================================== Notice: Installing ConfigurationOfMoose development =============================================================================== [0m[0m[31m==== Startup Error: Error: Could not load Mondrian-ShapeVisitor-TudorGirba.6.mcz: ConnectionTimedOut: Data receive timed out. [0mMCHttpRepository(Object)>>error: MCHttpRepository>>readStreamForFileNamed:do: in Block: [:exception | self error: 'Could not load ' , aStr...etc... BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [self exceptionHandlerBlock cull: exception] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ConnectionTimedOut(Exception)>>pass ZnClient>>executeWithRetriesRemaining: in Block: [:exception | retryCount > 0... BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [self exceptionHandlerBlock cull: exception] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: ConnectionTimedOut(Exception)>>signal ConnectionTimedOut(Exception)>>signal: ConnectionTimedOut class(Exception class)>>signal: Socket>>waitForDataFor: in Block: [ConnectionTimedOut signal: 'Data receive timed ou...etc... Socket>>waitForDataFor:ifClosed:ifTimedOut: Socket>>waitForDataFor: Socket>>receiveDataSignallingTimeout:into:startingAt: SocketStream>>receiveData SocketStream>>next ZnLineReader>>processNext ZnLineReader>>nextLine ZnStatusLine>>readFrom: ZnStatusLine class>>readFrom: ZnResponse>>readHeaderFrom: ZnResponse(ZnMessage)>>readFrom: ZnResponse class(ZnMessage class)>>readFrom: [0m[31mGot startup errors: [0m[31m Error: Could not load Mondrian-ShapeVisitor-TudorGirba.6.mcz: ConnectionTimedOut: Data receive timed out. [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

11 years, 8 months

Issue 964 in moose-technology: <Initializer> methods created as stub

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 964 by anquetil...(a)gmail.com: <Initializer> methods created as stub http://code.google.com/p/moose-technology/issues/detail?id=964 When an attribute is initialized at declaration, the initialization code goes in a <Initializer> method. This one should not be a stub but it is -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

11 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev