April 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Moving/rolling average implementations ?

by CÃ©drick BÃ©ler

Superb, thank you Richard, very interesting answer :) For the rounding issue, since I got bitten once, I most of the time use ScaleDecimal instead of floats for data anyway. Cheers, CÃ©drick > Le 10 avr. 2020 Ã 05:04, Richard O'Keefe <raoknz(a)gmail.com> a Ã©crit : > > Let's take the inheritance issue first. > Yes, Collection has some subclasses where #average makes no sense, > such as String. If any subclass of Collection should have #average, it is > Array, as #(1 2 3 4) average makes perfect sense. > BUT #($a $b $c $d) average makes exactly as much sense as 'abcd' average. > So we have > - subclasses where a method never makes sense (String) > - subclasses where a method always makes sense (ByteArray) > - subclasses where a method may or may not make sense (Array). > Traits will not help at all with the third category. > Historic Smalltalk practice has been to define methods like > String>>average self shouldNotImplement. > to "cancel" inappropriate methods to deal with the "never" subclasses, > but that still does not help with the "maybe" ones. > > In my own code I try very hard to ensure that a method is available in > a class if and only if the class can have instances where the method > makes sense. That is, I try to make sure that #respondsTo: is "honest". > It is not always practical. > > This is not a problem that is peculiar to Smalltalk. Java and C# and C++ > and you-name-it also have the "maybe" problem, where a method seems > to be available for an object but thanks to its state it is not. > > As long as sending a message to an inappropriate object (whether due to > its class or its state) results in *some* exception, do we really have a problem? > 'abcd' average > 'abcd' asArray average > result in the same error. > > Now for the roundoff error issue. > > Oh dear, we really need to do a much better job educating programmers > about floating point, we really do. In real number arithmetic, > (a + b) - a = b > is always true. In floating-point arithmetic it is not. > This is easiest to see in cases like > (1.0e20 + 1.0) - 1.0e20 > where Pharo answers 0.0 instead of 1.0. > Less extreme cases still give you roundoff error. > > Much has been written about how to stably update mean, variance, &c. > The simplest thing is to use Welford's algorithm for the weighted mean, > using weight +1 to add the new element and -1 to remove the old. > > On Thu, 9 Apr 2020 at 19:33, Christian Haider <christian.haider(a)smalltalked-visuals.com <mailto:christian.haider@smalltalked-visuals.com>> wrote: > I donât see how rounding errors could accumulate, if you keep the sum and not the average. > > The rounding errors should be neutral, because each element is added once and subtracted once. > > If + and â is symmetrical in this respect, rounding inaccuracies should balance out. > > > > Cheers, > > Christian > > > > Von: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org>> Im Auftrag von Richard O'Keefe > Gesendet: Donnerstag, 9. April 2020 05:26 > An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Betreff: Re: [Pharo-users] Moving/rolling average implementations ? > > > > I note that "self species ofSize: n" is not generally a good idea. > > Consider ByteArray, ShortIntegerArray, WordArray. > > Computing rolling means of these is perfectly sensible, > > but the results will not fit into an array of the same species. > > I'd stick with Array. > > > > The suggestion about subtracting an old element and adding a new > > one is great for integers, but for floating-point numbers risks > > accumulating errors. > > > > The > > > > On Wed, 8 Apr 2020 at 20:07, CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>> wrote: > > Hi, > > > > I wanted to do a moving/rolling average on raw data [1]. > > I havenât find code for that (maybe this is done in polymath though). > > > > So I ended writing that (I thing this is SMA): > > > > SequenceableCollection>>movingAverage: anOrder > "Answer the moving or rolling average for anOrder window" > > > > | retval size x y | > > anOrder <= 0 ifTrue: [ Error signal: 'the order must be positive']. > > size := self size - anOrder. > > size negative ifTrue: [ Error signal: 'the collection size is too small']. > > retval := self species ofSize: size + 1. > > > > x := 1. > > y := anOrder. > > [y <= self size ] whileTrue: [ > > retval at: x put: (self copyFrom: x to: y) average > > x := x + 1. y := y + 1 > > ]. > > ^retval > > > > Not perfect but seems to works quite well (thatâs probably better to remove copyFrom: and use some kind of buffer instead). > > > > Any interest in that ? If any existing code too, Iâll be interested especially for other implementation (weighted, exponential) ? > > > > <image001.png> > > > > (#(118 113 105 105 103 99 98 101 100 107) movingAverage: 3) collect: [:v | v asScaledDecimal: 1 ] . > > > > "an Array(112.0s1 107.7s1 104.3s1 102.3s1 100.0s1 99.3s1 99.7s1 102.7s1)" > > > > Cheers, > > CÃ©drick > > > > > > > > [1] https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html <https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html> (in French but is understandable) > > >

