[Pharo-dev] Re: Broken window alert

[Guillermo Polito]

> El 6 abr 2021, a las 22:55, Sven Van Caekenberghe  escribió:
> 
> I agree, could you post a link to or a list of the broken tests ?

Sure :)

The CI:
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/
 
<https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/>

Last Three Jobs:
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/1286/
 
<https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/1286/>
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/1285/
 
<https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/1285/>
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/1284/
 
<https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/1284/>


> 
>> On 6 Apr 2021, at 22:54, Guillermo Polito  wrote:
>> 
>> Hi Guys,
>> 
>> With Pablo we were discussing that it would be nice to stop with the 
>> integrations until we fix the broken tests.
>> We have crossed the 20 broken tests for more than 20 builds.
>> We should put some energy in fixing those, but we are afraid that if we 
>> continue this way, eventually it will become unmanageable.
>> 
>> Cheers,
>> Guille

[Pharo-dev] Broken window alert

[Guillermo Polito]

Hi Guys,

With Pablo we were discussing that it would be nice to stop with the 
integrations until we fix the broken tests.
We have crossed the 20 broken tests for more than 20 builds.
We should put some energy in fixing those, but we are afraid that if we 
continue this way, eventually it will become unmanageable.

Cheers,
Guille

[Pharo-dev] Re: PharoJ now available for Pharo10

[Guillermo Polito]

> El 1 abr 2021, a las 13:38, Noury Bouraqadi  escribió:
> 
> Hi everyone,
> 
> We continue to make progress during our weekly coding sessions. We are glad 
> to announce that this week we made a huge leap forward. Now PharoJS is 
> available for Pharo 10. To install it, run the following script in a Pharo 10 
> playground
> 
> Metacello new
>   baseline: 'PharoJS';
>   repository: 'github://PharoJS/PharoJS:pharo10';
>   load

Nice!!! I’ve tested my little tic tac toe game and it worked without changing 
anything !

[Pharo-dev] Re: Pharo - GSOC 2021

[Guillermo Polito]

Nice!!! Thanks everybody!!!

> El 11 mar 2021, a las 17:38, Hernán Morales Durand  
> escribió:
> 
> Congratulations :-)
> 
> Hernán
> 
> El jue, 11 mar 2021 a las 7:34, Serge Stinckwich ( >) escribió:
> Dear all,
> 
> great news I want to share with you: Pharo has been selected to be part of 
> GSOC 2021
> 
> https://summerofcode.withgoogle.com/organizations/?sp-search=pharo#4667274369171456
>  
> 
> 
> Thank you to the great team of admins for making this happen: Oleksandr 
> Zaitsev, Gordana Rakic and Juan Pablo Sandoval Alcocer !
> 
> We will send updates soon on the student selection process soon.
> Regards,
> -- 
> Serge Stinckwich
> https://twitter.com/SergeStinckwich 

[Pharo-dev] Re: Cmd-line (headless) Pharo Launcher - structure of commands

[Guillermo Polito]

Hi David,

I think this is cool :)

The things you describe are what I was having in mind too.
The commands I use the most from the UI are:
 - create/delete an image
 - launch it

:)

About the design of the command line, have you checked Clap? It should provide 
support for parsing command line arguments and printing all the helps for you.

Also, If I can dream, I’d like that the launcher remembers the open images, so 
we could also introduce something like

launcher kill imageXXX

Thanks!!!
G.


> El 10 mar 2021, a las 14:00, baj...@gmail.com escribió:
> 
> Hi all!
> I had a chat with Stephane regarding his inquiry about Pharo Launcher 
> controlled from command-line interface (headless mode).
> I'd like to ask core Pharo developers to briefly review, if current list of 
> commands seems to be ok. Document here: 
> https://github.com/Bajger/Pharo-snippets/blob/master/pharoLauncherCmdLine-description.md
>  
> 
>  
> Some notes: 
> - List of commands is based on what can be executed on UI of Pharo Launcher 
> - there are some open questions, that you can try to comment on. 
> 
> Also, please suggest, if I should move .md page to some more appropriate 
> project (e.g. Pharo wiki?) 
> Thanks for feedback! 
> David
> 

[Pharo-dev] Re: Progress Report -> Refactoring Project - ( February 1 - 5 )

[Guillermo Polito]

Hi Tim, 

you may want to have a look at

Preserving Instance State during Refactorings in Live Environments
https://hal.archives-ouvertes.fr/hal-02541754/document

G

> El 13 feb 2021, a las 9:46, Tim Mackinnon  escribió:
> 
> I never thought of that implication - if ivars are proper objects (is that 
> now applied?) would this issue go away (an ivar would just get a new parent)?
> 
> This is a very interesting problem, as its a type of transaction, and I never 
> though of it that way - its easy to think of it as just dumb code - but in 
> effect it isn’t.
> 
> Tim
> 
> On Fri, 12 Feb 2021, at 4:30 PM, Sean P. DeNigris wrote:
>> Wonderful to have progress on this important topic - thank you!
>> 
>> Sorry I haven't been following closely (maybe you addressed it already), but
>> pushing up instance variables has a dangerous limitation - instances lose
>> any data held in that var. I guess it's because it's deleted from the
>> subclass prior to adding to the superclass to avoid duplicating. One
>> solution would be to add a var to the superclass with a mangled name, copy
>> the data for all instances, remove the var from the subclass, and then
>> rename the mangled var.
>> 
>> 
>> 
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>> 

[Pharo-dev] Re: Ephemeron Status?

[Guillermo Polito]

Hi Sean,

Ephemerons are working well in Pharo 9, as far as I am concerned, at least from 
the VM side.
We have thoroughly tested them and stressed the implementation with several 
thousand ephemerons.
And we have used them to prototype a precise memory profiler with a student 
during the summer (yet to be published).

But, there is still missing a good Ephemeron library from the image side.
We were planning on having that for Pharo 10, but if somebody wants to take the 
lead on that, you’re welcome.

Cheers,
G

> El 27 sept 2021, a las 20:56, s...@clipperadams.com escribió:
> 
> What is the status of ephemerons/weakly held objects? Is this fully working 
> or are there still limitations/gotchas? I have lost track
> 

[Pharo-dev] Re: Hardening Zinc's Core HTTP Server

[Guillermo Polito]

Thanks Sven, 51 days uptime is super encouraging :)

> El 30 nov 2021, a las 17:45, Sven Van Caekenberghe  escribió:
> 
> Hi,
> 
>> On 29 Oct 2021, at 20:42, Sven Van Caekenberghe > > wrote:
>> 
>> Here is yet another update:
>> 
>> The instances
>> 
>> - On Amazon AWS: http://34.245.183.130:1701 
>> 
>> - On Microsoft Azure: http://51.137.72.94:8080 
>> 
>> have now been running for 18+ days.
>> 
>> Having observed the overall amounts of critical resources inside the Pharo 
>> images, things look good.
>> 
>> Seaside WASSession cleanup goes slowly but does work over time.
>> 
>> Eventually I will stop at least the Azure instance because it costs me 
>> personal money.
> 
> I disabled the Microsoft Azure VM instance at http://51.137.72.94:8080 
>  to save money. Final uptime was 51 days.
> 
> Here is the final screenshot:
> 
> 
> 
> I'll leave the Amazon AWS VM instance at http://34.245.183.130:1701 
>  up for now.
> 
> Sven
> 
>>> On 11 Oct 2021, at 19:37, Sven Van Caekenberghe >> > wrote:
>>> 
>>> Here is an update on the status of both instances.
>>> 
>>> A couple of people tried fiddling with invalid input which did result in 
>>> exceptions, but everything was handled correctly so that the server kept on 
>>> functioning.
>>> 
>>> There were no spurious crashes.
>>> 
>>> There was one attack by Levente Uzonyi that was successful though. 
>>> 
>>> He used the fact that Seaside sessions are long lived (cached for a certain 
>>> time) combined with the fact that the Reddit.st  app 
>>> kept one GLORP database connection through P3 open to PostgreSQL and fired 
>>> off a small denial of service (DOS) attack. Eventually either the VM ran 
>>> out of space in the ExternalSemaphoreTable, making Socket creation, either 
>>> for database connections or for handling new HTTP request impossible or the 
>>> database's own connection limit was reached. At that point the HTTP server 
>>> or the Pharo VM stopped functioning.
>>> 
>>> Although Levente used a sequential number of requests, a concurrent number 
>>> of request could cause similar problems (related, but differently).
>>> 
>>> In looking at what he reported it also became clear that I accidentally 
>>> left a debugging exception handler active, which is not good in a 
>>> production image.
>>> 
>>> Both instances are now redeployed with the following changes:
>>> 
>>> - the Reddit.st  code was changed to not keep the 
>>> database connection open all the time, but instead connect/disconnect per 
>>> request. this might be a bit slower, but it conserves resources much better 
>>> and solves the original issue Levente reported
>>> 
>>> https://github.com/svenvc/Reddit/commit/f2e0a0dc00b9cbb68cfa4fb007906365ae66ab1b
>>>  
>>> 
>>> 
>>> - a new feature was added to Zinc HTTP Components' 
>>> ZnManagingMultiThreadedServer (the default) to enforce a maximum number of 
>>> concurrent connections being allowed (the limit is 32 by default, but 
>>> changeable if you know what you are doing). when the limit is reached, 503 
>>> Service Unavailable responses are sent to the excess clients and the 
>>> connection is closed. this should help protect against concurrent 
>>> connection DOS attacks
>>> 
>>> https://github.com/svenvc/zinc/commit/ac0f06e74e7ab129610c466cb1d7ea9533d29b4c
>>> 
>>> - the deploy script was changed to use the more primitive WAErrorHandler
>>> 
>>> https://github.com/svenvc/Reddit/commit/874b631e6dc0c04c8c0b687ef770d00540d282df
>>> 
>>> Thanks again to Levente for taking the time to try an attack and for 
>>> reporting it clearly.
>>> 
>>> Sven
>>> 
 On 29 Sep 2021, at 17:10, Sven Van Caekenberghe  wrote:
 
 Both instances have been up for 5 days now, looking for more testers.
 
