February 2016 - Pharo-users

A new idea for a project: WarpSpeed (a C inliner)

by Dimitris Chloupis

So now that AsmJit is gone , I had a new idea for a project and I wanted your opinion on this if you think it will be useful for the community, I call it WarpSpeed. I was thinking it would still be cool to have some kind of library that will help us boost the speed of pharo . So I was thinking about a C inliner which is far easier than an Assembly inliner (see AsmJIT) I also found TinyC http://bellard.org/tcc/ which is as you guessed a tiny c compiler 100kbs in size which i can include with a pharo image to allow me to dynamically compile inlined C code inside the pharo image so even pharo users without a C compiler installed can benefit from it . That means that if something does not perform as fast as you want you could mix C code with pharo code , I am thinking passing the C source code as a string or even having the C code in a separate file, and then dynamically call the TinyC compiler, compile it to shared library and load if via UFFI back to pharo. TinyC is very fast so compilation of the code should be as fast if not faster than compiling pharo code. Looks easy enough to do for a small project by me with the condition there are people really interested into something like this. TinyC is licensed as LGPL but I can make it fall back to other compilers as well if ones want to close the source. How it sounds as an idea ?

Feb. 26, 2016

Re: [Pharo-users] CrashDetector made for sprint

by Blondeau Vincent

Nice! I am eager to see it with a better change set manager, i.e. Epicea ;) Your tool works nicely when you save and close the image properly. However, when you close directly the program by clicking on the cross (which is easier than going into the world menu after a CTRL+SHIFT+S), the image doesn't crashes, but you get a message to retrieve your changes. I think that managing this case is harder because you have to interact with the vm, haven't you? Cheers, Vincent > -----Message d'origine----- > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de > Thibault Raffaillac > EnvoyÃ© : vendredi 26 fÃ©vrier 2016 17:40 > Ã : pharo-users(a)lists.pharo.org > Objet : [Pharo-users] CrashDetector made for sprint > > Dear Pharo users, > > We made a short script with Guille during the Pharo sprint to detect at > startup when image crashed, and propose to open changes browser to > recover lost changes. It should be useful for beginners who do not know of > the Changes Browser. > > It should be available tomorrow on Catalog browser, otherwise run: > Gofer it > smalltalkhubUser: 'ThibaultRaffaillac' project: 'CrashDetector'; > configurationOf: 'CrashDetector'; > loadStable > > Patches and comments welcome :) > Thibault !!!************************************************************************************* "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

Feb. 26, 2016

CrashDetector made for sprint

by Thibault Raffaillac

Dear Pharo users, We made a short script with Guille during the Pharo sprint to detect at startup when image crashed, and propose to open changes browser to recover lost changes. It should be useful for beginners who do not know of the Changes Browser. It should be available tomorrow on Catalog browser, otherwise run: Gofer it smalltalkhubUser: 'ThibaultRaffaillac' project: 'CrashDetector'; configurationOf: 'CrashDetector'; loadStable Patches and comments welcome :) Thibault

Feb. 26, 2016

Re: [Pharo-users] Pb with the CI @ INRIA?

by Alexandre Bergel

