- Pharo-users - lists.pharo.org

Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)

by Stephan Eggermont

On 26/02/16 20:30, Dimitris Chloupis wrote: > 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 The first thing to test is if TinyC is actually faster than Pharo. Stephan

Feb. 28, 2016

Re: [Pharo-users] A Spec widget to hold non-editable multi-lines text?

by Julien Delplanque

I totally agree, I will do it and add this one. Maybe I will also make some research for similar content on the mailing list. Julien On 27/02/16 13:08, stepharo wrote: > Julien > > we should create a simple chapter with questions/answers and we > capture there such knowledge. > > Stef > > Le 25/2/16 11:30, Julien Delplanque a Ã©crit : >> Nice, can't wait to read it :) >> >> Julien >> >> On 25/02/16 10:58, Peter UhnÃ¡k wrote: >>> I'm sure it's documented somewhereâ¦ in any case new Spec >>> documentation is >>> emerging so let's not forget to make sure it's there. >>> >>> Peter >>> >>> On Thu, Feb 25, 2016 at 10:49 AM, Julien Delplanque <julien(a)tamere.eu> >>> wrote: >>> >>>> Indeed but I mean, I was not able to deduce the fact that to have a >>>> widget >>>> holding not-editable multi-line text I have to use >>>> >>>> TextInputFieldModel and use #enabled: message... >>>> >>>> But maybe there is already documentation about that? >>>> >>>> Julien >>>> >>>> >>>> >>>> On 25/02/16 09:58, Peter UhnÃ¡k wrote: >>>> >>>>> Maybe this should be documented in the class comment of >>>>>> TextInputFieldModel? >>>>>> >>>>>> This is a feature of AbstractWidgetModel, so it applies to all >>>>>> widgets >>>>> (buttons, texts, selects, ...). >>>>> >>>>> Peter >>>>> >>>>> >>>> >> >> >> > >

Feb. 27, 2016

Re: [Pharo-users] A Spec widget to hold non-editable multi-lines text?

by stepharo

Julien we should create a simple chapter with questions/answers and we capture there such knowledge. Stef Le 25/2/16 11:30, Julien Delplanque a Ã©crit : > Nice, can't wait to read it :) > > Julien > > On 25/02/16 10:58, Peter UhnÃ¡k wrote: >> I'm sure it's documented somewhereâ¦ in any case new Spec >> documentation is >> emerging so let's not forget to make sure it's there. >> >> Peter >> >> On Thu, Feb 25, 2016 at 10:49 AM, Julien Delplanque <julien(a)tamere.eu> >> wrote: >> >>> Indeed but I mean, I was not able to deduce the fact that to have a >>> widget >>> holding not-editable multi-line text I have to use >>> >>> TextInputFieldModel and use #enabled: message... >>> >>> But maybe there is already documentation about that? >>> >>> Julien >>> >>> >>> >>> On 25/02/16 09:58, Peter UhnÃ¡k wrote: >>> >>>> Maybe this should be documented in the class comment of >>>>> TextInputFieldModel? >>>>> >>>>> This is a feature of AbstractWidgetModel, so it applies to all >>>>> widgets >>>> (buttons, texts, selects, ...). >>>> >>>> Peter >>>> >>>> >>> > > >

Feb. 27, 2016

Re: [Pharo-users] A Spec widget to hold non-editable multi-lines text?

by stepharo

Le 25/2/16 08:15, Julien Delplanque a Ã©crit : > Hi, > > Thank you it works as expected :) Maybe this should be documented in > the class comment of TextInputFieldModel? please send a change. Stef > > Regards, > > Julien > > On Wed, Feb 24, 2016 at 7:49 PM, Johan Fabry <jfabry(a)dcc.uchile.cl > <mailto:jfabry@dcc.uchile.cl>> wrote: > > Hello Julien, > > have you tried configuring it with enabled: false ? > > > On Feb 24, 2016, at 13:24, Julien Delplanque <julien(a)tamere.eu > <mailto:julien@tamere.eu>> wrote: > > > > Hello, > > > > I wonder if there is a Spec widget to hold non-editable > multi-line text? > > > > There is TextInputFieldModel but the text is editable. > > > > Thanks in advance, > > > > Julien > > > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - > University of Chile > > >

Feb. 27, 2016

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