> On 23 Sep 2021, at 17:03, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> Zinc HTTP Components [https://github.com/svenvc/zinc] has been a part of 
> Pharo since version 1.3 (2011). It is an open-source framework to deal 
> with the HTTP networking protocol, modelling all aspects involved. It 
> also offers both client and server functionality.
> 
> The reliability of the code base has improved steadily over the years, 
> thanks to virtually all Pharo developers using it, directly or 
> indirectly. Over the summer a number of issues that popped up after Pharo 
> 9 was released were resolved.
> 
> The robustness of the core HTTP server is one important aspect. To put 
> this quality further to the test, I deployed two servers with the same 
> demo Seaside application, Reddit.st, open to the internet, without any 
> further protections.
> 
> - On Amazon AWS: http://34.245.183.130:1701
> 
> - On 

[Pharo-dev] Re: Serious NetNameResolver regression

[Guillermo Polito]

Hi all,

it seems we need a new VM release.
The issue seems fixed since ~6 months ago

https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce104d8f38d60242fa1cc2bb

Pablo is updating the stable VMs just in this moment.

G

> El 16 jul 2021, a las 12:07, Sven Van Caekenberghe  escribió:
> 
> Anyway, for now, I added guards:
> 
> https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8
> https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64
> 
> but the core problem remains.
> 
>> On 15 Jul 2021, at 21:35, Gabriel Cotelli  wrote:
>> 
>> You're right Sven. The code in the image looks exactly the same betwen Pharo 
>> 8 and 9 but the behavior is different. 
>> 
>> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe  wrote:
>> 
>> 
>>> On 15 Jul 2021, at 16:42, Gabriel Cotelli  wrote:
>>> 
>>> Just doing 
>>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu';primNameLookupResult
>>> produces the bogus result. And both methods only call primitives in the 
>>> SocketPlugin. So I think that no image code is responsible for the behavior 
>>> change.
>> 
>> I don't know, but your example is not good. You have to wait else the result 
>> is always 0.0.0.0
>> 
>> Pharo 7
>> 
>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; 
>> waitForCompletionUntil: 5 
>> 
>> false (signal exception)
>> 
>> Pharo 9
>> 
>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; 
>> waitForCompletionUntil: 5
>> 
>> true (bogus 0.0.0.0 result)
>> 
>>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe  wrote:
>>> Hi,
>>> 
>>> It seems that we have a serious NetNameResolver regression: instead of 
>>> signalling an exception, a bogus value is returned.
>>> 
>>> Pharo 7:
>>> 
>>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: 
>>> NameLookupFailure do: [ :exception | exception ]. 
>>> 
>>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu'"
>>> 
>>> Pharo 9:
>>> 
>>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: 
>>> NameLookupFailure do: [ :exception | exception ]. 
>>> 
>>> "0.0.0.0"
>>> 
>>> This is bad. What is even worse is that the following kills your image 
>>> without leaving any trace (on macOS):
>>> 
>>> ZnClient new get: 'http://unknown-stfx.eu'.
>>> 
>>> Because it tries to connect to 0.0.0.0
>>> 
>>> On linux, at least there is a backtrace:
>>> 
>>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl
>>> NeoConsole 
>>> Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit)
>>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10.
>>> 
>>> 0.0.0.0
>>> pharo> ZnClient new get: 'http://unknown-stfx.eu'.
>>> 
>>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80
>>> [ConnectionTimedOut signal: 'Cannot connect to '
>>>, (NetNameResolver 
>>> stringFromAddress: hostAddress) , ':' , port asString] in 
>>> Socket>>connectTo:port:waitForConnectionFor:
>>>Receiver: a Socket[unconnected]
>>>Arguments and temporary variables: 
>>>hostAddress:0.0.0.0
>>>port:   80
>>>timeout:30
>>>Receiver's instance variables: 
>>>semaphore:  a Semaphore()
>>>socketHandle:   #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 0]
>>>readSemaphore:  a Semaphore()
>>>writeSemaphore: a Semaphore()
>>> 
>>> Socket>>waitForConnectionFor:ifTimedOut:
>>> Socket>>connectTo:port:waitForConnectionFor:
>>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port:
>>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port:
>>> ZdcSocketStream class(ZdcSimpleSocketStream 
>>> class)>>openConnectionToHost:port:timeout:
>>> ZnNetworkingUtils>>socketStreamToUrlDirectly:
>>> ZnNetworkingUtils>>socketStreamToUrl:
>>> ZnNetworkingUtils class>>socketStreamToUrl:
>>> 
>>> I had a quick look at changes to Network-Kernel but had no luck yet. 
>>> 
>>> Because of this running Zinc HTTP Components tests on macOS Pharo 9 also 
>>> kills the image (ZnClientTest>>#testIfFailNonExistingHost).
>>> 
>>> Of course, NetNameResolverTest does not do enough.
>>> 
>>> Sven

[Pharo-dev] Re: Array sum. is very slow

[Guillermo Polito]

Yes, I just saw also that I used an interval instead of an array… I need to 
sleep more ^^

Anyways, even with a 28k large array wether they are small integers or floats, 
I have "reasonable results” (where reasonable = not taking hours, nor minutes 
but a couple of milliseconds :P)

randarray := Array new: 28800 withAll: 0.
[randarray sum] bench "'2059.176 per second'"

randarray2 := Array new: 28800 withAll: 0.1234567.
[randarray2 sum] bench "'1771.737 per second’"

I join John’s request to see the Python code…
Is that possible?
G