How that could beâ¦ All the tests are okay on my machine Alexandre > On Feb 26, 2016, at 4:03 PM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > For this job, the image crashes because of an OutOfMemory as you can check here: https://ci.inria.fr/moose/job/roassal2/2253/console > > Le 26 fÃ©vr. 2016 Ã 16:01, Christophe Demarey a Ã©crit : > >> Thanks for the link. >> >> The ugly java stack trace is because the junit result publisher jenkins plugin tries to parse a file that is not well generated. >> It happens when the image crashes during tests: the xml output does not contain end tags. >> As Aliaksei sait, probably dut to the cairo lib missing. I will check. >> >> >> Le 26 fÃ©vr. 2016 Ã 15:14, Aliaksei Syrel a Ã©crit : >> >>> It is because image crashed without saving logs. More likely slave used to build has no cairo installed. >>> >>> Cheers, >>> Alex >>> >>> On Fri, Feb 26, 2016 at 2:47 PM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >>> Hi Alex, >>> >>> Could you provide the link to the job providing this output? >>> >>> Le 26 fÃ©vr. 2016 Ã 09:57, Alexandre Bergel a Ã©crit : >>> >>> > Hi! >>> > >>> > We regularly get this error: >>> > >>> > Failed to read test report file /builds/workspace/roassal2/Roassal2GT-Test.xml >>> > org.dom4j.DocumentException: Error on line 27 of document file:///builds/workspace/roassal2/Roassal2GT-Test.xml : 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:123) >>> > at hudson.tasks.junit.TestResult.parse(TestResult.java:286) >>> > at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:232) >>> > at hudson.tasks.junit.TestResult.parse(TestResult.java:167) >>> > at hudson.tasks.junit.TestResult.parse(TestResult.java:150) >>> > at hudson.tasks.junit.TestResult.<init>(TestResult.java:126) >>> > at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:132) >>> > at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:107) >>> > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2691) >>> > at hudson.remoting.UserRequest.perform(UserRequest.java:120) >>> > at hudson.remoting.UserRequest.perform(UserRequest.java:48) >>> > at hudson.remoting.Request$2.run(Request.java:326) >>> > >>> > Any idea why? >>> > >>> > Alexandre >>> > -- >>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> > Alexandre Bergel http://www.bergel.eu >>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> > >>> > >>> > >>> > >>> >>> >>> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 26, 2016

Re: [Pharo-users] CDB project

by Damien Cassou

Nicolas Berveglieri <nicolas.berve(a)gmail.com> writes: > Also we're looking for some help about file reading with pharo. We couldn't > find sufficient info about it on the web, if anyone has a link to share we > would be gratefull. the Pharo Mooc contains a few slides about that: https://ci.inria.fr/pharo-contribution/job/PharoMooc/lastSuccessfulBuild/ar… -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Feb. 26, 2016

Re: [Pharo-users] Pb with the CI @ INRIA?

by Christophe Demarey

For this job, the image crashes because of an OutOfMemory as you can check here: https://ci.inria.fr/moose/job/roassal2/2253/console Le 26 fÃ©vr. 2016 Ã 16:01, Christophe Demarey a Ã©crit : > Thanks for the link. > > The ugly java stack trace is because the junit result publisher jenkins plugin tries to parse a file that is not well generated. > It happens when the image crashes during tests: the xml output does not contain end tags. > As Aliaksei sait, probably dut to the cairo lib missing. I will check. > > > Le 26 fÃ©vr. 2016 Ã 15:14, Aliaksei Syrel a Ã©crit : > >> It is because image crashed without saving logs. More likely slave used to build has no cairo installed. >> >> Cheers, >> Alex >> >> On Fri, Feb 26, 2016 at 2:47 PM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> Hi Alex, >> >> Could you provide the link to the job providing this output? >> >> Le 26 fÃ©vr. 2016 Ã 09:57, Alexandre Bergel a Ã©crit : >> >> > Hi! >> > >> > We regularly get this error: >> > >> > Failed to read test report file /builds/workspace/roassal2/Roassal2GT-Test.xml >> > org.dom4j.DocumentException: Error on line 27 of document file:///builds/workspace/roassal2/Roassal2GT-Test.xml : 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:123) >> > at hudson.tasks.junit.TestResult.parse(TestResult.java:286) >> > at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:232) >> > at hudson.tasks.junit.TestResult.parse(TestResult.java:167) >> > at hudson.tasks.junit.TestResult.parse(TestResult.java:150) >> > at hudson.tasks.junit.TestResult.<init>(TestResult.java:126) >> > at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:132) >> > at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:107) >> > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2691) >> > at hudson.remoting.UserRequest.perform(UserRequest.java:120) >> > at hudson.remoting.UserRequest.perform(UserRequest.java:48) >> > at hudson.remoting.Request$2.run(Request.java:326) >> > >> > Any idea why? >> > >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> >