April 10, 2020

Re: [Pharo-users] Thinking aloud about project at hand

by Hilaire

Hi, No doubt Pharo will fit the task. I developed a financial application for mortgages debt consolidation where the sources of data were numerous. With Pharo you will build a model with classes representing each part of the domain of your data set. With Tests you will consolidate your model, important when you change your model it will ensure your computations are still valid. I use it a lot in mortgage, debt ratio and debt consolidation calculus. From your description, it seems your application will be mono-user. If so any text file to keep the data will be ok: xml, json, csv. But sqlite could be a very nice option too, I think this is what I will use. I think you will enjoy using Pharo to write your app. Hilaire Le 09/04/2020 Ã 21:12, TomaÅ¾ Turk a Ã©critÂ : > I'm thinking about implementing a software solution in Pharo (as one > of the candidate environments), it's a project that I'm dealing with > professionally. The goal is to develop a financial planning/simulation > application on the country level, which is at present developed as a > set of interrelated Excel spreadsheets. The requirement is that the > solution should be more "manageable", resilient and straightforward > than Excel permits, that it should present a workflow to the user - > i.e. , that the tasks the user should do are suggested through the GUI. > -- Dr. Geo http://drgeo.eu

April 10, 2020

Re: [Pharo-users] Moving/rolling average implementations ?

by Richard O'Keefe

Let's take the inheritance issue first. Yes, Collection has some subclasses where #average makes no sense, such as String. If any subclass of Collection should have #average, it is Array, as #(1 2 3 4) average makes perfect sense. BUT #($a $b $c $d) average makes exactly as much sense as 'abcd' average. So we have - subclasses where a method never makes sense (String) - subclasses where a method always makes sense (ByteArray) - subclasses where a method may or may not make sense (Array). Traits will not help at all with the third category. Historic Smalltalk practice has been to define methods like String>>average self shouldNotImplement. to "cancel" inappropriate methods to deal with the "never" subclasses, but that still does not help with the "maybe" ones. In my own code I try very hard to ensure that a method is available in a class if and only if the class can have instances where the method makes sense. That is, I try to make sure that #respondsTo: is "honest". It is not always practical. This is not a problem that is peculiar to Smalltalk. Java and C# and C++ and you-name-it also have the "maybe" problem, where a method seems to be available for an object but thanks to its state it is not. As long as sending a message to an inappropriate object (whether due to its class or its state) results in *some* exception, do we really have a problem? 'abcd' average 'abcd' asArray average result in the same error. Now for the roundoff error issue. Oh dear, we really need to do a much better job educating programmers about floating point, we really do. In real number arithmetic, (a + b) - a = b is always true. In floating-point arithmetic it is not. This is easiest to see in cases like (1.0e20 + 1.0) - 1.0e20 where Pharo answers 0.0 instead of 1.0. Less extreme cases still give you roundoff error. Much has been written about how to stably update mean, variance, &c. The simplest thing is to use Welford's algorithm for the weighted mean, using weight +1 to add the new element and -1 to remove the old. On Thu, 9 Apr 2020 at 19:33, Christian Haider < christian.haider(a)smalltalked-visuals.com> wrote: > I donât see how rounding errors could accumulate, if you keep the sum and > not the average. > > The rounding errors should be neutral, because each element is added once > and subtracted once. > > If + and â is symmetrical in this respect, rounding inaccuracies should > balance out. > > > > Cheers, > > Christian > > > > *Von:* Pharo-users <pharo-users-bounces(a)lists.pharo.org> *Im Auftrag von *Richard > O'Keefe > *Gesendet:* Donnerstag, 9. April 2020 05:26 > *An:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Betreff:* Re: [Pharo-users] Moving/rolling average implementations ? > > > > I note that "self species ofSize: n" is not generally a good idea. > > Consider ByteArray, ShortIntegerArray, WordArray. > > Computing rolling means of these is perfectly sensible, > > but the results will not fit into an array of the same species. > > I'd stick with Array. > > > > The suggestion about subtracting an old element and adding a new > > one is great for integers, but for floating-point numbers risks > > accumulating errors. > > > > The > > > > On Wed, 8 Apr 2020 at 20:07, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > Hi, > > > > I wanted to do a moving/rolling average on raw data [1]. > > I havenât find code for that (maybe this is done in polymath though). > > > > So I ended writing that (I thing this is SMA): > > > > SequenceableCollection>>movingAverage: anOrder > "Answer the moving or rolling average for anOrder window" > > > > | retval size x y | > > anOrder <= 0 ifTrue: [ Error signal: 'the order must be positive']. > > size := self size - anOrder. > > size negative ifTrue: [ Error signal: 'the collection size is too > small']. > > retval := self species ofSize: size + 1. > > > > x := 1. > > y := anOrder. > > [y <= self size ] whileTrue: [ > > retval at: x put: (self copyFrom: x to: y) average > > x := x + 1. y := y + 1 > > ]. > > ^retval > > > > Not perfect but seems to works quite well (thatâs probably better to > remove copyFrom: and use some kind of buffer instead). > > > > Any interest in that ? If any existing code too, Iâll be interested > especially for other implementation (weighted, exponential) ? > > > > > > (#(118 113 105 105 103 99 98 101 100 107) movingAverage: 3) collect: [:v | > v asScaledDecimal: 1 ] . > > > > "an Array(112.0s1 107.7s1 104.3s1 102.3s1 100.0s1 99.3s1 99.7s1 102.7s1)" > > > > Cheers, > > CÃ©drick > > > > > > > > [1] > https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html (in > French but is understandable) > > > >

April 10, 2020

Thinking aloud about project at hand

by TomaÅ¾ Turk

Dear all, I'm thinking about implementing a software solution in Pharo (as one of the candidate environments), it's a project that I'm dealing with professionally. The goal is to develop a financial planning/simulation application on the country level, which is at present developed as a set of interrelated Excel spreadsheets. The requirement is that the solution should be more "manageable", resilient and straightforward than Excel permits, that it should present a workflow to the user - i.e. , that the tasks the user should do are suggested through the GUI. The majority of the data is in a form of a time series (for instance: GDP for a series of years). There are many variables in the model which shoud be calculated from other variables, year by year. There are also lagged variables (the value for the current year depends from the value of previous year), and running averages. There are also some variables which are not time series (parameters). As a part of GUI, there is a need to present the results as diagrams, too (scatterplots, line charts), otherwise tables are the output. I found Pharo to be a very elegant language and environment, with version 8.0 it became pretty stable, however I don't have any experiences in building software solutions of this type in Smalltalk. In other words, I'd like to be more confident in setting the architecture, both in the sense of the model content (variables interrelation) and the architecture of classes. Besides, for the calculated variables I'd like to have a relatively simple syntax to define them (like 'GDPpC <- GDP / Population'). My thoughts and questions: - for easier maintenance I'd like to separate the data from the code - so the question is what would be the best way to implement persistence (another Pharo image - with what?, some relational database, XML/JSON, flat files ...) - I wonder what would be the best "architecture" of classes - so, we have a lot of aggregate variables like GDP and population, which can be grouped at least according to the stage in the planning workflow. There are also resulting (calculated) variables (e.g. GDP per capita). On the other hand, since this is a planning software, it's a kind of simulation, where we have a "data warehouse", experiments and results - As a core packages I would use Spec2, Roassal, and PolyMath. I'm just thinking aloud, and would greatly appreciate any thoughts from experienced Pharoers :-) Best wishes, Tomaz

April 9, 2020

Re: [Pharo-users] Moving/rolling average implementations ?

by CÃ©drick BÃ©ler

Hi Richard and Christian, thanks for the comments/suggestions. For the "self species ofSizeâ¦ Â», I got inspiration from the image like with #overlappingPairsCollect: As for float rounding errors, that interesting to consider indeed. Iâll try a buffer variant. Some related questions for my OO culture ;-) : #average is defined in Collectionâ¦ That makes me wonder (especially in Collection hierarchy) that some methods are not applicable to some subclass. I think this is a common problem with inheritance ? Whatâs the way to deal with that ? Traits ? I found #shouldNotImplement that is used 106 times in one P8 image. Is it a good/favored pattern to prevent usage of such methods ? Cheers, CÃ©drick PS: would such method be a candidate for integration in base image ? If yes, I could try a PR.

April 9, 2020

Re: [Pharo-users] Automation of MS Office from Pharo

by Ben Coman

I'd be very interested to hear how this ends up. Parsing Outlook mails from Pharo may prove useful in my day job. cheers -ben On Wed, 8 Apr 2020 at 18:02, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > Hello Pablo > > Success! I have rerun one of the troublesome cases, with no problem. I > then re-ran the test on the latest 16 messages, collecting all the HTML > outputs in an array, which took just over 5 secs total; quicker than I > expected. The longest texts, from the most verbose newsletters, run from > 267K to over 300K, so that is where they ran into the limit we found > yesterday. > > I now know that I can pass the HTML to the XMLHTMLParser in memory, > without saving to file first; this will be more convenient. Thanks for the > prompt help. > > @Guillermo - All this is a proof of possibility, it will need to be > combined with other bits I am working on to make the automated system I > want. I shall let you know when it is worked out - but it won't be in the > next few days! > > Thanks to all > > Peter Kenny > > -----Original Message----- > From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of > Guillermo Polito > Sent: 08 April 2020 09:20 > To: TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si>; Any question about pharo is > welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Automation of MS Office from Pharo > > Cool, thanks to the three :) > > @Peter, Iâd like if you tell us at the end if you had success at > automating you mail workflow ^^ > > > El 8 abr 2020, a las 10:15, TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> > escribiÃ³: > > > > Thanks Pablo for your quick response! I tested 32 and 64 bit images with > >1.000.000 strings and it works just fine. > > > > Best wishes, > > Tomaz > > > > > > ------ Original Message ------ > > From: "tesonep(a)gmail.com" <tesonep(a)gmail.com> > > To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > > Cc: "TomaÅ¾ Turk" <tomaz.turk(a)ef.uni-lj.si> > > Sent: 8.4.2020 9:54:35 > > Subject: Re: [Pharo-users] Automation of MS Office from Pharo > > > >> Hi!!! > >> This was a great report. I have submitted a fix in the master of > Pharo-COM. > >> > >> Basically the problem was to free twice the BSTR in the Variant. > >> It was being free in the access to the value and in the free of the > struct. > >> Why it works with other BSTR when they are smaller, I cannot know. > >> > >> I have added another smoke test using Word > >> > >> Can you try the fix? > >> > >> Thanks, both for helping me with the reports, they were great. > >> > >> On Wed, Apr 8, 2020 at 9:37 AM PBKResearch <peter(a)pbkresearch.co.uk> > wrote: > >>> > >>> Tomaz, that was my understanding from the VBA piece you cited > yesterday. So presumably it must be something in Pharo-Com which imposes > the limits we have seen. I am OK at the moment, because all this work is > just an exploration of possibilities; I can wait until you and Pablo have > sorted it out. But from the results of your tests, a maximum of 16K in > 64-bit systems must be a serious limitation, so something in Pharo-Com > needs fixing. > >>> > >>> > >>> > >>> For my immediate work, I shall continue exporting the full text using > MailItem.SaveAs; my further processing uses files I have exported manually > in this way, so itâs not a problem. > >>> > >>> > >>> > >>> Thanks > >>> > >>> > >>> > >>> Peter Kenny > >>> > >>> > >>> > >>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of > TomaÅ¾ Turk > >>> Sent: 08 April 2020 07:58 > >>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > >>> Subject: Re: [Pharo-users] Automation of MS Office from Pharo > >>> > >>> > >>> > >>> Thanks, Stephane, for the acknowledgement. Peter, as I understand, the > limits in COM BSTR data type are defined by the header's length prefix > (which is 4 bytes) and software implementatios - for instance, string data > type in Visual Basic for Applications is described as "a variable-length > string can contain up to approximately 2 billion (2^31) characters", which > is in line with the BSTR header. I'm not sure if the OS architecture (32 > and 64 bit) influences these values. > >>> > >>> > >>> > >>> Best wishes, > >>> > >>> Tomaz > >>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Pablo Tesone. > >> tesonep(a)gmail.com > > > > > > > >

