- Pharo-dev - lists.pharo.org

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