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
hi!
I think your loading script should instead be:
Gofer new smalltalkhubUser: 'DanielAvivNotario'
project: 'Graph-ET';
package: 'Graph-ET'; load
I was able to use Graph-ET in a Roassal easel. Cool! I think we should _always_ be able to do so.
Here is a script:
-=-=--=-=--=-=--=-=-
view interaction popupView: [ :el :v |
v shape rectangle.
v node: 'node' forIt: [
| diag |
diag := GETVerticalBarDiagram new.
diag
models: ((el methods collect: #numberOfLinesOfCode) asSortedCollection);
height: 50;
spacing: 2.
diag generateIn: v raw.
] ].
view shape rectangle size: #numberOfMethods.
view nodes: ROShape withAllSubclasses.
view edgesFrom: #superclass.
view treeLayout.
-=-=--=-=--=-=--=-=-
Aqui un screenshot de un popup view:
Cheers,
Alexandre
On Jun 3, 2013, at 11:20 PM, Daniel Aviv Notario <daniel_avivnotario(a)hotmail.com> wrote:
> Hi Doru!
>
> I send you this email to inform you of the stage of development in Graph-ET.
>
> I recently added all the interactions in EyeSee (pop-ups and hightlights) using Roassal's events and interactions. Because of the implementation in Graph-ET, I had to use a wrapper to make the syntax in EyeSee work, I tested them only in the bar chart so far.
>
> This week I'll work on adding the coloring to the bar charts. And maybe trying to understand and implement a little bit of the Axis and AxisStrategy hierarchy, as they represent most of the classes in EyeSee. Once coloring and axis are implemeted and tested on the bar charts, i'll port the other charts.
>
> Here's my Gofer to Graph-ET:
>
> Gofer new
> smalltalkhubUser: ‘DanielAvivNotario’
> project: ‘Graph-ET’
> package: ‘Graph-ET’.
>
> Remember to upload first the last version of Roassal, as Alex made some changes that affect my code directly.
>
>
> Hope you're doing great! Greetings,
>
> Daniel :-)
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Yuriy,
Ok, I'm not in a hurry. Please note that your latest version is out of sync
since PetitJava-MartinDias.104, and there are lots of versions to merge
by cbc & ChrisCunningham. Automerge fails.
Stephan
Hi
I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu.
Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal.
Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be
a solution at its architectural level to have one library for Athens and one for the rest.
In addition I do not understand how Roassal can work fast on amber while using Athens without again using the
athens infrastructure.
So I would like to know.
Stef
