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

[Pharo 8.0] Build #291: 3404-Update-to-Iceberg-171

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

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

May 24, 2019

[Pharo 8.0] Build #290: 2279-We-should-revisit-definitionForNautilus-

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

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

May 24, 2019

[Pharo 8.0] Build #289: 3333-Test-Runner-history-menu-is-broken

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

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

May 24, 2019

[Pharo 8.0] Build #288: 3366-Do-not-run-testNoDeadWeakSubscriptionstestNoDeadSubscriptions

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

There is a new Pharo build available! The status of the build #288 was: FAILURE. The Pull Request #3367 was integrated: "3366-Do-not-run-testNoDeadWeakSubscriptionstestNoDeadSubscriptions" Pull request url: https://github.com/pharo-project/pharo/pull/3367 Issue Url: https://github.com/pharo-project/pharo/issues/3366 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 24, 2019

[Pharo 8.0] Build #287: 3388-Morphic-should-not-depend-on-Reflectivity

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

There is a new Pharo build available! The status of the build #287 was: SUCCESS. The Pull Request #3400 was integrated: "3388-Morphic-should-not-depend-on-Reflectivity" Pull request url: https://github.com/pharo-project/pharo/pull/3400 Issue Url: https://github.com/pharo-project/pharo/issues/3388 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 24, 2019

[Pharo 8.0] Build #286: 3385-Sync-Spec

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

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

May 23, 2019

[Pharo 8.0] Build #285: 3147-Class-converted-to-trait-is-unusable

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

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

May 23, 2019

[Call for Topics] Pharo TechTalks

by Marcus Denker

Hi, Last year we had some âPharo Tech Talksââ¦ we want to start that again. Dates: June 20 July 18 Sept 19 Oct 17 Nov 21 Dec 12 The time would be 17h local time (Berlin/Paris). -> If you want to âdriveâ one of those dates â> send me a mail. -> Dates are flexible, if you want to do a tech talk you can propose another date, too -> For the dates without special talk, I think I will do a âlets fix something smallâ session as the default. (with screen sharing, while the people on Discord help and discuss how to do it) What can it be? -> you could present your project -> you could give a âlectureâ -> you could do some tutorial -> You could moderate a audio chat around a topic If someone wants to do something, send me a mail. I will for now already add these dates to the events list at https://association.pharo.org/events Marcus

May 23, 2019

[Pharo 8.0] Build #284: 3381-MorphhandlesMouseMove-does--not-works-if-using-an-event-handler

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

There is a new Pharo build available! The status of the build #284 was: SUCCESS. The Pull Request #3382 was integrated: "3381-MorphhandlesMouseMove-does--not-works-if-using-an-event-handler" Pull request url: https://github.com/pharo-project/pharo/pull/3382 Issue Url: https://github.com/pharo-project/pharo/issues/3381 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 22, 2019

Re: [Pharo-dev] FloatArray

by Nicolas Cellier

