Moose-dev August 2013

moose-dev@list.inf.unibe.ch

26 participants
167 discussions

Start a nNew thread

Jenkins build is back to stable : moose-latest-dev-4.8 #904
by admin＠moosetechnology.org 20 Aug '13

20 Aug '13

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

1 0

MooseDay in Lille
by Anne Etien 20 Aug '13

20 Aug '13

Hi, In order to start the organization of the MooseDay in Lille, we would like to know, who would be interested in attending and who would like to make a presentation. The idea would be to organize it the first or the second week of October. Please let us know your interest in the MooseDay in Lille (France). Thanks in advance. Anne

2 1

Re: persisting moose models
by Stephan Eggermont 20 Aug '13

20 Aug '13

Hi Fabrizio, Moose models are highly interconnected, and the analyzing algorithms tend to touch a lot of other objects. There is very limited locality of reference, so a RDBMS (or NoSQL) cannot help you here. You basically would only be swapping in and out objects. Stephan

1 0

looking at the frozen spec
by Stéphane Ducasse 19 Aug '13

19 Aug '13

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

2 8

Build failed in Jenkins: moose-latest-dev-4.8 #887
by admin＠moosetechnology.org 15 Aug '13

15 Aug '13

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

1 1

thanks for the new configuration
by Stéphane Ducasse 14 Aug '13

14 Aug '13

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

2 3

inria jenkins got much faster
by Tudor Girba 14 Aug '13

14 Aug '13

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"

2 2

Missing change in latest Moose
by Stéphane Ducasse 13 Aug '13

13 Aug '13

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

2 2

Issue 965 in moose-technology: ParameterizedType should have same stub status as their ParameterizableClass
by moose-technology＠googlecode.com 13 Aug '13

13 Aug '13

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

1 1

Issue 966 in moose-technology: doItContext: in text presentations
by moose-technology＠googlecode.com 13 Aug '13

13 Aug '13

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

1 1

← Newer
1
...
10
11
12
13
14
15
16
17
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev August 2013