Feb. 26, 2016

Re: [Pharo-users] Pb with the CI @ INRIA?

by Christophe Demarey

Thanks for the link. The ugly java stack trace is because the junit result publisher jenkins plugin tries to parse a file that is not well generated. It happens when the image crashes during tests: the xml output does not contain end tags. As Aliaksei sait, probably dut to the cairo lib missing. I will check. Le 26 fÃ©vr. 2016 Ã 15:14, Aliaksei Syrel a Ã©crit : > It is because image crashed without saving logs. More likely slave used to build has no cairo installed. > > Cheers, > Alex > > On Fri, Feb 26, 2016 at 2:47 PM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Hi Alex, > > Could you provide the link to the job providing this output? > > Le 26 fÃ©vr. 2016 Ã 09:57, Alexandre Bergel a Ã©crit : > > > Hi! > > > > We regularly get this error: > > > > Failed to read test report file /builds/workspace/roassal2/Roassal2GT-Test.xml > > org.dom4j.DocumentException: Error on line 27 of document file:///builds/workspace/roassal2/Roassal2GT-Test.xml : 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:123) > > at hudson.tasks.junit.TestResult.parse(TestResult.java:286) > > at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:232) > > at hudson.tasks.junit.TestResult.parse(TestResult.java:167) > > at hudson.tasks.junit.TestResult.parse(TestResult.java:150) > > at hudson.tasks.junit.TestResult.<init>(TestResult.java:126) > > at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:132) > > at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:107) > > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2691) > > at hudson.remoting.UserRequest.perform(UserRequest.java:120) > > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > > at hudson.remoting.Request$2.run(Request.java:326) > > > > Any idea why? > > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > >

Feb. 26, 2016

Re: [Pharo-users] [Moose-dev] Re: [Pharo-dev] Re: Call for action for Roassal

by Peter UhnÃ¡k

Hi Anne, I've just added a Roassal plugin with the GraphViz-based layout. Note that I had to hack it to work with RTMultiLine (it was originally designed for different lines which are currently not part of Roassal), so it's possible there will be some issues. You can load it (if you have latest Roassal installed) via the Roassal plugin menu, or by executing the following Metacello new baseline: 'GraphVizLayout'; repository: 'github://peteruhnak/graphviz-layout:master/repository'; load Then look at the class-side examples in RTGraphVizLayout. Finally if you use this, you shouldn't move elements within the layout (because graphviz layout hard-codes the pathing)â¦ we could probably change this in the future, but I am not sure how (ideally the layout would have to be recomputed, but that's expensive to do live), So to summarize: * you must have GraphViz installed in your system * you must use RTMultiLine for lines (because only they support bending) Let me know how it goes, â â Peter On Thu, Feb 25, 2016 at 2:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Oh, I missed this one :). So, now I can refactor the code that is still > using the RTEdge class side methods :). > > Great! > > Thanks, > Doru > > > > On Feb 25, 2016, at 1:59 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > > Oh, but this has been in Roassal for many months (I have implemented > since right after ESUG). You need to use #source:connectFrom:toAll: > > > > Here is an example that randomly generate a graph and render it using > this facility: > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > nbOfNodes := 40. > > nbOfRandomEdges := 40. > > > > nodes := 1 to: nbOfNodes. > > edges := (1 to: nbOfRandomEdges) > > collect: [ :notUsed | nodes atRandom -> > {nodes atRandom . nodes atRandom} ]. > > > > b := RTMondrian new. > > > > b shape circle color: (Color black alpha: 0.5). > > b nodes: nodes. > > > > b shape line color: (Color gray alpha: 0.3). > > b edges > > source: edges connectFrom: #key toAll: #value. > > > > b layout force. > > b > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > <Screen Shot 2016-02-25 at 1.57.24 PM.png> > > > > Cheers, > > Alexandre > > > >> On Feb 25, 2016, at 1:37 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Hi, > >> > >> We discussed this before. Try to draw a hierarchy using classes and > inheritance objects (so, without using the class to superclass navigation). > Something like this: > >> > >> view := RTMondrian new. > >> view nodes: classes. > >> view edges objects: inheritances; connectFrom: #superclass to: > #subclass. > >> view layout tree. > >> view > >> > >> It wonât work. > >> > >> Cheers, > >> Doru > >> > >> > >>> On Feb 25, 2016, at 1:29 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >>> > >>> Do you have an example? I am not sure to understand. > >>> > >>> Alexandre > >>> > >>> > >>>> On Feb 25, 2016, at 12:40 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>>> > >>>> This is very cool. We will all benefit from this documentation. > >>>> > >>>> One thing that I would still like to see fixed before the release is > the edge building (this problem of not being able to properly specify > random objects to be taken into account when building edges). Could we work > on that? > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>>>> On Feb 24, 2016, at 9:51 AM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > >>>>> > >>>>> Dear community, > >>>>> > >>>>> As you may have seen, Roassal has entered a stabilization phase. The > book AgileVisualization.com will soon be released. After its release, > Roassal will go over a new development phase. In order to prepare it, I am > asking this question: > >>>>> > >>>>> What are the 3 aspects you would like to see improved in Roassal? > >>>>> > >>>>> You can answer publicly or by sending private messages. > >>>>> > >>>>> Kind regards, > >>>>> Alexandre > >>>>> -- > >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>>> Alexandre Bergel http://www.bergel.eu > >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Moose-dev mailing list > >>>>> Moose-dev(a)list.inf.unibe.ch > >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> www.feenk.com > >>>> > >>>> âLive like you mean it." > >>>> > >>>> > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)list.inf.unibe.ch > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "Value is always contextual." > >> > >> > >> > >> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > www.feenk.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Feb. 26, 2016