> El 6 ene 2022, a las 23:35, Jimmie Houchin  escribió:
> 
> No, it is an array of floats. The only integers in the test are in the 
> indexes of the loops.
> 
> Number random. "generates a float  0.8188008774329387"
> 
> So in the randarray below it is an array of 28800 floats.
> 
> It just felt so wrong to me that Python3 was so much faster. I don't care if 
> Nim, Crystal, Julia are faster. But...
> 
> 
> I am new to Iceberg and have never shared anything on Github so this is all 
> new to me. I uploaded my language test so you can see what it does. It is a 
> micro-benchmark. It does things that are not realistic in an app. But it does 
> stress a language in areas important to my app.
> 
> 
> https://github.com/jlhouchin/LanguageTestPharo
> 
> 
> Let me know if there is anything else I can do to help solve this problem.
> 
> I am a lone developer in my spare time. So my apologies for any ugly code.
> 
> 
> Thanks for your help.
> 
> Jimmie
> 
> 
> On 1/6/22 15:07, Guillermo Polito wrote:
>> Hi Jummie,
>> 
>> Is it possible that your program is computing a lot of **very** large 
>> integers?
>> 
>> I’m just trying the following with small numbers, and I don’t see the issue. 
>> #sum executes on a 28k large collection around 20 million times per second 
>> on my old 2015 i5.
>> 
>> a := (1 to: 28000).
>> [a sum] bench "'20256552.490 per second’"
>> 
>> If you could share with us more data, we could take a look.
>> Now i’m curious.
>> 
>> Thanks,
>> G
>> 
>>> El 6 ene 2022, a las 21:37, Jimmie Houchin  escribió:
>>> 
>>> I have written a micro benchmark which stresses a language in areas which 
>>> are crucial to my application.
>>> 
>>> I have written this micro benchmark in Pharo, Crystal, Nim, Python, 
>>> PicoLisp, C, C++, Java and Julia.
>>> 
>>> On my i7 laptop Julia completes it in about 1 minute and 15 seconds, 
>>> amazing magic they have done.
>>> 
>>> Crystal and Nim do it in about 5 minutes. Python in about 25 minutes. Pharo 
>>> takes over 2 hours. :(
>>> 
>>> In my benchmarks if I comment out the sum and average of the array. It 
>>> completes in 3.5 seconds.
>>> And when I sum the array it gives the correct results. So I can verify its 
>>> validity.
>>> 
>>> To illustrate below is some sample code of what I am doing. I iterate over 
>>> the array and do calculations on each value of the array and update the 
>>> array and sum and average at each value simple to stress array access and 
>>> sum and average.
>>> 
>>> 28800 is simply derived from time series one minute values for 5 days, 4 
>>> weeks.
>>> 
>>> randarray := Array new: 28800.
>>> 
>>> 1 to: randarray size do: [ :i | randarray at: i put: Number random ].
>>> 
>>> randarrayttr := [ 1 to: randarray size do: [ :i | "other calculations 
>>> here." randarray sum. randarray average ]] timeToRun.
>>> 
>>> randarrayttr. "0:00:00:36.135"
>>> 
>>> 
>>> I do 2 loops with 100 iterations each.
>>> 
>>> randarrayttr * 200. "0:02:00:27"
>>> 
>>> 
>>> I learned early on in this adventure when dealing with compiled languages 
>>> that if you don’t do a lot, the test may not last long enough to give any 
>>> times.
>>> 
>>> Pharo is my preference. But this is an awful big gap in performance. When 
>>> doing backtesting this is huge. Does my backtest take minutes, hours or 
>>> days?
>>> 
>>> I am not a computer scientist nor expert in Pharo or Smalltalk. So I do not 
>>> know if there is anything which can improve this.
>>> 
>>> 
>>> However I have played around with several experiments of my #sum: method.
>>> 
>>> This implementation reduces the time on the above randarray in half.
>>> 
>>> sum: col
>>> | 

[Pharo-dev] Re: [lse-consortium-eng] Array sum. is very slow

[Guillermo Polito]

Yet, be careful, that way of benchmarking will have a lot of variation and
noise. Remember there is an OS, other apps open, even the CPU getting
hot/cold can introduce performance differences...

At least, that snippet should be run so many times (I do 100 iterations in
general), and the averages should be compared taking into account standard
deviation.



El dom., 9 ene. 2022 10:14, Stéphane Ducasse 
escribió:

> On my machine so this is the same.
>
> SQ5.3
>
> Test with 1000 elements
> Original #sum -> Time: 196 milliseconds, Total: 5.001448710680429e6
> Naive #sum -> Time: 152 milliseconds, Total: 5.001448710680429e6
> Inject #sum -> Time: 143 milliseconds, Total: 5.001448710680429e6
>
>
>
> On 8 Jan 2022, at 21:47, stephane ducasse 
> wrote:
>
> Thanks benoit for the snippet
> I run it in Pharo 10 and I got
>
> Test with 1000 elements
> Original #sum -> Time: 195 milliseconds, Total: 4.999452880735064e6
> Naive #sum -> Time: 153 milliseconds, Total: 4.999452880735063e6
> Inject #sum -> Time: 198 milliseconds, Total: 4.999452880735063e6
>
>
> in Pharo 9
> Test with 1000 elements
> Original #sum -> Time: 182 milliseconds, Total: 4.999339450212771e6
> Naive #sum -> Time: 148 milliseconds, Total: 4.999339450212771e6
> Inject #sum -> Time: 203 milliseconds, Total: 4.999339450212771e6
>
> I’m interested to understand why Pharo is slower. May be this is the
> impact
> of the new full blocks.
> We started to play with the idea of regression benchmarks.
>
> S
>
>
> On 7 Jan 2022, at 16:36, Benoit St-Jean via Pharo-dev <
> pharo-dev@lists.pharo.org> wrote:
>
> Can you come up with a simple "base case" so we can find the
> bottleneck/problem?
>
> I'm not sure about what you're trying to do.
>
> What do you get if you try this in a workspace (adjust the value of n to
> what you want, I tested it with 10 million items).
>
> Let's get this one step at a time!
>
>
>
> |  floatArray  n  rng t1 t2 t3 r1 r2 r3 |
>
> n := 1000.
>
> rng := Random new.
>
> floatArray := Array new: n.
> floatArray doWithIndex: [:each :idx | floatArray at: idx put: rng next].
>
> t1 := Time millisecondsToRun: [r1 := floatArray sum].
> t2 := Time millisecondsToRun: [| total |
> total := 0.
> floatArray do: [:each | total := total + each ].
> r2 := total].
> t3 := Time millisecondsToRun: [r3 := floatArray inject: 0 into:  [: total
> :each | total + each ]].
>
> Transcript cr.
> Transcript cr; show: 'Test with ', n printString, ' elements'.
> Transcript cr;show: 'Original #sum -> Time: ', t1 printString, '
> milliseconds, Total: ', r1 printString.
> Transcript cr;show: 'Naive #sum -> Time: ', t2 printString, '
> milliseconds, Total: ', r2 printString.
> Transcript cr;show: 'Inject #sum -> Time: ', t3 printString, '
> milliseconds, Total: ', r3 printString.
>
> --
>
> Here are the results I get on Squeak 5.3
>
> Test with 1000 elements
> Original #sum -> Time: 143 milliseconds, Total: 4.999271889099622e6
> Naive #sum -> Time: 115 milliseconds, Total: 4.999271889099622e6
> Inject #sum -> Time: 102 milliseconds, Total: 4.999271889099622e6
>
>
>
> -
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> GitHub: bstjean
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>
>
> On Thursday, January 6, 2022, 03:38:22 p.m. EST, Jimmie Houchin <
> jlhouc...@gmail.com> wrote:
>
>
> I have written a micro benchmark which stresses a language in areas
> which are crucial to my application.
>
> I have written this micro benchmark in Pharo, Crystal, Nim, Python,
> PicoLisp, C, C++, Java and Julia.
>
> On my i7 laptop Julia completes it in about 1 minute and 15 seconds,
> amazing magic they have done.
>
> Crystal and Nim do it in about 5 minutes. Python in about 25 minutes.
> Pharo takes over 2 hours. :(
>
> In my benchmarks if I comment out the sum and average of the array. It
> completes in 3.5 seconds.
> And when I sum the array it gives the correct results. So I can verify
> its validity.
>
> To illustrate below is some sample code of what I am doing. I iterate
> over the array and do calculations on each value of the array and update
> the array and sum and average at each value simple to stress array
> access and sum and average.
>
> 28800 is simply derived from time series one minute values for 5 days, 4
> weeks.
>
> randarray := Array new: 28800.
>
> 1 to: randarray size do: [ :i | randarray at: i put: Number random ].
>
> randarrayttr := [ 1 to: randarray size do: [ :i | "other calculations
> here." randarray sum. randarray average ]] timeToRun.
>
> randarrayttr. "0:00:00:36.135"
>
>
> I do 2 loops with 100 iterations each.
>
> randarrayttr * 200. "0:02:00:27"
>
>
> I learned early on in this adventure when dealing with compiled
> languages that if you don’t do a lot, the test may not last long enough
> to give any times.
>
> Pharo is my preference. 

[Pharo-dev] [Pharo Days'22] Call for participation

[Guillermo Polito]

Pharo Days

March 3rd and 4th, Lille, France

https://days.pharo.org/


Do not miss the opportunity to meet Pharo and its community! PharoDays is a 
unique event where you can meet other Pharoers, discover latest advances, and 
share your experience. Hand-ons sessions are there to help you getting started 
on advance topics. Follow the "Show us your project" sessions to get immersed 
in Pharo lively community.

This year, PharoDays is a mix of technical talks and hand-ons. Come to join 
business chat and enjoy friendly atmosphere and discuss with experts.

Do you have a project to show? We are looking for presentations to fill up our 
schedule!
Presentations will have 30' slots. Contact the Pharo board at  
before January 21st with your ideas!

Are you a student wanting to show your research project?
We are going to organize poster sessions so you can show your work to the 
community!
Prepare your posters, and contact us for a slot at !

[Pharo-dev] PharoDays'22: Inscriptions are open!

[Guillermo Polito]

Pharo Days

March 3rd and 4th, Lille, France

https://days.pharo.org/ 


Inscriptions are open!

Do not miss the opportunity to meet the Pharo programming environment and its 
community! PharoDays is a unique event where you can meet other Pharoers, 
discover latest advances, and share your experience. Hand-ons sessions are 
there to help you getting started on advance topics. Follow the "Show us your 
project" sessions to get immersed in Pharo lively community.

This year, PharoDays is a mix of technical talks and hand-ons. Come to join 
business chat and enjoy friendly atmosphere and discuss with experts.
Check the tentative schedule: from building command line interfaces to web 
applications, through modern desktop applications, visualisations, debugging 
and even a live music performance!

See you in march!

[Pharo-dev] Re: Array sum. is very slow

[Guillermo Polito]

Hi Jummie,

Is it possible that your program is computing a lot of **very** large integers?

I’m just trying the following with small numbers, and I don’t see the issue. 
#sum executes on a 28k large collection around 20 million times per second on 
my old 2015 i5.

a := (1 to: 28000).
[a sum] bench "'20256552.490 per second’"

If you could share with us more data, we could take a look.
Now i’m curious.

Thanks,
G

> El 6 ene 2022, a las 21:37, Jimmie Houchin  escribió:
> 
> I have written a micro benchmark which stresses a language in areas which are 
> crucial to my application.
> 
> I have written this micro benchmark in Pharo, Crystal, Nim, Python, PicoLisp, 
> C, C++, Java and Julia.
> 
> On my i7 laptop Julia completes it in about 1 minute and 15 seconds, amazing 
> magic they have done.
> 
> Crystal and Nim do it in about 5 minutes. Python in about 25 minutes. Pharo 
> takes over 2 hours. :(
> 
> In my benchmarks if I comment out the sum and average of the array. It 
> completes in 3.5 seconds.
> And when I sum the array it gives the correct results. So I can verify its 
> validity.
> 
> To illustrate below is some sample code of what I am doing. I iterate over 
> the array and do calculations on each value of the array and update the array 
> and sum and average at each value simple to stress array access and sum and 
> average.
> 
> 28800 is simply derived from time series one minute values for 5 days, 4 
> weeks.
> 
> randarray := Array new: 28800.
> 
> 1 to: randarray size do: [ :i | randarray at: i put: Number random ].
> 
> randarrayttr := [ 1 to: randarray size do: [ :i | "other calculations here." 
> randarray sum. randarray average ]] timeToRun.
> 
> randarrayttr. "0:00:00:36.135"
> 
> 
> I do 2 loops with 100 iterations each.
> 
> randarrayttr * 200. "0:02:00:27"
> 
> 
> I learned early on in this adventure when dealing with compiled languages 
> that if you don’t do a lot, the test may not last long enough to give any 
> times.
> 
> Pharo is my preference. But this is an awful big gap in performance. When 
> doing backtesting this is huge. Does my backtest take minutes, hours or days?
> 
> I am not a computer scientist nor expert in Pharo or Smalltalk. So I do not 
> know if there is anything which can improve this.
> 
> 
> However I have played around with several experiments of my #sum: method.
> 
> This implementation reduces the time on the above randarray in half.
> 
> sum: col
> | sum |
> sum := 0.
> 1 to: col size do: [ :i |
>  sum := sum + (col at: i) ].
> ^ sum
> 
> randarrayttr2 := [ 1 to: randarray size do: [ :i | "other calculations here."
> ltsa sum: randarray. ltsa sum: randarray ]] timeToRun.
> randarrayttr2. "0:00:00:18.563"
> 
> And this one reduces it a little more.
> 
> sum10: col
> | sum |
> sum := 0.
> 1 to: ((col size quo: 10) * 10) by: 10 do: [ :i |
>  sum := sum + (col at: i) + (col at: (i + 1)) + (col at: (i + 2)) + (col 
> at: (i + 3)) + (col at: (i + 4))
>  + (col at: (i + 5)) + (col at: (i + 6)) + (col at: (i + 7)) + (col 
> at: (i + 8)) + (col at: (i + 9))].
> ((col size quo: 10) * 10 + 1) to: col size do: [ :i |
>  sum := sum + (col at: i)].
> ^ sum
> 
> randarrayttr3 := [ 1 to: randarray size do: [ :i | "other calculations here."
> ltsa sum10: randarray. ltsa sum10: randarray ]] timeToRun.
> randarrayttr3. "0:00:00:14.592"
> 
> It closes the gap with plain Python3 no numpy. But that is a pretty low 
> standard.
> 
> Any ideas, thoughts, wisdom, directions to pursue.
> 
> Thanks
> 
> Jimmie
> 

[Pharo-dev] Re: [Pharo-users] The results of the Pharo Browser usage survey are available

[Guillermo Polito]

Thanks Koen! It’s fun to read in detail :)

So, what’s the action plan?

> El 5 sep. 2023, a las 22:10, Koen De Hondt  
> escribió:
> 
> Dear Pharo users and developers,
> 
> Last week at ESUG’23 I presented the results of the survey on the usage of 
> the Pharo Browser. Half an hour was not enough to show and discuss all 
> questions and answers. You find all results on my blog: 
> https://all-objects-all-the-time.st/#/blog/posts/3 
> . If you have questions, 
> comments, or suggestions, please do not hesitate to send me a message.
> 
> Best regards,
> Koen

[Pharo-dev] Next Pharo sprints

[Guillermo Polito]

Hi all,

For those who would like to participate, we are opening the Pharo sprints we do 
at Lille every last friday of the month.
Feel free to contact us if you would like to participate, drop an email or a 
message somewhere :)

More info in the link below!

https://thepharo.dev/2023/09/13/next-pharo-sprints-lille/ 


G

[Pharo-dev] Re: Pharo @ ESUG'23

[Guillermo Polito]

Of course, better if I send the right link :)

https://thepharo.dev/2023/09/13/pharo-esug23/

> El 13 sep. 2023, a las 09:39, Guillermo Polito  
> escribió:
> 
> Hi all,
> 
> for those that were not at ESUG, we did a small write-up about the Pharo 
> activity at the conference.
> 
> https://wordpress.com/post/thepharo.dev/1957 
> <https://wordpress.com/post/thepharo.dev/1957>
> 
> Cheers,
> Guille

[Pharo-dev] Pharo @ ESUG'23

[Guillermo Polito]

Hi all,

for those that were not at ESUG, we did a small write-up about the Pharo 
activity at the conference.

https://wordpress.com/post/thepharo.dev/1957 


Cheers,
Guille

[Pharo-dev] Re: Next Pharo sprints

[Guillermo Polito]

Ha, of course, I forgot that. I’ll update the post:

29/09
27/10
24/11
22/12

> El 14 sep. 2023, a las 12:26, Noury Bouraqadi  escribió:
> 
> Hi,
> 
> I'd like to attend. When is the next one ?
> 
> Noury 
> 
> On Wed, Sep 13, 2023, 09:42 Guillermo Polito  <mailto:guillermopol...@gmail.com>> wrote:
> Hi all,
> 
> For those who would like to participate, we are opening the Pharo sprints we 
> do at Lille every last friday of the month.
> Feel free to contact us if you would like to participate, drop an email or a 
> message somewhere :)
> 
> More info in the link below!
> 
> https://thepharo.dev/2023/09/13/next-pharo-sprints-lille/ 
> <https://thepharo.dev/2023/09/13/next-pharo-sprints-lille/>
> 
> G

[Pharo-dev] Re: Compiling Pharo VM used for P8

[Guillermo Polito]

Hi Jan,

could you share a link to the repo/commit you’re building?

Have you tried with this tag?

https://github.com/pharo-project/pharo-vm/tree/v8.6.1

G

> El 1 sep. 2023, a las 14:32, Jan Vraný  escribió:
> 
> Hi, 
> 
> I'm trying (and failing) to (re)compile Pharo VM used for P8, more 
> specifically
> this one (from `pharo -version): Date: Wed Feb 12 11:43:20 2020 CommitHash: 
> 52202d8.
> I'm targeting linux on x86_64.
> 
> Whether I use mvm (seems that it was used by Jenkins by then) or cmake I 
> always end
> up having following errors (just a few, there're loads of them): 
> 
> /usr/bin/ld: vm/vm.a(cogit.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:377: 
> multiple definition of `debugCallbackInvokes'; vm/vm.a(gcc3x-
> cointerp.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:377: first defined here
> /usr/bin/ld: vm/vm.a(cogit.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:376: 
> multiple definition of `checkForLeaks'; vm/vm.a(gcc3x-
> cointerp.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:376: first defined here
> /usr/bin/ld: vm/vm.a(cogit.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:375: 
> multiple definition of `checkedPluginName'; vm/vm.a(gcc3x-
> cointerp.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:375: first defined here
> /usr/bin/ld: vm/vm.a(cogit.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:374: 
> multiple definition of `checkAllocFiller'; vm/vm.a(gcc3x-
> cointerp.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:374: first defined here
> /usr/bin/ld: vm/vm.a(cogit.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:371: 
> multiple definition of `breakLookupClassTag'; vm/vm.a(gcc3x-
> cointerp.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:371: first defined here
> 
> Does anyone have an idea? Is there a more detailed description of build
> environment to use? 
> 
> Thanks! Jan
> 
> 
> 
> 
> 

[Pharo-dev] VM Release 10.0.8

[Guillermo Polito]

Hi all,

TL;DR; update your launcher VMs and your download scripts!


There is a new VM version: release 10.0.8 which fixes, among others, a 
performance regression that showed in some cases that overly relied on the 
interpreter.
See below the changes log, and for those interested, the fix for the 
performance issue is here: https://github.com/pharo-project/pharo-vm/pull/705 


What's Changed

Fixes #14768: File class>>primFileAttributes answers corrupted result by 
@akgrant43  in #697 

Fix/speed regression by @tesonep  in #705 

Full Changelog: v10.0.7...v10.0.8 

[Pharo-dev] Re: [ANN] Pharo Launcher 3.0 released!

[Guillermo Polito]

Thanks Christophe, this is super work :)

> El 14 abr 2022, a las 14:26, Christophe Demarey  
> escribió:
> 
> Hi all,
> 
> Pharo Launcher 3.0 has just been released! It is available from 
> http://pharo.org/download .
> It is based on latest Spec2 and Pharo 10 image.
> It now comes with a native Apple Silicon version and Mac OS packages are 
> notarized.
> Big thanks to all contributors, including issue reports. 
> 
> Here is the changelog:
> Pharo Launcher v3.0
> New features:
> 
> Full rewrite of the UI using Spec 2 and Pharo 10
> Pharo Launcher can now run natively on Apple Silicon #544 
> 
> Pharo Launcher is now signed with a Mac Os developper account and notarized 
> #529 
> Windows "portable" package (only an archive without installer) #534 
> 
> Improvements:
> 
> While importing image .sources and .version are not moved #543 
> 
> recreate the image does not re apply the script if one is provided #536 
>  (thanks to 
> @hogoww )
> Save keybind for scripts #545 
>  (thanks to @hogoww 
>  and @Inao0 )
> Bug fixes:
> 
> GitHub releases artefacts download were not always working #535 
> 
> "Basic launch" does not do its job in Pharo 10 #540 
> 
> Proxy settings not applied through settings screen #541 
> 
> 
> Regards,
> The Pharo team.

[Pharo-dev] Re: [Compiler] Variables in DoIts

[Guillermo Polito]

> El 25 jun 2022, a las 14:38, Denis Kudriashov  escribió:
> 
> Now we can play with other interesting options.
> We can completely remove reformatting of code for DoIts and make the 
> debugging more "transparent" for users:
> 
> 
> 
> Notice there is no DoIt header anymore . What is selected for the DebugIt 
> command is what the user really sees in the debugger.
> I remember when for the first time I tried the smalltalk environment DoIt 
> methods were a real magic for me.  With this view I would have much less 
> questions.
> 
> What do you think?
> 

I like this much much better than what was that before!!

I’d suggest, for further improvement (but not blocking), that I’d like to see 
the entire code and context of the do-it context.
Just showing the selected text makes one lose context.
Instead, it would be super cool to show the entire context + code of where the 
selection was done, and that the program counter is set where the selection was 
set.

Of course, now that I’m thinking about it, I would wonder how to resolve when 
to *stop*.
Only showing the selected code solves visually the *stopping*. It is clear that 
evaluation stops when we arrive at the end.

G

[Pharo-dev] Re: [Compiler] Variables in DoIts

[Guillermo Polito]

Wow, I think that’s super cool!! And a worthy direction to explore.
Having the surrounding code would give developers a lot more context!!

> El 24 jul 2022, a las 20:47, Denis Kudriashov  escribió:
> 
> Hi.
> 
> сб, 25 июн. 2022 г. в 13:48, Guillermo Polito  <mailto:guillermopol...@gmail.com>>:
> I’d suggest, for further improvement (but not blocking), that I’d like to see 
> the entire code and context of the do-it context.
> Just showing the selected text makes one lose context.
> Instead, it would be super cool to show the entire context + code of where 
> the selection was done, and that the program counter is set where the 
> selection was set.
> 
> Of course, now that I’m thinking about it, I would wonder how to resolve when 
> to *stop*.
> 
> In theory we can highlight the code from the full outer context as something 
> inactive or we can try to draw the border over a selection.
> I did a little experiment but it does not look good. And I am not sure how 
> useful it will be:
> 
> 
> 
> 
> 

[Pharo-dev] Re: This week (18/2022) on the Pharo Issue Tracker

[Guillermo Polito]

Thanks Marcus!

> El 6 may 2022, a las 8:15, Marcus Denker  escribió:
> 
> We merged 8 PRs and fixed 9 Issue tracker entries.
> 
> There are more PRs ready to be reviewed! 
> https://github.com/pharo-project/pharo/pulls
> 
> Even a reviews for trivial changes (like improvements in comments, removal of 
> dead code…) 
> are very helpful.
> 
> 
> Memory/Image Size
> =
> 
> Size is down to 56.5 MB for the bootstrapped full image after this.
> 
> - 
> 11172-ClassclassPool-empty-dictionary-for-all-classes-but-not-many-define-class-vars
>  #11175
>   https://github.com/pharo-project/pharo/pull/11175
> 
> 
> Features
> 
> - Reflectivity-AddPragmaSupport #10436
>   https://github.com/pharo-project/pharo/pull/10436
>   
> - Added shortcut method to show the formatting key bindings. #11181
>   https://github.com/pharo-project/pharo/pull/11181
>   
> - Added Array2D inspector extension #365
>   https://github.com/pharo-spec/NewTools/pull/365
>   
> Bugs
> ===
> - Fixes issue #11143: MiniDrTests raise error #11180
>   https://github.com/pharo-project/pharo/pull/11180
>   
>   
> Cleanup
> ===
> 
> - Rename BlockClosure startpc to compiledBlock #11188
>   https://github.com/pharo-project/pharo/pull/11188
> 
> - Start to remove code from Deprecated10 package. #11192
>   https://github.com/pharo-project/pharo/pull/11192
>   
> - [ci skip] [cleanup] improve comment of directories and files methods #11174
>   https://github.com/pharo-project/pharo/pull/11174

[Pharo-dev] Status update of Libgit2 and CI issues

[Guillermo Polito]

A couple of weeks ago we got reported a big recurrent failure on CI jobs while 
cloning using iceberg/libgit 
https://github.com/pharo-project/pharo/issues/11481.

TL;DR; So far (Friday ~17h Paris time) we managed to get everything up and 
running. A new VM is being released by our CI, all pull requests are issued and 
we should have everything integrated by tonight.

=-=-=-=-=-=-=-=

More on the situation: Errors happened randomly  with

```
error reading from the zlib stream
```

or
```
bad packet length
```

Several people helped in getting a reliable script to reproduce the issue, plus 
some instructions to produce a reproduction environment using a docker 
container. With that in our hands, we managed to corner the issue to a new 
incompatibility between old libgit2 versions, ssh2, OpenSSL, and (at least) 
Github.

After testing some configurations, we decided to upgrade the libgit and related 
binaries to newer versions:
 - libgit 1.4.4
 - libssh 1.9.0
 - OpenSSL 1.1.1k

This was of course not as straightforward as we would have liked.
Libgit2 1.4.4 was not compatible with its older versions and broke our ffi 
bindings.
We needed to provide new VM binaries for all our major platforms, make a new VM 
release, upgrade the libgit2 bindings, and make releases of the libgit2 
bindings, iceberg, and backport to Pharo 10 and Pharo 9.

TL;DR; So far (Friday ~17h Paris time) we managed to get everything up and 
running. A new VM is being released by our CI, all pull requests are issued and 
we should have everything integrated by tonight.

Libgit+related compilation instructions are updated in the VM wiki
  
https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-ARM64-Third-Party-Dependencies
  
https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Party-Dependencies
  
https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-Party-Dependencies
  
https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-Party-Dependencies

Libgit bindings Upgrade
changes: 
https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c3170d2f19a984a54c01a294b
release: 
https://github.com/pharo-vcs/libgit2-pharo-bindings/releases/tag/v2.2.6

Iceberg Upgrade
pr: https://github.com/pharo-vcs/iceberg/pull/1605
release: https://github.com/pharo-vcs/iceberg/releases/tag/v2.0.7

Upgrading library dependencies in the VM
  https://github.com/pharo-project/pharo-vm/pull/447
  Release VM 9.0.16 
https://github.com/pharo-project/pharo-vm/releases/tag/v9.0.16

Backports to Pharo
  Pharo10 https://github.com/pharo-project/pharo/pull/11545
  Pharo9  https://github.com/pharo-project/pharo/pull/11546

We have left for later to upgrade library dependencies for the Windows VM 
(x86-64, ARM64).
Of course, any help in this direction is welcome.

Cheers,
G in behalf of the team

[Pharo-dev] Re: Status update of Libgit2 and CI issues

[Guillermo Polito]

Hi all, 

* after some hiccups, CI servers are up un running.

See for example:

https://github.com/moosetechnology/Moose/runs/7976358526?check_suite_focus=true 
<https://github.com/moosetechnology/Moose/runs/7976358526?check_suite_focus=true>

* Another extra fix to an issue affecting only OSX machines is on the pipe with 
backports for Pharo10 and Pharo9.

https://github.com/pharo-project/pharo/issues/11561 
<https://github.com/pharo-project/pharo/issues/11561>

Please, tell us if you find some other problem.
G

> El 19 ago 2022, a las 21:31, Hernán Morales Durand  
> escribió:
> 
> 
> Thank you for the update. 
> I followed the thread and I imagine it was not easy to work on this problem.
> 
> Best regards,
> 
> Hernán
> 
> 
> El vie, 19 ago 2022 a las 16:45, Guillermo Polito ( <mailto:guillermopol...@gmail.com>>) escribió:
> A couple of weeks ago we got reported a big recurrent failure on CI jobs 
> while cloning using iceberg/libgit 
> https://github.com/pharo-project/pharo/issues/11481 
> <https://github.com/pharo-project/pharo/issues/11481>.
> 
> TL;DR; So far (Friday ~17h Paris time) we managed to get everything up and 
> running. A new VM is being released by our CI, all pull requests are issued 
> and we should have everything integrated by tonight.
> 
> =-=-=-=-=-=-=-=
> 
> More on the situation: Errors happened randomly  with
> 
> ```
> error reading from the zlib stream
> ```
> 
> or
> ```
> bad packet length
> ```
> 
> Several people helped in getting a reliable script to reproduce the issue, 
> plus some instructions to produce a reproduction environment using a docker 
> container. With that in our hands, we managed to corner the issue to a new 
> incompatibility between old libgit2 versions, ssh2, OpenSSL, and (at least) 
> Github.
> 
> After testing some configurations, we decided to upgrade the libgit and 
> related binaries to newer versions:
>  - libgit 1.4.4
>  - libssh 1.9.0
>  - OpenSSL 1.1.1k
> 
> This was of course not as straightforward as we would have liked.
> Libgit2 1.4.4 was not compatible with its older versions and broke our ffi 
> bindings.
> We needed to provide new VM binaries for all our major platforms, make a new 
> VM release, upgrade the libgit2 bindings, and make releases of the libgit2 
> bindings, iceberg, and backport to Pharo 10 and Pharo 9.
> 
> TL;DR; So far (Friday ~17h Paris time) we managed to get everything up and 
> running. A new VM is being released by our CI, all pull requests are issued 
> and we should have everything integrated by tonight.
> 
> Libgit+related compilation instructions are updated in the VM wiki
>   
> https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-ARM64-Third-Party-Dependencies
>  
> <https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-ARM64-Third-Party-Dependencies>
>   
> https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Party-Dependencies
>  
> <https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Party-Dependencies>
>   
> https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-Party-Dependencies
>  
> <https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-Party-Dependencies>
>   
> https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-Party-Dependencies
>  
> <https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-Party-Dependencies>
> 
> Libgit bindings Upgrade
> changes: 
> https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c3170d2f19a984a54c01a294b
>  
> <https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c3170d2f19a984a54c01a294b>
> release: 
> https://github.com/pharo-vcs/libgit2-pharo-bindings/releases/tag/v2.2.6 
> <https://github.com/pharo-vcs/libgit2-pharo-bindings/releases/tag/v2.2.6>
> 
> Iceberg Upgrade
> pr: https://github.com/pharo-vcs/iceberg/pull/1605 
> <https://github.com/pharo-vcs/iceberg/pull/1605>
> release: https://github.com/pharo-vcs/iceberg/releases/tag/v2.0.7 
> <https://github.com/pharo-vcs/iceberg/releases/tag/v2.0.7>
> 
> Upgrading library dependencies in the VM
>   https://github.com/pharo-project/pharo-vm/pull/447 
> <https://github.com/pharo-project/pharo-vm/pull/447>
>   Release VM 9.0.16 
> https://github.com/pharo-project/pharo-vm/releases/tag/v9.0.16 
> <https://github.com/pharo-project/pharo-vm/releases/tag/v9.0.16>
> 
> Backports to Pharo
>   Pharo10 https://github.com/pharo-project/pharo/pull/11545 
> <https://github.com/pharo-project/pharo/pull/11545>
>   Pharo9  https://github.com/pharo-project/pharo/pull/11546 
> <https://github.com/pharo-project/pharo/pull/11546>
> 
> We have left for later to upgrade library dependencies for the Windows VM 
> (x86-64, ARM64).
> Of course, any help in this direction is welcome.
> 
> Cheers,
> G in behalf of the team

[Pharo-dev] A/B Testing the latest VM on the Pharo repository PRs

[Guillermo Polito]

Hi all,

TL;DR; I propose we start testing the latest VMs on PRs to the Pharo repository 
in a "semi-random” way. The idea is to earn some confidence while having a 
small impact on all of you.


We need to slowly start pushing the latest VM version, right now hosted in the 
pharoX branch of the VM repository.

This branch so far has all our latest work on the VM for at least one year. 
Some highlights

Interpreter variable auto-localization (Feat/automatic localization 
pharo-vm#371 )
Slang cleanups and improvements (Clean slang warnings pharo-vm#413 
, Fix while statement 
printing pharo-vm#265 , 
Cast pharo-vm#230 , Clean 
slang warnings pharo-vm#413 
, Switch translation to 
CAST, and tests pharo-vm#311 
, Add several CAST 
translations and tests pharo-vm#307 
, Fix type inference tests 
pharo-vm#291 )
SIMD support in the JIT (Speed up object initialization in AArch64 using SIMD 
instructions pharo-vm#421 , 
SIMD bytecodes pharo-vm#444 
)
Initial work on the perm space (Composed image format pharo-vm#377 
, Composed image format: C 
translation pharo-vm#388 , 
Refactoring of Snapshot and Loading of Images pharo-vm#372 
, Perm space on image 
pharo-vm#416 , New & old 
remembered sets pharo-vm#418 
)
Many many bugfixes
…
To not disrupt anybody’s work, I propose to make some kind of AB testing on the 
CI, only impacting PRs to the Pharo repository.

odd builds (1,3,5,…) use the latest VM
even builds (2,4,6,…) use the stable VM
This will make sure that:

the latest VM will be tested in a complex scenario (load code, run tests…)
people that have a problem can re-run their builds to get a stable run

I’ve made the following PR that follows this idea 
https://github.com/pharo-project/pharo/pull/11678

G

[Pharo-dev] MPLR 2022 -- Call for Participation

[Guillermo Polito]

  Call for Participation

 MPLR 2022 - 19th International Conference
on Managed Programming Languages & Runtimes

September 14-15, 2022 in Brussels, Belgium

https://soft.vub.ac.be/mplr22/
  Follow us @MPLR_Conf


The 19th International Conference on Managed Programming Languages &
Runtimes (MPLR, formerly ManLang) is a premier forum for presenting and
discussing novel results in all aspects of managed programming languages
and runtime systems, which serve as building blocks for some of the most
important computing systems in use, ranging from small-scale (embedded and
real-time systems) to large-scale (cloud-computing and big-data platforms)
and anything in between (desktop, mobile, IoT, and wearable applications).

This year, MPLR will be held at the campus of
the Vrije Universiteit Brussel(VUB) in Brussels, Belgium.


Keynotes


Performance Optimizations in the .NET GC
Dr. Maoni Stephens, Microsoft, USA

Static Compilation of JavaScript
Dr. Manuel Serrano, Inria Sophia-Antipolis, France


Accepted Papers
---

Automatic Array Transformation to Columnar Storage at Run Time
Lukas Makor et al.

Compressed Forwarding Tables Reconsidered
Jonas Norlinder et al.

Event-Based Out-of-place Debugging
Tom Lauwaerts et al.

Machine-Learning-Based Self-Optimizing Compiler Heuristics
Raphael Mosaner et al.

SecSharp: Towards Efficient Trusted Execution in Managed Languages
Gilang Mentari Hamidy et al.

A Model Checking Framework for a New Collector Framework
Bochen Xu et al.

Porting a JIT compiler to RISC-V: Challenges and Opportunities
Quentin Ducasse et al.

Analyzing and Predicting Energy Consumption of Garbage Collectors in OpenJDK
Marina Shimchenko et al.

Better Understanding the Costs and Benefits of Automatic Memory Management
Kunal Sareen et al.

Dynamic Taint Analysis with Label-Defined Semantics
Jacob Kreindl et al.


Attendance
--

Thanks to our generous sponsors, we were able to significantly reduce this
year’s registration fees.

Early Registration Fees:
Students: 175 Euro
Regular:  250 Euro

In addition to the conference participation, the registration includes:
- 2-day transportation ticket in the Brussels area
- welcome reception on Wednesday, September 14
- guided tour to the city hall and conference banquet on Thursday, September 15

More details, and link to registration system:

https://soft.vub.ac.be/mplr22/registration/


Important Dates
---

Early Registration:   23 August 2022
Conference Dates:   14-15 September 2022

[Pharo-dev] Re: Linux OBS builds updated

[Guillermo Polito]

Hi Pavel,

thanks for looking into this.

Why not adding those mappings in the table so they are mapped by `self 
mapSpecialCharacter: keysym sym` ?

G

> El 6 ene. 2023, a las 08:53, Pavel Krivanek  
> escribió:
> 
> Hi, 
> 
> that is interesting issue. I have here a notebook with Numpad where I can 
> reproduce it. Pharo is getting information from SDL2 and there nothing really 
> seems to tell us that the incomming event is PgDown or similar key.
> 
> If I log incomming events in OSSDL2BackendWindow>>#visitKeyDownEvent:, I'm 
> getting these values:
> 
> Num 3
> a SDL_KeyDownEventan Array(835757 a SDL_Keysym#(4096 91 1073741915) 768 1 1)
> Num PgDown
> a SDL_KeyDownEventan Array(860624 a SDL_Keysym#(0 91 1073741915) 768 1 1)
> PgDown
> a SDL_KeyDownEventan Array(886723 a SDL_Keysym#(0 78 1073741902) 768 1 1)
> 
> (ignore the first number, the values in SDL_Keysym are mod, scancode, sym)
> 
> So the information about the key event only differs in the Num Lock modifier. 
> It is way too low-level. I see now the only solution - to the the ugly manual 
> conversion, You may try to install the attached *.st file (drag it on Pharo 
> window and then choose to install).
> 
> I will open an issue.
> 
> Cheers,
> -- Pavel
> 
> 
> 
> čt 5. 1. 2023 v 17:18 odesílatel Aik-Siong Koh  > napsal:
> Thanks for help.
> I have an OMEN 17" notebook.
> The keyboard has NumPad with Num Lock.
> Superimposed on the numbers are Home, End, PgUp, etc.
> When Num Lock is on, 1,2,3,4... works everywhere in Windows and apps.
> When Num Lock is off, Home, End, PgUp, etc. work in Windows and every app 
> except in Pharo (9, 10 or 11).
> In Pharo, pressing the Home key does nothing at all.
> 
> FYI. Above the Numpad are two keys: (HOME / PG UP) and (END / PG DN)
> They work in Pharo with the FN key to get HOME and END.
> 
> I hope this helps.
> 
> Aik-Siong Koh
> 
> 
> Pavel Krivanek wrote:
>> Hi, in Schmidt, we use Pharo 11 on Windows and Home and End keys work for 
>> us. Tested in the code editor and Calypso lists. Do you miss it in some 
>> special context, or does it not work for you at all? Do you use some 
>> different input methods? Or keyboard layouts are the boring European ones.
>> 
>> -- Pavel
>> 
>> st 4. 1. 2023 v 16:09 odesílatel Aik-Siong Koh > > napsal:
>> I do use Pharo Launcher.
>> I really miss Home and End keys in Pharo right now.
>> Are there very few users of Pharo in Windows?
>> Aik-Siong
>> 
>> Esteban Lorenzano wrote:
>>> yes, but for windows the recommended way is to use the pharo launcher 
>>> installer : https://files.pharo.org/pharo-launcher/windows 
>>> 
>>> or, if you want to download the standalone VM: 
>>> http://files.pharo.org/get-files/100/pharo-vm-Windows-x86_64-stable.zip 
>>> 
>>> Esteban
>>> 
>>> On Jan 4 2023, at 3:25 pm, Aik-Siong Koh  
>>>  wrote:
>>>  
>>> Does Windows get as good support as Linux or Mac?
>>> I am waiting for the Home and End key to work on Windows.
>>> Thanks,
>>> Aik-Siong Koh
>>> 
>>> Esteban Lorenzano wrote:
>>>  
>>> Hi,
>>> 
>>> I updated linux OBS builds to get it up to date with distro changes :
>>> 
>>> Added:
>>> Fedora 37
>>> Ubuntu 22.10
>>> OpenSUSE Leap 15.3
>>> OpenSUSE Leap 15.4
>>> Fixed:
>>> Arch (Manjaro)
>>> OpenSUSE Tumbleweed
>>> Removed (Obsoletes):
>>> OpenSUSE Leap 15.1
>>> OpenSUSE Leap 15.2
>>> Fedora 32
>>> Fedora 33
>>> You can test all the new/fixed as correspond: 
>>> https://software.opensuse.org//download.html?project=devel%3Alanguages%3Apharo%3Alatest=pharo9-ui
>>>  
>>> 
>>> Enjoy,
>>> Esteban
>> 
> 
> 

[Pharo-dev] Draft Phep on new Finalization

[Guillermo Polito]

Hi all,

I’ve drafted a phep proposal for the new finalization mechanism, so we can 
discuss it here!

https://github.com/pharo-project/pheps/pull/14 


A proposal describing a new finalization mechanism for Pharo with the following 
properties:

• API independent from its implementation
• Avoids memory leaks
This document describes both a finalization API as a Pharo library and an 
efficient virtual machine implementation through Ephemerons.


Cheers,
G

[Pharo-dev] Re: Pharo VM Release - v9.0.21

[Guillermo Polito]

Thanks Pablo!!!

> El 12 dic. 2022, a las 14:30, teso...@gmail.com escribió:
> 
> Hello, 
>   I have released a new version of the Pharo VM for Pharo 9, Pharo 10 and 
> Pharo 11. This VM is accessible right now from Zero-Conf, updating it in the 
> Pharo Launcher or using the usual downloads (as described in 
> pharo.org/download ). 
> 
> This version includes a series of bug fixes and upgrades on the third-party 
> libraries.
> 
> Changelog: 
> 
> - Implementing High resolution clock for ARM64 (Used during profiling)
> - Updating third party libraries for all the graphic layer.
> - Fixing a performance regression on the allocation of opcodes and fix-ups.
> Cleaning only the ones that are going to be used.
> Like this, this version has the same speed than before when 
> allocating in the stack.
> - Correctly handling the encoding of the command line arguments of the VM 
> (Windows)
> - Allocating the opcodes and fixup structs only once and reusing them 
> (Reducing risk of C Stack Overflow)
> 
> Thanks a lot, and any doubt please let me know.
> Cheers, 
> 
> Pablo on behalf of the whole Pharo team.
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com 

[Pharo-dev] Re: Pharo11 32 bits images missing?

[Guillermo Polito]

Nope, this is most certainly a bug, thanks for raising the flag!

> El 22 ene. 2023, a las 18:10, Pierre Misse Chanabier 
>  escribió:
> 
> Hello,
> 
> Apparently Pharo 11 does not build 32 bit images [1].
> Did I miss an announcement?
> 
> Pierre
> 
> http://files.pharo.org/image/110/

[Pharo-dev] Re: Pharo VM Release - v10.0.0

[Guillermo Polito]

PR has been green for two weeks waiting for a review

https://github.com/pharo-project/pharo/pull/12042

And the Phep was updated taking (almost) all comments into account

https://github.com/pharo-project/pheps/pull/19

:)

> El 13 mar. 2023, a las 20:32, s...@clipperadams.com escribió:
> 
> Norbert Hartl wrote:
> 
> I'm especially interested in ephemerons and how it improves the weak 
> structures in the image. Hope the image support that makes use of the vm 
> features follows soon.
> 
> +1. This has seemed to be just out of our grasp for so long. Are we “there 
> yet” or close to completion?
> 

[Pharo-dev] Ephemerons in P11

[Guillermo Polito]

Hi all,

For those that may not be following the day-to-day development, you may be 
interested in that Ephemeron support is now enabled in Pharo 11 for one week or 
so (VM version 10.0.0, Image build 627).
Here are some takeaways and actions to take you may be interested in:

To get the latest version:
 - ZeroConf works out of the box
 - You must update your VMs in the pharo launcher

About compatibility:
 - old images will run on both the old and latest VMs
 - new images will only run on the latest VM

You can read more on:

https://github.com/pharo-project/pheps/blob/main/phep-0003.md

Cheers,
Guille

[Pharo-dev] Re: PhEP: Underscores in Numeric Literals

[Guillermo Polito]

+1

> El 13 feb. 2023, a las 20:37, Daniel Slomovits  
> escribió:
> 
> Seems reasonable to me. I was just wishing for such a thing for exactly the 
> reason you mention (keeping track of zeroes in large integer literals). 
> AFAICT you've done a pretty good job laying out the possible error 
> conditions. I think your option 1 makes sense—the error-prone-ness is the 
> sort of thing that could happen in theory, but I'm not too worried about in 
> practice. Or option 2 is fine, I'm just not familiar enough with the parser 
> to know how much harder it might be to implement.
> 
> On Mon, Feb 13, 2023 at 1:54 PM Privat, Jean  > wrote:
> This PhEP describes the extension of Pharo numeric literals to accepts (and 
> ignore) underscore characters (`_` ASCII 95).
> 
> Many languages (including Python https://peps.python.org/pep-0515/ 
>  , Java 
> https://docs.oracle.com/javase/7/docs/technotes/guides/language/underscores-literals.html
>  
> 
>  or Ruby) accept some forms of numeric literal that ignore _.
> 
> The idea is to permit long literals that are still readable, eg. 
> `1_000_000_000` is easier for a human than `1` especially since in 
> the previous literal a zero is missing (I'm a tricky deceitful fellow).
> 
> The details of the proposal are in the PR: 
> https://github.com/pharo-project/pheps/pull/16 
> 
> 
> --
> Jean Privat

[Pharo-dev] Fun with dates

[Guillermo Polito]

Try to guess what each of the following lines of code do:

'''/5%9/$#=7*''*(?&&)58-,=93/1(0 1&<"1%?#$-::#)' asDate.

'*%!@$4*4#!$!.&0-";)7.<7?%(;  $535(0536.%#56&++''3!%0/' asDate.

'/-@+%3:3.''9"04=. @5+$;"& (6.-,?@*6"?43@@>*>:' asDate.

'1(%&0:19)) 7-?1.8;=?8+!&42-(?#>357).!=21603* 
6=?38.1**,//'':@663>.09!2%=!%%%2!>4'':@#/8!@==2>%651):#14-8+(1@$&827%6-!)9-<>:"2+>&*39 !"(27' asDate.

'''"?. <>!@"2(%7#)0 )46+#'';=+"94?%)9 +!<.+!9,2*5("9$11-,?49 =6*77. 0;/''%%/*' 
asDate.

'4.+@)3&11)."+.6=$&$0>5:5;:$,%5-+,4$0>")>4838''*2/' asDate.

'!7$:''!@0=)?0?<#&@*./0.:&?$?4 =<(7)@3$!:"$%%=""/?4*4=0?*$).,<+& 
::"8>:925$8!,2,95' asDate.

' &+?!$3"(<*)1");35 $:&<"$!' asDate.

'>6(# %2736:-1#@@9%9''+"#?37''2,<3>8-*5"$2-6#''365++*8 &' asDate.

'?(2/=-@=@:4?/(3$3(8"&,!-2/&6&&' asDate.

'&?7+=''9,:$(430,3#/$4#866'';2/*,?):. -!#"7=?6:$3"5 -$/=0' asDate.

'3-;;=72@,9=%*.;+)74@7") 
-&?(''7+!3-3<-0,<8:(,,;+5-$:81#&6''7830;"01+@>7<37''!(#/9"6%0?' asDate.

';";5!9!,4/;25!0(<$4)''2"(2&-''4/>/.'')99(>><' asDate.

'03="9-/,*(;74"%@>=''91%>#=*=6*0/#02@?)0.' asDate


G

[Pharo-dev] VM Release 10.0.6 on the pipe

[Guillermo Polito]

Hi all,

This email is to tell you that there is a new VM release on the CI pipe, with 
many fixes and improvements.
This release will be available for versions of Pharo 11 and above.

Improvements in build environment
* Update build environment for Pharo 10 vm branch by @guillep in 
https://github.com/pharo-project/pharo-vm/pull/594
* Make tests run in parallel by @guillep in 
https://github.com/pharo-project/pharo-vm/pull/596
* Update Jenkins to use Pharo 110 for building by @PalumboN in 
https://github.com/pharo-project/pharo-vm/pull/661

Cleanups
* Cleanups/externalize internalize by @guillep in 
https://github.com/pharo-project/pharo-vm/pull/583
* Fix/warnings by @guillep in https://github.com/pharo-project/pharo-vm/pull/584
* fixing-categorization in P10 by @tesonep in 
https://github.com/pharo-project/pharo-vm/pull/625

Fixes
* Fix mnuMethodOrNilFor: for method wrappers by @guillep in 
https://github.com/pharo-project/pharo-vm/pull/578
* fix function signatures by @pavel-krivanek in 
https://github.com/pharo-project/pharo-vm/pull/582

Debugging improvements
* Gdbinit file and helpers v2 by @guillep in 
https://github.com/pharo-project/pharo-vm/pull/486
* VM Debugger improvement with IR by @QDucasse in 
https://github.com/pharo-project/pharo-vm/pull/342

VM Improvements
* improving-permSpace by @tesonep in 
https://github.com/pharo-project/pharo-vm/pull/614
* Changing the order of command-line processing and PList in OSX by @tesonep in 
https://github.com/pharo-project/pharo-vm/pull/609
* Adding parsing of image parameters from PList by @tesonep in 
https://github.com/pharo-project/pharo-vm/pull/636
* Change terminate handler to exit with 128+signal by @jvalteren in 
https://github.com/pharo-project/pharo-vm/pull/644
* Improvements in parameters handling in OSX by @tesonep in 
https://github.com/pharo-project/pharo-vm/pull/639
* Adding check to fix when the image is open with an older VM by @tesonep in 
https://github.com/pharo-project/pharo-vm/pull/642
* Fix/ephemeron list by @guillep in 
https://github.com/pharo-project/pharo-vm/pull/668

New Contributors
* @jvalteren made their first contribution in 
https://github.com/pharo-project/pharo-vm/pull/644

**Full Changelog**: 
https://github.com/pharo-project/pharo-vm/compare/v10.0.5...v10.0.6 


Cheers,
Guille et al

[Pharo-dev] Re: [ANN] CBOR for Pharo

[Guillermo Polito]

Thanks Sven :)

> El 23 jun. 2023, a las 00:06, stephane ducasse  
> escribió:
> 
> Super nice 
> for a moment I thought that you forgot the final G of the name :)
> 
>> On 21 Jun 2023, at 11:25, Sven Van Caekenberghe  wrote:
>> 
>> [ANN] CBOR for Pharo
>> 
>> https://github.com/svenvc/CBOR
>> 
>> Concise Binary Object Representation (CBOR) is a binary data serialization 
>> format. CBOR is based on the JSON data model: a number of primitive types 
>> (integers, floats, booleans, strings and null), lists and maps (which 
>> represent objects or structures). Being binary, CBOR is more efficient than 
>> JSON, which is text based. CBOR also supports binary data and optional 
>> extensions (called tags). This implementation has native support for string 
>> and epoch based timestamps (DateAndTime) and big integers (Integer).
>> 
>> This project contains encoding/decoding support for the half-precision, IEEE 
>> 754 16-bit (binary16) floating-point format.
>> 
>> Sven
>> 
>> 
>> --
>> Sven Van Caekenberghe
>> Proudly supporting Pharo
>> http://pharo.org
>> http://association.pharo.org
>> http://consortium.pharo.org
>> 
>> 
>> 

[Pharo-dev] Re: Pharo contribution Jenkins end of service

[Guillermo Polito]

Thanks Christophe!

> El 11 may. 2023, a las 11:32, Christophe Demarey 
>  escribió:
> 
> Hi all,
> 
> Some years ago, we provided a Jenkins instance to check the health / quality 
> of projects that are not in Pharo core but important for the community:
> https://ci.inria.fr/pharo-contribution/ 
> 
> 
> Since, we moved to GitHub and GitHub actions are mainly used to achieve the 
> same goal. Therefore there is no more reason to keep this service. That’s why 
> we decided to stop the Pharo contribution Jenkins on 12th June 2023.
> If you need to save some data (job artefacts, job setup), let us know. The 
> server is now up but it has not been updated since a while and can stop 
> working from time to time.
> 
> On 12th June 2023, we will shutdown the server and all data will be removed.
> 
> The Pharo team.

[Pharo-dev] Re: [ANN] Pharo 11 Released !

[Guillermo Polito]

++1 !! :)

> El 11 may. 2023, a las 14:02, Gabriel Cotelli  escribió:
> 
> Congratulations on the new release. Now it's time to adapt the libraries and 
> check that continue working with this version :P 
> 
> I think you need to update also 
> https://github.com/pharo-project/pharo/releases 
>  to tag the commit used to 
> produce the released image.
> 
> Regards,
> Gabriel
> 
> On Thu, May 11, 2023 at 8:39 AM Esteban Lorenzano  > wrote:
> Dear Pharo users and dynamic language lovers:
> 
> We have released Pharo  version 11!
> What is Pharo?
> 
> Pharo is a pure object-oriented programming language and a powerful 
> environment focused on simplicity and immediate feedback.
> 
> 
> 
> Simple & powerful language: No constructors, no types declaration, no 
> interfaces, no primitive types. Yet a powerful and elegant language with a 
> full syntax fitting in one postcard! Pharo is objects and messages all the 
> way down.
> Live, immersive environment: Immediate feedback at any moment of your 
> development: Developing, testing, debugging. Even in production environments, 
> you will never be stuck in compiling and deploying steps again!
> Amazing debugging experience: Pharo environment includes a debugger unlike 
> anything you've seen before. It allows you to step through code, restart the 
> execution of methods, create methods on the fly, and much more!
> Pharo is yours: Pharo is made by an incredible community, with more than 100 
> contributors for the last revision of the platform and hundreds of people 
> constantly contributing with frameworks and libraries.
> Fully open-source: Pharo full stack is released under MIT 
>  License and available on GitHub 
> 
> ... more on the Pharo Features page .
> 
> In this iteration of Pharo, we continue working on our objectives of 
> improvement, clean-up and modularization. Also, we included a number of 
> usability and speed improvements. A complete list of changes and improvements 
> is available in our Changelog 
> 
> Some highlights of this amazing version:
> Highlights
> 
> Tools
> Iceberg (the git client/VCS control tool) has received a lot of tweaks and 
> fixes to work better with GitHub and other Git services.
> Our debugger now incorporates lots of tweaks and notably the capability of 
> adding bindings in the context interaction model.
> The is a new implementation of rewrite tools and improved refactoring support.
> There is a new tool: The Document Browser, which presents Microdown (markdown 
> compatible) documents placed on the web or locally.
> New Tools presented in Calypso (the System Browser) and additional extended 
> Inspectors.
> All versions of NewTools, Spec, Roassal and Microdown have been updated with 
> their respective bug fixes and improvements.
> System
> Extended Full Blocks and Constant Clock closures support.
> Additional Inlining and optimizations
> Bug Fixes and Clean up.
> Ephemeron Finalization support.
> Virtual machine
> Ephemerons Production Ready.
> Initial support for Single-Instruction Multiple-Data (SIMD).
> Third-Party Dependency Update (Newer versions, Graphic Libraries using 
> Hardware Acceleration).
> Clean Ups: Remove lots of old code, notably old experiments, and dead code.
> Development Effort
> 
> This new version is the result of 1412 Pull Requests integrated just in the 
> Pharo repository. We have closed 972 issues and received contributions from 
> more than 70 different contributors. We have also a lot of work in the 
> separate projects that are included in each Pharo release:
> 
> http://github.com/pharo-spec/NewTools 
> http://github.com/pharo-spec/NewTools-DocumentBrowser 
> 
> http://github.com/pharo-spec/Spec 
> http://github.com/pharo-vcs/Iceberg 
> http://github.com/ObjectProfile/Roassal3 
> 
> http://github.com/pillar-markup/Microdown 
> 
> http://github.com/pillar-markup/BeautifulComments 
> 
> http://github.com/pharo-project/pharo-vm 
> 
> Contributors
> 
> We always say Pharo is yours. It is yours because we made it for you, but 
> most importantly because it is made by the invaluable contributions of our 
> great community (yourself). A large community of people from all around the 
> world contributed to Pharo 11.0 by making pull requests, reporting bugs, 
> participating in discussion threads, providing feedback, and a lot of helpful 
> tasks in all our 

[Pharo-dev] Re: IMPORTANT: Pharo 12 will enter feature freeze on March 1st

[Guillermo Polito]

Thanks Esteban.

Everybody, please join us in the bugfixing phase to have a robust release!

G

> El 13 feb 2024, a las 11:25, Esteban Lorenzano via Pharo-dev 
>  escribió:
> 
> Hi,
> 
> The development of Pharo 12 will enter in feature freeze on March 1st and we 
> plan to have at least one month of stabilization (but we will release when we 
> are ready, in April).
> 
> cheers,
> 
> Esteban
> 
> 

[Pharo-dev] Re: About removing class side initialization

[Guillermo Polito]

> El 31 ene 2024, a las 15:36, Marcus Denker  escribió:
> 
> For both #isAbstract and #initialize, one can understand both as cases where 
> we have to use behavior for something that should actually be a kind o 
> declarative property of the objects.
> 
> - isAbstract 
> 
> This is a property of the class.
> 
> - initialize 
> 
> This is a property of the Variable. It’s really unfortunate to have to fall 
> back on code execution for that. What the initalize does is to say

There is out there indeed code that uses class side initialize methods to 
initialize class variables to constants.
But that is not the only case.

Some class side initalizes have complex initializations.
Some are used to register the loaded class to some registration mechanism.

> 
>> On 31 Jan 2024, at 15:03, Noury Bouraqadi  wrote:
>> 
>> This is indeed an issue I'd like to see solved.
>> Class initialization is just an instance of a more general isssue.
>> In SUnit, defining abstract classes is dirty. The code often looks like this 
>> MyTestClass class>>#isAbstract
>>^self == MyTestClass
>> In PharoJS we face the issue of class specific methods. Upon transpiling to 
>> JS, we want to perform some actions for some classes and not their 
>> subclasses.
>> A possible solution is to introduce class specific properties through an 
>> extra-layer of metaclasses.

Yes, I agree. I would like to have two levels of “Metaclasses”.
Actually, one metaclass that is the traditional metaclass defining the class 
behavior.
One “companion” object where we can define domain concerns.

The companion object should respect the double hierarchy, but it will not class 
anymore with the meta-behaviour in the class!
We will be able to freely program there without mistakenly overriding critical 
behavior from classes :).
And we will be able to define metaclasses with really specific behavior for a 
single class in the hierarchy chain.

G

[Pharo-dev] IWST Paper Submission Deadline is Approaching!

[Guillermo Polito]

Dear community,

IWST invites everybody to submit full/short papers to be considered to be 
plublished in the IWST 2024 Proceedings.
Papers can both be presented in the conference's IWST track and appear in 
proceedings independently of the initially submitted abstracts.

Full/short paper submission deadline: May 19th, 2024

We are looking for papers of two kinds:

- Short position papers (5 to 10 pages) describing fresh ideas and early 
results.
- Full papers (more than 10 pages) with deeper description of experiments and 
of research results.

Paper accepted for publishing will be published within a *CEUR-WS 
Proceedings>https://ceur-ws.org/*.
Hence, both submissions and final papers must be prepared using the *CEUR ART 
style>https://ceur-ws.org/Vol-XXX/CEURART.zip*. 
We recommend to use the template in single column style, although you may use 
two colums.
CEUR proceedings accepts papers in boths styles as soon as they follow the 
template and have 5 or more pages.

The IWST team, Gordana, Guille and Steven
https://esug.org/2024-Conference/IWST2024.html

Re: [Pharo-dev] Happy new year!

[Guillermo Polito via Pharo-dev]

--- Begin Message ---
Feliz año nuevo!

On Wed, Jan 2, 2019 at 4:11 AM Sean P. DeNigris via Pharo-dev <
pharo-dev@lists.pharo.org> wrote:

> EstebanLM wrote
> > I wish you all have a happy new year, and may it be even better than this
> > one :)
>
> Happy New Year to all!!
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13
--- End Message ---