April 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How to convey that a message create a new instance

by Gabriel Cotelli

I tend to use the following idioms: - 'beSomething' idiom for cases modifying the receiver. - 'asSomething' can or cannot return a new object - 'newWithSomething' or 'copyWithXx' for cases when I want to make it clear that you would get a new instance On Sat, Apr 27, 2019, 14:27 ducasse <stepharo(a)netcourrier.com> wrote: > Hi > > I was looking at the API of Color and it is really confusing to me and > wrong > For example beOpaque > > beOpaque > "Set the transparency of the receiver to opaque, i.e. alpha to > 1.0." > > ^ self alpha: 1.0 > > But > > alpha: aFloat > "Answer a new Color with the given amount of opacity ('alpha')." > > ^ self class r: self red g: self green b: self blue alpha: aFloat > > Or > > adjustBrightness: brightness > "Adjust the relative brightness of this color. (lowest value is > 0.005 so that hue information is not lost)â > > but this creates a new color. > > I would really like to see how we can improve the fact that reading the > method selector should > let us understand whether a message is modifying or not the receiver. > > Since many methods such as darker, duller,â¦. do not show that they return > a new instance but actually do it. > May be we can make sure that modifying receiver methods are much better > identified as doing so. > > beOpaque -> asOpaque > adjustBrightness: -> colorWithBrigthness: > > Do you have any better ideas? > > Stef > >

April 27, 2019

How to convey that a message create a new instance

by ducasse

Hi I was looking at the API of Color and it is really confusing to me and wrong For example beOpaque beOpaque "Set the transparency of the receiver to opaque, i.e. alpha to 1.0." ^ self alpha: 1.0 But alpha: aFloat "Answer a new Color with the given amount of opacity ('alpha')." ^ self class r: self red g: self green b: self blue alpha: aFloat Or adjustBrightness: brightness "Adjust the relative brightness of this color. (lowest value is 0.005 so that hue information is not lost)â but this creates a new color. I would really like to see how we can improve the fact that reading the method selector should let us understand whether a message is modifying or not the receiver. Since many methods such as darker, duller,â¦. do not show that they return a new instance but actually do it. May be we can make sure that modifying receiver methods are much better identified as doing so. beOpaque -> asOpaque adjustBrightness: -> colorWithBrigthness: Do you have any better ideas? Stef

April 27, 2019

[Pharo 8.0] Build #243: SUCCESS

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

There is a new Pharo build available! The status of the build #243 was: SUCCESS. Could not extract further issue information from commit message: Update minimum-reviews.yml make changesThreshold 1... 100 is far too high as most changes are very small Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 26, 2019

[Pharo 8.0] Build #242: 3225-RGPackage-should-be-RGPackageDefinition

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

There is a new Pharo build available! The status of the build #242 was: SUCCESS. The Pull Request #3226 was integrated: "3225-RGPackage-should-be-RGPackageDefinition" Pull request url: https://github.com/pharo-project/pharo/pull/3226 Issue Url: https://github.com/pharo-project/pharo/issues/3225 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 26, 2019

[Pharo 8.0] Build #241: 3239-CDNode-protocols-look-totally-broken

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

There is a new Pharo build available! The status of the build #241 was: SUCCESS. The Pull Request #3249 was integrated: "3239-CDNode-protocols-look-totally-broken" Pull request url: https://github.com/pharo-project/pharo/pull/3249 Issue Url: https://github.com/pharo-project/pharo/issues/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 26, 2019

[Pharo 8.0] Build #240: 3241-install-probot-to-suggest-us-to-not-forget-reviews

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

There is a new Pharo build available! The status of the build #240 was: SUCCESS. The Pull Request #3248 was integrated: "3241-install-probot-to-suggest-us-to-not-forget-reviews" Pull request url: https://github.com/pharo-project/pharo/pull/3248 Issue Url: https://github.com/pharo-project/pharo/issues/3241 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 26, 2019

[Pharo 8.0] Build #239: 2590-We-can-get-two-times-the-mouseEntermouseLeave-event-when-subscribing-to-the-eventHandler-of-a-Morph

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

