- Moose-dev - INF Mailman

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, 10 months

2
8
0 0

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, 10 months

1
1
0 0

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, 10 months

2
3
0 0

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, 10 months

2
2
0 0

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, 10 months

2
2
0 0

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, 10 months

1
1
0 0

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, 10 months

1
1
0 0

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, 10 months

3
27
0 0

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, 11 months

1
0
0 0

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, 11 months

1
1
0 0

what makes moose

by Tudor Girba

Hi Stef, On Sun, Aug 11, 2013 at 3:19 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr > wrote: > ... > To me I think that it would be good to have a Moosedev and a > MooseDeployment part because we have many differnt frameworks in the system > This is certainly an important topic and it warrants its own discussion. I think we should not distinguish between MooseDev and MooseDeployment :). My vision goes like this: - Moose is a platform that works for multiple technologies. Perhaps we can distinguish between what makes sense for Java or for a language like C#, but the differences would be small and would not warrant different distributions. - Moose is a platform for Pharo as well, although not many are seeing it like that. This means that the tools we have with Moose should be used for analyzing Pharo. - We could distinguish between a Pharo only distribution and the distribution for all other languages. Actually, this is what we have with the GToolkit project: a Pharo specific toolset. However, we still want to have the Pharo-specific tools inside a Java-specific distribution given that we want people to develop their own tools fast. And to debug them. And to inspect them. So we want all the Pharo specific tools in the large distribution, too. All in all, we now go towards: - GToolkit for everyone that wants to develop in Pharo only. - Moose for every other language (and it includes GToolkit). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

11 years, 11 months

2
5
0 0

Jenkins build became unstable: moose-latest-dev-4.8 #860

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/860/>

11 years, 11 months

1
0
0 0

another one but that one I do not understand it :)

by Stéphane Ducasse

