August 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ZnCharacterEncoder default instances

by Alistair Grant

On Tue, 28 Aug 2018 at 12:43, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven and Everyone, > > Instantiation of character encoders is relatively expensive, as can be > seen by the following code snippet: > > | count str ba enc new old | > > count := 10000. > str := 'test-Ã¤Ã¶Ã¼'. > new := [ > count timesRepeat: [ > (ZnCharacterEncoder newForEncoding: 'utf8') encodeString: str > ] ] timeToRunWithoutGC. > enc := ZnCharacterEncoder newForEncoding: 'utf8'. > old := [ > count timesRepeat: [ > enc encodeString: str ] ] timeToRunWithoutGC. > { old. new. } > > " #(14 122)" > > What do you think of the idea of caching default instances of encoders? > > My idea was to have a dictionary in ZnCharacterEncoder and add a class > method #forEncoding:. This would lazily create an instance, store it > in the dictionary, and then re-use the instance whenever that encoder > is requested. If people really want their own instance (not sure why, > there aren't any instance variables, and so there's no state), they > can use the existing #newForEncoding:. > > For example, sending #exists to a file reference currently > instantiates two encoders. > > This was actually previously fixed by #20273[1], but seems to have > been lost with the refactoring of FilePluginPrims to File. From > memory, Cyril's application saved 12 seconds by caching the encoder. > But in that case the instance was private to the file plugin > primitives. This would be a more general solution. > > [1] https://pharo.fogbugz.com/f/cases/20273/FilePluginPrims-could-save-an-encod… Just so people don't focus on the wrong thing: I realise that the ratio (almost 10:1 above) drops quickly as the string being converted grows in length. But if we take typical file names, the ratio, while smaller, is still significant, as suggested by Cyril's anecdote. Thanks, Alistair

Aug. 28, 2018

ZnCharacterEncoder default instances

by Alistair Grant

Hi Sven and Everyone, Instantiation of character encoders is relatively expensive, as can be seen by the following code snippet: | count str ba enc new old | count := 10000. str := 'test-Ã¤Ã¶Ã¼'. new := [ count timesRepeat: [ (ZnCharacterEncoder newForEncoding: 'utf8') encodeString: str ] ] timeToRunWithoutGC. enc := ZnCharacterEncoder newForEncoding: 'utf8'. old := [ count timesRepeat: [ enc encodeString: str ] ] timeToRunWithoutGC. { old. new. } " #(14 122)" What do you think of the idea of caching default instances of encoders? My idea was to have a dictionary in ZnCharacterEncoder and add a class method #forEncoding:. This would lazily create an instance, store it in the dictionary, and then re-use the instance whenever that encoder is requested. If people really want their own instance (not sure why, there aren't any instance variables, and so there's no state), they can use the existing #newForEncoding:. For example, sending #exists to a file reference currently instantiates two encoders. This was actually previously fixed by #20273[1], but seems to have been lost with the refactoring of FilePluginPrims to File. From memory, Cyril's application saved 12 seconds by caching the encoder. But in that case the instance was private to the file plugin primitives. This would be a more general solution. [1] https://pharo.fogbugz.com/f/cases/20273/FilePluginPrims-could-save-an-encod… Thanks, Alistair

Aug. 28, 2018

Debugging FFI Calls

by Eliot Miranda

Hi All, the latest VMs support a new facility which catches and reports exceptions during FFI calls as primitive failures. That means that if you have the relevant support code loaded (described below) and depending on dialect, you write your FFI interface method to contain an error code, or you're using the UnifiedFFI which uses invokeWithArguments:, then any exception that occurs during the FFI call will be caught and reported to use with the error code bound to an instance of ExceptionInFFICall, which contains a platform-specific error code and the pc at which it occurred. To use this facility you'll need to download a VM built yesterday or later (it should be derived from VMMaker.oscog-eem.2435 or later), or build your own from the tip of the Cog branch in opensmalltalk/vm. You'll then need to update the image code to install ExceptionInFFICall appropriately: in Pharo6 load SLICE 22367 in Squeak load the latest FFI code from source.squeak.org/FFI and update your image from trunk in Cuis, you'll need to adapt these changes to Cuis (sorry!!) There are two command-line flags to override the default behavior. [-]-failonffiexception causes the handling to be applied to all FFI calls, so if a method doesn't contain an error, you'll just see a primitive failure, and if ExceptionInFFICall is not installed you'll see only an error number in the call's error code. [-]-nofailonffiexception ignores exceptions during FFI calls, hence defaulting to the old behavior of crashing the VM (which may be useful if one is using a low-level debugger to debug the VM and/or external code). HTH _,,,^..^,,,_ best, Eliot

Aug. 27, 2018

