- Moose-dev - INF Mailman

by mathieubmddehouck＠mailoo.org

Hi Back on code, after a little week off. Just rewrite rawEdgesFrom: to: using rawEdges: from: to: and we win up to 53 second on Object withAllSubclasses (11000 classes). That's very nice. Regards Mathieu

11 years, 11 months

4
7
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/765/> ------------------------------------------ [...truncated 1004084 lines...] wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait stack page bytes 4096 available headroom 3300 minimum unused headroom 3508 (last object overwritten) ./pharo: line 11: 17970 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" -nodisplay "$@" Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed: <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> at hudson.remoting.Channel@2f17e8fb:moose-ubuntu1204-dualproc-i386 at hudson.FilePath.act(FilePath.java:848) at hudson.FilePath.act(FilePath.java:825) at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:87) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:785) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:732) at hudson.model.Run.execute(Run.java:1568) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.util.IOException2: Failed to read <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/SmallDude-Tests-Core-…> at hudson.tasks.junit.TestResult.parse(TestResult.java:244) at hudson.tasks.junit.TestResult.parse(TestResult.java:163) at hudson.tasks.junit.TestResult.parse(TestResult.java:140) at hudson.tasks.junit.TestResult.<init>(TestResult.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:117) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:90) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.dom4j.DocumentException: Error on line 99 of document file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/SmallDude-Tests-Core-…> : XML document structures must start and end within the same entity. Nested exception: XML document structures must start and end within the same entity. at org.dom4j.io.SAXReader.read(SAXReader.java:482) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:129) at hudson.tasks.junit.TestResult.parse(TestResult.java:227) ... 15 more Caused by: org.xml.sax.SAXParseException; systemId: file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/SmallDude-Tests-Core-…;> lineNumber: 99; columnNumber: 1; XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:391) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1404) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.endEntity(XMLDocumentFragmentScannerImpl.java:882) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:582) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1370) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1740) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipChar(XMLEntityScanner.java:1393) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2769) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525) at org.dom4j.io.SAXReader.read(SAXReader.java:465) ... 18 more

11 years, 11 months

1
2
0 0

Issue 952 in moose-technology: Exporting Famix numberOfLinesOfCode fails when a function is defined

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 952 by step...(a)stack.nl: Exporting Famix numberOfLinesOfCode fails when a function is defined http://code.google.com/p/moose-technology/issues/detail?id=952 FAMIXNamespace numberOfLinesOfCode <MSEProperty: #numberOfLinesOfCode type: #Number> <derived> <MSEComment: 'The number of lines of code in a namespace'> ^self lookUpPropertyNamed: #numberOfLinesOfCode computedAs: [self types , self functions inject: 0 into: [ :Sum :each | sum + each numberOfLinesOfCode] ] self types, self functions fails Easy to solve by calculating the sum independently and adding together -- 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

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/762/> ------------------------------------------ [...truncated 1021556 lines...] wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait wait wait signal wait signal wait signal signal basicNew: basicNew class at:put: wait stack page bytes 4096 available headroom 3300 minimum unused headroom 3508 (last object overwritten) ./pharo: line 11: 17753 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" -nodisplay "$@" Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed: <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> at hudson.remoting.Channel@2f17e8fb:moose-ubuntu1204-dualproc-i386 at hudson.FilePath.act(FilePath.java:848) at hudson.FilePath.act(FilePath.java:825) at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:87) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:785) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:732) at hudson.model.Run.execute(Run.java:1568) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.util.IOException2: Failed to read <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/SmallDude-Tests-Core-…> at hudson.tasks.junit.TestResult.parse(TestResult.java:244) at hudson.tasks.junit.TestResult.parse(TestResult.java:163) at hudson.tasks.junit.TestResult.parse(TestResult.java:140) at hudson.tasks.junit.TestResult.<init>(TestResult.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:117) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:90) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.dom4j.DocumentException: Error on line 99 of document file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/SmallDude-Tests-Core-…> : XML document structures must start and end within the same entity. Nested exception: XML document structures must start and end within the same entity. at org.dom4j.io.SAXReader.read(SAXReader.java:482) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:129) at hudson.tasks.junit.TestResult.parse(TestResult.java:227) ... 15 more Caused by: org.xml.sax.SAXParseException; systemId: file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/SmallDude-Tests-Core-…;> lineNumber: 99; columnNumber: 1; XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:391) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1404) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.endEntity(XMLDocumentFragmentScannerImpl.java:882) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:582) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1370) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1740) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipChar(XMLEntityScanner.java:1393) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2769) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525) at org.dom4j.io.SAXReader.read(SAXReader.java:465) ... 18 more

