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

[Guillermo Polito]

Hi Shawon,

where did you get the docs?

Have you tried the latest version (january/february this year)

http://books.pharo.org/booklet-uffi/ 

?

> El 8 abr 2020, a las 4:44, shawon58  escribió:
> 
> 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
> 

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

[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  On Behalf Of Tomaž Turk
Sent: 08 April 2020 07:58
To: Any question about pharo is welcome 
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

 

 

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

[teso...@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  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  On Behalf Of Tomaž 
> Turk
> Sent: 08 April 2020 07:58
> To: Any question about pharo is welcome 
> 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.
teso...@gmail.com

[Pharo-users] Moving/rolling average implementations ?

[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 
 
(in French but is understandable)

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

[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: "teso...@gmail.com" 
To: "Any question about pharo is welcome" 
Cc: "Tomaž Turk" 
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  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  On Behalf Of Tomaž Turk
 Sent: 08 April 2020 07:58
 To: Any question about pharo is welcome 
 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.
teso...@gmail.com

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

[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  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: "teso...@gmail.com" 
> To: "Any question about pharo is welcome" 
> Cc: "Tomaž Turk" 
> 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  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  On Behalf Of Tomaž 
>>> Turk
>>> Sent: 08 April 2020 07:58
>>> To: Any question about pharo is welcome 
>>> 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.
>> teso...@gmail.com
> 
> 

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

[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  Im Auftrag von Cédrick 
Béler
Gesendet: Mittwoch, 8. April 2020 10:07
An: Any question about pharo is welcome 
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)

 

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

[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  On Behalf Of Guillermo 
Polito
Sent: 08 April 2020 09:20
To: Tomaž Turk ; Any question about pharo is welcome 

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  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: "teso...@gmail.com" 
> To: "Any question about pharo is welcome" 
> Cc: "Tomaž Turk" 
> 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  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  On Behalf Of Tomaž 
>>> Turk
>>> Sent: 08 April 2020 07:58
>>> To: Any question about pharo is welcome 
>>> 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.
>> teso...@gmail.com
> 
> 

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

[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  wrote:
>
> Not bad at all, made me smile.
>
> > On 7 Apr 2020, at 12:21, Nicolas Anquetil  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
> > 
>
>

[Pharo-users] [ANN] RewriteTool has successfully ported to Spec2

[stephan]

Thanks.

I've done a PR and also one in Matchtool


Stephan

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

[Alexandre Bergel via Pharo-users]

--- Begin Message ---
I like the mosaic

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Apr 7, 2020, at 8:31 AM, Cédrick Béler  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).
> 
> 
> 
> 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 
>  
> 
> There are some other free and available. This one is Creative Commons:
> https://www.flickr.com/photos/kaptainkobold/6699472801 
> 
> 
> => google image searches 
> 
>  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_-_Original_Spanish_design.png
>  
> .
>   Section_of_new_Eddystone_Lighthouse.jpg 
> .
> 
> 
> My 2 cents,
> Cédrick (preference for the spiral effect)
> 

--- End Message ---

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

[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

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

[Renaud de Villemeur via Pharo-users]

--- Begin Message ---
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, 

with surface enum here: 
https://www.cairographics.org/manual/cairo-Image-Surfaces.html#cairo-format-t
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 shawonhoqu...@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
>

--- End Message ---

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

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