Chris wrote:
>Interestingly, Stephan has commented most of the other nodes - thanks!
Can't claim that. We tried merging with the last version and had conflicts.
We then used an earlier version that merged. Good to see it working though.
I noticed you're committing as both cbc and ChrisCunningham?
Seems to confuse smalltalkhub (it can't find user ChrisCunningham).
Stephan
Hi All,
it has been a while for me, so apologies in advance if this is known/stupid/...
I have not worked on at AspectMaps in a looooong time, and now I am assessing (heh) the effort of getting it up to date to the latest version of Moose. (Last working version is for 4.3) It has been going reasonably well, but now I have encountered something in the custom importer that has me stumped. Any pointers on how to resolve this would be most helpful.
FAMIXStructuralEntity>>declaredType: throws a DNU because it ends up sending #structuresWithDeclaredType to the ByteString 'method' when executing FMMultiValueLink class>>on: update: from: to: The only guys that understand that messages are FAMIXType instances. This is weird to me because there is no obvious relation between 'method' and any FAMIXType instances.
Can anybody point me to a solution?
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile
Hi,
I want to share with you a screenshot of the first version of the web client
for the Moose On Web Project.
It's based on Amber and use a Rest Api to interact with the Moose image.
A demo version will be online next week !
Cheers,
Vincent
Hi,
The Moose builds got messy:
- there are extensions that do not load
- there are tests that fail
https://ci.inria.fr/moose/
Please let us stop for a moment and clean the mess. It's a question of
hygiene.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
ConfigurationOfGToolkit wants to load some extensions to EyeContextInspector.
But, where is this class coming from?
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
I noticed that both ConfigurationOfPetitParser and ConfigurationOfGToolkit
are loading only the Core and Morphic groups from Glamour.
However, the code inside depends on visualizations, too, and thus, it needs
at least Roassal. So, now I added a Roassal group explicitly in the
ConfigurationOfGlamour and had the two other configurations load the
Roassal group as well.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/593/>
------------------------------------------
[...truncated 1192 lines...]
@
@
basicNew
truncated
class
@
fractionPart
truncated
@
@
@
@
basicNew
@
@
basicNew
perform:with:
perform:with:
@
@
@
basicNew
truncated
@
@
@
@
fractionPart
truncated
fractionPart
truncated
@
@
@
species
species
basicAt:
basicAt:
bitShiftMagnitude:
basicAt:
bitOr:
digitCompare:
bitShiftMagnitude:
perform:with:
class
perform:with:
fractionPart
truncated
perform:with:
@
@
basicNew
@
@
basicNew
perform:with:
perform:with:
@
@
@
basicNew
truncated
@
@
@
@
fractionPart
truncated
fractionPart
truncated
@
@
basicNew:
replaceFrom:to:with:startingAt:
at:put:
class
stringHash:initialHash:
class
class
compare:with:collated:
perform:with:
@
perform:with:
@
@
perform:with:
@
basicNew
@
@
@
perform:with:
@
@
perform:with:
@
basicNew
@
shallowCopy
shallowCopy
shallowCopy
@
@
new:
at:put:
at:put:
at:put:
at:put:
species
new:
@
at:put:
@
at:put:
@
at:put:
@
at:put:
@
@
@
@
@
@
basicNew
@
perform:with:
@
@
perform:with:
@
basicNew
@
@
basicNew
@
@
basicNew
@
perform:with:
@
@
perform:with:
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
@
@
basicNew
compare:with:collated:
new:
at:put:
at:put:
perform:with:
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
stack page bytes 4096 available headroom 3300 minimum unused headroom 3480
(last object overwritten)
./pharo: line 11: 10265 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 471 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: 471; 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
Currently, we have a bug in the latest version of Pharo VM that does not
allow a build to complete (Esteban is working to correct it) As the builds
in Moose jenkins depend on the latest version of Pharo VM, we were unable
to perform any build since 10 days (that also includes INRIA downtime). But
the question is:
Should Moose and other builds in the moose jenkins depend on the latest VM?
Or we should depend on the stable version of the VM?
Now, stable version is good but we dont have many bug fixes that are
integrated in the latest version. For example, most of the builds in the
jenkins are now unstable and I suspect that's being caused by the fact that
we are now depending on the stable Pharo VM. I cannot verify it since the
latest VM is buggy.
Can you please see your respective builds and see why is jenkins becoming
unstable?
usman