- Pharo-dev - lists.pharo.org

[ANN] Next Pharo Sprint: May 24

by Marcus Denker

We will organize a Pharo sprint / Moose dojo May 24, starting at 10:00am. (Local Time Paris). Goals of this sprint: - Pharo 8: Fix issues from tracker https://github.com/pharo-project/pharo/issues Remote Sprint: Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events We have added a Board to coordinate the work: https://github.com/orgs/pharo-project/projects/9 Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come

May 17, 2019

[Pharo 8.0] Build #276: 3355-Strange-logic-in-RBFactoryChangeManager

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

There is a new Pharo build available! The status of the build #276 was: FAILURE. The Pull Request #3357 was integrated: "3355-Strange-logic-in-RBFactoryChangeManager" Pull request url: https://github.com/pharo-project/pharo/pull/3357 Issue Url: https://github.com/pharo-project/pharo/issues/3355 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 16, 2019

[Pharo 8.0] Build #275: 3341-Begin-to-split-tests-linked-to-Halt-in-Kernel

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

There is a new Pharo build available! The status of the build #275 was: SUCCESS. The Pull Request #3343 was integrated: "3341-Begin-to-split-tests-linked-to-Halt-in-Kernel" Pull request url: https://github.com/pharo-project/pharo/pull/3343 Issue Url: https://github.com/pharo-project/pharo/issues/3341 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 16, 2019

Re: [Pharo-dev] FloatArray

by ducasse

Thanks to remind us. It skipped our mind. I will raise the point tomorrow and discuss with marcus. Stef > On 16 May 2019, at 20:26, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Any feedback on this? > Did someone tried to use Smallapack in Pharo? > Jimmie? > > Le jeu. 25 avr. 2019 Ã 22:50, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> a Ã©crit : > Thanks nicolas. > We will discuss this during the sprint tomorrow. > > >> On 25 Apr 2019, at 22:43, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >> >> I've just published a new ConfigurationOfSmallapack >> >> Currently, there is one test failing because I did not finish the support of LegacyFFI for invoking methods with more than 15 arguments (see below). >> The other tests are passing, so you may try it now. >> >> gory details: >> The failing test requires the Opal Compiler to generate fallback code for invoking primitive 117 (ExternalFunction invokeWithArguments:) under the hood... >> Old Compiler workaround was hackish, and is extremely complex to implement in cleaner Opal architecture >> (Old compiler enabled mixing AST rewrite/code generation phase without a problem) >> The plan was either to enhance primitive 120 to handle the case of many arguments passed through a single array... >> Or to switch to UnifiedFFI (but even there, I don't remember if invoking primitive 117 was that straight forward...) >> >> Le jeu. 25 avr. 2019 Ã 20:16, Jimmie Houchin <jlhouchin(a)gmail.com <mailto:jlhouchin@gmail.com>> a Ã©crit : >> Thanks. >> >> I appreciate your working to make this happen. No pressure from me on time. I am blessed that you are contributing this to the community and that I can benefit from your labors. At your convenience. >> >> I look forward to using Smallapack when available. I am thrilled to be able to stay with Pharo and not have to use Python/Numpy. :) >> Thanks. >> >> Jimmie >> >> On 4/25/19 12:38 PM, Nicolas Cellier wrote: >>> Hi Jimmie, >>> The Metacello Configuration is not ready for Pharo7. >>> I have succeeded in loading Smallapack yesterday without Metacello, and could run some of the tests. >>> I had to modify a few methods because of Pharo refactorings, and there is still some work to make it fully operational. >>> When ready, I'll update the Metacello configuration and keep you informed. >>> >>> Le jeu. 25 avr. 2019 Ã 19:06, Jimmie Houchin <jlhouchin(a)gmail.com <mailto:jlhouchin@gmail.com>> a Ã©crit : >>> When I attempt to install via Metacello in Pharo 7, I get the following warning. >>> >>> This package depends on the following classes: >>> Parser >>> MessageAsTempNode >>> Compiler >>> MessageNode >>> >>> I do not know how to proceed from there. Any help greatly appreciated. >>> Thanks. >>> >>> Jimmie >>> >>> On 4/24/19 12:20 AM, Nicolas Cellier wrote: >>>> Hi, >>>> I recommand inquiring about Smallapack, the Smalltalk interface to LAPACK, on squeaksource.com <http://squeaksource.com/> or github. You'll get the speed of numpy. There is a Metacello configuration. I have not checked the port on current >>>> Pharo, but I can reactivate if there is some interest. >>>> >>>> Le mer. 24 avr. 2019 Ã 05:55, Jimmie Houchin <jlhouchin(a)gmail.com <mailto:jlhouchin@gmail.com>> a Ã©crit : >>>> I just recently discovered FloatArray by accident. >>>> >>>> I was close to having to use Python/Numpy due to considerable >>>> performance differences. Performance is very important. >>>> >>>> In one of my test using a 212000 item array of floats and doing a sum on >>>> each iteration through the array Pharo was taking 17 minutes verses >>>> Python/Numpy taking 20 seconds. Using FloatArray closes the gap to 40 >>>> seconds. That is acceptable. >>>> >>>> However when looking at the FloatArray comment it says it uses 32bit >>>> floats. I need 64bit. I don't even know where to look to create 64bit >>>> FloatArrays. I am surprised that they didn't get converted when moving >>>> to 64bit Pharo. >>>> >>>> Would I need to change VM source? Compile a new VM and create image side >>>> classes? I have not messed with VM in years. I do not know where the >>>> FloatArray plugin would be. >>>> >>>> Any pointers would be a great help. If this needs to be on the vm-dev >>>> list I can move it there. >>>> >>>> Thanks. >>>> >>>> Jimmie >>>> >>>> >