Re: [Pharo-users] Is Seaside's Canvas/Brush metaphor for creating HTML available outside of Seaside?

by Pierce Ng

On Fri, Feb 26, 2016 at 07:34:00AM +0100, Sven Van Caekenberghe wrote: > And Zn has a very simple one too (since recently): And I published WaterMint a few months ago. http://www.samadhiweb.com/blog/2015.09.26.watermint.html.html http://www.smalltalkhub.com/#!/~PierceNg/WaterMint-HTML | html | html := WMHtmlCanvas new. html html with: [ html head with: [ html title: 'WaterMint' ]. html body with: [ html h1: 'WATERMINT'. html div id: 'foo'; class: 'foo'; with: [ html p: 'Foo!' ]. html div id: 'bar'; with: [ html p: 'Bar!' ]. html h1: 'BAZ!' ]]. html render. Pierce

Feb. 26, 2016

Re: [Pharo-users] Pb with the CI @ INRIA?

by Peter UhnÃ¡k

Hi Chris, for example https://ci.inria.fr/moose/job/roassal2/2253/testReport/junit/Roassal2GT-Tes… On Fri, Feb 26, 2016 at 2:47 PM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi Alex, > > Could you provide the link to the job providing this output? > > Le 26 fÃ©vr. 2016 Ã 09:57, Alexandre Bergel a Ã©crit : > > > Hi! > > > > We regularly get this error: > > > > Failed to read test report file > /builds/workspace/roassal2/Roassal2GT-Test.xml > > org.dom4j.DocumentException: Error on line 27 of document > file:///builds/workspace/roassal2/Roassal2GT-Test.xml : 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:123) > > at hudson.tasks.junit.TestResult.parse(TestResult.java:286) > > at > hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:232) > > at hudson.tasks.junit.TestResult.parse(TestResult.java:167) > > at hudson.tasks.junit.TestResult.parse(TestResult.java:150) > > at hudson.tasks.junit.TestResult.<init>(TestResult.java:126) > > at > hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:132) > > at > hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:107) > > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2691) > > at hudson.remoting.UserRequest.perform(UserRequest.java:120) > > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > > at hudson.remoting.Request$2.run(Request.java:326) > > > > Any idea why? > > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > >

Feb. 26, 2016