11 years, 11 months

1
1
0 0

Issue 958 in moose-technology: parameterizableClass does not have an opposite

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Famix New issue 958 by tu...(a)tudorgirba.com: parameterizableClass does not have an opposite http://code.google.com/p/moose-technology/issues/detail?id=958 parameterizableClass <MSEProperty: #parameterizableClass type: #FAMIXParameterizableClass> <MSEComment: 'Base type of this parameterized type.'> ^self privateState attributeAt: #parameterizableClass ifAbsent: [nil] We should get an opposite to a newly created FAMIXParameterizableClass>>#parameterizedTypes -- 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

Issue 959 in moose-technology: clientClasses and providerClasses should be renamed to clientTypes and providerTypes

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Famix Milestone-4.8 New issue 959 by tu...(a)tudorgirba.com: clientClasses and providerClasses should be renamed to clientTypes and providerTypes http://code.google.com/p/moose-technology/issues/detail?id=959 These methods actually return types, like for example in: clientClasses <MSEProperty: #clientClasses type: #FAMIXType> <multivalued> <derived> <MSEComment: 'returns a set of all the classes that depend on the receiver'> ^ self queryAllIncomingAssociations atTypeScope withoutSelfLoops Thus, we should deprecate clientClasses and renamed it to clientTypes -- 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

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/760/> ------------------------------------------ Started by timer Started by upstream project "fame" build number 130 originally caused by: Started by timer Started by upstream project "gtoolkit" build number 202 originally caused by: Started by timer 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/hudson457599445756841378.sh + wget --quiet -O - http://get.pharo.org/20+vm + 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/stable.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 Please install the 32bit libraries sudo aptitude install ia32-libs + ./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 [31m==== Startup Error: ConnectionTimedOut: Data receive timed out. [0mSocket>>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: ZnClient>>executeRequestResponse ZnClient>>getConnectionAndExecute in Block: [self executeRequestResponse] BlockClosure>>ensure: ZnClient>>getConnectionAndExecute ZnClient>>executeWithRedirectsRemaining: ZnClient>>executeWithRetriesRemaining: in Block: [self executeWithRedirectsRemaining: self maxNumbe...etc... BlockClosure>>on:do: ZnClient>>executeWithRetriesRemaining: 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>>connectTo:port:waitForConnectionFor: in Block: [ConnectionTimedOut signal: 'Cannot connect to '... [0m[31mGot startup errors: [0m[31m ConnectionTimedOut: Data receive timed out. [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

11 years, 11 months