There is a new Pharo build available! The status of the build #239 was: SUCCESS. The Pull Request #2724 was integrated: "2590-We-can-get-two-times-the-mouseEntermouseLeave-event-when-subscribing-to-the-eventHandler-of-a-Morph" Pull request url: https://github.com/pharo-project/pharo/pull/2724 Issue Url: https://github.com/pharo-project/pharo/issues/2590 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 26, 2019

[Pharo 8.0] Build #238: 3217-copy-class-do-not-copy-class-side-instanceVariableNames

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

There is a new Pharo build available! The status of the build #238 was: SUCCESS. The Pull Request #3230 was integrated: "3217-copy-class-do-not-copy-class-side-instanceVariableNames" Pull request url: https://github.com/pharo-project/pharo/pull/3230 Issue Url: https://github.com/pharo-project/pharo/issues/3217 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 26, 2019

Re: [Pharo-dev] FloatArray

by ducasse

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 <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 >>> >>>

April 25, 2019

Re: [Pharo-dev] FloatArray

by Nicolas Cellier

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 >>> >>> >>>

April 25, 2019

Re: [Pharo-dev] FloatArray

by Jimmie Houchin

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 >> >>

April 25, 2019

[Pharo 8.0] Build #237: newbutton2

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

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

April 25, 2019

Re: [Pharo-dev] FloatArray

by Nicolas Cellier

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 >> >> >>

April 25, 2019

Re: [Pharo-dev] FloatArray

by Jimmie Houchin

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 > >

April 25, 2019

[Pharo 8.0] Build #236: Exporting MCZ from the BaselineOfMetacello

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

There is a new Pharo build available! The status of the build #236 was: SUCCESS. The Pull Request #3215 was integrated: "Exporting MCZ from the BaselineOfMetacello" Pull request url: https://github.com/pharo-project/pharo/pull/3215 Issue Url: https://github.com/pharo-project/pharo/issues/exporting Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 25, 2019

ReadWriteStream>>on:

by Ben Coman

I notice... rs := ReadStream on: #( 1 2 3 4 5 6 7 8 9). rs do: [ :x | self inform: x printString ]. ==> shows 10 notifications. but... rws := ReadWriteStream on: #( 1 2 3 4 5 6 7 8 9). rws do: [ :x | self inform: x printString ] ==> nothing it seems because "readLimit" instance variable of ReadWriteStream is zero. Comparing... ReadStream(PositionalStream)>>on: aCollection readLimit := aCollection size. ReadWriteStream(WriteStream)>>on: aCollection readLimit := 0. I wonder if ReadWriteStream should override #on: to set readLimit similar to ReadStream, but are there subtleties in the stream hierarchy I'm not aware of ? cheers -ben

April 25, 2019

Call for Papers, The Programming Journal, Volume 4, Issue 2

by Fabio Niephaus