ACD-Model depends on MessageSendDebugAction ??? may be this one is the fix package: 'ACD-Model' with: [spec requires: #('NewDebugger-Core' 'DebuggerActions)]; in AnnouncerCentricDebugger To me I think that it would be good to have a Moosedev and a MooseDeployment part because we have many differnt frameworks in the system Stef

11 years, 11 months

2
10
0 0

MooseImage

by Tudor Girba

Hi, MooseImage is a new class that is meant to store meta-information about the origin of the current image. Right now, this populated by the Jenkins build job. You can simply print the result of "MooseImage current" to find the information For example, you can get: Moose https://ci.inria.fr/moose/job/moose-latest-dev-4.8/855/ 11 August 2013 3:23:43 pm >From now on, we can identify our images better. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

11 years, 11 months

2
1
0 0

Issue 963 in moose-technology: Jenkins should stamp a build number in the Moose image

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Maintainability New issue 963 by tu...(a)tudorgirba.com: Jenkins should stamp a build number in the Moose image http://code.google.com/p/moose-technology/issues/detail?id=963 The best way to do this would be to extend the MooseImageSetupCommandLineHandler to support a build number parameter. -- 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, 11 months

1
2
0 0

Jenkins build is back to normal : moose-latest-dev-4.8 #855

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/855/>

11 years, 11 months

1
0
0 0

MooseCycleTable depends on DSMFamixCell

by Stéphane Ducasse

package: 'Moose-CycleTable' with: [spec requires: 'Moose-Dsm-Core']; => package: 'Moose-CycleTable' with: [spec requires: #('Moose-Dsm-Core' 'Moose-Dsm-Famix')]; or package: 'Moose-CycleTable' with: [spec requires: #('Moose-Dsm-Famix')]; because Moose-Dsm-Famix depends on Dsm-core

11 years, 11 months

2
2
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/853/> ------------------------------------------ Started by user tudor(a)tudorgirba.com 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/hudson4028892227397677743.sh + + bash wget --quiet -O - http://get.pharo.org/20+vmLatest 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+ ./pharo moose-latest-dev-4.8.image mooseimagesetup --signature=https://ci.inria.fr/moose/job/moose-latest-dev-4.8/853/ [31m==== Startup Error: MessageNotUnderstood: MooseImage>>description: [0mMooseImage(Object)>>doesNotUnderstand: #description: MooseImageSetupCommandLineHandler>>installImageDescription MooseImageSetupCommandLineHandler>>activate MooseImageSetupCommandLineHandler class(CommandLineHandler class)>>activateWith: DefaultCommandLineHandler>>handleSubcommand DefaultCommandLineHandler>>handleArgument: DefaultCommandLineHandler>>activate DefaultCommandLineHandler class>>startUp: in Block: [self new activate] BlockClosure>>cull: SmalltalkImage>>executeDeferredStartupActions: in Block: [each cull: resuming] BlockClosure>>on:do: SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger: SmalltalkImage>>executeDeferredStartupActions: in Block: [:each | self... OrderedCollection>>do: SmalltalkImage>>executeDeferredStartupActions: SmalltalkImage>>startupImage:snapshotWorked: SmalltalkImage>>snapshot:andQuit: ConfigurationCommandLineHandler>>installVersion: ConfigurationCommandLineHandler>>installConfiguration ConfigurationCommandLineHandler>>activate ConfigurationCommandLineHandler class(CommandLineHandler class)>>activateWith: DefaultCommandLineHandler>>handleSubcommand DefaultCommandLineHandler>>handleArgument: DefaultCommandLineHandler>>activate DefaultCommandLineHandler class>>startUp: in Block: [self new activate] BlockClosure>>cull: SmalltalkImage>>executeDeferredStartupActions: in Block: [each cull: resuming] BlockClosure>>on:do: SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger: SmalltalkImage>>executeDeferredStartupActions: in Block: [:each | self... [0m[31mGot startup errors: [0m[31m MessageNotUnderstood: MooseImage>>description: [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

11 years, 11 months

1
0
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/851/> ------------------------------------------ Started by user tudor(a)tudorgirba.com 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/hudson9046971053432843357.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+ ./pharo moose-latest-dev-4.8.image mooseimagesetup --signature=https://ci.inria.fr/moose/job/moose-latest-dev-4.8/851/ [31m==== Startup Error: MessageNotUnderstood: MooseImage>>timestamp: [0mMooseImage(Object)>>doesNotUnderstand: #timestamp: MooseImageSetupCommandLineHandler>>installImageDescription MooseImageSetupCommandLineHandler>>activate MooseImageSetupCommandLineHandler class(CommandLineHandler class)>>activateWith: DefaultCommandLineHandler>>handleSubcommand DefaultCommandLineHandler>>handleArgument: DefaultCommandLineHandler>>activate DefaultCommandLineHandler class>>startUp: in Block: [self new activate] BlockClosure>>cull: SmalltalkImage>>executeDeferredStartupActions: in Block: [each cull: resuming] BlockClosure>>on:do: SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger: SmalltalkImage>>executeDeferredStartupActions: in Block: [:each | self... OrderedCollection>>do: SmalltalkImage>>executeDeferredStartupActions: SmalltalkImage>>startupImage:snapshotWorked: SmalltalkImage>>snapshot:andQuit: ConfigurationCommandLineHandler>>installVersion: ConfigurationCommandLineHandler>>installConfiguration ConfigurationCommandLineHandler>>activate ConfigurationCommandLineHandler class(CommandLineHandler class)>>activateWith: DefaultCommandLineHandler>>handleSubcommand DefaultCommandLineHandler>>handleArgument: DefaultCommandLineHandler>>activate DefaultCommandLineHandler class>>startUp: in Block: [self new activate] BlockClosure>>cull: SmalltalkImage>>executeDeferredStartupActions: in Block: [each cull: resuming] BlockClosure>>on:do: SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger: SmalltalkImage>>executeDeferredStartupActions: in Block: [:each | self... [0m[31mGot startup errors: [0m[31m MessageNotUnderstood: MooseImage>>timestamp: [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

11 years, 11 months

1
0
0 0

Another problem GlamourExamples and EyeSee and others

by Stéphane Ducasse

HI doru GLMBrowserTemplate You must resolve these dependencies before you will be able to load these definitions: GLMEyeSeeExamplesBrowser I checked and GLMEyeSeeExamplesBrowser class >> open ^ self new openOn: ESExamples package: 'Glamour-Examples' ; look bogus it depends on Magritte!, EyeSee and Roassal I tried package: 'Glamour-Examples' with: [spec requires: #('Glamour-Magritte-Presentations' 'Glamour-EyeSee-Presentations' 'Glamour-Mondrian-Presentations')] ; but I navigate in the total guess here. Can you have a look? Stef

11 years, 11 months

2
2
0 0

Problem: Mondrian-ComplexShape depends on MONodeShape

by Stéphane Ducasse

So I did package: 'Mondrian-Core'; package: 'Mondrian-ComplexShape' with: [ spec requires: 'Mondrian-Core' ]; package: 'Mondrian-Layouts'; and restarted again….

11 years, 11 months

1
3
0 0

Another problem (Mondrian-Pharo-Tests)

by Stéphane Ducasse

Mondrian-Pharo-Tests says This package depends on the following classes: MondrianTest You must resolve these dependencies before you will be able to load these definitions: MOCanvasTest allEventPollsEmpty I'm trying to find the problem now but in parallel I'm painting my house door :) Stef

11 years, 11 months

1
2
0 0

SnapshotCello feedabck

by Stéphane Ducasse

Hi doru I like the interface much better than the moose reloader :) Else - what about dirty packages that are not in the configuration tree? I would not handle them to force people to get clean Did you try to rebuild Moose using it? I will ;) Stef

11 years, 11 months

2
23
0 0

Issue 960 in moose-technology: Smalltalk importer creates a non-stub Object.DependentsFields

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-SmalltalkImporter New issue 960 by anquetil...(a)gmail.com: Smalltalk importer creates a non-stub Object.DependentsFields http://code.google.com/p/moose-technology/issues/detail?id=960 When creating a moose model from smalltalk code not including Object The class Object is created with isStub=true Object has an attribute Object.DependentsFields (a class variable) with isStub=false -- 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, 11 months

1
3
0 0

Issue 962 in moose-technology: Metanool should not extend MooseEntity and MooseGroup

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Milestone-4.8 Component-Metanool Component-Finder New issue 962 by tu...(a)tudorgirba.com: Metanool should not extend MooseEntity and MooseGroup http://code.google.com/p/moose-technology/issues/detail?id=962 Metanool extends these classes with MooseFinder specific methods. These methods should move to MooseFinder. -- 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, 11 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev