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

Re: [Pharo-dev] Cover for PBE8

by Alexandre Bergel

I like the mosaic Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Apr 7, 2020, at 8:31 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > Just a try. > > I searched for free picture around the words lighthouse and/or (mosaic patchwork painterâ¦). > A bit like this one (which is not free). > <GraphiqueCollÃ©-4.png> > > > Also, I kind of like the spiral effect which evoke practicing the internalâ¦ and the spiral effet (learning/getting better). > https://www.flickr.com/photos/28752865@N08/19369475232 <https://www.flickr.com/photos/28752865@N08/19369475232> > > There are some other free and available. This one is Creative Commons: > https://www.flickr.com/photos/kaptainkobold/6699472801 <https://www.flickr.com/photos/kaptainkobold/6699472801> > <GraphiqueCollÃ©-2.png> > => google image searches <https://www.google.com/search?q=lighthouse+inside+stairs&tbm=isch&ved=2ahUK…> on Â« free Â» internal stairs. > > > I also searched for Â« lighthouse anatomy / internals Â». Itâs nice but donât think usable out of the box. It should be stylized (and eventually adapted to programming internals). > https://commons.wikimedia.org/wiki/File:Antique_-_Maniguin_Lighthouse_-_Ori… <https://commons.wikimedia.org/wiki/File:Antique_-_Maniguin_Lighthouse_-_Ori…>. Section_of_new_Eddystone_Lighthouse.jpg <https://upload.wikimedia.org/wikipedia/commons/7/74/Section_of_new_Eddyston…>. > > > My 2 cents, > CÃ©drick (preference for the spiral effect) >

April 8, 2020

[ANN] RewriteTool has successfully ported to Spec2

by stephan

Thanks. I've done a PR and also one in Matchtool Stephan

April 8, 2020

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

by Richard O'Keefe

Speaking of PBE8, the draft I downloaded still mentions SkipList in the Collections chapter. On Tue, 7 Apr 2020 at 22:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Not bad at all, made me smile. > > > On 7 Apr 2020, at 12:21, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > > > > > :-) > > > > > > > > > > On Tue, 2020-04-07 at 09:45 +0200, StÃ©phane Ducasse wrote: > >> Hello > >> > >> We are working on PBE80 and we are looking for a new cool cover. > >> If you think that you can do this we are all ears. > >> > >> S > >> -------------------------------------------- > >> StÃ©phane Ducasse > >> http://stephane.ducasse.free.fr / http://www.pharo.org > >> 03 59 35 87 52 > >> Assistant: Julie Jonas > >> FAX 03 59 57 78 50 > >> TEL 03 59 35 86 16 > >> S. Ducasse - Inria > >> 40, avenue Halley, > >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > >> Villeneuve d'Ascq 59650 > >> France > >> > > -- > > Nicolas Anquetil > > RMod team -- Inria Lille > > <pbe.png> > >

April 8, 2020

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

by PBKResearch

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 8, 2020

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

by Christian Haider

Hi CÃ©drick, for smallCharts, I had to implement the same, but for stock market time series, which are a bit bigger than your example (like creating a 38 day moving average over 5 years). Always copying the values to average is far too slow in this case. My solution is to add up the first n (for an n-movAvg) numbers and remember the sum. The new average point is of course the sum divided by n. For the next point you subtract the first number from the sum and add the next (1 + n th) number to the sum. Happy hacking, Christian Von: Pharo-users <pharo-users-bounces(a)lists.pharo.org> Im Auftrag von CÃ©drick BÃ©ler Gesendet: Mittwoch, 8. April 2020 10:07 An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Betreff: [Pharo-users] Moving/rolling average implementations ? 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 8, 2020

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

by Guillermo Polito

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 8, 2020

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

by TomaÅ¾ Turk

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 8, 2020

Moving/rolling average implementations ?

by CÃ©drick BÃ©ler

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 <https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html> (in French but is understandable)

April 8, 2020

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

by tesonep＠gmail.com

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 8, 2020

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

by PBKResearch

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

April 8, 2020