May 16, 2019

Re: [Pharo-dev] FloatArray

by Nicolas Cellier

Any feedback on this? Did someone tried to use Smallapack in Pharo? Jimmie? Le jeu. 25 avr. 2019 Ã 22:50, ducasse <stepharo(a)netcourrier.com> a Ã©crit : > Thanks nicolas. > We will discuss this during the sprint tomorrow. > > > On 25 Apr 2019, at 22:43, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I've just published a new ConfigurationOfSmallapack > > Currently, there is one test failing because I did not finish the support > of LegacyFFI for invoking methods with more than 15 arguments (see below). > The other tests are passing, so you may try it now. > > gory details: > The failing test requires the Opal Compiler to generate fallback code for > invoking primitive 117 (ExternalFunction invokeWithArguments:) under the > hood... > Old Compiler workaround was hackish, and is extremely complex to implement > in cleaner Opal architecture > (Old compiler enabled mixing AST rewrite/code generation phase without a > problem) > The plan was either to enhance primitive 120 to handle the case of many > arguments passed through a single array... > Or to switch to UnifiedFFI (but even there, I don't remember if invoking > primitive 117 was that straight forward...) > > Le jeu. 25 avr. 2019 Ã 20:16, Jimmie Houchin <jlhouchin(a)gmail.com> a > Ã©crit : > >> Thanks. >> >> I appreciate your working to make this happen. No pressure from me on >> time. I am blessed that you are contributing this to the community and that >> I can benefit from your labors. At your convenience. >> >> I look forward to using Smallapack when available. I am thrilled to be >> able to stay with Pharo and not have to use Python/Numpy. :) >> >> Thanks. >> >> Jimmie >> >> >> On 4/25/19 12:38 PM, Nicolas Cellier wrote: >> >> Hi Jimmie, >> The Metacello Configuration is not ready for Pharo7. >> I have succeeded in loading Smallapack yesterday without Metacello, and >> could run some of the tests. >> I had to modify a few methods because of Pharo refactorings, and there is >> still some work to make it fully operational. >> When ready, I'll update the Metacello configuration and keep you informed. >> >> Le jeu. 25 avr. 2019 Ã 19:06, Jimmie Houchin <jlhouchin(a)gmail.com> a >> Ã©crit : >> >>> When I attempt to install via Metacello in Pharo 7, I get the following >>> warning. >>> >>> This package depends on the following classes: >>> Parser >>> MessageAsTempNode >>> Compiler >>> MessageNode >>> >>> >>> I do not know how to proceed from there. Any help greatly appreciated. >>> >>> Thanks. >>> >>> Jimmie >>> >>> >>> On 4/24/19 12:20 AM, Nicolas Cellier wrote: >>> >>> Hi, >>> I recommand inquiring about Smallapack, the Smalltalk interface to >>> LAPACK, on squeaksource.com or github. You'll get the speed of numpy. >>> There is a Metacello configuration. I have not checked the port on current >>> Pharo, but I can reactivate if there is some interest. >>> >>> Le mer. 24 avr. 2019 Ã 05:55, Jimmie Houchin <jlhouchin(a)gmail.com> a >>> Ã©crit : >>> >>>> I just recently discovered FloatArray by accident. >>>> >>>> I was close to having to use Python/Numpy due to considerable >>>> performance differences. Performance is very important. >>>> >>>> In one of my test using a 212000 item array of floats and doing a sum >>>> on >>>> each iteration through the array Pharo was taking 17 minutes verses >>>> Python/Numpy taking 20 seconds. Using FloatArray closes the gap to 40 >>>> seconds. That is acceptable. >>>> >>>> However when looking at the FloatArray comment it says it uses 32bit >>>> floats. I need 64bit. I don't even know where to look to create 64bit >>>> FloatArrays. I am surprised that they didn't get converted when moving >>>> to 64bit Pharo. >>>> >>>> Would I need to change VM source? Compile a new VM and create image >>>> side >>>> classes? I have not messed with VM in years. I do not know where the >>>> FloatArray plugin would be. >>>> >>>> Any pointers would be a great help. If this needs to be on the vm-dev >>>> list I can move it there. >>>> >>>> Thanks. >>>> >>>> Jimmie >>>> >>>> >>>> >