======================================================================== The Programming Journal The Art, Science, and Engineering of Programming Call for Papers for Volume 4, Issue 2 http://programming-journal.org/cfp/ Follow us @programmingconf ======================================================================== The Art, Science, and Engineering of Programming was created with the goal of placing the wonderful art of programming on the map of scholarly works. Many academic journals and conferences exist that publish research related to programming, starting with programming languages, software engineering, and expanding to the whole Computer Science field. Yet, many of us feel that, as the field of Computer Science expanded, programming, in itself, has been neglected to a secondary role not worthy of scholarly attention. That is a serious gap, as much of the progress in Computer Science lies on the basis of computer programs, the people who write Them, and the concepts and tools available to them to express computational tasks. The Art, Science, and Engineering of Programming aims at closing this gap by focusing primarily on programming: the art itself (programming styles, pearls, models, languages), the emerging science of understanding what works and what doesnât work in general and in specific contexts, as well as more established engineering and mathematical perspectives. We solicit papers describing work from one of the following perspectives: Art: knowledge and technical skills acquired through practice and personal experiences. Examples include libraries, frameworks, languages, APIs, programming models and styles, programming pearls, and essays about programming. Science (Theoretical): knowledge and technical skills acquired through mathematical formalisms. Examples include formal programming models and proofs. Science (Empirical): knowledge and technical skills acquired through experiments and systematic observations. Examples include user studies and programming-related data mining. Engineering: knowledge and technical skills acquired through designing and building large systems and through calculated application of principles in building those systems. Examples include measurements of artifactsâ properties, development processes and tools, and quality assurance methods. Independent of the type of work, the journal accepts submissions covering several areas of expertise, including but not limited to: - General-purpose programming - Data mining and machine learning programming, and for programming - Database programming - Distributed systems programming - Graphics and GPU programming - Interpreters, virtual machines, and compilers - Metaprogramming and reflection - Model-based development - Modularity and separation of concerns - Parallel and multi-core programming - Program verification - Programming education - Programming environments - Security programming - Social coding - Testing and debugging - User interface programming - Visual and live programming All details, including the selection process are described on http://programming-journal.org/cfp/ Details on the submission processed are available at http://programming-journal.org/submission/ Authors of accepted papers will be invited to present at the <Programming>â20 conference in Porto, Portugal from March 23-26: https://2020.programming-conference.org/ ## Upcoming Deadlines We solicit submissions for the following upcoming deadlines: Submission: June 1 First notification: August 1 Revised submission: September 1 Final notification: September 7 Camera-ready: September 15 Weâll also solicit submissions for Issue 3, for full details, see: https://programming-journal.org/timeline/ ## Standing Review Committee Volume 4 Christophe Scholliers, Ghent University Coen De Roover, Vrije Universiteit Brussel Craig Anslow, Victoria University of Wellington New Zealand Didier Verna, EPITA / LRDE France Diego Garbervetsky University of Buenos Aires Edd Barrett, King's College London Erik Ernst, Google Felienne Hermans, Leiden University Francisco Sant'Anna, Rio de Janeiro State University Friedrich Steimann, FernuniversitÃ¤t Gordana Rakic, University of Novi Sad Guido Salvaneschi, TU Darmstadt Hidehiko Masuhara, Tokyo Institute of Technology Jeremy Gibbons, University of Oxford Jonathan Edwards, US Jun Kato, AIST Japan Luke Church, University of Cambridge Matthew Flatt, University of Utah Michael L. Van De Vanter, Cal Poly San Luis Obispo NicolÃ¡s Cardozo, Universidad de los Andes Colombia Stephen Kell, University of Kent ## Editors Stefan Marr (Editor Volume 4), University of Kent Cristina V. Lopes (Editor-in-Chief), University of California, Irvine

April 25, 2019

[Pharo 8.0] Build #235: 3219-bad-argument-names

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

There is a new Pharo build available! The status of the build #235 was: FAILURE. The Pull Request #3220 was integrated: "3219-bad-argument-names" Pull request url: https://github.com/pharo-project/pharo/pull/3220 Issue Url: https://github.com/pharo-project/pharo/issues/3219 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 25, 2019

[Pharo 8.0] Build #234: 3218-Clean-Refactoring-change-tests

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

There is a new Pharo build available! The status of the build #234 was: SUCCESS. The Pull Request #3221 was integrated: "3218-Clean-Refactoring-change-tests" Pull request url: https://github.com/pharo-project/pharo/pull/3221 Issue Url: https://github.com/pharo-project/pharo/issues/3218 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 25, 2019

[Pharo 8.0] Build #233: 3224-Fix-ProperMethodCategorizationTest-to-not-enforce-running-protocol-

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

There is a new Pharo build available! The status of the build #233 was: FAILURE. The Pull Request #3227 was integrated: "3224-Fix-ProperMethodCategorizationTest-to-not-enforce-running-protocol-" Pull request url: https://github.com/pharo-project/pharo/pull/3227 Issue Url: https://github.com/pharo-project/pharo/issues/3224 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 25, 2019

Re: [Pharo-dev] [vwnc] most energy efficient AI system - challenge of the German Federal Ministry of Education and Research BMBF

by Bernhard HÃ¶fner