And my less performant 2.7 GHz Intel Core i5 MBP with Apple accelerated VecLib is way faster than naive netlib BLAS (I guess it's multi-threaded): | a b | a := LapackDGEMatrix randNormal: #(1000 1000). b := LapackDGEMatrix randNormal: #(1000 1000). [a * b] timeToRun. 45 | a b | a := LapackSGEMatrix randNormal: #(1000 1000). b := LapackSGEMatrix randNormal: #(1000 1000). [a * b] timeToRun 19 Le mar. 21 mai 2019 Ã 10:05, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > Hi Serge, > this is good news, having tensor flow bindings is also a must! > I have this in Smallapack with pure CPU unaccelerated blas (no MKL, nor > ATLAS, just plain and dumb netlib code) > > | a b | > a := LapackDGEMatrix randNormal: #(1000 1000). > b := LapackDGEMatrix randNormal: #(1000 1000). > [a * b] timeToRun > 783 > > | a b | > a := LapackSGEMatrix randNormal: #(1000 1000). > b := LapackSGEMatrix randNormal: #(1000 1000). > [a * b] timeToRun > 448 > > Intel(R) Xeon(R) CPU E3-1245 v3 @ 3.40GHz > So I think that we can get much better with accelerated library! > > Le mar. 21 mai 2019 Ã 05:13, Serge Stinckwich <serge.stinckwich(a)gmail.com> > a Ã©crit : > >> There is another solution with my TensorFlow Pharo binding: >> https://github.com/PolyMathOrg/libtensorflow-pharo-bindings >> >> You can do a matrix multiplication like that : >> >> | graph t1 t2 c1 c2 mult session result | >> graph := TF_Graph create. >> t1 := TF_Tensor fromFloats: (1 to:1000000) asArray shape:#(1000 1000). >> t2 := TF_Tensor fromFloats: (1 to:1000000) asArray shape:#(1000 1000). >> c1 := graph const: 'c1' value: t1. >> c2 := graph const: 'c2' value: t2. >> mult := c1 * c2. >> session := TF_Session on: graph. >> result := session runOutput: (mult output: 0). >> result asNumbers >> >> Here I'm doing a multiplication between 2 matrices of 1000X1000 size in >> 537 ms on my computer. >> >> All operations can be done in a graph of operations that is run outside >> Pharo, so could be very fast. >> Operations can be done on CPU or GPU. 32 bits or 64 bits float operations >> are possible. >> >> This is a work in progress but can already be used. >> Regards, >> >> >> >> On Tue, May 21, 2019 at 6:54 AM Jimmie Houchin <jlhouchin(a)gmail.com> >> wrote: >> >>> I wasn't worried about how to do sliding windows. My problem is that >>> using LapackDGEMatrix in my example was 18x slower than FloatArray, which >>> is slower than Numpy. It isn't what I was expecting. >>> >>> What I didn't know is if I was doing something wrong to cause such a >>> tremendous slow down. >>> >>> Python and Numpy is not my favorite. But it isn't uncomfortable. >>> >>> So I gave up and went back to Numpy. >>> >>> Thanks. >>> >>> >>> >>> On 5/20/19 5:17 PM, Nicolas Cellier wrote: >>> >>> Hi Jimmie, >>> effectively I did not subsribe... >>> Having efficient methods for sliding window average is possible, here is >>> how I would do it: >>> >>> "Create a vector with 100,000 rows filles with random values (uniform >>> distrubution in [0,1]" >>> v := LapackDGEMatrix randUniform: #(100000 1). >>> >>> "extract values from rank 10001 to 20000" >>> w1 := v atIntervalFrom: 10001 to: 20000 by: 1. >>> >>> "create a left multiplier matrix for performing average of w1" >>> a := LapackDGEMatrix nrow: 1 ncol: w1 nrow withAll: 1.0 / w1 size. >>> >>> "get the average (this is a 1x1 matrix from which we take first element)" >>> avg1 := (a * w1) at: 1. >>> >>> [ "select another slice of same size" >>> w2 := v atIntervalFrom: 15001 to: 25000 by: 1. >>> >>> "get the average (we can recycle a)" >>> avg2 := (a * w2) at: 1 ] bench. >>> >>> This gives: >>> '16,500 per second. 60.7 microseconds per run.' >>> versus: >>> [w2 sum / w2 size] bench. >>> '1,100 per second. 908 microseconds per run.' >>> >>> For max and min, it's harder. Lapack/Blas only provide max of absolute >>> value as primitive: >>> [w2 absMax] bench. >>> '19,400 per second. 51.5 microseconds per run.' >>> >>> Everything else will be slower, unless we write new primitives in C and >>> connect them... >>> [w2 maxOf: [:each | each]] bench. >>> '984 per second. 1.02 milliseconds per run.' >>> >>> Le dim. 19 mai 2019 Ã 14:58, Jimmie <jlhouchin(a)gmail.com> a Ã©crit : >>> >>>> On 5/16/19 1:26 PM, Nicolas Cellier wrote:> Any feedback on this? >>>> > Did someone tried to use Smallapack in Pharo? >>>> > Jimmie? >>>> > >>>> >>>> I am going to guess that you are not on pharo-users. My bad. >>>> I posted this in pharo-users as I it wasn't Pharo development question. >>>> >>>> I probably should have posted here or emailed you directly. >>>> >>>> All I really need is good performance with a simple array of floats. No >>>> matrix math. Nothing complicated. Moving Averages over a slice of the >>>> array. A variety of different averages, weighted, etc. Max/min of the >>>> array. But just a single simple array. >>>> >>>> Any help greatly appreciated. >>>> >>>> Thanks. >>>> >>>> >>>> On 4/28/19 8:32 PM, Jimmie Houchin wrote: >>>> Hello, >>>> >>>> I have installed Smallapack into Pharo 7.0.3. Thanks Nicholas. >>>> >>>> I am very unsure on my use of Smallapack. I am not a mathematician or >>>> scientist. However the only part of Smallapack I am trying to use at >>>> the >>>> moment is something that would be 64bit and compare to FloatArray so >>>> that I can do some simple accessing, slicing, sum, and average on the >>>> array. >>>> >>>> Here is some sample code I wrote just to play in a playground. >>>> >>>> I have an ExternalDoubleArray, LapackDGEMatrix, and a FloatArray >>>> samples. The ones not in use are commented out for any run. >>>> >>>> fp is a download from >>>> http://ratedata.gaincapital.com/2018/12%20December/EUR_USD_Week1.zip >>>> and unzipped to a directory. >>>> >>>> fp := '/home/jimmie/data/EUR_USD_Week1.csv' >>>> index := 0. >>>> pricesSum := 0. >>>> asum := 0. >>>> ttr := [ >>>> lines := fp asFileReference contents lines allButFirst. >>>> a := ExternalDoubleArray new: lines size. >>>> "la := LapackDGEMatrix allocateNrow: lines size ncol: 1. >>>> a := la columnAt: 1." >>>> "a := FloatArray new: lines size." >>>> lines do: [ :line || parts price | >>>> parts := ',' split: line. >>>> index := index + 1. >>>> price := Float readFrom: (parts last). >>>> a at: index put: price. >>>> pricesSum := pricesSum + price. >>>> (index rem: 100) = 0 ifTrue: [ >>>> asum := a sum. >>>> ]]] timeToRun. >>>> { index. pricesSum. asum. ttr }. >>>> "ExternalDoubleArray an Array(337588 383662.5627699992 >>>> 383562.2956199993 0:00:01:59.885)" >>>> "FloatArray an Array(337588 383662.5627699992 383562.2954441309 >>>> 0:00:00:06.555)" >>>> >>>> FloatArray is not the precision I need. But it is over 18x faster. >>>> >>>> I am afraid I must be doing something badly wrong. Python/Numpy is over >>>> 4x faster than FloatArray for the above. >>>> >>>> If I am using Smallapack incorrectly please help. >>>> >>>> Any help greatly appreciated. >>>> >>>> Thanks. >>>> >>>> >>>> >> >> -- >> 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, Cameroon >> "Programs must be written for people to read, and only incidentally for >> machines to execute." >> https://twitter.com/SergeStinckwich >> >

May 21, 2019