May 16, 2019

Re: [Pharo-dev] ESUG 2019 - Call for presentations

by serge.stinckwich＠gmail.com

IWST is a research track and you have to submit a paper. For the regular conference, a title and a summary should be enough. Sent from my iPhone > On 16 May 2019, at 22:51, askoh <askoh(a)askoh.com> wrote: > > Thanks for reply. > Do I submit to both to see which one will accept my presentation? > Or am I restricted to submit to one only? > > All the best, > Aik-Siong Koh > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

May 16, 2019

Re: [Pharo-dev] ESUG 2019 - Call for presentations

by askoh

Thanks for reply. Do I submit to both to see which one will accept my presentation? Or am I restricted to submit to one only? All the best, Aik-Siong Koh -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 16, 2019

[Pharo 8.0] Build #274: 3349-refactor-to-remove-not-in-method-hasSubclasses

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

There is a new Pharo build available! The status of the build #274 was: SUCCESS. The Pull Request #3350 was integrated: "3349-refactor-to-remove-not-in-method-hasSubclasses" Pull request url: https://github.com/pharo-project/pharo/pull/3350 Issue Url: https://github.com/pharo-project/pharo/issues/3349 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 16, 2019

[Pharo 8.0] Build #273: 3338-Slots-isSpecial-cleanup-part-2

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

There is a new Pharo build available! The status of the build #273 was: SUCCESS. The Pull Request #3339 was integrated: "3338-Slots-isSpecial-cleanup-part-2" Pull request url: https://github.com/pharo-project/pharo/pull/3339 Issue Url: https://github.com/pharo-project/pharo/issues/3338 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 15, 2019

Re: [Pharo-dev] Some more effort to make Slang and VMMaker work on Pharo [for review]

by David T. Lewis

Guille, This is excellent work. Thank you also for your careful explanations. Dave On Wed, May 15, 2019 at 10:33:38AM +0200, Guillermo Polito wrote: > Hi Eliot, > > > El 15 may 2019, a las 3:20, Eliot Miranda <eliot.miranda(a)gmail.com> escribi??: > > > > Hi Guille, > > > > On Tue, May 14, 2019 at 7:30 AM Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > > > - I had to review the AST-to-AST transformation, checking the output, comparing it to what squeak does and so on... > > > > Can you show a little of th differences in output between Squeak compiler derived sources and RB parser derived sources? I'm not going to demand changes or fixes or that they be exactly the same. But I am curious to know what kind of changes there are. > > From what I have now, I can see three main kind of differences (I actually compared with source code I generated myself from squeak and the existing sources in the git repo). > I did not work on them because the VM seemed to work, so I left them for later: > > 1) some comments are placed in different places in the output source code. This is entirely cosmetic, but it brings unnecessary noise to C source diffs. > > 2) labels in the gnu???ed code are numbered differently. I did not spot any ???bug??? in that yet, I did not dig enough into the gnuification to see why the difference, and I???m not entirely sure that this difference is caused by that either :)??? > Anyhow, this is mostly annoying because it also brings lots of noise to diffs. > > 3) some for loops inline the condition while they probably shouldn't. For example: > > 0 to: (self numSlotsOf: array1) - 1 do: [ ??? ] > > gets in my output translated to > > for (i = 0; i < (numSlotsOf(array1)); i += 1) { ... > > while in the version generated from squeak > > for (i = 0, iLimiT = ((numSlotsOf(array1)) - 1); i <= iLimiT; i += 1) { ??? > > This seems the most ???dangerous" difference I have so far specially if the limit condition has some side effect. > We will probably agree in that this third point should be fixed ^^. > > > > > - I???ve written several unit tests to ensure that future migrations are easier to do > > - I???ve introduced several compatibility classes/methods related to PackageInfo, Time and so on??? > > > > This is great1 Thank you. Perhaps we can move some of the source generation tests into the core. It would be good for there to be tests that apply to the Squeak compiler side too. I never took the time to run tests (I look at the generated source every time I make a change Slang), and writing a really good set of tests always seemed like a lot of work. But I might be tempted to add to the ones you've written. > > Maybe in the next weeks I can try to massage the tests to make them less dependent on the source (wether squeak's or pharo???s) AST. > The thing is that Pharo???s AST is closer to the source code, while Squeak???s has already some pre-cooked code transformations (like #ifNil: & co), and my tests assume a specific AST structure to traverse the tree and compare??? > > Cheers, > Guille

May 15, 2019