Hello group, Bernard Portier from University Brest allowed me to forward his ideas referring to works of different scientists. It may help to concretize an AI-project or to fertilize discussion. I am not an AI-specialist and sorry not to be able to participate on a discussion. Best Regards, Bernhard â¦ Dear Bernhard, This is a summary of work done at University of Brest for mapping Smalltalk computation to hardware. 1) efficiency is concurrency in execution During decades researchers and industry was running behind the work of Xerox PARC on micro- programmed computers, such as the Dorado. The Dorado implemented a pipeline for decoding languages intermediate code developped for this purpose. Smalltalk bytecodes as delivered for Smalltalk-80 were of this kind. Behind the streaming engine that prepared the execution, there was the micro-machine routines translated by PARC into micro-program control executing several internal operations in parallel. The blue book implementation part is just a description of how the instructions are executed. (For those who do not know about micro-programming, there are primers written in the 70's by Michael Flynn to explain link between the instruction set, micro-program structure, and program execution. It takes 1 day to read, understand, and experiment: look at Ci lines that activate concurrent operations from a micro-code word.) [Flynn] Micro-programming, includes Rosin machine, in Computer Architecture 1972. Annex 1. [Dorado] Retrospective, Pier. http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/ISL-83 <http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/ISL-83>- 1_A_Retrospective_on_the_Dorado_A_High-Performance_Personal_Computer.pdf So, Smalltalk was fast enough in 1980, it was well understood for a machine execution, and became so slow when executed on micro processors, despite valuable efforts at UCBerkeley, Stanford and others. 2) concurrency is now easily available Probably one could implement Rosin machine in few days, plus a compiler to translate a calculator syntax into instruction set for it. Research could rather examine chances to execute high level computer language at the current level of resources as FPGAs devices and shared memory accelerators. In the second case, one can recall that previous generation of massive parallel computers used Smalltalk to model execution. It was the case for Maspar machine which debugger was showing clearly a ParcPlace support to display assertions on parallel (plural) variables. This debugger inspired some work to support parallel execution on GPU as shown in [VanLong]. [VanLong] Master report. Annex 2. http://wsn.univ-brest.fr/pottier/long.pdf <http://wsn.univ-brest.fr/pottier/long.pdf> (See also https://www.mdpi.com/1424-8220/18/7/2323 <https://www.mdpi.com/1424-8220/18/7/2323> about parallel physical simulation) 3) execution and definition of object spaces can replace types. Smalltalk does not have types. Types ease program checking and preparation of execution on machines. Instead, Smalltalk provides classes to resolve call to methods. Instead of relying on class tags, we can also rely on object sets (called contexts), solve binding on these object sets, and produce logic networks that will replace the slow interpretation or execution by one call to a dedicated function block. Computer operative parts are either logic networks, combinational or sequential, defined at boolean level. Thus this schema is the common way to produce operative blocks, even dynamically. The first stage is a high level look-up table tree production organized around method calls, with evolved backtracking memory optimizers. This could be suitable for architectures such as GPUs or memory based nano-architectures. The second stage is mapping to reconfigurable architectures, expecially those oriented to logic, such as FPGAs. The Madeo framework address Smalltalk to technology translation in its different stages address this question, such as: [FCCM96] Smalltalk blocks to logic, 4th IEEE Symposium on FPGAs for Custom Computing Machines (FCCM '96), Napa Valley, CA, USA, April 17-19, 1996. IEEE 1996, ISBN 0-8186-7548-9 also at http://wsn.univ-brest.fr/reports/96/st80-2-FPGA.ps.Z <http://wsn.univ-brest.fr/reports/96/st80-2-FPGA.ps.Z> [SAMOS2002] A LUT based approach for high level synthesis, Shuvra S. Bhattacharyya, E.F. Deprettere, Jurgen Teich, (Eds.), Domain-Specific Processors: Systems, Architectures, Modeling, and Simulation, Hardcover, pp. 261, plus XV, Marcel Dekker, Inc., New York, 2004, ISBN 0-8427-4711-9 also at http://wsn.univ-brest.fr/reports/2002/samos2.pdf <http://wsn.univ-brest.fr/reports/2002/samos2.pdf> 4) Mapping LUT systems to hardware were addressed by two excellent PhD works, one that draws a flattened LUT tree on an FPGA, the other one that address nano technologies, largely connected to Pr Moritz work at Umass. As a conclusion (I hope it is not final), there are large opportunities to improve specific execution speed of Smalltalk engines using new 'back to the future' approaches. We just need to stop doing bad copies of the sacred 40 years implementation, pretending that it is a 'virtual machine' for today, look to GPUs, reconfigurable devices, and new technologies especially those based on low energy and fast physical memories. Bernard Pottier UniversiteÌ de Brest, France pottier(a)univ-brest.fr <mailto:pottier@univ-brest.fr> > Am 17.04.2019 um 01:00 schrieb Sean Glazier <sglazier456(a)gmail.com <mailto:sglazier456@gmail.com>>: > > This sounds great do they need a great Smalltalker? My linked in profile is www.linkedin.com/in/seanglazier <http://www.linkedin.com/in/seanglazier> I would love to be a contributor > > Kind Regards, > > Sean Glazier > > On Mon, Apr 15, 2019 at 4:33 PM Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> wrote: > Thank you, Helge, I had no clue but I felt something like this. > â¦at least it would be an excellent advertisement for Smalltalk when it succeeds and therefore maybe it would be worth to harness the forces in the Smalltalk community, no matter if Squeak, Pharo, VisualWorksâ¦ > But Smalltalk will not have any effect without an excellent partner for hardware and for AI algorithms. Maybe the suitable Fraunhofer institute? At least they invented mp3. > > Best regards, Bernhard > > >> Am 15.04.2019 um 17:54 schrieb Nowak, Helge <HNowak(a)cincom.com <mailto:HNowak@cincom.com>>: >> >> Dear Bernhard, Alexandre and all, <> >> >> Thanks Bernhard for pointing to this. I would have missed it completelyâ¦ >> >> The German BMBF (Bundesministerium fÃ¼r Bildung und Forschung = German Federal Ministry of Research and Technology) started this competition for German universities and public research centers. It is targeted at increasing energy efficiency for AI systems. The aim is to increase Germanyâs competencies and competitiveness in this sector which is deemed to be a future key technology with the potential of disruptive innovation. >> >> It is clear that the energy efficiency is less determined by what programming language is used and what virtual machine is run on some standard hardware. The real gains are rather found in maybe novel algorithms, surely in novel hardware architectures and implementations. Indeed, when you look at the details of the competition (link below) that is exactly the case: any proposed solutions submitted to the competition must belong to one of three categories: FPGAs, ASIC s in 130 nm technology or ASICs in FDSOI technology. Close hardware/software co-design is explicitly requested. Not eligible are solutions that only optimize software components or use commercially available hardware unchanged. >> >> Does this mean that this competition is of no interest to ambitious Smalltalkers? No! In contrary. With Smalltalk being a perfect interactive modeling, exploration and simulation tool we Smalltalkers can help our competition team to build, explore and optimize their ideas before and while building them in hardware. Also hardware is nothing without software. Smalltalk is in my view best positioned to execute the desired co-design in a co-evolutionary way. Certainly we could demonstrate modern âagileâ engineering approaches as a side-means to increase competitiveness. >> >> Everyone interested should take a look at the competition here:https://www.bmbf.de/foerderungen/bekanntmachung-2371.html <https://www.bmbf.de/foerderungen/bekanntmachung-2371.html> (in German, obviously). >> >> Please also forward to all people who might be interested. >> >> Cheers >> Helge >> >> Helge Nowak >> Cincom Smalltalk Technical Account Manager >> <image001.png> <http://www.cincomsmalltalk.com/> >> >> Cincom Systems GmbH & Co. oHG >> HumboldtstraÃe 3 >> 60318 Frankfurt am Main >> GERMANY > >> office >> mobile >> >> website >> email >> +49 89 89 66 44 94 >> +49 172 74 00 402 >> >> http://www.cincomsmalltalk.com <http://www.cincomsmalltalk.com/> >> hnowak(a)cincom.com <mailto:hnowak@cincom.com> >> A standpoint is an intellectual horizon of radius zero. -- Albert Einstein >> >> GeschÃ¤ftsfÃ¼hrer/Managing Directors: Thomas M. Nies, Donald E. Vick >> oHG mit Sitz/based in Frankfurt am Main (Amtsgericht Frankfurt am Main HRA 50297) >> Pers. haftender Gesellschafter/Partner liable to unlimited extent: >> Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht KÃ¶nigstein/Ts. HRB 5069) >> >> --- CONFIDENTIALITY STATEMENT --- >> This e-mail transmission contains information that is intended to be privileged and confidential. It is intended only for the addressee named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited, please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. > >> >> >> Von: Alexandre Bergel [mailto:alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>] >> Gesendet: Freitag, 12. April 2019 19:08 >> An: Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> >> Cc: VisualWorks mailing list list <vwnc(a)cs.uiuc.edu <mailto:vwnc@cs.uiuc.edu>>; pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >> Betreff: Re: [vwnc] most energy efficient AI system - challenge of the German Federal Ministry of Education and Research BMBF >> >> Hello, >> >> We conducted some experiment in characterizing virtual machine from an energetic point of view. Results are not public yet. This is just to say this is a topic that I am interested in. >> >> Cheers, >> Alexandre >> >> >> On Apr 11, 2019, at 5:29 PM, Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> wrote: >> >> Hello Group, >> the German BMBF advertised a reward for the most energy efficient AI system, see: https://www.bmbf.de/de/mehr-ki-erfordert-weniger-energie-8156.html <https://www.bmbf.de/de/mehr-ki-erfordert-weniger-energie-8156.html> (in German), and I am wondering what is the position of Smalltalk in that field or what it could be. From the early 90th I know that much of the pretended slowness of Smalltalk was absorbed by the more efficient programs due to better analysis, concepts, design and development tools (and maybe developers ? ). >> >> Best Regards, Bernhard > > -- > > Kind Regards, > > Sean Glazier > 603 892 0167 cell > 603 583 4575 Skype phone > Skype Id: visualwave >