1
1
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/758/> ------------------------------------------ Started by upstream project "glamour" build number 202 originally caused by: Started by timer Started by upstream project "petitjava" build number 150 originally caused by: Started by timer Started by upstream project "petitparser" build number 147 originally caused by: Started by timer Started by upstream project "roassal" build number 346 originally caused by: Started by timer Building remotely on moose-slave 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/hudson2810844350764825185.sh + bash + wget --quiet -O - http://get.pharo.org/20+vm 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/stable.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 Please install the 32bit libraries sudo aptitude install ia32-libs + ./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 resolve: Collections-Support [Collections-Support] in <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/package-cache> http://smalltalkhub.com/mc/Pharo/XMLWriter/main ERROR: 'GoferRepositoryError: Could not access http://ss3.gemtalksystems.com/ss/Pharo20: ZnHttpUnsuccessful: 500 Internal Server Error' [0mMetacelloFetchingMCSpecLoader(Object)>>error: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: in Block: [| references nearestReference cachedReference ext...etc... MetacelloPharoPlatform>>do:displaying: in Block: [:bar | ... BlockClosure>>cull: Job>>run in Block: [result := block cull: self] BlockClosure>>on:do: Job>>run in Block: [self prepareForRunning.... BlockClosure>>ensure: Job>>run NonInteractiveUIManager(UIManager)>>displayProgress:from:to:during: ByteString(String)>>displayProgressFrom:to:during: MetacelloPharoPlatform>>do:displaying: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: MetacelloPackageSpec>>loadUsing:gofer: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: in Block: [:pkg | pkg loadUsing: self gofer: gofer] OrderedCollection>>do: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpecs:repositories: in Block: [super linearLoadPackageSpecs: packageSpecs reposi...etc... BlockClosure>>ensure: MetacelloLoaderPolicy>>pushLoadDirective:during: MetacelloLoaderPolicy>>pushLinearLoadDirectivesDuring:for: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpecs:repositories: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>load MetacelloMCVersionSpecLoader>>load MetacelloMCVersion>>executeLoadFromArray: MetacelloMCVersion>>fetchRequiredFromArray: in Block: [:dict | ^ self executeLoadFromArray: anArray] MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in Block: [^ aBlock value: dict] BlockClosure>>on:do: MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: [0m[31mGot startup errors: [0m[31m Error: Could not resolve: Collections-Support [Collections-Support] in <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/package-cache> http://smalltalkhub.com/mc/Pharo/XMLWriter/main ERROR: 'GoferRepositoryError: Could not access http://ss3.gemtalksystems.com/ss/Pharo20: ZnHttpUnsuccessful: 500 Internal Server Error' [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

11 years, 11 months

1
1
0 0

Re: what about a mooseday at Lille in fall?

by Stephan Eggermont

Sounds like a good idea. Stephan

11 years, 11 months

3
2
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/751/> ------------------------------------------ [...truncated 520 lines...] bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: @ @ basicNew truncated truncated @ truncated truncated @ basicNew @ @ basicNew @ @ basicNew @ @ @ perform:with: @ @ perform:with: @ basicNew @ @ basicNew basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: basicAt: bitShiftMagnitude: basicAt: bitAnd: bitShiftMagnitude: basicAt: + bitOr: digitCompare: bitShiftMagnitude: perform:with: @ @ basicNew truncated truncated @ truncated truncated @ basicNew @ @ basicNew @ @ basicNew @ @ basicNew class basicNew @ basicNew basicNew: stack page bytes 4096 available headroom 3300 minimum unused headroom 3476 (last object overwritten) ./pharo: line 11: 14073 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" -nodisplay "$@" Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed: <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> at hudson.remoting.Channel@2f17e8fb:moose-ubuntu1204-dualproc-i386 at hudson.FilePath.act(FilePath.java:848) at hudson.FilePath.act(FilePath.java:825) at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:87) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:785) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:732) at hudson.model.Run.execute(Run.java:1568) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.util.IOException2: Failed to read <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Mondrian-Tests-Test.x…> at hudson.tasks.junit.TestResult.parse(TestResult.java:244) at hudson.tasks.junit.TestResult.parse(TestResult.java:163) at hudson.tasks.junit.TestResult.parse(TestResult.java:140) at hudson.tasks.junit.TestResult.<init>(TestResult.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:117) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:90) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.dom4j.DocumentException: Error on line 581 of document file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Mondrian-Tests-Test.x…> : XML document structures must start and end within the same entity. Nested exception: XML document structures must start and end within the same entity. at org.dom4j.io.SAXReader.read(SAXReader.java:482) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:129) at hudson.tasks.junit.TestResult.parse(TestResult.java:227) ... 15 more Caused by: org.xml.sax.SAXParseException; systemId: file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Mondrian-Tests-Test.x…;> lineNumber: 581; columnNumber: 1; XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:391) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1404) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.endEntity(XMLDocumentFragmentScannerImpl.java:882) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:582) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1370) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1740) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipChar(XMLEntityScanner.java:1393) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2769) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525) at org.dom4j.io.SAXReader.read(SAXReader.java:465) ... 18 more