April 9, 2020

Re: [Pharo-users] Moving/rolling average implementations ?

by Christian Haider

I donât see how rounding errors could accumulate, if you keep the sum and not the average. The rounding errors should be neutral, because each element is added once and subtracted once. If + and â is symmetrical in this respect, rounding inaccuracies should balance out. Cheers, Christian Von: Pharo-users <pharo-users-bounces(a)lists.pharo.org> Im Auftrag von Richard O'Keefe Gesendet: Donnerstag, 9. April 2020 05:26 An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Betreff: Re: [Pharo-users] Moving/rolling average implementations ? I note that "self species ofSize: n" is not generally a good idea. Consider ByteArray, ShortIntegerArray, WordArray. Computing rolling means of these is perfectly sensible, but the results will not fit into an array of the same species. I'd stick with Array. The suggestion about subtracting an old element and adding a new one is great for integers, but for floating-point numbers risks accumulating errors. The On Wed, 8 Apr 2020 at 20:07, CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com> > wrote: Hi, I wanted to do a moving/rolling average on raw data [1]. I havenât find code for that (maybe this is done in polymath though). So I ended writing that (I thing this is SMA): SequenceableCollection>>movingAverage: anOrder "Answer the moving or rolling average for anOrder window" | retval size x y | anOrder <= 0 ifTrue: [ Error signal: 'the order must be positive']. size := self size - anOrder. size negative ifTrue: [ Error signal: 'the collection size is too small']. retval := self species ofSize: size + 1. x := 1. y := anOrder. [y <= self size ] whileTrue: [ retval at: x put: (self copyFrom: x to: y) average x := x + 1. y := y + 1 ]. ^retval Not perfect but seems to works quite well (thatâs probably better to remove copyFrom: and use some kind of buffer instead). Any interest in that ? If any existing code too, Iâll be interested especially for other implementation (weighted, exponential) ? (#(118 113 105 105 103 99 98 101 100 107) movingAverage: 3) collect: [:v | v asScaledDecimal: 1 ] . "an Array(112.0s1 107.7s1 104.3s1 102.3s1 100.0s1 99.3s1 99.7s1 102.7s1)" Cheers, CÃ©drick [1] https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html (in French but is understandable)

April 9, 2020

Re: [Pharo-users] Moving/rolling average implementations ?

by Richard O'Keefe

I note that "self species ofSize: n" is not generally a good idea. Consider ByteArray, ShortIntegerArray, WordArray. Computing rolling means of these is perfectly sensible, but the results will not fit into an array of the same species. I'd stick with Array. The suggestion about subtracting an old element and adding a new one is great for integers, but for floating-point numbers risks accumulating errors. The On Wed, 8 Apr 2020 at 20:07, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hi, > > I wanted to do a moving/rolling average on raw data [1]. > I havenât find code for that (maybe this is done in polymath though). > > So I ended writing that (I thing this is SMA): > > SequenceableCollection>>movingAverage: anOrder > "Answer the moving or rolling average for anOrder window" > > | retval size x y | > anOrder <= 0 ifTrue: [ Error signal: 'the order must be positive']. > size := self size - anOrder. > size negative ifTrue: [ Error signal: 'the collection size is too > small']. > retval := self species ofSize: size + 1. > > x := 1. > y := anOrder. > [y <= self size ] whileTrue: [ > retval at: x put: (self copyFrom: x to: y) average > x := x + 1. y := y + 1 > ]. > ^retval > > Not perfect but seems to works quite well (thatâs probably better to > remove copyFrom: and use some kind of buffer instead). > > Any interest in that ? If any existing code too, Iâll be interested > especially for other implementation (weighted, exponential) ? > > > (#(118 113 105 105 103 99 98 101 100 107) movingAverage: 3) collect: [:v | > v asScaledDecimal: 1 ] . > > "an Array(112.0s1 107.7s1 104.3s1 102.3s1 100.0s1 99.3s1 99.7s1 102.7s1)" > > Cheers, > CÃ©drick > > > > [1] > https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html (in > French but is understandable) > >

April 9, 2020

Re: [Pharo-users] Can't able to understand the code

by Renaud de Villemeur

Hi I'm not a FFI expert, and you code may not be the latest FFI version. However, If I look at it from Pharo side: When you want to use Athens with Cairo backend, you have to initialize its surface using a call like: surface := AthensCairoSurface extent: self extent Note that I'm calling a class method of AthensCairoSurface. In this example, 'self extent' will give you the size of the rectangle used by Morph for its bounds size. This, in turn, will call AthensCairoSurface class >> extent: anExtent Â ^self extent: anExtent format: CAIRO_FORMAT_ARGB32 and you reach: AthensCairoSurface class >> extent: anExtent format: aFormat^ ( self primImage: aFormat width: anExtent x height: anExtent y + 1) initialize Which lead you to: primImage: aFormat width: aWidth height: aHeight ^ self ffiCall: #(AthensCairoSurface cairo_image_surface_create (int aFormat, Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â int aWidth, Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â int aHeight) ) >From there, you have linked your pharo code done to initialize a Cairo surface. This will do a C call like: cairo_image_surface_create(CAIRO_FORMAT_ARGB32, aWidth, aHeight) This C call is documented here: https://www.cairographics.org/manual/cairo-Image-Surfaces.html, <https://www.cairographics.org/manual/cairo-Image-Surfaces.html> with surface enum here: https://www.cairographics.org/manual/cairo-Image-Surfaces.html#cairo-format… Through the magic of FFI, It'll return an instance ofÂ AthensCairoSurface you''ll be able to use directly in your Pharo code. You can have a look to AthensFlakeDemo in Athens-Demo for a full working example. Renaud Apr. 7, 2020, 22:44 by shawonhoque58(a)gmail.com: > actually i am just exploring UFFI from the pdf "Calling Foreign Functions > with Pharo" there one section is for external objects so i cant understand > that code what i attach as screenshot above. can u able to explain what > actually happen here ?? > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

April 8, 2020

Re: [Pharo-users] [Pharo-dev] Cover for PBE8

by Hilaire

Nice Le 07/04/2020 Ã 14:31, CÃ©drick BÃ©ler a Ã©critÂ : > I searched for free picture around the words lighthouse and/or (mosaic > patchwork painterâ¦). -- Dr. Geo http://drgeo.eu

April 8, 2020