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

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

10 years, 8 months

MooseDay in Lille

by Anne Etien

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

10 years, 8 months

Re: persisting moose models

by Stephan Eggermont

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

10 years, 8 months

looking at the frozen spec

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

10 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

10 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

10 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"

10 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

10 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

10 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

10 years, 8 months

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev August 2013