11 years, 11 months

1
1
0 0

Re: [Pharo-users] Re: [ann] snapshotcello

by Tudor Girba

Hi, On Jul 23, 2013, at 11:51 PM, "Dale K. Henrichs" <dale.henrichs(a)gemtalksystems.com> wrote: > Stef, > > I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). What is not clear? I would be interested in describing our scenario in more details because I think this is a development pattern. But, I need some concrete questions to start from. > However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. I still do not understand why Versionner would be affected by the current versions given that we are only generating versions that should be immutable hence no need for management. > With that said it _is_ performing a useful function ... > > I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... Having a different way to store the information should be no problem. I am curious about your ideas. Cheers, Doru > Dale > > [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html > ----- Original Message ----- > | From: "Stéphane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> > | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" > | <pharo-dev(a)lists.pharo.org> > | Sent: Tuesday, July 23, 2013 2:17:50 PM > | Subject: [Moose-dev] Re: [ann] snapshotcello > | > | Nice to see SnapshotCello coming to live. May be it should be > | integrated to Metacello. > | Because everybody may need this cool feature. > | > | Stef > | > | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> > | wrote: > | > | > Hi, > | > > | > Stef and I developed Snapshotcello, a little utility that enables > | > you to freeze a snapshot of a given configuration based on what is > | > already loaded in your current image. > | > > | > The idea is simple. You develop against the latest versions of all > | > packages, and commit your changes for each package. When you are > | > ready for a release, you assemble your image, and generate a > | > snapshot version that can be reloaded later. > | > > | > Here is an example of how it can work to take a snapshot of a > | > development version: > | > Snapshotcello new > | > configurationClass: ConfigurationOfMoose; > | > configurationVersion: #development; > | > publishVersion: '4.8-snapshot' > | > > | > You can find more details here: > | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… > | > > | > You can get the code at: > | > Gofer new > | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; > | > package: 'ConfigurationOfSnapshotcello'; > | > load. > | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) > | > loadDevelopment > | > > | > Cheers, > | > Doru > | > > | > -- > | > www.tudorgirba.com > | > > | > "Every successful trip needs a suitable vehicle." > | > > | > > | > > | > > | > > | > _______________________________________________ > | > Moose-dev mailing list > | > Moose-dev(a)iam.unibe.ch > | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > | > | > | _______________________________________________ > | Moose-dev mailing list > | Moose-dev(a)iam.unibe.ch > | https://www.iam.unibe.ch/mailman/listinfo/moose-dev > | > -- www.tudorgirba.com "Live like you mean it."

11 years, 11 months

2
1
0 0

Re: [Pharo-dev] Re: [ann] snapshotcello

by Stéphane Ducasse

On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > Stef, > > I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). > > However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the existing configuration trees but this requires some work. > > With that said it _is_ performing a useful function ... > > I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... > > Dale > > [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html > ----- Original Message ----- > | From: "Stéphane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Moose-related development" <moose-dev(a)iam.unibe.ch> > | Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" > | <pharo-dev(a)lists.pharo.org> > | Sent: Tuesday, July 23, 2013 2:17:50 PM > | Subject: [Moose-dev] Re: [ann] snapshotcello > | > | Nice to see SnapshotCello coming to live. May be it should be > | integrated to Metacello. > | Because everybody may need this cool feature. > | > | Stef > | > | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor(a)tudorgirba.com> > | wrote: > | > | > Hi, > | > > | > Stef and I developed Snapshotcello, a little utility that enables > | > you to freeze a snapshot of a given configuration based on what is > | > already loaded in your current image. > | > > | > The idea is simple. You develop against the latest versions of all > | > packages, and commit your changes for each package. When you are > | > ready for a release, you assemble your image, and generate a > | > snapshot version that can be reloaded later. > | > > | > Here is an example of how it can work to take a snapshot of a > | > development version: > | > Snapshotcello new > | > configurationClass: ConfigurationOfMoose; > | > configurationVersion: #development; > | > publishVersion: '4.8-snapshot' > | > > | > You can find more details here: > | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… > | > > | > You can get the code at: > | > Gofer new > | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; > | > package: 'ConfigurationOfSnapshotcello'; > | > load. > | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) > | > loadDevelopment > | > > | > Cheers, > | > Doru > | > > | > -- > | > www.tudorgirba.com > | > > | > "Every successful trip needs a suitable vehicle." > | > > | > > | > > | > > | > > | > _______________________________________________ > | > Moose-dev mailing list > | > Moose-dev(a)iam.unibe.ch > | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > | > | > | _______________________________________________ > | Moose-dev mailing list > | Moose-dev(a)iam.unibe.ch > | https://www.iam.unibe.ch/mailman/listinfo/moose-dev > | >

11 years, 11 months

3
4
0 0

Is the Moose Book available as PDF?

by MartinW

Hi, is there a way to get the Moose Book as a PDF? That would be very handy. M. -- View this message in context: http://forum.world.st/Is-the-Moose-Book-available-as-PDF-tp4700309.html Sent from the Moose mailing list archive at Nabble.com.

11 years, 11 months

3
2
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/747/> ------------------------------------------ [...truncated 545 lines...] perform:with: @ basicNew class copyBits basicNew new: shallowCopy shallowCopy shallowCopy shallowCopy basicNew new: @ @ basicNew @ shallowCopy basicNew @ @ basicNew @ @ basicNew basicNew @ @ basicNew perform:with: perform:with: @ basicNew class stringHash:initialHash: class stringHash:initialHash: basicNew at:put: basicNew class stringHash:initialHash: class class class class class stringHash:initialHash: class class class class basicNew at:put: basicNew class stringHash:initialHash: class class class class class class class stringHash:initialHash: class class class class class class basicNew at:put: new: class stringHash:initialHash: at:put: class stringHash:initialHash: at:put: class stringHash:initialHash: at:put: class stringHash:initialHash: at:put: class stringHash:initialHash: class class at:put: basicNew class stringHash:initialHash: class stringHash:initialHash: basicNew at:put: @ @ basicNew class copyBits @ perform:with: @ @ perform:with: @ basicNew class copyBits basicNew new: shallowCopy shallowCopy shallowCopy shallowCopy basicNew new: @ @ basicNew @ shallowCopy basicNew @ @ basicNew @ @ basicNew basicNew @ @ basicNew perform:with: perform:with: @ basicNew class stringHash:initialHash: class stringHash:initialHash: basicNew at:put: basicNew class stringHash:initialHash: class class class class class stringHash:initialHash: class class class class basicNew at:put: basicNew class stringHash:initialHash: class class class class class class class stringHash:initialHash: class class class class class class basicNew at:put: new: stack page bytes 4096 available headroom 3300 minimum unused headroom 3464 (last object overwritten) ./pharo: line 11: 12978 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" -nodisplay "$@" Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed: <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> at hudson.remoting.Channel@2f17e8fb:moose-ubuntu1204-dualproc-i386 at hudson.FilePath.act(FilePath.java:848) at hudson.FilePath.act(FilePath.java:825) at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:87) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:785) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:732) at hudson.model.Run.execute(Run.java:1568) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.util.IOException2: Failed to read <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Mondrian-Tests-Test.x…> at hudson.tasks.junit.TestResult.parse(TestResult.java:244) at hudson.tasks.junit.TestResult.parse(TestResult.java:163) at hudson.tasks.junit.TestResult.parse(TestResult.java:140) at hudson.tasks.junit.TestResult.<init>(TestResult.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:117) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:90) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.dom4j.DocumentException: Error on line 485 of document file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Mondrian-Tests-Test.x…> : XML document structures must start and end within the same entity. Nested exception: XML document structures must start and end within the same entity. at org.dom4j.io.SAXReader.read(SAXReader.java:482) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:129) at hudson.tasks.junit.TestResult.parse(TestResult.java:227) ... 15 more Caused by: org.xml.sax.SAXParseException; systemId: file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Mondrian-Tests-Test.x…;> lineNumber: 485; columnNumber: 1; XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:391) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1404) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.endEntity(XMLDocumentFragmentScannerImpl.java:882) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:582) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1370) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1740) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipChar(XMLEntityScanner.java:1393) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2769) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525) at org.dom4j.io.SAXReader.read(SAXReader.java:465) ... 18 more

11 years, 11 months

1
1
0 0

[ann] snapshotcello

by Tudor Girba

Hi, Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image. The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later. Here is an example of how it can work to take a snapshot of a development version: Snapshotcello new configurationClass: ConfigurationOfMoose; configurationVersion: #development; publishVersion: '4.8-snapshot' You can find more details here: http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment Cheers, Doru -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

11 years, 11 months

2
1
0 0

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

by admin＠moosetechnology.org

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

11 years, 11 months

1
2
0 0

Jenkins build is back to stable : moose-latest-dev-4.8 #728

by admin＠moosetechnology.org

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

11 years, 11 months

2
1
0 0

roassal is failing

by Tudor Girba

https://ci.inria.fr/moose/job/roassal/ Doru -- www.tudorgirba.com "Every thing has its own flow"

11 years, 11 months

3
6
0 0

ROAddName label string

by Usman Bhatti

Hello, ROAddName in Roassal allows dynamically adding labels on mouse hover (See example ROMondrianViewBuilder>>addingNameOn:). Is it possible that a selector be provided to the class instead of doing a printString to compute the label for the element being hovered on. tx, Usman

11 years, 11 months

2
2
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/722/> ------------------------------------------ Started by upstream project "petitjava" build number 130 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/hudson1537883375513150841.sh + wget --quiet -O - http://get.pharo.org/20+vm + 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/stable.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 Please install the 32bit libraries sudo aptitude install ia32-libs + ./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 PetitMSE-AndreHora.21.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 PetitMSE-AndreHora.21.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

moose on web job is failing

by Tudor Girba

Hi, Please take a look at it: https://ci.inria.fr/moose/job/Moose-On-The-Web/ Cheers, Doru -- www.tudorgirba.com "Value is always contextual."

11 years, 11 months

2
1
0 0

Issue 957 in moose-technology: Finder has an ugly white background

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Glamour New issue 957 by tu...(a)tudorgirba.com: Finder has an ugly white background http://code.google.com/p/moose-technology/issues/detail?id=957 Just do: | finder | finder := GLMFinder new. finder with: [:f | f showFirst: [:a | a list]; show: [:a | a list display: [:x | 1 to: x] ]]. finder openOn: (1 to: 42). And you will notice that as you scroll, the space between the finder panes is white instead of transparent. -- 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
0
0 0

online code review

by Alexandre Bergel

Hi! Just in case you haven't heard about it: https://codeclimate.com It may interest the MooseOnTheWeb crew Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

11 years, 11 months

1
0
0 0

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

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/715/> ------------------------------------------ Started by upstream project "petitjava" build number 121 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/hudson6861657170500421976.sh + + bash wget --quiet -O - http://get.pharo.org/20+vm 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/stable.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 Please install the 32bit libraries sudo aptitude install ia32-libs + ./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 + ./pharo moose-latest-dev-4.8.image moosetest --junit-xml-output [31m[33m =============================================================================== Notice: Running tests in 136 Packages =============================================================================== [0m[0m[31mError: index out of range [0mTabSelectorMorph(Object)>>error: TabSelectorMorph(Morph)>>privateAddAllMorphs:atIndex: TabSelectorMorph(Morph)>>addAllMorphs: TabSelectorMorph>>updateTabs TabSelectorMorph>>extent: TabSelectorMorph(Morph)>>bounds: TabSelectorMorph(Morph)>>layoutInBounds: TableLayout>>layoutLeftToRight:in: TableLayout>>layout:in: PanelMorph(Morph)>>doLayoutIn: PanelMorph(Morph)>>fullBounds in Block: [self doLayoutIn: self layoutBounds] BlockClosure>>on:do: PanelMorph(Morph)>>fullBounds LazyTabGroupMorph(Morph)>>submorphBounds in Block: [:m | | subBox | m visible... Array(SequenceableCollection)>>do: LazyTabGroupMorph(Morph)>>submorphBounds LazyTabGroupMorph(Morph)>>privateFullBounds LazyTabGroupMorph(Morph)>>doLayoutIn: LazyTabGroupMorph(Morph)>>fullBounds in Block: [self doLayoutIn: self layoutBounds] BlockClosure>>on:do: LazyTabGroupMorph(Morph)>>fullBounds LazyTabGroupMorph(Morph)>>layoutProportionallyIn: ProportionalLayout>>layout:in: in Block: [:m | m layoutProportionallyIn: newBounds] Array(SequenceableCollection)>>do: PanelMorph(Morph)>>submorphsDo: ProportionalLayout>>layout:in: PanelMorph(Morph)>>doLayoutIn: PanelMorph(Morph)>>fullBounds in Block: [self doLayoutIn: self layoutBounds] BlockClosure>>on:do: PanelMorph(Morph)>>fullBounds [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed: <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/> at hudson.remoting.Channel@2f17e8fb:moose-ubuntu1204-dualproc-i386 at hudson.FilePath.act(FilePath.java:848) at hudson.FilePath.act(FilePath.java:825) at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:87) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:122) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:134) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:785) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:732) at hudson.model.Run.execute(Run.java:1568) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.util.IOException2: Failed to read <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Glamour-Tests-Morphic…> at hudson.tasks.junit.TestResult.parse(TestResult.java:244) at hudson.tasks.junit.TestResult.parse(TestResult.java:163) at hudson.tasks.junit.TestResult.parse(TestResult.java:140) at hudson.tasks.junit.TestResult.<init>(TestResult.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:117) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:90) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.dom4j.DocumentException: Error on line 111 of document file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Glamour-Tests-Morphic…> : XML document structures must start and end within the same entity. Nested exception: XML document structures must start and end within the same entity. at org.dom4j.io.SAXReader.read(SAXReader.java:482) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:129) at hudson.tasks.junit.TestResult.parse(TestResult.java:227) ... 15 more Caused by: org.xml.sax.SAXParseException; systemId: file://<https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/Glamour-Tests-Morphic…;> lineNumber: 111; columnNumber: 1; XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:391) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1404) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.endEntity(XMLDocumentFragmentScannerImpl.java:882) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:582) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1370) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1740) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipChar(XMLEntityScanner.java:1393) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2769) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525) at org.dom4j.io.SAXReader.read(SAXReader.java:465) ... 18 more

11 years, 11 months

1
0
0 0

Re: Rubric test failures

by Tudor Girba

Hi, In the meantime, I added a utility method in GLMRubricTextMorphicTest: simulateOnlyOneClickOn: aMorph (Delay forMilliseconds: HandMorph doubleClickTime + 1) wait. aMorph simulateClick We should integrate this utility in Pharo 3.0. All tests are green locally. Let's see how it goes on the server. Cheers, Doru On Jul 15, 2013, at 8:57 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > This sounds good. I would call the block method as ignoreMultipleClicksWhile:. > > Doru > > > On Mon, Jul 15, 2013 at 8:43 AM, Alain Plantec <alain.plantec(a)univ-brest.fr> wrote: > maybe another solution would be to unplug the hand mouseclickstate before sending the event and to replug it after. > something like: > > -------- > simulateClick > self activeHand forbidMultipleClickWhile: [ > self simulateClickWith: MouseEvent redButton] > -------- > it would be much more efficient. > I will make a try. > Alain > > > Le 14 juil. 2013 à 21:26, Alain Plantec <alain.plantec(a)univ-brest.fr> a écrit : > > > yep, caught. > > and finally it is funny :) > > > > It has something to do with #simulateClick. > > In Rubric, MouseClickState is used to have a real doubleClick (whereas in TextMorph, the editor handle click/doubleClick by itself and not with MouseClickState). > > Mouse clickState mesures the time between two MouseDown and decide for a simple click if the time is > than HandMorph doubleClickTime. > > When several tests with simulateClick are runned, then depending on the state of the hand MouseClickState, a simple click or a double click are triggered. > > So it explains why when you run several tests some of then are failing. > > But when you run a single test with a single simultateClick, then it doesn't fail. > > > > the lesson is that mouseClickState should not be shared (instance var of the HandMorph). > > or it should test the target morph and not only the time. > > > > > > the workarround is to wait before any simulateClick, I've tried and it works. > > change the simulateClick method as follow and all your Rubric related tests should be green again. > > -------- > > simulateClick > > (Delay forMilliseconds: HandMorph doubleClickTime + 1) wait. > > self simulateClickWith: MouseEvent redButton. > > -------- > > > > Cheers > > Alain > > > > > > Le 13 juil. 2013 à 17:26, Tudor Girba <tudor(a)tudorgirba.com> a écrit : > > > >> Wow, thank you very much for looking into this. > >> > >> Doru > >> > >> > >> On Jul 13, 2013, at 3:14 PM, Alain Plantec <alain.plantec(a)univ-brest.fr> wrote: > >> > >>> ok, I 've a track > >>> With rubric, if a textArea do not have the focus but has a selection, then the first click on it give it the focus but don't deselect. > >>> In that case, one have to click to times to have the old TextMorph behavior. > >>> So, depending on the goal of the test, one have to send simulateClick one time or two times and not alway only one time. > >>> I will dig more to really understand. > >>> > >>> > >>> Le 13 juil. 2013 à 10:11, Alain Plantec <alain.plantec(a)univ-brest.fr> a écrit : > >>> > >>>> and if one add a #inspect send in a testMethod, the results are the same with the TestRunner but differ > >>>> if one run them from Nautilus. > >>>> As an example, with: > >>>> ----- > >>>> testEnteringTextInPort > >>>> | composite textMorph | > >>>> composite := GLMCompositePresentation new with: [ :a | a rubricText display: '' ]. > >>>> window := composite openOn: 4. > >>>> textMorph := self find: RubScrolledTextMorph in: window. > >>>> textMorph simulateClick. > >>>> self assert: textMorph activeHand keyboardFocus = textMorph textArea. > >>>> self simulateKeyStrokes: 'hello'. > >>>> (composite pane port: #text) value asString inspect. <-------------------------------- ** inspect added here ** > >>>> self assert: (composite pane port: #text) value asString = 'hello' > >>>> ---- > >>>> by running tests from Nautilus, the inspect runs ok and the result string is 'hello'. > >>>> but now #testAcceptKeyCanBeOverriden turns yellow > >>>> > >>>> by running test from the TestRunner, #testEnteringTextInPort and #testPastingUpdatesTextPort stay yellow (as without the inspect) > >>>> and #testAcceptKeyCanBeOverriden is green > >>>> > >>>> Alain > >>>> > >>>> > >>>> Le 2 juil. 2013 à 12:49, Tudor Girba <tudor(a)tudorgirba.com> a écrit : > >>>> > >>>>> Thanks. I got the same problem and I do not know where to start from. It's really strange. > >>>>> > >>>>> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run all of them repeatedly, you get some errors. If you run them individually, you do not. > >>>>> > >>>>> Alain: do you happen to have an insight? > >>>>> > >>>>> Doru > >>>>> > >>>>> > >>>>> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >>>>> Hi guys. > >>>>> > >>>>> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing tests and the only one is Rubric test. I was working with it for some time, and I have no idea what's up. When you run tests separately they work fine, but when being run in a suite some test fail and failures are inflicted by test order > >>>>> > >>>>> Maybe someone have ideas where to look at? UI maybe? > >>>>> > >>>>> Uko > >>>>> _______________________________________________ > >>>>> Moose-dev mailing list > >>>>> Moose-dev(a)iam.unibe.ch > >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> www.tudorgirba.com > >>>>> > >>>>> "Every thing has its own flow" > >>>> > >>>> > >>> > >> > >> -- > >> www.tudorgirba.com > >> > >> "If you interrupt the barber while he is cutting your hair, > >> you will end up with a messy haircut." > >> > >> > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

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