In Pharo6 what has happened to package scripts?

by Eliot Miranda

Hi All, I'm trying to submit a SLICE for Pharo6 that contains chains related to FFI error handling. This SLICE needs a package script to recreate the specialObjectsArray. But I see no accessor for editing package scripts in the Pharo6 Monticello Browser. Have package scripts become unsupported? If so, what is the alternative? If not, how does one edit them? _,,,^..^,,,_ best, Eliot

Aug. 27, 2018

[Pharo 7.0-dev] Build #1194: 22172-Some-test-in-MustBeBooleanTests-are-rotten

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1194 was: FAILURE. The Pull Request #1720 was integrated: "22172-Some-test-in-MustBeBooleanTests-are-rotten" Pull request url: https://github.com/pharo-project/pharo/pull/1720 Issue Url: https://pharo.fogbugz.com/f/cases/22172 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 27, 2018

Re: [Pharo-dev] Submit your Project to the ESUG Awards

by Matteo Marra

Hello Noury, I would like to participate to the innovation award @ ESUG! My project, Port, is about running pharo on a cluster and executing map/reduce-like applications on it. My research focuses on debugging such problems, and I will try give a demo of both deploying and executing applications on a cluster (surely) and debugging them (if time will allow me). Let me know if you need additional (or more detailed, or better presented) information, Kind regards, Matteo > On 21 Aug 2018, at 14:58, N. Bouraqadi <bouraqadi(a)gmail.com> wrote: > > Hi everyone! > > This is a reminder to submit your projects to the ESUG Innovation Technology Awards. It will be held on september the 10th as part of the ESUG conference in Sardinia (https://esug.github.io/2018-Conference/conf2018.html) > > Any Pharo Smalltalk-related project is eligible. > All you need to do is provide me with few info and give a short demo during the awards session. > > I hope to hear from you soon, > Noury > >

Aug. 27, 2018

What tools or methods we have in Smalltalk (Pharo) for Model Driven programming?

by ponyatov

I mean MDP in a wide, in a more generic way, not the things like UML and other OMG derivatives. As an example, I defined a little set of generic classes <http://ponyatov.quora.com/Smalltalk-etudes-Model-Driven-MetaProgramming> for metaprogramming in terms of generic programming elements. My idea is about - creating domain-specific models, then - translate them into generic language-independent models, and finally - transform them into some code-synthesizable representation for the specific target programming language (which let me write in Smalltalk in any mainstream language and avoid no-vacancy lock) What tools or methods we have in Smalltalk (Pharo) for this approach? - data structure visualization - model transformation - logic-like inference over such a like models -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 26, 2018

Re: [Pharo-dev] [Vm-dev] Sign of Impending Iceberg Doom on Pharo 6.1

by Ben Coman

On Sat, 25 Aug 2018 at 01:40, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Sean, > On Fri, Aug 24, 2018 at 10:03 AM Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like >> the >> following: >> <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg> >> >> This seems to usually signal that a crash is not far away. > > Do you mean seconds or minutes or more away from a crash? > It's doubly concerning because there is no clear way to stop the troubled >> process >> (interrupts often bring up a debugger on something else) and because, >> since >> one is now unable to save any code, it's unclear how to start over easily >> in >> a new image. > > Just some general ideas (you may have already considered) The string "Diffing..." appears in only one location in MCPatch>>initializeWithBase:target: I'm not clear on the behaviour of #on:displayProgress: whether its possible some inside loop can make that string appear multiple times, or whether it indicates #initializeWithBase:target: is being called multiple times. A specific check there for an escape key-combo might help debug this. Or a class variable reset from Iceberg that halts when it exceeds a limit on the number of loops. Or log to file five or so levels of "thisContext senders senders etc" for post crash analysis to help isolate the loop. cheers -ben P.S. While I was browsing senders-of-senders-of-senders I quickly got lost and wondered if a tool that graphically showed a senders-tree might be a useful demo for Diagrammer. >

Aug. 26, 2018

[Pharo 7.0-dev] Build #1193: 22365 Introduced dynamic presenters list builder and tests.

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1193 was: SUCCESS. The Pull Request #1718 was integrated: "22365 Introduced dynamic presenters list builder and tests." Pull request url: https://github.com/pharo-project/pharo/pull/1718 Issue Url: https://pharo.fogbugz.com/f/cases/22365 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 25, 2018

Re: [Pharo-dev] Sign of Impending Iceberg Doom on Pharo 6.1

by Sean P. DeNigris

EstebanLM wrote > You would ask why being an obsolete version we do not backport the good > version for Pharo 6.1 That is totally understandable. EstebanLM wrote > recommended to install themselves the correct version... Ah! I didn't realize there was still a viable upgrade path. I will check that out! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 24, 2018