April 24, 2019

Re: [Pharo-dev] [vwnc] most energy efficient AI system - challenge of the German Federal Ministry of Education and Research BMBF

by Bernhard HÃ¶fner

Hello group, Bernard Portier from University Brest allowed me to forward his ideas referring to works of different scientists. It may help to concretize an AI-project or to fertilize discussion. I am not an AI-specialist and sorry not to be able to participate on a discussion. Best Regards, Bernhard â¦ Dear Bernhard, This is a summary of work done at University of Brest for mapping Smalltalk computation to hardware. 1) efficiency is concurrency in execution During decades researchers and industry was running behind the work of Xerox PARC on micro- programmed computers, such as the Dorado. The Dorado implemented a pipeline for decoding languages intermediate code developped for this purpose. Smalltalk bytecodes as delivered for Smalltalk-80 were of this kind. Behind the streaming engine that prepared the execution, there was the micro-machine routines translated by PARC into micro-program control executing several internal operations in parallel. The blue book implementation part is just a description of how the instructions are executed. (For those who do not know about micro-programming, there are primers written in the 70's by Michael Flynn to explain link between the instruction set, micro-program structure, and program execution. It takes 1 day to read, understand, and experiment: look at Ci lines that activate concurrent operations from a micro-code word.) [Flynn] Micro-programming, includes Rosin machine, in Computer Architecture 1972. Annex 1. [Dorado] Retrospective, Pier. http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/ISL-83 <http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/ISL-83>- 1_A_Retrospective_on_the_Dorado_A_High-Performance_Personal_Computer.pdf So, Smalltalk was fast enough in 1980, it was well understood for a machine execution, and became so slow when executed on micro processors, despite valuable efforts at UCBerkeley, Stanford and others. 2) concurrency is now easily available Probably one could implement Rosin machine in few days, plus a compiler to translate a calculator syntax into instruction set for it. Research could rather examine chances to execute high level computer language at the current level of resources as FPGAs devices and shared memory accelerators. In the second case, one can recall that previous generation of massive parallel computers used Smalltalk to model execution. It was the case for Maspar machine which debugger was showing clearly a ParcPlace support to display assertions on parallel (plural) variables. This debugger inspired some work to support parallel execution on GPU as shown in [VanLong]. [VanLong] Master report. Annex 2. http://wsn.univ-brest.fr/pottier/long.pdf <http://wsn.univ-brest.fr/pottier/long.pdf> (See also https://www.mdpi.com/1424-8220/18/7/2323 <https://www.mdpi.com/1424-8220/18/7/2323> about parallel physical simulation) 3) execution and definition of object spaces can replace types. Smalltalk does not have types. Types ease program checking and preparation of execution on machines. Instead, Smalltalk provides classes to resolve call to methods. Instead of relying on class tags, we can also rely on object sets (called contexts), solve binding on these object sets, and produce logic networks that will replace the slow interpretation or execution by one call to a dedicated function block. Computer operative parts are either logic networks, combinational or sequential, defined at boolean level. Thus this schema is the common way to produce operative blocks, even dynamically. The first stage is a high level look-up table tree production organized around method calls, with evolved backtracking memory optimizers. This could be suitable for architectures such as GPUs or memory based nano-architectures. The second stage is mapping to reconfigurable architectures, expecially those oriented to logic, such as FPGAs. The Madeo framework address Smalltalk to technology translation in its different stages address this question, such as: [FCCM96] Smalltalk blocks to logic, 4th IEEE Symposium on FPGAs for Custom Computing Machines (FCCM '96), Napa Valley, CA, USA, April 17-19, 1996. IEEE 1996, ISBN 0-8186-7548-9 also at http://wsn.univ-brest.fr/reports/96/st80-2-FPGA.ps.Z <http://wsn.univ-brest.fr/reports/96/st80-2-FPGA.ps.Z> [SAMOS2002] A LUT based approach for high level synthesis, Shuvra S. Bhattacharyya, E.F. Deprettere, Jurgen Teich, (Eds.), Domain-Specific Processors: Systems, Architectures, Modeling, and Simulation, Hardcover, pp. 261, plus XV, Marcel Dekker, Inc., New York, 2004, ISBN 0-8427-4711-9 also at http://wsn.univ-brest.fr/reports/2002/samos2.pdf <http://wsn.univ-brest.fr/reports/2002/samos2.pdf> 4) Mapping LUT systems to hardware were addressed by two excellent PhD works, one that draws a flattened LUT tree on an FPGA, the other one that address nano technologies, largely connected to Pr Moritz work at Umass. As a conclusion (I hope it is not final), there are large opportunities to improve specific execution speed of Smalltalk engines using new 'back to the future' approaches. We just need to stop doing bad copies of the sacred 40 years implementation, pretending that it is a 'virtual machine' for today, look to GPUs, reconfigurable devices, and new technologies especially those based on low energy and fast physical memories. Bernard Pottier UniversiteÌ de Brest, France pottier(a)univ-brest.fr <mailto:pottier@univ-brest.fr> the text as pdf: > Am 17.04.2019 um 01:00 schrieb Sean Glazier <sglazier456(a)gmail.com>: > > This sounds great do they need a great Smalltalker? My linked in profile is www.linkedin.com/in/seanglazier <http://www.linkedin.com/in/seanglazier> I would love to be a contributor > > Kind Regards, > > Sean Glazier > > On Mon, Apr 15, 2019 at 4:33 PM Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> wrote: > Thank you, Helge, I had no clue but I felt something like this. > â¦at least it would be an excellent advertisement for Smalltalk when it succeeds and therefore maybe it would be worth to harness the forces in the Smalltalk community, no matter if Squeak, Pharo, VisualWorksâ¦ > But Smalltalk will not have any effect without an excellent partner for hardware and for AI algorithms. Maybe the suitable Fraunhofer institute? At least they invented mp3. > > Best regards, Bernhard > > >> Am 15.04.2019 um 17:54 schrieb Nowak, Helge <HNowak(a)cincom.com <mailto:HNowak@cincom.com>>: >> >> Dear Bernhard, Alexandre and all, <> >> >> Thanks Bernhard for pointing to this. I would have missed it completelyâ¦ >> >> The German BMBF (Bundesministerium fÃ¼r Bildung und Forschung = German Federal Ministry of Research and Technology) started this competition for German universities and public research centers. It is targeted at increasing energy efficiency for AI systems. The aim is to increase Germanyâs competencies and competitiveness in this sector which is deemed to be a future key technology with the potential of disruptive innovation. >> >> It is clear that the energy efficiency is less determined by what programming language is used and what virtual machine is run on some standard hardware. The real gains are rather found in maybe novel algorithms, surely in novel hardware architectures and implementations. Indeed, when you look at the details of the competition (link below) that is exactly the case: any proposed solutions submitted to the competition must belong to one of three categories: FPGAs, ASIC s in 130 nm technology or ASICs in FDSOI technology. Close hardware/software co-design is explicitly requested. Not eligible are solutions that only optimize software components or use commercially available hardware unchanged. >> >> Does this mean that this competition is of no interest to ambitious Smalltalkers? No! In contrary. With Smalltalk being a perfect interactive modeling, exploration and simulation tool we Smalltalkers can help our competition team to build, explore and optimize their ideas before and while building them in hardware. Also hardware is nothing without software. Smalltalk is in my view best positioned to execute the desired co-design in a co-evolutionary way. Certainly we could demonstrate modern âagileâ engineering approaches as a side-means to increase competitiveness. >> >> Everyone interested should take a look at the competition here:https://www.bmbf.de/foerderungen/bekanntmachung-2371.html <https://www.bmbf.de/foerderungen/bekanntmachung-2371.html> (in German, obviously). >> >> Please also forward to all people who might be interested. >> >> Cheers >> Helge >> >> Helge Nowak >> Cincom Smalltalk Technical Account Manager >> <image001.png> <http://www.cincomsmalltalk.com/> >> >> Cincom Systems GmbH & Co. oHG >> HumboldtstraÃe 3 >> 60318 Frankfurt am Main >> GERMANY > >> office >> mobile >> >> website >> email >> +49 89 89 66 44 94 >> +49 172 74 00 402 >> >> http://www.cincomsmalltalk.com <http://www.cincomsmalltalk.com/> >> hnowak(a)cincom.com <mailto:hnowak@cincom.com> >> A standpoint is an intellectual horizon of radius zero. -- Albert Einstein >> >> GeschÃ¤ftsfÃ¼hrer/Managing Directors: Thomas M. Nies, Donald E. Vick >> oHG mit Sitz/based in Frankfurt am Main (Amtsgericht Frankfurt am Main HRA 50297) >> Pers. haftender Gesellschafter/Partner liable to unlimited extent: >> Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht KÃ¶nigstein/Ts. HRB 5069) >> >> --- CONFIDENTIALITY STATEMENT --- >> This e-mail transmission contains information that is intended to be privileged and confidential. It is intended only for the addressee named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited, please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. > >> >> >> Von: Alexandre Bergel [mailto:alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>] >> Gesendet: Freitag, 12. April 2019 19:08 >> An: Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> >> Cc: VisualWorks mailing list list <vwnc(a)cs.uiuc.edu <mailto:vwnc@cs.uiuc.edu>>; pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >> Betreff: Re: [vwnc] most energy efficient AI system - challenge of the German Federal Ministry of Education and Research BMBF >> >> Hello, >> >> We conducted some experiment in characterizing virtual machine from an energetic point of view. Results are not public yet. This is just to say this is a topic that I am interested in. >> >> Cheers, >> Alexandre >> >> >> On Apr 11, 2019, at 5:29 PM, Bernhard HÃ¶fner <bernhard.hoefner(a)web.de <mailto:bernhard.hoefner@web.de>> wrote: >> >> Hello Group, >> the German BMBF advertised a reward for the most energy efficient AI system, see: https://www.bmbf.de/de/mehr-ki-erfordert-weniger-energie-8156.html <https://www.bmbf.de/de/mehr-ki-erfordert-weniger-energie-8156.html> (in German), and I am wondering what is the position of Smalltalk in that field or what it could be. From the early 90th I know that much of the pretended slowness of Smalltalk was absorbed by the more efficient programs due to better analysis, concepts, design and development tools (and maybe developers ? ). >> >> Best Regards, Bernhard > > -- > > Kind Regards, > > Sean Glazier > 603 892 0167 cell > 603 583 4575 Skype phone > Skype Id: visualwave >

April 24, 2019

Re: [Pharo-dev] FloatArray

by Jimmie Houchin

That would be awesome. There is most definitely interest. Thanks. 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 > >

April 24, 2019

Re: [Pharo-dev] FloatArray

by ducasse

> On 24 Apr 2019, at 07:20, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> 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. Yes there is. I know that oleksandr wants to crunch a lot of numbers. > > 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 > >

April 24, 2019

Re: [Pharo-dev] FloatArray

by Serge Stinckwich

On Wed, Apr 24, 2019 at 6:20 AM Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> 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. > > Yes, we be nice to have a Pharo port. I would really like to integrate this with PolyMath in one way or another. Do you have a benchmark to test the performance ? We have already one implementation of SVD in PolyMath. We can compare the results with LAPACK. Not sure we can do sum of vectors or matrices with LAPACK ? Regards, -- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of YaoundÃ© I, Cameroun "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich

April 24, 2019