[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] 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: 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] 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: [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] 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.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] 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] 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: [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: 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] 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: 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] 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] 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: 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] 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] 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] 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] 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: [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: [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: 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] 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] 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] [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] 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] 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: 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: 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: 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: 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: 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: Pharo 8 Image blows up after restart

[Guillermo Polito]

Cool :)

Glad to help

> El 9 dic 2020, a las 10:46, Sabine Manaa  escribió:
> 
> Hi Eliot, hi Guille,
> 
> you saved my day!
> 
> starting from command line and killing with SIGUSR1 showed the stack below.
> 
> Starting the image without mongoservice running avoids the blowup.
> 
> Then, saving the image, starting mongoservice again and then I can proceed
> using the image.
> 
> I don't know yet why I get the
> MongoWireProtocolError(MongoNativeError)>messageText but I have a point
> where I can start seaching.
> 
> Thanks a lot
> Sabine
> 
> 
> 
> 
> SIGUSR1 Wed Dec  9 09:51:45 2020
> 
> 
> VM: 202002121007 https://github.com/pharo-project/opensmalltalk-vm.git
> Date: Wed Feb 12 11:07:12 2020 CommitHash: 2bd9e39
> Plugins: 202002121007 https://github.com/pharo-project/opensmalltalk-vm.git
> 
> C stack backtrace & registers:
>   rax 0x0001107d28f0 rbx 0x0003 rcx 0x rdx
> 0x0008
>   rdi 0x0003351a4690 rsi 0x0003351a4690 rbp 0x7ffeea61f050 rsp
> 0x7ffeea61f020
>   r8  0x00ff r9  0x0001 r10 0x0003351a4698 r11
> 0x00022b0c8fc8
>   r12 0x0003351a45d8 r13 0x0001 r14 0x r15
> 0x0006
>   rip 0x0001055f9862
> 0   Pharo   0x0001055f9862
> scavengeReferentsOf + 277
> 1   Pharo   0x0001056392da reportStackState
> + 952
> 2   Pharo   0x0001056394f8 sigusr1 + 182
> 3   libsystem_platform.dylib0x7fff725995fd _sigtramp + 29
> 4   ??? 0xc000 0x0 + 3221225472
> 5   Pharo   0x0001055d5eea doScavenge + 542
> 6   Pharo   0x0001055de05e
> scavengingGCTenuringIf + 333
> 7   Pharo   0x0001055c163a
> checkForEventsMayContextSwitch + 111
> 8   Pharo   0x0001055c5815 ceStackOverflow +
> 110
> 9   ??? 0x000109cca53b 0x0 + 4459373883
> 10  Pharo   0x0001055adb0a interpret + 632
> 11  Pharo   0x00010563aa62
> -[sqSqueakMainApplication runSqueak] + 393
> 12  Foundation  0x7fff3aac429b
> __NSFirePerformWithOrder + 360
> 13  CoreFoundation  0x7fff38330335
> __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
> 14  CoreFoundation  0x7fff38330267
> __CFRunLoopDoObservers + 457
> 15  CoreFoundation  0x7fff3832f805 __CFRunLoopRun +
> 874
> 16  CoreFoundation  0x7fff3832ee3e
> CFRunLoopRunSpecific + 462
> 17  HIToolbox   0x7fff36f5babd
> RunCurrentEventLoopInMode + 292
> 18  HIToolbox   0x7fff36f5b6f4
> ReceiveNextEventCommon + 359
> 19  HIToolbox   0x7fff36f5b579
> _BlockUntilNextEventMatchingListInModeWithFilter + 64
> 20  AppKit  0x7fff355a1039 _DPSNextEvent +
> 883
> 21  AppKit  0x7fff3559f880
> -[NSApplication(NSEvent)
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
> 22  AppKit  0x7fff3559158e -[NSApplication
> run] + 658
> 23  AppKit  0x7fff35563396 NSApplicationMain
> + 777
> 24  libdyld.dylib   0x7fff723a0cc9 start + 1
> 25  ??? 0x0002 0x0 + 2
> 
> 
> All Smalltalk process stacks (active first):
> Process0x120172de8 priority 20
>0x7ffeea630130 M MongoWireProtocolError(MongoNativeError)>messageText
> 0x120173f58: a(n) MongoWireProtocolError
>0x7ffeea63d980 M MongoWireProtocolError>errorMessage 0x120173f58: a(n)
> MongoWireProtocolError
>0x7ffeea63d9b0 M MongoWireProtocolError(MongoNativeError)>messageText
> 0x120173f58: a(n) MongoWireProtocolError
>0x7ffeea63d9e0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n)
> MongoWireProtocolError
>0x7ffeea63da10 M MongoWireProtocolError(MongoNativeError)>messageText
> 0x120173f58: a(n) MongoWireProtocolError
>0x7ffeea63da40 M MongoWireProtocolError>errorMessage 0x120173f58: a(n)
> MongoWireProtocolError
>0x7ffeea63da70 M MongoWireProtocolError(MongoNativeError)>messageText
> 0x120173f58: a(n) MongoWireProtocolError
>0x7ffeea63daa0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n)
> MongoWireProtocolError
>0x7ffeea63dad0 M MongoWireProtocolError(MongoNativeError)>messageText
> 0x120173f58: a(n) MongoWireProtocolError
>0x7ffeea63db00 M MongoWireProtocolError>errorMessage 0x120173f58: a(n)
> MongoWireProtocolError
>0x7ffeea63db30 M MongoWireProtocolError(MongoNativeError)>messageText
> 0x120173f58: a(n) MongoWireProtocolError
>0x7ffeea63db60 M 

[Pharo-dev] Re: Pharo 8 Image blows up after restart

[Guillermo Polito]

Another idea is that as soon as you detect the problem, you send the SIGUSR1 
signal to the VM from another terminal.

$ kill -SIGUSR1 thePID

When the Pharo process receives the SIGUSR1 signal it will output a dump with
  - the C execution stack
  - the Pharo execution stacks

Maybe for debugging this case you don’t want to use the launcher, and you want 
to manually launch the VM from a terminal, so you’ll have more control and see 
the output (maybe you’re already doing it, but just in case).

G.

> El 9 dic 2020, a las 6:35, Eliot Miranda  escribió:
> 
> Hi Sabine,
> 
>> On Dec 8, 2020, at 10:49 AM, Sabine Manaa  wrote:
>> 
>> Hi,
>> 
>> I have the following problem:
>> 
>> sometimes, after restarting my Pharo 8 image on mac, it is not responsive
>> and it blows up the memory.
>> 
>> I tried with  commandline handler  
>> eval "self halt"
>> and with 
>> Smalltalk addToStartUpList: 
>> 
>> but both is too late - the Image starts and blows up and is not responsive. 
>> 
>> I can not interrupt it and it grows to several GB memory (eg after 20
>> seconds 10 GigaByte! ) and I have to kill it.
>> 
>> Anyone having an idea what I can do to find the reason for this? 
> 
> Run the system under a low level debugger (lldb, gdb).
> Put a break point on the function 
> sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto, which is called when the 
> heap must grow to allocate new objects.
> When the system hits the breakpoint for the second or third time call the 
> function 
> printCallStack()
> and be patient; it will print a lot of stack.
> 
> There is also a command line argument to limit the maximum size of the heap. 
> So an alternative might be to restrict the heap to a few megabytes above the 
> image size and see if you get a crash.dmp file when the vm exits when the 
> system runs out of memory.
> 
> HTH
> 
>> 
>> Sabine
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html 
>> 

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

[Guillermo Polito]

> El 7 dic 2020, a las 17:02, Sean P. DeNigris  escribió:
> 
> Wow! Impressive list :)
> 
> 
> Marcus Denker-4 wrote
>> - Activation in single click (which triggers column expansion) is now
>> default for inspections (it was double click, but it felt weird).
> 
> -1 on this. The problem with single click is that it adds a column even when
> you don't want it to. This was very annoying. IMO after using the
> double-click for a few months (it took that long to get used to it), the
> extra click is significantly less disruptive than the unnecessary column
> adding.

+1 on this.
That is why I made double click by default when I first implemented it.
Every time you click on glamour everything shifts, rotates, moves, it is super 
disrupting when you **just want to click**.

The single click should not shuffle the UI, or the UI should provide a way to 
“click” on something without moving everything around.

> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Re: [ANN] New UI renderer with Hi-DPI support (Beta testing)

[Guillermo Polito]

The slides are here, I don’t know about any recordings, maybe Ronie will repeat 
it and  a record it later?

http://rmod-files.lille.inria.fr/Team/Presentations/2020-form-scene-graph-Salgado.pdf

> El 30 nov 2020, a las 11:09, Ben Coman  escribió:
> 
> Was there any recording?
> 
> On Thu, 26 Nov 2020 at 21:47, Ronie Salgado  > wrote:
> Hello,
> 
> Today I am giving a talk about this at 4 pm, Paris time through the Discord.
> 
> 
> Best regards,
> Ronie
> 
> El mié, 25 nov 2020 a las 16:11, Ronie Salgado ( >) escribió:
> Hello,
> 
> The last months I have been working in a new UI rendering framework for Pharo 
> based on adding an intermediate scene graph with the purpose of improving 
> rendering speed, and with the side effect of making the whole UI scalable and 
> adding support for Hi-DPI rendering.
> 
> We would appreciate that people could start testing this so that we can find 
> bugs and stabilize it. For using this the latest Pharo 9 image and headless 
> vm is required.
> 
> Form Scene Graph repo, installation and settings repository: 
> https://github.com/ronsaldo/form-scene-graph 
> 
> 
> Known issues:
> - Iceberg is hanging on fetches and pushes only when using the Athens 
> backend. No segmentation fault or debugger is being launched here so this is 
> difficult to fix. When having to deal with this issue we recommend using the 
> OSWindowGenericRenderer backend (SDL2).
> 
> Best regards,
> Ronie
> 

[Pharo-dev] [ANN] Smalltalkhub Readonly Migration tuesday 8hs - server maintenance / migration

[Guillermo Polito]

Hi all,


We wanted to announce that, as announced previously, Smalltalkhub is going read 
only from tomorrow, 8h central Europe time.
This means the service could be down for a couple of hours until the sync of 
data is done.


Keep tuned,
Guille and Christophe in behalf of the RMoD team

Re: [Pharo-dev] [rmod] [Pharo-users] [ANN] SmalltalkHub Deprecation Notice

[Guillermo Polito]

Hi Renaud,


> El 3 abr 2020, a las 16:27, Renaud de Villemeur  
> escribió:
> 
> Hi Guille.
> 
> It's a good news to see the community is moving forward. 
> 
> What would be the impact on Pharo catalog ? The instruction still advise to 
> upload information to smalltalkhub: 
> http://catalog.pharo.org/catalog/note-for-developers?_s=bHk4XDBcH9mb0muM&_k=WPHmGPa_-V3tv21k
>  
> 
> Will it be deprecated as well ? 

My *personal* take on this is is that we can migrate easily the catalog, 
without deprecating it:
 - the catalog repositories will stay alive as read-only, so it will be no 
problem to access old catalog entries (unless they depend on private projects, 
but that would be odd)
 - a low-energy solution for this is to migrate these repositories to 
squeaksource3. This should be mostly straight-forward.
 - a high-energy solution is to rethink the catalog. I know there have been 
some community efforts from Christophe Demarey for example, Esteban has also 
interesting ideas on how to attack this.

Thoughts?

> 
> Thanks
> Renaud
> 
> 
> 
> 
> Apr. 3, 2020, 05:55 by guillermopol...@gmail.com:
> SmalltalkHub Deprecation Notice
> SmalltalkHub is now getting old and it is time to deprecate it. We plan to 
> replace it by a static file server during 2020. The public data will still be 
> readable and consumable from monticello clients, but modifications will not 
> be allowed in the near future. SmalltalkHub users should move their projects 
> to git repositories or other monticello repository services.
> What is changing?
> If you currently host a project in SmalltalkHub, you should migrate your 
> projects to another platform as soon as possible. If you depend on a project 
> hosted on SmalltalkHub, you should contact the owner of that project to 
> schedule a migration.
> If you have documentation or tutorials using SmalltalkHub, we recommend to 
> update those after a migration.
> An archive of all public projects in SmalltalkHub will be made available in 
> read-only mode. This archive will be readable through monticello clients for 
> compatibility reasons.
> Private projects, due to privacy reasons, will not be published in the public 
> archive and will be removed to protect their owners.
> Why are RMoD and Inria making this change?
> SmalltalkHub has finished its cycle. The arrival of git integration in the 
> past years caused the move of most users in the Pharo community to git 
> hosting services. They now use exclusively other platforms. Furthermore, RMoD 
> and Inria lack the manpower to properly maintain the SmalltalkHub service and 
> keep it up to date. Smalltalkhub has no added value compared to other code 
> source hosting platforms.
> How much time do I have to adapt to this change?
> 
> The SmalltalkHub deprecation will follow the next timetable:
> Monday 04 of may 2020: SmalltalkHub will be read-only. Creation of new users 
> and projects will be forbidden. New commits will be rejected. All existing 
> users, projects (public and private) and their commits will remain available 
> and visible, but their settings will become read-only.
> Monday 02 of november 2020: SmalltalkHub will be migrated to a static file 
> server archive. Private projects and their commits will not be available 
> anymore.
> 
> The RMoD team and Inria plan to keep the static file server alive for, at 
> least, 5 years from the date of its creation.
> What will happen if I do nothing?
> Your public projects will become read-only and you will not be able to commit 
> anymore.
> Your private projects will become unavailable.
> What alternatives do I have?
> 
> Those wanting to keep using monticello can migrate their projects to other 
> monticello hostings such as http://squeaksource.com 
>  or http://ss3.gemstone.com 
> 
> 
> Those wanting to migrate to git, Peter Uhnak’s git migration tool 
> (https://github.com/peteruhnak/git-migration 
> ) automates monticello to git 
> migration in tonel format.
> 
> Cheers,
> Guille on behalf of the RMoD team
> 

[Pharo-dev] [ANN] SmalltalkHub Deprecation Notice

[Guillermo Polito]

SmalltalkHub Deprecation Notice
SmalltalkHub is now getting old and it is time to deprecate it. We plan to 
replace it by a static file server during 2020. The public data will still be 
readable and consumable from monticello clients, but modifications will not be 
allowed in the near future. SmalltalkHub users should move their projects to 
git repositories or other monticello repository services.
What is changing?
If you currently host a project in SmalltalkHub, you should migrate your 
projects to another platform as soon as possible. If you depend on a project 
hosted on SmalltalkHub, you should contact the owner of that project to 
schedule a migration.
If you have documentation or tutorials using SmalltalkHub, we recommend to 
update those after a migration.
An archive of all public projects in SmalltalkHub will be made available in 
read-only mode. This archive will be readable through monticello clients for 
compatibility reasons.
Private projects, due to privacy reasons, will not be published in the public 
archive and will be removed to protect their owners.
Why are RMoD and Inria making this change?
SmalltalkHub has finished its cycle. The arrival of git integration in the past 
years caused the move of most users in the Pharo community to git hosting 
services. They now use exclusively other platforms. Furthermore, RMoD and Inria 
lack the manpower to properly maintain the SmalltalkHub service and keep it up 
to date. Smalltalkhub has no added value compared to other code source hosting 
platforms.
How much time do I have to adapt to this change?

The SmalltalkHub deprecation will follow the next timetable:
Monday 04 of may 2020: SmalltalkHub will be read-only. Creation of new users 
and projects will be forbidden. New commits will be rejected. All existing 
users, projects (public and private) and their commits will remain available 
and visible, but their settings will become read-only.
Monday 02 of november 2020: SmalltalkHub will be migrated to a static file 
server archive. Private projects and their commits will not be available 
anymore.

The RMoD team and Inria plan to keep the static file server alive for, at 
least, 5 years from the date of its creation.
What will happen if I do nothing?
Your public projects will become read-only and you will not be able to commit 
anymore.
Your private projects will become unavailable.
What alternatives do I have?

Those wanting to keep using monticello can migrate their projects to other 
monticello hostings such as http://squeaksource.com  
or http://ss3.gemstone.com 
Those wanting to migrate to git, Peter Uhnak’s git migration tool 
(https://github.com/peteruhnak/git-migration 
) automates monticello to git 
migration in tonel format.

Cheers,
Guille on behalf of the RMoD team

[Pharo-dev] [ANN] Complishon: efficient heuristics for code completion

[Guillermo Polito]

Hi all,

Since yesterday, Pharo 9 contains a new alternative code completion engine.
The idea behind this engine is to be pluggable, to be efficient and to be more 
accurate through the introduction of heuristics.
The completion engine implements a couple of nice heuristics, like 
 - chances are `anOrderedCollection` references an ordered collection
 - chances are you want to auto-complete messages implemented in the same 
package

New heuristics can be added easily (I was playing with plugging heuristics 
using type inference like roel typer).
If you want more details, check the blogpost:

https://masteringobjects.wordpress.com/2020/03/30/complishon-efficient-heuristics-for-code-completion/
 


And if you have ideas for new heuristics that could make your Pharo experience 
better, let us know!

Cheers,
Guille

[Pharo-dev] Today 27/03/2020: Pharo Sprint!

[Guillermo Polito]

Hi all,

Today we are having a dematerialized Pharo sprint.

# What is this sprint thingy?

We join. We fix bugs. We discuss about fixing bugs.
We add documentation. We review issues and pull requests.

We make Pharo better for us and for everybody else :).

# How is this sprint thing going on?

In discord we have a text and a voice channel dedicated to #sprint.

http://pharo.org/community 

Please feel free to join and ask questions

# What can I do to help?

## Get some knowledge => Read a couple of issues

We have > 500 open issues.
Some of them are difficult to reproduce, or the instructions are not clear 
enough, or maybe were already fixed but the issue was never closed.
If everybody takes 3 issues at random and makes a review, we will be in much 
better shape for the next sprint!!

Reviewing an issue is as easy as asking yourself the questions:
 - are there reproduction instructions?
 - it is specified the version / commit?
 - can I reproduce it?

If some of those check fails, put a comment :)

## Get some action => Fix an easy issue

In this morning (europe time) I’ve taken some time doing a pass on issues, and 
I’ve identified a list of potentially easy ones.

https://github.com/pharo-project/pharo/issues?q=is%3Aissue+is%3Aopen+label%3AEasy
 

I’ve also categorised several of them as bugs, enhancements, new features and 
cleanups.
Within those, you’ll see 
  - super-easy (like adding a comment), 
  - medium-easy (like changing some code following the analysis on the issue) 
and 
  - hard-easy like a cleanup refactoring

So if somebody wants to do a contribution for the first time, this list of 26 
issues is probably a good place to look at.

The info of how to make a PR is in here 
https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo 


## Get to know other people involved in Pharo => Discuss with us in discord

And have fun :)

Guille

Re: [Pharo-dev] Is HiExampleTest a fleaky test?

[Guillermo Polito]

I confirm it was a timeout. The jenkins report has the information in the XML, 
but the app does not show it.

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

> El 18 mar 2020, a las 9:29, Guillermo Polito  
> escribió:
> 
> Hi all,
> 
> my morning started looking at PRs, and I’ve found this one failing test.
> I have a vague memory of having seeing it before this week. But I’d like to 
> have some confirmation
> 
> 
> 
> 
> The stack trace in Jenkins tells me two things:
> 
> 
> 
> 1- It looks like a timeout?
> 2- We are only storing the stack trace text, not the Exception title/message
> 
> I’ll open an issue for 2. Any input for the rest is highly appreciated :)
> 
> Thanks,
> Guille

Re: [Pharo-dev] New VM promoted to Stable for Pharo 8

[Guillermo Polito]

https://github.com/pharo-project/opensmalltalk-vm/issues/69 


> El 3 mar 2020, a las 19:11, Sven Van Caekenberghe  escribió:
> 
> A side note, VM version strings are an absolute disaster for end users, it is 
> simply impossible to talk about a specific version.
> 
> $ ./pharo-ui --version
> 5.0 5.0.201901051900 Mac OS X built on Jan  5 2019 19:11:02 UTC Compiler: 
> 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur 64-bit VM]
> CoInterpreter VMMaker.oscog-eem.2504 uuid: 
> a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan  5 2019
> StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: 
> a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan  5 2019
> VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6
> Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> 
> WTH ?
> 
>> On 3 Mar 2020, at 19:07, tbrunz  wrote:
>> 
>> Pablo, does this only affect Macs?  I just tried this on a Linux machine,
>> updating/launching a Pharo 8 64-bit image.
>> 
>> It still showed the older VM.  I tried restarting the VM Manager, restarting
>> Pharo Launcher (1.9.2), and then re-installing Pharo Launcher, then creating
>> a new image, each time trying everything again.
>> 
>> But the version of the VM only ever says "2020-02-12", not "2020-02-20". 
>> When I tried the same thing for a 32-bit Pharo 8 image, it uses a VM dated
>> "2020-02-06".
>> 
>> What am I doing wrong?
>> 
>> 
>> 
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>> 
> 
> 

[Pharo-dev] [ANN] uFFI Booklet v1.0

[Guillermo Polito]

Hi all,

We have been working a lot in the last months in the documentation of uFFI, and 
we are happy to announce a first stable version of it that you’ll find in a 
link below :)
The booklet talks about uFFI, how to use it, how marshalling works, how to use 
structures, unions, etc.
And it is aimed for the version present on Pharo8.0.

https://github.com/SquareBracketAssociates/Booklet-uFFI/releases/tag/v1.0.1 


Of course, a v1 does not mean it’s perfect. Future versions will include new 
chapters/features that are on the pipeline such as callbacks and how to specify 
string encodings in your bindings.
Also, so if you find something to fix, to add, to remove, or something hard to 
follow, let us know 
 - by email or
 - by issue (will be easier to track actually than an email) or
 - by PR (and we will have a boost of happiness in addition)

Cheers,
Guille in behalf of everybody that helped and contributed to this

Re: [Pharo-dev] Iceberg Bug? Branches with $/

[Guillermo Polito]

Hi all,

Iceberg supports branches named with slashes. It can pull, push, merge, 
checkout…
IIRC, what does not properly work is metacello support regarding it, because 
the parser of metacello urls may consider those extra “url path elements” part 
of the directory to fetch the project.

Guille

> El 14 ene 2020, a las 18:33, Ben Coman  escribió:
> 
> On Tue, 14 Jan 2020 at 21:26, Sean P. DeNigris  wrote:
>> 
>> Ben Coman wrote
>>> I find slashes in branch names problematic
>> 
>> Okay, you've convinced me. How do we guide people toward that policy?
>> A warning when creating such branches?
> 
> That sounds reasonable. Perhaps a discrete warning icon/button appears
> that opens a Help Subject
> that describes that slashes are supported, but warns of a few
> potential pitfalls.
> 
> cheers -ben
> 

Re: [Pharo-dev] Fwd: [GitHub] Deprecation Notice

[Guillermo Polito]

Did you re-clone your repository? I don’t think so…
Did you create a PR using Pharo’s github integration?

Those are the only points we use Github’s API :/

> El 22 ene 2020, a las 9:13, ducasse  escribió:
> 
> I was just committing to my pharo fork “….using Zinc HTTP Components 1.0 
> (Pharo/9.0) ...” 
> so I do not get fully get it. 
> If I’m the only one to receive this mail then this is ok 
> 
> Guille apparently I used password else it would have failed? Can it be that 
> my password is not well set?
> 
> I have hte impression that they mean something else. 
> 
>   "We will deprecate basic authentication using password”
> 
> S
> 
>> On 22 Jan 2020, at 07:47, Guillermo Polito  wrote:
>> 
>> Hi,
>> 
>> I believe that when cloning a repository using the Github tab from iceberg, 
>> iceberg makes a request to ask github for that project’s meta-data.
>> This query identifies if the cloned repository is a fork of another 
>> repository or not, and in case it is a fork, correctly pre-configure the 
>> repository remotes to simplify further operations (such as fetching from 
>> upstream, or creating pull requests in-image).
>> 
>> If user credentials are not available, such request is anonymous.
>> However, if user credentials **are** available, they are used => this is 
>> required for private projects to work.
>> 
>> One possible solution would be to add a new kind of credentials Token-based, 
>> to existing ones (passwords also used for https, ssh key pairs).
>> 
>>> El 22 ene 2020, a las 7:34, Sven Van Caekenberghe  escribió:
>>> 
>>> We probably have to change something.
>>> 
>>> Do you know which operation (GitHub API access from Pharo code) is 
>>> responsible for this ?
>>> 
>>>> On 21 Jan 2020, at 21:05, ducasse  wrote:
>>>> 
>>>> what will be the implication?
>>>> 
>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>> From: GitHub 
>>>>> Subject: [GitHub] Deprecation Notice
>>>>> Date: 21 January 2020 at 21:03:28 CET
>>>>> To: StéphaneDucasse 
>>>>> 
>>>>> Hi @Ducasse,
>>>>> 
>>>>> You recently used a password to access an endpoint through the GitHub API 
>>>>> using Zinc HTTP Components 1.0 (Pharo/9.0). We will deprecate basic 
>>>>> authentication using password to this endpoint soon:
>>>>> 
>>>>> https://api.github.com/repositories/169849137
>>>>> 
>>>>> We recommend using a personal access token (PAT) with the appropriate 
>>>>> scope to access this endpoint instead. Visit 
>>>>> https://github.com/settings/tokens for more information.
>>>>> 
>>>>> Thanks,
>>>>> The GitHub Team
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> 

Re: [Pharo-dev] Fwd: [GitHub] Deprecation Notice

[Guillermo Polito]

Hi,

I believe that when cloning a repository using the Github tab from iceberg, 
iceberg makes a request to ask github for that project’s meta-data.
This query identifies if the cloned repository is a fork of another repository 
or not, and in case it is a fork, correctly pre-configure the repository 
remotes to simplify further operations (such as fetching from upstream, or 
creating pull requests in-image).

If user credentials are not available, such request is anonymous.
However, if user credentials **are** available, they are used => this is 
required for private projects to work.

One possible solution would be to add a new kind of credentials Token-based, to 
existing ones (passwords also used for https, ssh key pairs).

> El 22 ene 2020, a las 7:34, Sven Van Caekenberghe  escribió:
> 
> We probably have to change something.
> 
> Do you know which operation (GitHub API access from Pharo code) is 
> responsible for this ?
> 
>> On 21 Jan 2020, at 21:05, ducasse  wrote:
>> 
>> what will be the implication?
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: GitHub 
>>> Subject: [GitHub] Deprecation Notice
>>> Date: 21 January 2020 at 21:03:28 CET
>>> To: StéphaneDucasse 
>>> 
>>> Hi @Ducasse,
>>> 
>>> You recently used a password to access an endpoint through the GitHub API 
>>> using Zinc HTTP Components 1.0 (Pharo/9.0). We will deprecate basic 
>>> authentication using password to this endpoint soon:
>>> 
>>> https://api.github.com/repositories/169849137
>>> 
>>> We recommend using a personal access token (PAT) with the appropriate scope 
>>> to access this endpoint instead. Visit https://github.com/settings/tokens 
>>> for more information.
>>> 
>>> Thanks,
>>> The GitHub Team
>> 
>> 
> 
> 

[Pharo-dev] Short Survey about automatic deprecation rewrites

[Guillermo Polito]

Hi all,

We would like to share with you a short survey about the automatic deprecation 
rewrites that have been around since Pharo 6.
It will be super useful for us to enhance the support for migrations.
We estimate it will take ~< 3 minutes to fill.

This survey is aimed at people both *using* Pharo, or writing libraries and 
frameworks for Pharo.
If you’re a library/framework maintainer and you know people using your 
library, would you mind share it with them?

Link to the survey: https://sondages.inria.fr/index.php/133442?lang=en 


Thanks a lot!
Guille, in behalf of the Pharo consortium

Re: [Pharo-dev] Pumping FFI documentation

[Guillermo Polito]

Hi Ted,

I think it's the double dash —, which is pillar syntax for strikethrough 
(https://bintray.com/squarebracketassociates/wip/download_file?file_path=DistributingPillar-wip.pdf
 
<https://bintray.com/squarebracketassociates/wip/download_file?file_path=DistributingPillar-wip.pdf>).
I’ve tried removing it and the pdf compiles neatly. Another solution is to 
escape the dashes \-\- to get the double dash output in the final text (which 
in latex renders as a long dash IIRC).

I’ve fixed it in the latest commit.

> El 30 sept 2019, a las 17:28, Brainstorms  escribió:
> 
> Guillermo Polito wrote
>>> El 29 sept 2019, a las 6:13, Brainstorms 
> 
>> wild.ideas@
> 
>>  escribió:
>>> 
>>> Hi Guillermo,
>>> 
>>> I forked the uFFI booklet repo, branched your "version2", and revised &
>>> expanded the introduction section of the first chapter...
>>> 
>>> I decided that before I got too far, I should submit a pull request for
>>> just
>>> that much and get some feedback in case I need trajectory tuning.  
>>> 
>>> Your prose is easy to edit.  :^)
>> 
>> haha, thanks!
>> I saw it and merged it already :)
>> 
>>> 
>>> And it looks like my submission promptly broke Travis...  Oops.
>> 
>> I’ll check it locally, probably there is a silly pillar syntax error
>> somewhere that generates broken latex...
>> 
>>> 
> 
> I think I know what it is:
> 
>==ls -1 /lib/*/libc.so*==
> 
> probably needs some escape characters.
> 
> -t
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] Pumping FFI documentation

[Guillermo Polito]

> El 1 oct 2019, a las 8:45, ducasse  escribió:
> 
> Guille can you merge in the master like that I can read it and check without 
> messing everything up. 

Done

> 
> 
>> On 30 Sep 2019, at 10:35, Guillermo Polito  wrote:
>> 
>> 
>> 
>>> El 29 sept 2019, a las 6:13, Brainstorms  escribió:
>>> 
>>> Hi Guillermo,
>>> 
>>> I forked the uFFI booklet repo, branched your "version2", and revised &
>>> expanded the introduction section of the first chapter...
>>> 
>>> I decided that before I got too far, I should submit a pull request for just
>>> that much and get some feedback in case I need trajectory tuning.  
>>> 
>>> Your prose is easy to edit.  :^)
>> 
>> haha, thanks!
>> I saw it and merged it already :)
>> 
>>> 
>>> And it looks like my submission promptly broke Travis...  Oops.
>> 
>> I’ll check it locally, probably there is a silly pillar syntax error 
>> somewhere that generates broken latex...
>> 
>>> 
>>> -Ted
>>> 
>>> 
>>> 
>>> Guillermo Polito wrote
>>>> Hi Ted,
>>>> 
>>>> I split this in a separate thread to avoid noise :)
>>>> 
>>>>> El 23 sept 2019, a las 23:14, Brainstorms 
>>> 
>>>> wild.ideas@
>>> 
>>>>  escribió:
>>>>> 
>>>>> Guillermo,
>>>>> 
>>>>> I'm interested in helping, but at this point, I think I'd be most helpful
>>>>> working at improving documentation (mainly editing) rather than working
>>>>> on
>>>>> Pharo code itself.  (I'd like to work toward that, though.)  
>>>> 
>>>> I’ve been doing a pass on the structure, and I was thinking on a rough
>>>> structure as follows:
>>>> 1) Intro to FFI (callouts, function and library lookup, intro to value
>>>> marshalling)
>>>> 2) Marshalling (sending arguments, literal arguments, more on
>>>> marshalling, basic C types: ints, floats, pointers and how they are
>>>> transformed to pharo objects and vice-versa…)
>>>> 3) Complex types: strings, unions, arrays, opaque types
>>>> 4) Derived types on the Pharo side: How to design nice classes with all
>>>> this
>>>> 5) Callbacks
>>>> 6) Memory management
>>>> 
>>>> I did already a pass on 1), and I got blocked in 2), though I want to
>>>> release a version of it this week.
>>>> 
>>>> If you’re up for it, there are several things we can do:
>>>> - review the english :)
>>>> - give feedback on what is missing, what is not understandable, what can
>>>> be explained better
>>>> - testing the examples?
>>>> 
>>>>> 
>>>>> I'm still a newbie with Pharo, but I am a good writer/editor.  And I
>>>>> expect
>>>>> that working with Pharo documentation would be another means of
>>>>> increasing
>>>>> my knowledge of the Pharo ecosystem -- so that's additional incentive for
>>>>> me.
>>>> 
>>>> Cool :)
>>>> 
>>>>> I gather that the PDF books are written using Pillar, which I know
>>>>> nothing
>>>>> about.  Are there resources & guides for this tool/format that would help
>>>>> me
>>>>> learn how to make & edit these kinds of documents?
>>>> 
>>>> Pillar is a markup syntax (from Pier’s CMS, if you know it).
>>>> https://github.com/pillar-markup/pillar
>>>> https://github.com/pillar-markup/pillar;
>>>> 
>>>> Pillar comes with a document model, parser and generators to html, pdf
>>>> (through latex), and others…
>>>> In Pillar’s readme there are the installation instructions + usage.
>>>> 
>>>> If you check the travis file in the ffi booklet repository
>>>> 
>>>> https://github.com/SquareBracketAssociates/Booklet-uFFI/blob/version2/.travis.yml
>>>> https://github.com/SquareBracketAssociates/Booklet-uFFI/blob/version2/.travis.yml;
>>>> 
>>>> You’ll see it is built with pillar 7.4.1. In other words
>>>> 
>>>> # install pillar
>>>> $ git clone https://github.com/pillar-markup/pillar.git -b v7.4.1
>>>> $ cd pillar && ./scripts/build.sh && cd ..
>>>> 
>>>> # go into the booklet repository and build the pdf
>>>> $ ./pillar/build/pillar build pdf
>>>> 
>>>> Although you’ll need a mostly up-to-date latex version (latexmk required,
>>>> plus several other packages, check Pillar’s readme)
>>>> 
>>>>> Also, I've never contributed to an open source project; Pharo seems to be
>>>>> a
>>>>> good place to start doing so.  I see that most of the documentation, web
>>>>> pages, booklets, etc. are in English so there's the advantage that
>>>>> English
>>>>> is my first language (and I actually paid attention in school  :^).  I'm
>>>>> also aware, from experience, that Documentation is rarely the first
>>>>> choice
>>>>> for developers to apply their time & enthusiasm…
>>>> 
>>>> And it’s super important nevertheless ^^.
>>>> 
>>>> Guille
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>> 
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] Pumping FFI documentation

[Guillermo Polito]

> El 29 sept 2019, a las 6:13, Brainstorms  escribió:
> 
> Hi Guillermo,
> 
> I forked the uFFI booklet repo, branched your "version2", and revised &
> expanded the introduction section of the first chapter...
> 
> I decided that before I got too far, I should submit a pull request for just
> that much and get some feedback in case I need trajectory tuning.  
> 
> Your prose is easy to edit.  :^)

haha, thanks!
I saw it and merged it already :)

> 
> And it looks like my submission promptly broke Travis...  Oops.

I’ll check it locally, probably there is a silly pillar syntax error somewhere 
that generates broken latex...

> 
> -Ted
> 
> 
> 
> Guillermo Polito wrote
>> Hi Ted,
>> 
>> I split this in a separate thread to avoid noise :)
>> 
>>> El 23 sept 2019, a las 23:14, Brainstorms 
> 
>> wild.ideas@
> 
>>  escribió:
>>> 
>>> Guillermo,
>>> 
>>> I'm interested in helping, but at this point, I think I'd be most helpful
>>> working at improving documentation (mainly editing) rather than working
>>> on
>>> Pharo code itself.  (I'd like to work toward that, though.)  
>> 
>> I’ve been doing a pass on the structure, and I was thinking on a rough
>> structure as follows:
>> 1) Intro to FFI (callouts, function and library lookup, intro to value
>> marshalling)
>> 2) Marshalling (sending arguments, literal arguments, more on
>> marshalling, basic C types: ints, floats, pointers and how they are
>> transformed to pharo objects and vice-versa…)
>> 3) Complex types: strings, unions, arrays, opaque types
>> 4) Derived types on the Pharo side: How to design nice classes with all
>> this
>> 5) Callbacks
>> 6) Memory management
>> 
>> I did already a pass on 1), and I got blocked in 2), though I want to
>> release a version of it this week.
>> 
>> If you’re up for it, there are several things we can do:
>> - review the english :)
>> - give feedback on what is missing, what is not understandable, what can
>> be explained better
>> - testing the examples?
>> 
>>> 
>>> I'm still a newbie with Pharo, but I am a good writer/editor.  And I
>>> expect
>>> that working with Pharo documentation would be another means of
>>> increasing
>>> my knowledge of the Pharo ecosystem -- so that's additional incentive for
>>> me.
>> 
>> Cool :)
>> 
>>> I gather that the PDF books are written using Pillar, which I know
>>> nothing
>>> about.  Are there resources & guides for this tool/format that would help
>>> me
>>> learn how to make & edit these kinds of documents?
>> 
>> Pillar is a markup syntax (from Pier’s CMS, if you know it).
>> https://github.com/pillar-markup/pillar
>> https://github.com/pillar-markup/pillar;
>> 
>> Pillar comes with a document model, parser and generators to html, pdf
>> (through latex), and others…
>> In Pillar’s readme there are the installation instructions + usage.
>> 
>> If you check the travis file in the ffi booklet repository
>> 
>> https://github.com/SquareBracketAssociates/Booklet-uFFI/blob/version2/.travis.yml
>> https://github.com/SquareBracketAssociates/Booklet-uFFI/blob/version2/.travis.yml;
>> 
>> You’ll see it is built with pillar 7.4.1. In other words
>> 
>> # install pillar
>> $ git clone https://github.com/pillar-markup/pillar.git -b v7.4.1
>> $ cd pillar && ./scripts/build.sh && cd ..
>> 
>> # go into the booklet repository and build the pdf
>> $ ./pillar/build/pillar build pdf
>> 
>> Although you’ll need a mostly up-to-date latex version (latexmk required,
>> plus several other packages, check Pillar’s readme)
>> 
>>> Also, I've never contributed to an open source project; Pharo seems to be
>>> a
>>> good place to start doing so.  I see that most of the documentation, web
>>> pages, booklets, etc. are in English so there's the advantage that
>>> English
>>> is my first language (and I actually paid attention in school  :^).  I'm
>>> also aware, from experience, that Documentation is rarely the first
>>> choice
>>> for developers to apply their time & enthusiasm…
>> 
>> And it’s super important nevertheless ^^.
>> 
>> Guille
> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

[Pharo-dev] Pumping FFI documentation [WAS] FFI beginner question

[Guillermo Polito]

Hi Ted,

I split this in a separate thread to avoid noise :)

> El 23 sept 2019, a las 23:14, Brainstorms  escribió:
> 
> Guillermo,
> 
> I'm interested in helping, but at this point, I think I'd be most helpful
> working at improving documentation (mainly editing) rather than working on
> Pharo code itself.  (I'd like to work toward that, though.)  

I’ve been doing a pass on the structure, and I was thinking on a rough 
structure as follows:
 1) Intro to FFI (callouts, function and library lookup, intro to value 
marshalling)
 2) Marshalling (sending arguments, literal arguments, more on marshalling, 
basic C types: ints, floats, pointers and how they are transformed to pharo 
objects and vice-versa…)
 3) Complex types: strings, unions, arrays, opaque types
 4) Derived types on the Pharo side: How to design nice classes with all this
 5) Callbacks
 6) Memory management

I did already a pass on 1), and I got blocked in 2), though I want to release a 
version of it this week.

If you’re up for it, there are several things we can do:
 - review the english :)
 - give feedback on what is missing, what is not understandable, what can be 
explained better
 - testing the examples?

> 
> I'm still a newbie with Pharo, but I am a good writer/editor.  And I expect
> that working with Pharo documentation would be another means of increasing
> my knowledge of the Pharo ecosystem -- so that's additional incentive for
> me.

Cool :)

> I gather that the PDF books are written using Pillar, which I know nothing
> about.  Are there resources & guides for this tool/format that would help me
> learn how to make & edit these kinds of documents?

Pillar is a markup syntax (from Pier’s CMS, if you know it).
https://github.com/pillar-markup/pillar 


Pillar comes with a document model, parser and generators to html, pdf (through 
latex), and others…
In Pillar’s readme there are the installation instructions + usage.

If you check the travis file in the ffi booklet repository

https://github.com/SquareBracketAssociates/Booklet-uFFI/blob/version2/.travis.yml
 


You’ll see it is built with pillar 7.4.1. In other words

# install pillar
$ git clone https://github.com/pillar-markup/pillar.git -b v7.4.1
$ cd pillar && ./scripts/build.sh && cd ..

# go into the booklet repository and build the pdf
$ ./pillar/build/pillar build pdf

Although you’ll need a mostly up-to-date latex version (latexmk required, plus 
several other packages, check Pillar’s readme)

> Also, I've never contributed to an open source project; Pharo seems to be a
> good place to start doing so.  I see that most of the documentation, web
> pages, booklets, etc. are in English so there's the advantage that English
> is my first language (and I actually paid attention in school  :^).  I'm
> also aware, from experience, that Documentation is rarely the first choice
> for developers to apply their time & enthusiasm…

And it’s super important nevertheless ^^.

Guille

Re: [Pharo-dev] [Pharo-users] FFI beginner question

[Guillermo Polito]

See

https://github.com/pharo-project/pharo/issues/4693 
<https://github.com/pharo-project/pharo/issues/4693>
https://github.com/pharo-project/pharo/issues/4694 
<https://github.com/pharo-project/pharo/issues/4694>
https://github.com/pharo-project/pharo/issues/4695 
<https://github.com/pharo-project/pharo/issues/4695>

Of course, if somebody wants to help, you’re welcome to :)

Guille

> El 23 sept 2019, a las 13:59, Guillermo Polito  
> escribió:
> 
> Just more detail into it:
> 
>  - the source code of the booklet, written in Pillar, resides in here:
>https://github.com/SquareBracketAssociates/Booklet-uFFI 
> <https://github.com/SquareBracketAssociates/Booklet-uFFI>
> 
>  - I’ve been in the last weeks doing a pass on it (see branch version2 
> https://github.com/SquareBracketAssociates/Booklet-uFFI/tree/version2 
> <https://github.com/SquareBracketAssociates/Booklet-uFFI/tree/version2>)
>I started adding examples, and enhancing the explanations.
>I got particularly blocked when explaining marshalling where I saw several 
> issues to address / features to add before continuing documenting
> 
> I have some issues written down to fix in FFI soon:
>   1 - unify vocabulary: module and library in the API (see #ffiCall:module: 
> #macModuleName #ffiLibraryName, #ffiLibrary…)
>   2 - some of the names above are misleading (#ffiLibraryName returning a 
> library object and not a name for example)
>   3 - extend literal object support to floats
>   4 - add a strict (but safe) mode where types for literals are mandatory 
> (otherwise marshalling can go wrong :))
> 
> I’ll create issues for these in the next hours ^^.
> 
>> El 23 sept 2019, a las 13:38, Richard O'Keefe > <mailto:rao...@gmail.com>> escribió:
>> 
>> how do I
>> connect C numeric
>> types introduced by the library to FFI?
> 
> Hi Richard, what do you mean? Do you have an example? What’s the signature of 
> your C function look like?
> 
> Guille

Re: [Pharo-dev] TraitedMetaclass / Behaviour bug?

[Guillermo Polito]

> El 18 sept 2019, a las 15:05, Alistair Grant  escribió:
>>> 
>>> TraitedMetaclass stores methods in two different instance variables:
>>> 
>>> - methodDict (inherited from Behavior)
>>> - localMethods
>>> 
>>> And the same method can be different in each dictionary.
>> 
>> Yes, trais actually work by flattening the methods of traits into the user 
>> class.
>> - localMethods defines the methods actually defined in the class
>> - methodDict has the raw low-level flattened version the VM uses for the 
>> lookup
> 
> So methodDict and localMethods should always contain the same instance
> of CompiledMethod for a given selector, right?

Yes it should.

>> 
>> We are tracking this, it seems you have found two bugs :D.
>> 
>> 1st bug) Calypso and the senders/implementors should be in sync and show the 
>> same (always the local methods for traited classes)
> 
> From what you've written above (and below), the two dictionaries
> should always have the same instance of CompiledMethod so it shouldn't
> matter where it comes from.

Just for the record, yes and no :).

With the new trait implementation, we have actually a modular MOP.
All classes (whether traited or not) understand:
  - #localMethods => returning the methods as they are implemented in the class
  - #methods => returning the actual methods executed by the VM

For normal classes, #localMethods is defined as follows:

localMethods 
^ self methods

And methods understand
 - #origin => where that method is actually defined
  For example, in a traited class a lookup should be done in the trait 
composition, otherwise is the class where the method is installed.

Tools should work against #localMethods and #origin, which hide how the actual 
implementation stores the things :).
We already had in the past a lot of tools that hardcoded/duplicated the 
internals of Traits for example.

The other advantage of this is that, imagine you want to extend Pharo with: 
  - multimethods => localMethods will have a single multi-method 
implementation, and the implementation side will contain maybe an expanded 
version with type checks or even one method per type combination
  - optional parameters => a single method with many parameters should be 
expanded to many methods with less parameters + default values 

The idea is that tools do not hardcode the implementation details of these 
extensions, so the public API is #localMethods and #origin :)
Of course, one could design a tool showing #methods, which will show the 
low-level view of classes.

> 
> 
>> Moreover, (I’m confirming this with Pablo on line right now) the local 
>> methods dictionary should be just a subset of the method dictionary.
>> In other words, the invariant is that methods in localMethods should be 
>> included in the methoddict, they should not differ as they are differing 
>> there.
>> 
>> 2nd bug) UFFI? seems to be messing with this invariant :)
>> 
>> When a UFFI binding is executed for the very first time, the ffi call 
>> definition gets compiled and a new compiled method is generated performing 
>> that call.
>> When a session finishes (the image stops/restarts) ffi bindings are reset 
>> (because their compilation is platform dependent).
>> 
>> What we are seeing there is that somehow UFFI managed to reset a binding 
>> method and put a wrong one in the local method
>> 
>> I’ve seen this bug before but never got the insight of what was producing it 
>> (neither put too much time to dig on it either :P).
>> Another possibility is that the culprit are the LibGit bindings, which 
>> extend UFFI binding compilation.
> 
> I haven't looked at this, but what I saw was the localMethods was
> correct and the methodDict was old:
> 
> Redefine a base system method (LGitCommit>>commit_author:) using an
> extension method resulted in methodDict containing the original
> definition and the localMethods containing the overridden method.
> What I would expect is that the overridden method is what is used
> everywhere.
> 
> I'm not sure if this is related to UFFI or not.

Pablo tracked this down to possibly

FFIMethodRegistry >> removeMethod: aMethod

aMethod methodClass methodDict
at: aMethod selector
put: (aMethod propertyValueAt: #ffiNonCompiledMethod)

Re: [Pharo-dev] TraitedMetaclass / Behaviour bug?

[Guillermo Polito]

About bug1) I’ve found that Calypso query scopes use sometimes #methods and 
sometimes #localMethods

ClyLocalClassScope >> methodsDo: aBlock

self classesDo: [ :eachClass | 
self metaLevelsOf: eachClass do: [ :concreteMetaLevelClass |
concreteMetaLevelClass methods do: aBlock ] ]


ClyClassHierarchyScope >> methodsDo: aBlock

self classesDo: [ :eachClass | 
self metaLevelsOf: eachClass do: [ :concreteMetaLevelClass |
concreteMetaLevelClass methods do: aBlock ] ]

ClyPackageScope >> methodsDo: aBlock
self classesDo: [:class | 
class localMethods do: aBlock.
class classSide localMethods do: aBlock].

self packagesDo: [ :package | 
package extensionMethods do: aBlock ]

ClySystemEnvironmentScope >> methodsDo: aBlock

self classesDo: [:class | 
class instanceSide localMethods do: aBlock.
class classSide localMethods do: aBlock]

We should get an homogeneous version of this.

Pablo is checking the UFFI compilation now :)


> El 18 sept 2019, a las 14:20, Alistair Grant  escribió:
> 
> P.S.  Two implications of this:
> 
> 1. The code you're looking at may not be the code that is executed.
> If in doubt, use the standard System Browser (not senders,
> implementers, etc.).
> 2. Iceberg may not be loading extension methods that override an
> existing method correctly, so the old version is left as the
> executable code.  There may be happening in other situations as well,
> I haven't checked.
> 
> Thanks,
> Alistair
> 
> On Wed, 18 Sep 2019 at 11:04, Alistair Grant  wrote:
>> 
>> Hi Everyone,
>> 
>> TraitedMetaclass stores methods in two different instance variables:
>> 
>> - methodDict (inherited from Behavior)
>> - localMethods
>> 
>> And the same method can be different in each dictionary.
>> 
>> Different browsers show different versions, i.e.:
>> 
>> - The System Browser uses the method in methodDict.
>> - Calypso's "Senders of" browser uses localMethods.
>> - The Iceberg versions browser uses localMethods.
>> 
>> It appears that the method in methodDict is the one that is actually
>> used when a message is sent, but it would be nice to get confirmation.
>> 
>> To reproduce this in a clean Pharo 8 image:
>> 
>> - Open the System Browser on LGitBuf class>>signature_free: (the
>> methodDict version).
>> - Open the system browser on TLGitCalloutTrait>>call:options: and then
>> press "Senders".  The resulting window will include LGitBuf
>> class>>signature_free:, but the localMethods version.
>> 
>> In this example, #signature_free: isn't defined by the trait, and
>> isn't overwritten, so I would expect that the method in both
>> dictionaries should be the same or it should only be in one
>> dictionary.
>> 
>> Can someone say what the intended behaviour is?
>> 
>> Thanks,
>> Alistair
> 

Re: [Pharo-dev] TraitedMetaclass / Behaviour bug?

[Guillermo Polito]

Hi Alistair,

we are checking this with Pablo here, some questions inline

> El 18 sept 2019, a las 11:04, Alistair Grant  escribió:
> 
> Hi Everyone,
> 
> TraitedMetaclass stores methods in two different instance variables:
> 
> - methodDict (inherited from Behavior)
> - localMethods
> 
> And the same method can be different in each dictionary.

Yes, trais actually work by flattening the methods of traits into the user 
class.
- localMethods defines the methods actually defined in the class
- methodDict has the raw low-level flattened version the VM uses for the lookup

> 
> Different browsers show different versions, i.e.:
> 
> - The System Browser uses the method in methodDict.

Which is this System browser? Calypso system browser?

> - Calypso's "Senders of" browser uses localMethods.

and this is Calypso senders, right?

> - The Iceberg versions browser uses localMethods.
> 
> It appears that the method in methodDict is the one that is actually
> used when a message is sent, but it would be nice to get confirmation.
> 
> To reproduce this in a clean Pharo 8 image:
> 
> - Open the System Browser on LGitBuf class>>signature_free: (the
> methodDict version).
> - Open the system browser on TLGitCalloutTrait>>call:options: and then
> press "Senders".  The resulting window will include LGitBuf
> class>>signature_free:, but the localMethods version.
> 
> In this example, #signature_free: isn't defined by the trait, and
> isn't overwritten, so I would expect that the method in both
> dictionaries should be the same or it should only be in one
> dictionary.
> 
> Can someone say what the intended behaviour is?

We are tracking this, it seems you have found two bugs :D.

 1st bug) Calypso and the senders/implementors should be in sync and show the 
same (always the local methods for traited classes)

Moreover, (I’m confirming this with Pablo on line right now) the local methods 
dictionary should be just a subset of the method dictionary.
In other words, the invariant is that methods in localMethods should be 
included in the methoddict, they should not differ as they are differing there.

 2nd bug) UFFI? seems to be messing with this invariant :)

When a UFFI binding is executed for the very first time, the ffi call 
definition gets compiled and a new compiled method is generated performing that 
call.
When a session finishes (the image stops/restarts) ffi bindings are reset 
(because their compilation is platform dependent).

What we are seeing there is that somehow UFFI managed to reset a binding method 
and put a wrong one in the local method 

I’ve seen this bug before but never got the insight of what was producing it 
(neither put too much time to dig on it either :P).
Another possibility is that the culprit are the LibGit bindings, which extend 
UFFI binding compilation.

> 
> Thanks,
> Alistair
> 

Re: [Pharo-dev] Slot definition API?

[Guillermo Polito]

> El 9 sept 2019, a las 9:57, Marcus Denker  escribió:
> 
> I will have a look, but I feel that we should first get the Composed Slots 
> into the image
> as they will change everything again.

Marcus, how much time could it take you to have a mature version we can test 
and try?
I'd avoid moving research experiments into the image before they have some 
maturity...

> 
> 
>> On 8 Sep 2019, at 09:17, ducasse  wrote:
>> 
>> Hi
>> 
>> I’m fixing the class definition parser and I have a question.
>> 
>> I’m stabilizing the API of CDSlotNode
>> 
>> 
>> 1 ‘first' =>  LazyClassVariable default: 5. 
>> 2 ’second' => InstanceVariableSlot.
>> 3 ‘instVar3’
>> 
>> Here is a proposal 
>> 
>>  slotdefinition(3) name ?  variable name
>>  >>> ’instVar3'
>> 
>>  slotDefinition(2) slotClass?
>>  >>> InstanceVariableSlot
>> 
>>  slotDefinition(1) initializationMessage
>>  >>> 'default: 5’
>>  or better
>>  >>> Node(default: 5) if it exist
>> 
>> S.
>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] Slot definition API?

[Guillermo Polito]

Th¡¡

> El 8 sept 2019, a las 23:48, Torsten Bergmann  escribió:
> 
> Hi,
> 
> I'm not too deep in the CDSlotNode and related - but I wonder why we need the 
> specific #=> selector and
> 
>slotName  => Definition
> 
> mapping form in the definition at all. What are the benefits of the 
> additional "=>" style ?
> 
> To me it looks not very natural to write:
> 
>   #id => InstanceVariable.
> 
> or other specific forms. The custom subclasses of class "Slot" are already 
> inheriting the "name" iVar for the slotName.
> So using the additional slotName in the definition is
> 
> - disrupting the slot name from other arguments
> - redundant if the slot creation should have the name as well
> 
> Why not use just the plain slot object by creating it directly with a class 
> message? We can just use custom class side instantiation
> methods for the slots including the name like
> 
>  #named:
>  #named:type:
>  #named:type:default:
>   ...
> or other. I mean #=> dispatches to #named: on the slot anyway.
> 
> If we define the class / slot objects like this:
> 
>   Object subclass: #MyTask
>  slots: { BOInstanceVariableSlot named: #'id'.
>  #anotherIVar.
>  BOTypedSlot named: #'description' type: String.
>  BOAttributeSlot named: #'isDone' type: Boolean default: true.
>  BOAttributeSlot named: #'created' type: Date default: [ Date 
> today ] }
>   classVariables: {  }
>   package: 'CustomSlots-Definitions-Examples'
> 
> is more natural than the => forms where the name is just disrupted from the 
> other arguments.
> The attached file out from a Pharo 8 example demonstrates this.
> 
> Just file it in and have a look at class MyTask or inspect "MyTask new 
> created"  or "MyTask new created: 2"  to see that
> the implemented simple slot typing and defaults are working.
> 
> Then look at the definition of #MyTask class, which looks like written above. 
> It could be made even more readable using
> 
>  Object subclass: #MyTaskEvenEasier
> slots: { BOAttributeSlot named: #'id'.
> BOAttributeSlot named: #'anotherIVar'.
> BOAttributeSlot named: #'description' type: String.
> BOAttributeSlot named: #'isDone' type: Boolean default: true.
> BOAttributeSlot named: #'created' type: Date default: [ Date 
> today ] }
>   classVariables: {  }
>   package: 'CustomSlots-Definitions-Examples'
> 
> only.
> 
> The benefits without the => indirection are:
> - a simple, compact and easy readable class definition even when slots are 
> used
> - slot definitions are regular messages to the slot class - simply evaluate 
> or inspect the full slot class side message
> - we keep the possibility to mix slots with other instance variables (here 
> #anotherIVar in the example by using the symbol)
> - we keep the possibility to evaluate the full slots definition and check the 
> array of their definition
> - we unify the definition with the "MyClass slots" message - as both are just 
> return the array of slot objects
> - we do not rely on an additional specific definition API one has to remember

To me there is a drawback on this: even though being a message send is actually 
more flexible, arbitrary messages can be hard to cope with by tools.
For example, if we want to validate if a slot definition is valid before 
loading it (e.g., if its class exists), we need to identify the slot kind/class 
from that message send.
The same happens with the slot name. If someone defines a slot as

MySlot new name: #asd.

or

MySlot withName: #asd.

tools will just be much harder to implement

Although this can be helped by strong name conventions (i.e., always a slot 
definition is a message send, always the receiver is a class, always the first 
keyword is #named: ?, all args are literal).
^^

> 
> So where is the real value in the often used additional indirection of the  
> => message in slot definitions?
> 
> Thanks
> T.
> 

Re: [Pharo-dev] Slot definition API?

[Guillermo Polito]

> El 8 sept 2019, a las 17:59, ducasse  escribió:
> 
> 
> 
>> On 8 Sep 2019, at 09:17, ducasse  wrote:
>> 
>> Hi
>> 
>> I’m fixing the class definition parser and I have a question.
>> 
>> I’m stabilizing the API of CDSlotNode
>> 
>> 
>> 1 ‘first' =>  LazyClassVariable default: 5. 
>> 2 ’second' => InstanceVariableSlot.
>> 3 ‘instVar3’
>> 
>> Here is a proposal 
>> 
>>  slotdefinition(3) name ?  variable name
>>  >>> ’instVar3'
>> 
>>  slotDefinition(2) slotClass?
>>  >>> InstanceVariableSlot
> 
> Right now I return a symbol instead of the class but I could return a class.
> Now I would like to avoid to blindly think that we have a single namespace. 
> So returning a class implies to be sure that the definition is parsed in the 
> same environment 
> than the class it refers and to me this is a constraint I do not like. 
> So I will return a symbol.
> Let me know what you think. 

maybe #slotClassName instead of #slotClass?
I’m not against the symbol...

> 
>>  slotDefinition(1) initializationMessage
>>  >>> 'default: 5’
>>  or better
>>  >>> Node(default: 5) if it exist
> 
> Now I do not know what to do: because I can create a message with an empty 
> receiver. 
> Because 

Two simple solutions that come to my mind
 1) ‘instVar3’ generates a CDSlotNode with a default #slotClassName = 
#InstanceVariableSlot (I like this solution the less because it hardcodes in 
the parser knowledge about the runtime)
 2) we have two different nodes (becase they have different syntax) CDSlotNode 
and CDDefaultSlotNode and DefaultSlotNode does not have a class name and should 
be visited differently.

>> 
>> S.

Re: [Pharo-dev] Slot definition API?

[Guillermo Polito]

> El 8 sept 2019, a las 17:55, ducasse  escribió:
> 
> 
> 
>> On 8 Sep 2019, at 10:15, teso...@gmail.com  wrote:
>> 
>> Hi, I really like the idea of returning a node object for the initialization.
>> From seeing the class definition, I think we should assume that:
>> 
>> - the receiver of the slot instantiation message is a Slot. 
>> - the parameters to the slot instatiation message are literals or 
>> literal-only expressions.
>> 
>> Do you think that these assumptions / constraints are cool / enough? 
> 
> I had the same :)
> Now I wondered if allowing a block would make sense. 

If you need behaviour specific for your domain, you can always create a 
subclass of slot and redefine read: and write:, 
++ you don’t need a block :D
++ it makes it super explicit you’re doing some magic

> But it automatically raises the evaluation environment so I would prefer not. 
> 
>> Cheers. 
>> 
>> On Sun, 8 Sep 2019, 09:41 ducasse, > > wrote:
>> Hi
>> 
>> I’m fixing the class definition parser and I have a question.
>> 
>> I’m stabilizing the API of CDSlotNode
>> 
>> 
>> 1 ‘first' =>  LazyClassVariable default: 5. 
>> 2 ’second' => InstanceVariableSlot.
>> 3 ‘instVar3’
>> 
>> Here is a proposal 
>> 
>> slotdefinition(3) name ?  variable name
>> >>> ’instVar3'
>> 
>> slotDefinition(2) slotClass?
>> >>> InstanceVariableSlot
>> 
>> slotDefinition(1) initializationMessage
>> >>> 'default: 5’
>> or better
>> >>> Node(default: 5) if it exist
>> 
>> S.
>> 
>> 
>> 
> 

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

[Guillermo Polito]

Hi all,

First, please, we would love if you can test what Pablo proposed and give us 
some feedback.
It will be super helpful to evaluate if it is worth to generate a new vm 
release!!!

Also, besides what Pablo said in the previous email, I wanted to share some 
more precisions.

=== Precisions on the problem ===

First, just to clarify, we isolated the issue happening only on Windows10 #1903 
on Pharo64 bits.
Pharo32 bits does work well on that update number does work well.

The origin of the problem seems to be a bad integration between libssh2 1.7.0 
and the windows CNG crypto layer, which seemingly changed in this update.

=== The path to the solution ===

The solution was theoretically super straight forward (upgrade to openssh 1.9.0 
+ openssl for crypto instead of windows CNG).

It was however super time consuming.
 - installing the windows update #1903 to test, reproduce and understand the 
issue took for us a couple of hours, reconfiguring the virtual machines to 
enlarge disks to download it, then install it...
 - compiling openssl took literally the entire afternoon yesterday in Pablo’s 
machine.
 - then we found several bugs in cmake openssl integration when compiling 
libssh2 on Cigwin + mingw, because life cannot be easy ^^

And fortunately, we found no incompatibilities between the different versions 
of these libraries (and libgit2 too!) so it could have been more time consuming 
:P.

=== Alternative solutions and workarounds ===

Alternatively for testing the libraries that Pablo sent in the previous email, 
there are some other workarounds that people could try in the meantime:

1) Use Pharo32 bits, which as I said above, does not have the problem.

2) Use Iceberg in HTTPS (and specifically set the Iceberg-Metacello integration 
to HTTP by default).



We are also evaluating setting HTTPS by default in Iceberg as it is simpler to 
setup.
Github, Gitkraken do use HTTPS as a sensible default too.

Cheers


> El 5 sept 2019, a las 14:28, teso...@gmail.com escribió:
> 
> Hi all,
> with Guille we have been working in this issue since Monday, it
> was a complicated issue to solve as we require to compile and test
> different versions of the libgit2 library and its dependencies
> (openssl and libssh2).
> We have a workaround for using ssh in windows.
> We have produced a new set of libraries with the correct versions.
> These libraries are available in
> https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1
> The idea is to start testing them while we are working on a new
> release of the VM.
> 
> Cheers,
> Pablo
> 
> On Wed, Sep 4, 2019 at 10:05 AM Guillermo Polito
>  wrote:
>> 
>> Hi all,
>> 
>> Sorry for not communicating better :).
>> We know this is an important issue and we did move it to top priority even 
>> prior to this email ;).
>> Doru, to answer you, what people can do for the moment is to test what we 
>> are going to propose in a couple of hours in your windows machines.
>> With Pablo we have tested in several Windows 10 machines pre- and post- 
>> update 1903. Still we would like people testing on their setups and other 
>> windows versions
>> 
>> We have been working the last couple of days debugging openssh and libgit, 
>> and building a version with a more up-to-date version of openssh.
>> We will come back later this morning / early afternoon with
>> - a new vm setup using up to date versions of openssh
>> - a description of workarounds for those tied to old versions of the VM
>> So people can test.
>> 
>> Cheers,
>> Guille and Pablo
>> 
>>> El 4 sept 2019, a las 8:38, ducasse  escribió:
>>> 
>>> I saw everybody super busy and I imagine that they will reply soon.
>>> I’m travelling to give Pharo lectures.
>>> 
>>>> On 3 Sep 2019, at 19:23, Tudor Girba  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Is there a way to speed the work on this one?
>>>> 
>>>> At this moment, people cannot load any code in Pharo on Windows 10.
>>>> 
>>>> Cheers,
>>>> Doru
>>>> 
>>>> --
>>>> www.feenk.com
>>>> "Every thing has its own flow."
>>>> 
>>>>> On 28 Aug 2019, at 16:20, ducasse  wrote:
>>>>> 
>>>>> tx doru
>>>>> 
>>>>> Stef
>>>>> 
>>>>>> On 28 Aug 2019, at 16:01, Tudor Girba  wrote:
>>>>>> 
>>>>>> Hi
>>>>>> 
>>>>>> I opened an issue: https://github.com/pharo-project/pharo/issues/4437
>>>>>> 
>>>>>> I believe this should be treated as critical given tha

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

[Guillermo Polito]

Hi all,

Sorry for not communicating better :).
We know this is an important issue and we did move it to top priority even 
prior to this email ;).
Doru, to answer you, what people can do for the moment is to test what we are 
going to propose in a couple of hours in your windows machines.
With Pablo we have tested in several Windows 10 machines pre- and post- update 
1903. Still we would like people testing on their setups and other windows 
versions

We have been working the last couple of days debugging openssh and libgit, and 
building a version with a more up-to-date version of openssh.
We will come back later this morning / early afternoon with 
 - a new vm setup using up to date versions of openssh
 - a description of workarounds for those tied to old versions of the VM
So people can test.

Cheers,
Guille and Pablo

> El 4 sept 2019, a las 8:38, ducasse  escribió:
> 
> I saw everybody super busy and I imagine that they will reply soon. 
> I’m travelling to give Pharo lectures. 
> 
>> On 3 Sep 2019, at 19:23, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>> Is there a way to speed the work on this one?
>> 
>> At this moment, people cannot load any code in Pharo on Windows 10.
>> 
>> Cheers,
>> Doru
>> 
>> --
>> www.feenk.com
>> "Every thing has its own flow."
>> 
>>> On 28 Aug 2019, at 16:20, ducasse  wrote:
>>> 
>>> tx doru
>>> 
>>> Stef
>>> 
 On 28 Aug 2019, at 16:01, Tudor Girba  wrote:
 
 Hi
 
 I opened an issue: https://github.com/pharo-project/pharo/issues/4437
 
 I believe this should be treated as critical given that we cannot load 
 code in Pharo 7 (or 8) which makes it almost useless for users.
 
 Cheers,
 Doru
 
 
> On Aug 27, 2019, at 10:54 AM, Tudor Girba  wrote:
> 
> Hi,
> 
> We just encountered this on two different machines. We got this after the 
> update to Windows 1903. For us it’s a critical issue at this point. What 
> can we do to help with this?
> 
> Cheers,
> Doru
> 
> 
> 
>> On Aug 17, 2019, at 12:50 PM, Ben Coman  wrote:
>> 
>> hi Stef,  
>> I feel you missed my point. Probably I wasn't clear this has already 
>> been tested with latest Pharo 8 launched by PharoLauncher.  
>> The problem occurs with Pharo 7.0.3(64 bit) and with 
>> Pharo8.0-SNAPSHOT-build.635(64 bit) 
>> after Microsoft Windows Update 1903...
>> https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-1803-to-1903-forced-upgrade.html
>>   
>> 
>> If indeed 1903 is the cause, with this update now being *forced* down on 
>> people, this will potentially soon impact more and more Windows users.
>> But my guess that 1903 is the culprit needs to be confirmed.  
>> So I am requesting someone with access to multiple Windows machines 
>> directly compare a 1903 machine with a pre-1903 machine. 
>> 
>> cheers -ben
>> 
>> On Sat, 17 Aug 2019 at 12:58, ducasse  wrote:
>> Hi ben 
>> 
>> in the pharo launcher if you click on P8.0 (development version) you get 
>> access to all the builds. 
>> 
>> Stef
>> 
>>> On 16 Aug 2019, at 16:02, Ben Coman  wrote:
>>> 
>>> IThis morning the May 2019 Windows Update "1903" forced itself onto my 
>>> computer and now 64-bits Pharo seems to have a problem with 
>>> git_remote_fetch() FFI callout.  I no longer have a non-1903 machine to 
>>> directly compare behaviour before "1903".  Can someone familiar with 
>>> this area with both "pre-1903" and "1903" machines triage whether 
>>> "1903" is indeed the cause?
>>> 
>>> A few other recent reports are noted here...
>>> https://github.com/pharo-project/pharo/issues/3418  
>>> 
>>> cheers -ben
>> 
> 
> --
> feenk.com
> 
> "Not knowing how to do something is not an argument for how it cannot be 
> done."
> 
 
 --
 feenk.com
 
 “Live like you mean it."
 
 
>>> 
>>> 
>>> 
>> 
> 
> 
> 

Re: [Pharo-dev] [Weekend Procastination] what the new minheadless opens as posibilities :D

[Guillermo Polito]

> El 26 ago 2019, a las 14:08, ducasse  escribió:
> 
> Hi guille
> 
>> Procastination 1: Render the world fully in athens (instead of a middling 
>> bitmap) to have an idea of the effort to get fast to hdpi
>> 
>>   What you see here is a world drawn completely in athens in minheadless, 
>> where in red are the invalidated rectangles in the screen (I’m using to 
>> debug a bit).
>>   Icons are broken because I broke them while playing, not because they do 
>> not work in athens :P.
>>   There is still work to do if we want to explore this direction. Mainly 
>> performance issues to make it at least usable, so it can be iterated easily.
>>   We have seen with Pablo that a lot of time is taken in the transformation 
>> of morphic/pharo form/bitmaps to athens ones, since they do not have the 
>> same format and right now it is done with a bit-per-bit copy.
> 
> I do not get it. You are saying that it is slow while I have the impression 
> that if we remove the bit-per-bit copy we should get faster. 

There are two different things in here :).

First, in morphic we have bitmaps and forms representing for example icons and 
images.
Those forms/bitmaps are stored in a format that is not cairo compatible, so 
every time we need to render an icon a super expensive transformation takes 
place.
The other day we worked with Pablo in some caching of those transformations and 
it improves indeed a lot.
Still we have to see if it makes sense to add those caches (where to put them 
how to invalidate them, are they shared or not…), or if we change the internal 
representation of forms, or what :).

Second, right now minheadless is drawing the morphic world into a form and then 
the form is copied (literally blitted usin bitblt) into the cairo context/sdl 
texture.
What this first experiment is about is to render directly on the sdl texture 
without the extra copy.
I don’t think is will be necessary faster as this is just avoiding a couple of 
copies (blits) but the athens morphic renderer is far less optimized than the 
historical one…
The question to me is: can this be **as fast as the bitblt one** yet render 
better in hdpi?

Re: [Pharo-dev] [Pharo-users] Information on Spec development

[Guillermo Polito]

Thanks for pushing this Cyril!
This will let us move forward with Iceberg too :)

> El 13 ago 2019, a las 12:15, Cyril Ferlicot  
> escribió:
> 
> On Thu, Jun 20, 2019 at 5:29 PM Cyril Ferlicot  > wrote:
>> 
>> Hello everyone!
>> 
>> This is an important update about the development of Spec.
>> 
>> As you might have heard, we are working on Spec to release a new
>> version in Pharo 8. One goal is to unify all Pharo interfaces behind
>> one GUI framework and a second goal is to allow multiple back-ends
>> (Morphic but also GTK, Bloc, ...). To reach those goals we have been
>> updating the current version of Spec. We see now, however, that
>> updating Spec directly creates troubles with migration. For example,
>> we currently have a lot of deprecation warnings in Iceberg, because we
>> can't update it without breaking Pharo 7 compatibility.
>> 
>> After some discussions between the engineers working on Spec, here is
>> our plan to improve the situation: We will copy all classes of Spec
>> and rename them with the "Sp" prefix. (We will also ensure that every
>> class of Spec started with the same prefix for consistency). For
>> extensions methods, we will rename them to have a version different
>> from Spec 1 (The spec from Pharo 7). Once done we will integrate this
>> new version in Pharo 8. From there we will wait some weeks to let
>> users who started to use the updated Spec change their projects to use
>> this new Spec2. Finally, we will revert all changes that happened on
>> Spec 1 and deprecate the packages. We hope this will make things
>> easier for everyone.
>> 
>> Have a nice day!
> 
> Hi,
> 
> The revert of changes of Spec 1 is now done in Pharo 8.
> 
> Spec 1 is now in the same state than in Pharo 7 and Spec2 can live next to it.
> All classes of Spec2 start with the Sp or TSp prefix.
> 
> Have a nice day.
> 
>> 
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr 
> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr 

[Pharo-dev] Some new bindings for native emulation stuff

[Guillermo Polito]

Hi everybody,

I’ve been playing around with machine code simulation this last week and I’ve 
made bindings for the unicorn library and the llvm disassembler:

https://github.com/guillep/pharo-unicorn 

https://github.com/guillep/pharo-llvmDisassembler 


Funny thing: both support lots of platforms (x86 and arm both 32 and 64 bits 
and more…). So out of the box we can simulate and disassemble lots of platforms.

And in one afternoon I’ve played with them to do a native debugger with Spec2 
just for fun.
Hope this evolves a bit more soon, and that it helps somebody.

Guille

Re: [Pharo-dev] proposal - contribution workflow - PR-only for pre-fixed Issues

[Guillermo Polito]

Hi Ben,

I agree.

In general, I too do see that this artificial separation is adding little/no 
value.
This would also simplify a bit the build scripts: instead of having to parse 
the PR name to get the issue number, we could just use the available PR number.

> El 14 jul 2019, a las 10:30, Ben Coman  escribió:
> 
> Some improvements are often discovered, fixed and submitted all in the same 
> moment - prior to their being an existing Issue logged.
> When we were using MCZ files that had no facility to hang a discussion on 
> them,
> it was a good policy that **every** contribution required an Issue as a place 
> for discussion and approval.
> However we are now using Pull Requests that provide such a facility for 
> discussion and approval. 
> 
> There is not much difference between an "Issue" and a "PR" - indeed their 
> index numbers are interleaved.
> So when we already have a PR ready to go, it seems redundant to first create 
> an matching Issue just to have something to close.
> It seems particularly redundant when an Issues is created and closed within 
> the same hour a PR is submitted and unnecessary double-handling.
> 
> So I propose that pre-fixed-issues that a submitted with a code contribution 
> require a PR-only
> and "Issues" are left for reports without an immediate fix that require 
> longer term visibility.
> 
> cheers -ben
> 
> P.S. Thank you Torsten for your stream of small fixes.  
> 
> 
> 

Re: [Pharo-dev] Default line endings while writing to a file stream

[Guillermo Polito]

> El 2 jun 2019, a las 20:45, ducasse  escribió:
> 
> Sven 
> 
> why not having this as extension. 

I’d even propose to have it by default: a FileReference writeStream can return 
a ZnNewLineWriterStream wrapping the corresponding stream.
By default it can be configured with the system’s default line ending 
convention (least surprise?).
And then users can change it accordingly…

Now I ask also myself what we could do when reading line endings from a file.
I’m 98.761% convinced that in the image we should have a single line ending 
convention for strings, and that we should convert internal strings to the 
external representation of convenience explicitly.
In this direction we could make that default read streams in FileSystem to 
automatically transform external line endings into internal line endings.

> 
> Stef
> 
> 
>> On 2 Jun 2019, at 13:52, Alistair Grant  wrote:
>> 
>> Hi Ben,
>> 
>> On Fri, 31 May 2019 at 07:08, Ben Coman  wrote:
>>> 
>>> 
>>> I'm on Windows wanting to write a text file with LF endings.
>>> The code developed on Linux is thus...
>>>   (destinationDirectory / 'README.md') ensureCreateFile
>>>   writeStreamDo: [ :stream | stream nextPutAll: class comment ]
>> 
>> I've come across this so many times that I always add a couple of
>> methods to my image:
>> 
>> ZnEncodedStream>>asNewLineStream
>> "Answer the receiver wrapped with a ZnNewLineWriterStream"
>> ^ZnNewLineWriterStream on: self! !
>> 
>> 
>> ZnNewLineWriterStream>>asNewLineStream
>> "Answer the receiver wrapped with a ZnNewLineWriterStream"
>> ^self! !
>> 
>> 
>> You could then modify the example above to be:
>> 
>> stream asNewLineStream forLf nextPutAll: class comment
>> 
>> Cheers,
>> Alistair
>> 
>> 
>> 
>>> and I am stuck with CR line endings.
>>> The specific symptom is that it screws `git diff`
>>> Here is a simple experiment...
>>>   testfile := 'README.md' asFileReference.
>>>   testfile ensureCreateFile writeStreamDo: [ :stream |
>>>   stream nextPutAll: 'aa
>>> bb' ].
>>>   testfile binaryReadStream contents at: 3  "==>  Character cr "
>>> 
>>> I think its safe to assume on Linux that will result in "==>  Character lf "
>>> but can someone please confirm?
>>> 
>>> So my issue is that I've got
>>>   #ensureCreateFile - returns a FileReference
>>> and
>>>   :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream 
>>> wrapping BinaryFileStream.
>>> 
>>> and neither seem to have an easily accessible defaultLineEnding setting.
>>> Indeed, line endings are not a property of FileReference
>>> and Binary & Characters have nothing to do with line endings,
>>> and questionable if Buffering is related.
>>> 
>>> Its more a property of a File, but IIUC that is being deprecated (??)
>>> 
>>> MultiByteFileStream has #lineEndConvention:
>>> but IIUC that also is being deprecated.
>>> 
>>> So what is the proper way to force default line endings?
>>> 
>>> 
>>> --
>>> Now while composing this email I discovered String>>withUnixLineEndings.
>>> So I have a solution...
>>>   testfile := 'README.md' asFileReference.
>>>   testfile ensureCreateFile writeStreamDo: [ :stream |
>>>   stream nextPutAll: 'aa
>>> bb'  withUnixLineEndings ].
>>>   (testfile binaryReadStream contents at: 3) asCharacter   "==> Character 
>>> lf "
>>> 
>>> but that seems to imply that on Windows...
>>> 'aa
>>> bb' at: 3  "==> Character cr "
>>> 
>>> and on Linux (someone please confirm)...
>>> 'aa
>>> bb' at: 3   "==> Character lf "
>>> 
>>> and that is *very* curious.  Strange that I never noticed it before and 
>>> obviously that hasn't hurt me,
>>> but considering the Principal Of Least Surprise it leaves me feeling 
>>> somewhat violated :)
>> 
> 
> 
> 

Re: [Pharo-dev] Calypso idea - inherited tests

[Guillermo Polito]

Hi Ben,

> El 29 may 2019, a las 3:46, Ben Coman  escribió:
> 
> (Just a quick share from work before that neuron goes back to sleep and I 
> forget it...)
> 
> When a number of domain substitute classes need to satisfy the same tests,
> its useful to define these in a superclass and have subclasses define which 
> domain class is being tested e.g. 
> TestDelaySemaphoreSchedulerMmicrosecondTeicker>>classForScheduler.

For a more complex scenario (but applying to this one too), we use in Spec and 
Iceberg parametrizable tests.
Parametrizable tests define a matrix of values and then create dynamically 1 
test case per configuration in the matrix.
Still these matrixes do not yet have IDE support.

Julien and Dayné have in their roadmap to make an integration with DrTests

> 
> From the Browser "all tests" can be run for each subclass by clicking the 
> class's test-icon,
> but when that goes red, its not visible which individual test failed, and you 
> can't run an individual test from the Browser.

Yes, I’ve seen this. I run the tests in the TestRunner as a workaround myself.

> 
> In the same way that extension methods are shown in gray, it would be useful 
> for inherited tests to be shown in gray, so each has an individual indication 
> and can be run separately.
> 
> cheers -ben

Re: [Pharo-dev] Some more effort to make Slang and VMMaker work on Pharo [for review]

[Guillermo Polito]

Hi Subbu,

I do not believe this deserves a paper :P. At most a blogpost. What I can do 
quickly here is to draft the “methodology” I followed by instinct, but that can 
be reproduced by anyone.

1) generate sources from pharo
2) try to compile (and run)
3) in case of failure, make a diff with the latest version of the same file in 
the git repository of opensmalltalk vm
4) spot an interesting difference (most common cases were related to loops and 
conditions, missing or extra inlinings) => get ONE method with the problem
  4.1) Check 1: verify that the generating that method from squeak does **not** 
have the problem
  4.2) Check 2: verify that the generating that method from pharo **does have** 
the problem
 For these checks I used some of the already given VMMaker scripts
5) generate a small artificial but representative case for testing. For example:

methodWithIfNil
self something
ifNil: [ 1 ]
ifNotNil: [ 2 ]

Then I have two level of tests: AST-to-AST transformation, and generation tests.

testIfNilIfNotNilBecomesIfTrueIfFalse

| translation thisAST |
thisAST := (self class >> #methodWithIfNil) ast.
translation := thisAST asTranslationMethodOfClass: TMethod.

self assert: translation statements first selector equals: 
#ifTrue:ifFalse:

testSimpleIfNilAssignment

| translation thisAST codeGenerator result |
thisAST := (self class >> #methodWithIfNil) ast.
translation := thisAST asTranslationMethodOfClass: TMethod.
codeGenerator := CCodeGeneratorGlobalStructure new.
codeGenerator generateDeadCode: false.
codeGenerator addMethod: translation.
codeGenerator doInlining: true.

result := String streamContents: [ :stream |
translation parseTree statements first emitCCodeOn: stream 
level: 0 generator: codeGenerator.
].

self assert: result equals: 'if ((something()) == null) {
}
else {
}’

6) Fix it

* Most of the “bugs” were related to making the different #asTranslatorNodeIn: 
methods in the RB AST compliant to what it was doing in squeak.
* Sometimes I ended up doing parallel stepping in Pharo and Squeak to spot 
where the translation diverged
* Something important that I’ve learnt in the process is that Squeak’s AST 
contain already some transformations/expansions like

what you see/write:  self x ifNil: [  … ]
what you actually have:   self x == nil ifTrue: [ … ]

BUT, the most confusing point is that even if the AST internally is structured 
as in the version in the right, the printString of the AST in the inspector 
showed the left version.


Nothing new under the sun ^^.

Guille

> El 15 may 2019, a las 9:34, ducasse  escribió:
> 
> Hi Subbu
> 
>>> To do this work
>>> - I had to review the AST-to-AST transformation, checking the output,
>>> comparing it to what squeak does and so on...
>> 
>> Guillermo,
>> 
>> This is a superb effort! Thanks. Are you planning to write a paper on this 
>> part of your work? A blog? It can open new vistas for research students in 
>> Pharo.
> 
> We will see if we can produce a tutorial in how to extend the VM. Igor did it 
> in 2011 and we will redo it. Life is a cycle.
> 
> Then we would love to see if we can have a VMMaker repackaged (it should not 
> be difficult) with less code so that we can do lectures on the Pharo VM 
> and exercises for students with it. It is not really pedagogical to tell them 
> to jump over many not used classes. 
> And more important since we want to attract smart guys they will not take us 
> seriously if we present a system that is monolithic
> - we got several times students asking why VMMaker could not be cut into 
> different packages and well they are right. 
> 
> What I was thinking is that we should have soon a travis to build it 
> automatically with Pharo. 
> If you are interested to help please join the effort. 
> What guille showed us is that it was not difficult to do it in fact. 
> 
> Stef
> 
>> 
>> Regards .. Subbu
>> 
> 
> 

Re: [Pharo-dev] Some more effort to make Slang and VMMaker work on Pharo [for review]

[Guillermo Polito]

Hi Eliot,

> El 15 may 2019, a las 3:20, Eliot Miranda  escribió:
> 
> Hi Guille,
> 
> On Tue, May 14, 2019 at 7:30 AM Guillermo Polito  <mailto:guillermopol...@gmail.com>> wrote:
> 
>  - I had to review the AST-to-AST transformation, checking the output, 
> comparing it to what squeak does and so on...
> 
> Can you show a little of th differences in output between Squeak compiler 
> derived sources and RB parser derived sources?  I'm not going to demand 
> changes or fixes or that they be exactly the same.  But I am curious to know 
> what kind of changes there are.

From what I have now, I can see three main kind of differences (I actually 
compared with source code I generated myself from squeak and the existing 
sources in the git repo).
I did not work on them because the VM seemed to work, so I left them for later:

1) some comments are placed in different places in the output source code. This 
is entirely cosmetic, but it brings unnecessary noise to C source diffs.

2) labels in the gnu’ed code are numbered differently. I did not spot any “bug” 
in that yet, I did not dig enough into the gnuification to see why the 
difference, and I’m not entirely sure that this difference is caused by that 
either :)…
Anyhow, this is mostly annoying because it also brings lots of noise to diffs.

3) some for loops inline the condition while they probably shouldn't. For 
example:

0 to: (self numSlotsOf: array1) - 1 do: [ … ]

gets in my output translated to 

for (i = 0; i < (numSlotsOf(array1)); i += 1) { ...

while in the version generated from squeak

for (i = 0, iLimiT = ((numSlotsOf(array1)) - 1); i <= iLimiT; i += 1) { …

This seems the most “dangerous" difference I have so far specially if the limit 
condition has some side effect.
We will probably agree in that this third point should be fixed ^^.

>  
>  - I’ve written several unit tests to ensure that future migrations are 
> easier to do
>  - I’ve introduced several compatibility classes/methods related to 
> PackageInfo, Time and so on…
> 
> This is great1  Thank you.  Perhaps we can move some of the source generation 
> tests into the core.  It would be good for there to be tests that apply to 
> the Squeak compiler side too.  I never took the time to run tests (I look at 
> the generated source every time I make a change Slang), and writing a really 
> good set of tests always seemed like a lot of work.  But I might be tempted 
> to add to the ones you've written. 

Maybe in the next weeks I can try to massage the tests to make them less 
dependent on the source (wether squeak's or pharo’s) AST.
The thing is that Pharo’s AST is closer to the source code, while Squeak’s has 
already some pre-cooked code transformations (like #ifNil: & co), and my tests 
assume a specific AST structure to traverse the tree and compare…

Cheers,
Guille

Re: [Pharo-dev] Metacello/Iceberg detached head of cascade loaded requirements

[Guillermo Polito]

Hi Ben,

I’ll complement a bit Gabriel’s answer. See inline

> El 11 may 2019, a las 10:39, Ben Coman  escribió:
> 
> I have a query about "Detached HEAD" status after a Metacello/Iceberg
> cascade load of required packages.  Starting with the general questions...
>  Is that a common status for this scenario?

Yes.

A git repository can be mainly in two states (I’m not being really accurate 
here, just simplifying the explanation).
 - you’re working on a branch, and thus commit, merge and other operations will 
affect the current branch
 - you’re working on a commit, outside of a branch. In this case some 
operations do not work, others will work but with different semantics. The 
thing that is clear is that operations do not affect any branch.

To understand it a bit better: there is a git variable called HEAD which points 
to the current commitish we are working on.
A git repository is said to be in `Detached HEAD` when HEAD does point to a 
commitish other than a branch.

To put in in bare command-line git, in general you’ll see that HEAD points to a 
branch, mostly when we clone a fresh repository, or when we `checkout` a branch:

```
$ git checkout myBranch
```

However, when checking out a tag or a commit, HEAD points respectively to the 
commit referenced by the tag (recursively…) or to the checked out commit.

```
$ git checkout tagV1.0

or

$ git checkout abcd123
```

This happens in your scenario because the project you’re loading has some 
dependency that has a version corresponding to a tag.
Detached HEAD does not mean your repository is broken, it means that to work 
properly you need to check out a branch.


Now, let’s imagine we decide to do a tool that automatically leaves you in the 
“correct branch” to avoid Detached HEAD state, the reality is that it is no 
straight forward.

Case 1) Take the simple case where the tagged commit is referenced directly by 
two branches.
There is no good automatic way to decide which branch is the good one without 
knowing the intentions of the user, or the conventions of the project…
Even creating an automatic branch may not be what the user wanted...


Case 2) Still simple but even more complicated: the two branches have diverged 
from the tagged commit.
The tagged commit is in the history of both branches, and there is no good 
automatic way to determine which branch is the good.
They are actually both equally good.
And even more dangerous, if we silently checkout one of the branches, we may be 
checking out a version that does not work!

>  How to leave the status looking good as "Up to date”?

Well, usually you have nothing to do. First thing to understand is that in git 
there is not such thing as "Up to date”.
The best you can do is to say that

[a branch] is up to date [with respect to a remote repository]

Which means that a particular branch has everything from that specific remote 
repository.
But
 * maybe there is another repository that has more commits (typical case of 
forks in github for example)
 * while there could be in your repository a branch that is up to date, other 
branches may not.

Now, I understand that you want to “update your project” to the latest version.
Looking at the graph in Case 2 above, what you need to do is to checkout the 
correct branch.
The selection of the correct branch would depend on the decisions of the 
developer, or the conventions of the community.
Right now we have no such conventions, and even if we had them, we should give 
some alternative for those who don’t want to strictly follow them.


> 
> Here is a case example...
> To avoid the a Filetree repo "filename too long" error on Windows,
> I pre-cloned the repo to specify s shorter path name...
>   Repositories > Add > Clone from github.com
>   Owner: dionisiydk
>   Project name: Mocketry
>   Local directory: C:\Temp\Mocketry
>   Protocol: SSH
> 
> Then in Playground evaluated...
>  Metacello new
> baseline: 'Mocketry';
> repository: 'github://dionisiydk/Mocketry';
> load
> 
> This cascade loaded Ghost and StateSpecs repos leaving them
> with a status of "Detached HEAD".
> What does this mean?
> And how to have these load cleanly so they are left "Up to date” ?

Hope I answered those questions :).
If not, keep asking!

Cheers,
Guille

Re: [Pharo-dev] how implement isAbstract?

[Guillermo Polito]

Hi Andrei, Doru,

Sorry for the late reply, I've been away on vacations last week :).

Denis introduced originally the behaviour making classes return true for
#isAbstract only when they had #subclassResponsibility methods in them.
Originally, if I'm not mistaken, it was to introduce the `should be
implemented` protocol in Calypso: this was originally shown for subclasses
of abstract classes that were not abstract themselves (under that
definition).

[image: image.png]

My main point against that definition is that sometimes I have hierarchies
like:

A <|- B <|- C

Where conceptually both A and B are abstract, but I only put the subclass
responsibility methods in A.
However under that definition B was not considered as abstract, though in
my design it was.
And then I had Calypso asking me all the time to <> the methods
in the superclass, which I did not want to!

My point at the time (and that resulted in the split of isAbstract into
hasAbstractMethods) was that (at least for me) the heuristic of having
abstract methods was super weak.
A class is abstract by design and not necessarily because I can compute
something from its implementation that tells me that maybe it is abstract.
I somehow mark a class as abstract because it is abstract, not the other
way around.

On Tue, Apr 23, 2019 at 6:10 PM Tudor Girba  wrote:

> Hi,
>
> I think that it is good that isAbstract does not mean isInstantiatable.
> However, I also think that isAbstract is too generic and that it would be
> better to have the tools implement their meaning rather than relying on a
> generic term.
>
> Cheers,
> Doru
>
> > On Apr 23, 2019, at 5:58 PM, Andrei Chis 
> wrote:
> >
> > I ended up being surprised today that classes that have abstract
> > methods (send #subclassResponsibility) were returning false to
> > `isAbstract` and true to `hasAbstractMethods`.
> > I see that the behavior for isAbstract changed over the years: when it
> > was added [1] it was checking for abstract methods. Then it was
> > changed to always return false and allow overrides [2].
> >
> > Is there an explicit need to have/keep `isAbstract` at the class
> > level? Users can still instantiate those classes, send message to them
> > and get SubclassResponsibility errors. Tools could implement specific
> > solutions for handling this.
> >
> > Cheers,
> > Andrei
> >
> > [1] https://github.com/pharo-project/pharo/pull/541/files
> > [2] https://github.com/pharo-project/pharo/pull/1090/files
> >
> > On Mon, Apr 1, 2019 at 3:02 PM Tim Mackinnon  wrote:
> >>
> >> On 1 Apr 2019, at 09:54, Henrik Sperre Johansen <
> henrik.s.johan...@veloxit.no> wrote:
> >>
> >>
> >> Or, if the class has subclasses, one could get a suggestion/action to
> >> implement the missing method as
> >> missingMethod
> >> ^self subclassResponsibility
> >>
> >> Which also has the benefit of working nicely with the "expected (or was
> that
> >> "missing"?) protocol" functionality.
> >> Unless you meant something else?
> >>
> >>
> >>
> >> I don’t know if we are all talking about the same thing. In my image, I
> have a class where I haven’t got the isAbstract defined, and so Calypso
> shows a red message - as it thinks I’m supposed to implement #execute (if
> it knows my intent that my class is abstract, then it doesn’t show the red
> warning). I think this is Denis’ question?
> >>
> >> Sure, if I choose to use the abstract class, then its my choice, but as
> a lint checker -having useful warnings is helpful. But it is a nuisance
> defining isAbstract - and I’d almost prefer it assumes its abstract in this
> case (the normal expectations?) unless I tag it as concrete and signal to
> users that they might consider using my class (its probably a design smell
> these days though)
> >>
> >
>
> --
> www.feenk.com
>
> "If you interrupt the barber while he is cutting your hair,
> you will end up with a messy haircut."
>
>
>

-- 



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

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

[Guillermo Polito]

So, this morning we have been working on validating this hypothesis and
making a meaningful and reproducible test for it.
I'm just the messenger here because Pablo who has done most of the job is
shy.

## The main story

Since we are working with concurrency and non-determinism, we have designed
a test that reproduces the case with an accuracy of ~94%.
Basically the test renders a Rubric morph in concurrent green threads on a
big string, and then we compare that the drawn morphs should be bit
identical.
We have made some measurements and observed that putting three concurrent
processes made the chance of hitting the bug to almost 94%.
So running it more than ~5 times makes it highly reproducible.

Good thing: this test inside a loop of 10 iterations (to increase the
probability of hitting the bug to >~99%) detects the bug in the stock image
and not in the one with our patch.
Bad thing: this test relies on rubric, we have tried to simplify it (like
just doing a collect on the string to fetch the glyph for each character),
but simpler code produces a tighter loop which makes it far less
reproducible (down from 94 to 33%).

Still, there are several questions open:
 - can we simplify the test? :)
 - we have to think about a smart way to serialize Freetype access in the
image (there are several users)
 - I'll paste below our math, so if somebody would like to review it would
be good too, our probability is a bit rusty.
 - we have been doing benchmarks with Pablo this morning and adding a mutex
does not seem to have any negative impact in rendering.

Help is super welcome of course!!
The patch that Pablo has done in the PR will just work for the most common
cases (at least for the calypso tabs), but it shows that FT* needs some
love.
Still we would like to be able to backport something like this in Pharo7,
but backporting a big Freetype refactor would not be so good.
Maybe the mutex is a good enough change for Pharo7?

Any more ideas? input?

Cheers,
Guille and Pablo

## The code

The code of the test is the following:

```
 | sem text canvases blocky |
sem := Semaphore new.
text := (String loremIpsum: 25*1024).
FreeTypeCache current removeAll.
canvases := OrderedCollection new.

blocky := [  | canvas |
canvas := FormCanvas extent: 1000@1000.
canvases add: canvas.
(RubScrolledTextMorph new)
setText: text;
font: StandardFonts codeFont;
bounds: (0@0 corner: canvas form extent);
fullDrawOn: canvas.
sem signal ].
blocky forkAt: 39.
blocky forkAt: 39.
blocky forkAt: 39.
sem
wait;
wait;
wait.

self assert: (((canvases at:1) form bits = (canvases at:2) form bits) and:
[ ((canvases at:2) form bits = (canvases at:3) form bits) ])
```

## The math
p := 0.94 asScaledDecimal.

hittingTheBug := 0.
notHittingTheBug := 1 - hittingTheBug.
5 timesRepeat: [
hittingTheBug := hittingTheBug + (notHittingTheBug * p).
notHittingTheBug := 1 - hittingTheBug ].
hittingTheBug. "after 5 iterations"
"0.9969s8"

On Wed, Apr 10, 2019 at 8:04 PM Sven Van Caekenberghe  wrote:

> Thanks a lot for actually diving into this, this mysterious issue has been
> bugging us for a very long time. I do hope you can finally solve this. I am
> sure many people will be grateful.
>
> Sven
>
> > On 10 Apr 2019, at 15:38, teso...@gmail.com wrote:
> >
> > Hello,
> >
> > After checking the problem with Guille, we have the hypothesis of the
> > source of the problem.
> > We have seen that accessing Free Type is not thread-safe.
> > Basically, the FTFace holds a structure that is filled up with the
> > glyph and its information. As this structure is part of the Font Face
> > (a font face is a font plus size and attributes), only one request to
> > a glyph can be executed at the time. As we are sharing the same font
> > in many places, you will be starting to see the problem.
> >
> > Also, we have seen that there many accesses to the glyphs outside the
> > UI process.
> > This problem started to appear as we starting to use Calypso (but it
> > is not limited to it), as Calypso uses lazy tabs. The creation of
> > these tabs is done outside the UI process.
> >
> > This is only a hack to test our hypothesis.
> > To fix it correctly we will have to rewrite the drawing of the glyphs
> > and synchronize the access to the glyph data information. Also, we
> > want to do it in a way that does not penalize the processing in the UI
> > process.
> >
> > I have only patched the code that is used by the rendering of morphic,
> > other renderings like Athens or any other user using FT should be
> > correctly rewritten.
> >
> > Once we are sure that synchronizing the access to FT fixes the
> > problem, we will do a real fix not a dirty hack like this.
> >
> > I will be testing this new Image to see if there is an improvement.
> >
> > I will really love you try to use this image and tell me if you still
> > find the problem.
> >
> > There is a PR generating a Pharo8 image (it is called wrong, but... it
> > is a 

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

[Guillermo Polito]

We need a new stable vm...

On Wed, Apr 10, 2019 at 4:16 PM ducasse  wrote:

> Pablo I tried the file you sent and I imported it in the PharoLauncher and
> I could not handle file.
> I got a File class bad argument and after I could not use iceberg.
>
> Stef
>
> > On 10 Apr 2019, at 15:38, teso...@gmail.com wrote:
> >
> > Hello,
> >
> > After checking the problem with Guille, we have the hypothesis of the
> > source of the problem.
> > We have seen that accessing Free Type is not thread-safe.
> > Basically, the FTFace holds a structure that is filled up with the
> > glyph and its information. As this structure is part of the Font Face
> > (a font face is a font plus size and attributes), only one request to
> > a glyph can be executed at the time. As we are sharing the same font
> > in many places, you will be starting to see the problem.
> >
> > Also, we have seen that there many accesses to the glyphs outside the
> > UI process.
> > This problem started to appear as we starting to use Calypso (but it
> > is not limited to it), as Calypso uses lazy tabs. The creation of
> > these tabs is done outside the UI process.
> >
> > This is only a hack to test our hypothesis.
> > To fix it correctly we will have to rewrite the drawing of the glyphs
> > and synchronize the access to the glyph data information. Also, we
> > want to do it in a way that does not penalize the processing in the UI
> > process.
> >
> > I have only patched the code that is used by the rendering of morphic,
> > other renderings like Athens or any other user using FT should be
> > correctly rewritten.
> >
> > Once we are sure that synchronizing the access to FT fixes the
> > problem, we will do a real fix not a dirty hack like this.
> >
> > I will be testing this new Image to see if there is an improvement.
> >
> > I will really love you try to use this image and tell me if you still
> > find the problem.
> >
> > There is a PR generating a Pharo8 image (it is called wrong, but... it
> > is a Pharo8)
> >
> > 32 bits
> > =
> >
> >
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-3157/2/artifact/bootstrap-cache/Pharo7.0-PR-32bit-f8c6957.zip
> >
> > 64 bits
> > =
> >
> >
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-3157/2/artifact/bootstrap-cache/Pharo7.0-PR-64bit-f8c6957.zip
> >
> > If somebody is willing to use it in Pharo 7, I can create a PR against
> > Pharo7 to generate patched P7 images.
> >
> > Thanks!
> >
> > --
> > Pablo Tesone.
> > teso...@gmail.com
> >
>
>
>
>

-- 



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

Re: [Pharo-dev] IceGenericError: failed to stat file, Pharo LAUNCHER images and long file names on Windows

[Guillermo Polito]

Hi,


On Mon, Apr 1, 2019 at 9:26 PM Torsten Bergmann  wrote:

> If one downloads images with Launcher on Windows and accepts default names
> like "Pharo 7.0 - 32bit (stable)" this will end up in path names like
>
>"C:/Users/Admin/Documents/Pharo/images/Pharo 7.0 - 32bit (stable)"
>
> The dot and space combination in such files can later make trouble when
> downloading projects (like Seaside) using Iceberg and libgit and leading
> later to the  "IceGenericError: failed to stat file  ... The filename or
> extension is too long" problem.
>
> I guess the dot in combination with spaces in the name is sometimes seen
> as the path element on current directory.
>
> If one gives an own name like "LatestPharo7" in Launcher (having
> C:/Users/Admin/Documents/Pharo/images/LatestPharo7 then) Seaside loads
> even from the FileTree format.
>

Wow, this is weird :)

Would this be related too to this:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e8f235ef313990acae0cda037bb0b35a9c88b7ad
?


> As many people prefer to use Launcher now these days they might easily hit
> this problem.
>
> I opened an issue already for Launcher so this discussion here on ML is
> watched:
> https://github.com/pharo-project/pharo-launcher/issues/327
>
> Feedback and tests from Windows users are welcomed.
>
>
But still, the bug looks like a libgit bug, doesn't it?
I have in my hyper long TODO list to try to enhance libgit's windows
support and contribute it back to libgit...

Re: [Pharo-dev] Green tests

[Guillermo Polito]

On Tue, Apr 2, 2019 at 5:36 PM Marcus Denker  wrote:

>
>
> > On 2 Apr 2019, at 17:30, ducasse  wrote:
> >
> > Cool and thanks!
> > I love this green bar and I will try to keep it green.
> > Do you know if the test writing by pierre should be pushed in Pharo
> because I have the impression that they will be red first
> >
> If we add failing tests, then *everyone* is impacted. Instead of “ah,
> green” we will again have to manually check
> *every* *single*  Pull request. And we, again, will forget to do it. And
> thus break even more.
>
> I really think keeping the tests green is very, very much better for
> everyone.
>

Yes Marcus, but there is another "hidden" point in my mail: my fix was
really simple, anybody could have done it.
So
 - just complaining does not fix the build.
 - removing breaking tests will not guarantee us a better quality either


>
> Marcus
>
>
>

-- 



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

Re: [Pharo-dev] Green tests

[Guillermo Polito]

On Tue, Apr 2, 2019 at 5:31 PM ducasse  wrote:

> Cool and thanks!
> I love this green bar and I will try to keep it green.
> Do you know if the test writing by pierre should be pushed in Pharo
> because I have the impression that they will be red first
>

Short answer: no :).
Long answer:
  I've made a review and requested changes. The issue is related to the
need of the new VM.
  The main problem is that the only way to test it properly is to open a
file, closing it and ask your system if the file is still open (which is OS
dependent e.g., calling lsof on unix/osx, or the equivalent on windows).
  The second better test we can do is to try to open as many files as the
limit and check that we cannot open more files or that we do not segfault
:) but it's not super fun when debugging.
  Maybe we can just close/ignore that PR?

>
> Hi all,
>
> In a couple of minutes I've made some (not complicated) fixes to make
> Rubric tests green again:
> https://github.com/pharo-project/pharo/pull/3129
>
>
> I will check them.
> We got some tests for maxlength and started with the stupid point.
>

Yeah, we have to fix some ugly stuff on it (the centered ghost text, the
max length...), but there is "no rush" :).

>
> This is of course not a super Rubric enhancement (for which I've opened
> another issue requesting some missing feature
> https://github.com/pharo-project/pharo/issues/3128) but this allows us to
> move on with a better infrastructure :).
>
> There are still some some tests that fail from time to time, related to
> system announcers and finalization. See
> https://github.com/pharo-project/pharo/issues/2471.
> Though I've spent half a day yesterday and half today trying to track it
> down, I don't yet have a clear way of reproducing it. I've read the entire
> code that touches this part of the system and I really bet this is a race
> condition :).
> So any second pair of eyes here would really be helpful!
>
>
> I’m inherently race condition incompatible and just avoid concurrent
> programming because I’m too dull on this.
>

Even funnier is that I think the race condition happens during the stage
loading BaselineOfPharo. It's a super huge step, and we need better
debugging tools for that kind of scenarios...


>
> Guille
>
>
>

-- 



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

[Pharo-dev] Green tests

[Guillermo Polito]

Hi all,

In a couple of minutes I've made some (not complicated) fixes to make
Rubric tests green again:
https://github.com/pharo-project/pharo/pull/3129

This is of course not a super Rubric enhancement (for which I've opened
another issue requesting some missing feature
https://github.com/pharo-project/pharo/issues/3128) but this allows us to
move on with a better infrastructure :).

There are still some some tests that fail from time to time, related to
system announcers and finalization. See
https://github.com/pharo-project/pharo/issues/2471.
Though I've spent half a day yesterday and half today trying to track it
down, I don't yet have a clear way of reproducing it. I've read the entire
code that touches this part of the system and I really bet this is a race
condition :).
So any second pair of eyes here would really be helpful!

Guille

Re: [Pharo-dev] New stable VM for Pharo8?

[Guillermo Polito]

On Tue, Apr 2, 2019 at 2:11 PM ducasse  wrote:

> Thanks guille and pablo for you dedication for Pharo, I love you :)
>
> Now just that I understand, does it mean that the latest open smalltalk vm
> does not run on anything else that Mojave and High Sierra?
>

I don't know exactly on what versions it is not working because I have
Windows10 and Mojave.
But I know that it's not working for Pablo on OSX Sierra (which dates from
2016...).

AFAIU, Ronie has updated the VM's code to render on Metal, which made that
at some point the VM was not compiling for latest versions of OSX.
In these last weeks Ronie has also updated the code to make it compile in
older machines, but still in those versions that not support Metal the main
window just renders a black screen.

I don't know what are the following steps regarding this, I put Ronie in
cc, he may clarify a bit the situation.
In the meanwhile, using the build I say in the email above may suffice us
all I think ^^.


>
> Stef (back writing research proposal…..)
>
> On 2 Apr 2019, at 13:40, Guillermo Polito 
> wrote:
>
> Hi all, Esteban,
>
> In the last sprint with Pablo and Pierre we have detected several
> misbehaviours with files.
> The issue was particular reproducible when trying to run iceberg tests:
> the VM kind of ran out of slots for opening files. The strangest thing is
> that the leaks seemed to happen when deleting directories, so we had a look
> at the changes done to iterate directories, get file attributes and so on.
>
> While on the FileReference code everything seemed ok, we have observerd
> with `lsof` that still several directories remained open even after
> deleting them.
>
> Latest VM fixes this issue but contains another one related to Metal
> rendering, which prevents rendering in OSX versions < than High Sierra.
>
> Tracking the issue a bit, this seems to be a bug in the FileAttributes
> plugin that was fixed by this PR by alistair (
> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc28298534dafbd0c26ea34fb
> ).
>
> We have tested that particular commit (
> a838346b1a67712cc28298534dafbd0c26ea34fb
> <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc28298534dafbd0c26ea34fb>)
> and this one contains Alistair's fixes but not yet the new rendering using
> Metal. We have been testing that VM since yesterday and it seems stable,
> what do you think about marking it stable for Pharo8?
>
> Regarding Pharo7, Pharo7's stable VM is the same as Pharo8's, so it
> contains the same issue. However, since on the image side the code does not
> use the problematic primitives, we do not think we need to change the VM
> for Pharo7 (yet). However, there is seemingly a fix for directories
> containing blanks, maybe Alistair can give us some input here? :)
>
> Ideas?
>
> Thanks,
> Guille and Pablo
>
>
>

-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

[Pharo-dev] New stable VM for Pharo8?

[Guillermo Polito]

Hi all, Esteban,

In the last sprint with Pablo and Pierre we have detected several
misbehaviours with files.
The issue was particular reproducible when trying to run iceberg tests: the
VM kind of ran out of slots for opening files. The strangest thing is that
the leaks seemed to happen when deleting directories, so we had a look at
the changes done to iterate directories, get file attributes and so on.

While on the FileReference code everything seemed ok, we have observerd
with `lsof` that still several directories remained open even after
deleting them.

Latest VM fixes this issue but contains another one related to Metal
rendering, which prevents rendering in OSX versions < than High Sierra.

Tracking the issue a bit, this seems to be a bug in the FileAttributes
plugin that was fixed by this PR by alistair (
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc28298534dafbd0c26ea34fb
).

We have tested that particular commit (
a838346b1a67712cc28298534dafbd0c26ea34fb
)
and this one contains Alistair's fixes but not yet the new rendering using
Metal. We have been testing that VM since yesterday and it seems stable,
what do you think about marking it stable for Pharo8?

Regarding Pharo7, Pharo7's stable VM is the same as Pharo8's, so it
contains the same issue. However, since on the image side the code does not
use the problematic primitives, we do not think we need to change the VM
for Pharo7 (yet). However, there is seemingly a fix for directories
containing blanks, maybe Alistair can give us some input here? :)

Ideas?

Thanks,
Guille and Pablo

Re: [Pharo-dev] Missing tests for FFI in CI

[Guillermo Polito]

Hi Stephan,

Le jeu. 21 mars 2019 à 21:39, Stephan Eggermont  a écrit :

> ducasse  wrote:
> > Hello Stefan
> >
> > Can you report the exact call you were doing?
> > I talked with G and Pablo and the bug they fixed is not the same.
> > Now they would like to experiment and write tests for all the platform.
>
> BOOL GetExitCodeProcess(
>   HANDLE  hProcess,
>   LPDWORD lpExitCode
> );
>

what are your mappings for BOOL, HANDLE and LPDWORD? Those are user defined
types :)


> I was trying to get the exit code of a running process on windows. That
> didn’t work, so we started again with OSWindows on a clean Pharo 8. There
> we noticed that the currentProcess was not [ 255 255 255 255 255 255 255
> 255] but [ 255 255 255 255 0 0 0 0]. That (and the test being green in 32
> bit) triggered the idea. We did a quick and dirty change to verify, and
> then found out that the Squeak code had cleaner fixes.
>
> Stephan
>
>
>
>
> --



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

Re: [Pharo-dev] About a better filedialog

[Guillermo Polito]

YES!

On Mon, Mar 18, 2019 at 11:13 PM ducasse  wrote:

> Yes I had to rename ComposableModel into ComposablePresenter so this is
> probably that
>
> On 18 Mar 2019, at 23:09, Peter Uhnak  wrote:
>
> Thanks Stef!
>
> The build is failing for Pharo 6.1 for some reason (I can't reproduce it
> locally), but I can look at that during the weekend...
>
> Peter
>
> On Mon, Mar 18, 2019 at 9:23 PM ducasse  wrote:
>
>> Alex
>>
>> Have a look at the one I propose and play with it.
>> Let me know what you think.
>>
>> Stef
>>
>> On 18 Mar 2019, at 21:20, Alexandre Bergel 
>> wrote:
>>
>>
>> *From: *Alexandre Bergel 
>> *Subject: **Re: [Pharo-dev] About a better filedialog*
>> *Date: *18 March 2019 at 21:20:35 CET
>> *To: *Pharo Development List 
>>
>>
>> I do not have time to personally work on this. But yes, having a better
>> file dialog would be fantastic
>>
>> Alexandre
>>
>> On Mar 18, 2019, at 4:31 PM, ducasse  wrote:
>>
>> Hi guys
>>
>> I did a pass (ported to P7, tonel, some little fixes) on the file-dialog
>> developed by Peter Uhnak and I think that it would be good to propose it by
>> default in the image.
>> what do you think?
>>
>> https://github.com/Ducasse/file-dialog
>>
>> I would also like that the filedialog remembers the last list of visited
>> directory. (I will see if I can add this).
>> When Spec2 is out I would like to port it to Spec2.
>>
>> Does anybody want to help? Because it would be super nice and I’m full
>> with cleaning textEditor and pluggableTextMorph.
>>
>> Stef
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

-- 



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

[Pharo-dev] [ANN] Iceberg 1.5.7 (pharo6 is back)

[Guillermo Polito]

Hi all,

I'm on vacations, so I've produced a new patch version of Iceberg :).
This version restores compatibility with Pharo6, which was broken since
latest changes done for Pharo7 64bit support.

https://github.com/pharo-vcs/iceberg/releases/tag/v1.5.7

I hope people still using Pharo6 find this useful. You should be able now
to use again the update script to use latest iceberg on it. I've updated
the doc to point to the latest supported version:

"load iceberg"Metacello new
baseline: 'Iceberg';
repository: 'github://pharo-vcs/iceberg:v1.5.?';
onWarningLog;
load.


On this same direction, we have been discussing that v1.5.* will be the
latest minor version supporting Pharo6. Still, we will keep integrating
bugfixes and patches as they come.

New versions (>= 1.6) will host the new features and will be available and
maintained for both the stable Pharo7 and the in-development Pharo8
versions.

Enjoy,
Guille

Re: [Pharo-dev] Pillar branch names (was: ConfigurationOfGrease for Pharo8)

[Guillermo Polito]

On Sat, Feb 9, 2019 at 5:32 PM Alistair Grant  wrote:

> Hi Guille,
>
> On Mon, 4 Feb 2019 at 09:43, Guillermo Polito 
> wrote:
> >
> > On Mon, Feb 4, 2019 at 9:28 AM Alistair Grant 
> wrote:
> >>
> >> Hi Stef,
> >> On Mon, 4 Feb 2019 at 09:20, ducasse  wrote:
> >> >
> >>
> >> The dev-7 branch loads fine in Pharo 8.
> >>
> >> > > But what do you mean by "now it is 70”?
> >> >
> >> > I thought that guillermo changed the dev-7 branch.
> >
> > Nope, I think that name is good, and then we manage releases using tags.
> We have the following branches:
>
> What do you think of following the same naming convention as
> pharo-project/pharo, i.e. using branch names Pharo7.0 instead of
> dev-7?


> I think that would make it easier for newcomers.
>

Well, not necessarily pillar version 7 is for Pharo version 7, or pillar
version 6 is for pharo 6.
Until now, those namings were a bit accidental...

Actually, between pillar 6 and 7, the major change (user-wise, and not
implementation wise) is that it can be built without makefiles and works on
windows.
But the pillar parser and ASTs do not change (or not that I'm aware of).


> Cheers,
> Alistair
>
>

-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Esteban's ChangeLog week of 4 February 2019

[Guillermo Polito]

On Mon, Feb 11, 2019 at 9:54 AM Norbert Hartl  wrote:

>
>
> Am 11.02.2019 um 09:22 schrieb Esteban Lorenzano :
>
>
>
> On 11 Feb 2019, at 09:20, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
>
>
> Le lun. 11 févr. 2019 à 08:45, Norbert Hartl  a
> écrit :
>
>>
>>
>> > Am 11.02.2019 um 08:00 schrieb esteba...@gmail.com:
>> >
>> > Hello!
>> >
>> > This is my weekly ChangeLog, from 4 February 2019 to 10 February 2019.
>> > You can see it in a better format by going here:
>> http://log.smallworks.eu/web/search?from=4/2/2019=10/2/2019
>> >
>> > ChangeLog
>> > =
>> >
>> > 9 February 2019:
>> > 
>> >
>> > *=== On layouts
>> >As you know, I've been workingon layouts for Spec 2. The basic
>> layouts I want to have available next week(s) are four:
>> >
>> >* +SpecBoxLayout+ : A simple way to place components horizontally or
>> vertically
>> >* +SpecPanedLayout+ : Same as box layout, but with a resizable
>> splitter (and it will allow just two... if you want more you will need to
>> compose).
>> >* +SpecGridLayout+ : To place components in a grid (x,y coordinates
>> and spans)
>> >* +SpecXYLayout+ : This could be renamed as +SpecAbsoluteLayout+ and
>> it's name says all, it will allow absolute location of components
>> (obviously, in relation with its parent).
>> >
>> >For a second phase there will be a couple more +SpecFlowLayout+ and
>> a kasowari layout (without name yet :P).
>> >
>> Apple and others call it auto layout. I don‘t like that name as it isn‘t
>> really clear. It could be called ConstraintLayout.
>>
>> +1 for  ConstraintLayout
>
>
> Ok, Constraint will be :)
> (But it will not arrive until half part of P8 development :P)
>
> No problem if you remember then ;) In the meantime you can rename XYLayout
> to AbsoluteLayout :D
>

Or FixedLayout :P. Because actually it's not absolute, it's relative to its
parent xD.


>
> Norbert
>
> Esteban
>
>
> Norbert
>> >The ones on first phase are the most important ones. In particular,
>> we have detected that with
>> >first three (Box, Paned, Grid) we can reproduce everything we have
>> currently in Pharo. The second phase
>> >will add possibilities for the future.
>> >
>> >Anyway, I have "kind-of-working" the first three, but I have
>> problems when applying layouts here and there, because
>> >morphic time to time wants to behave differently than asked.
>> >
>> >One of the problems is that for this layouts, to make them behave
>> correctly (and without a lot of work from users),
>> >I will need to add the concept of "minimum, preferred and maximum"
>> extent. Reason why I'm playing with a small
>> >implementation of styling... which most probably will go away once I
>> find the best way to handle this constraints.
>> >
>> >So, this week I have nothing finished, just a pointer to my current
>> work: [
>> https://github.com/estebanlm/Spec/tree/dev-2.0](https://github.com/estebanlm/Spec/tree/dev-2.0)
>> >
>> >
>> > 7 February 2019:
>> > 
>> >
>> > *Small fix-a-day: [
>> https://github.com/pharo-project/pharo/pull/2452](https://github.com/pharo-project/pharo/pull/2452)
>> >
>> >
>> > cheers!
>> > Esteban
>> >
>
>
>

-- 



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

Re: [Pharo-dev] iceberg: merging branches just at the git level without changing code in the image

[Guillermo Polito]

Hi,

On Mon, Feb 4, 2019 at 6:19 PM Andrei Chis 
wrote:

> Hi,
>
> Currently in Iceberg to merge a branch into another, we need to checkout
> the branch into which we want to merge and then do the merge.
>

For the moment it is done that way because
 - every commit is first written in disk before moved to the index and then
commited
 - a merge, unless fast forward, will need to create a new commit, and
potentially if there is a merge conflict it requires some manual
intervention

Also, we have decided for the moment to follow git's semantics to avoid
MORE terminology/technological mismatch than what we have.
We could implement the merge operation to work on any two arbitrary
branches, but still in case of merge conflict it's not so straight forward.
We have discussed in Esug with some guys, and there would be the
possibility to have automatic merge strategies like:
  - take all incoming
  - take all outgoing

But still there are cases where the user would like a mix of them, and even
do manual modifications.

Checking out a branch also updates the code in the image, which when
> needing to perform automatic releases on a branch can cause issues.
>

> Is there already a way in Iceberg to switch to a branch (for example
> `release`) and then merge another branch (for example `master`) into it
> without updating any code in the image?
> The use-case is that the user is on the `master` branch and needs to merge
> `master` into `release` without changing any code in the image.
>

Yes, when you checkout a branch, there is a combobox:

[image: image.png]

You can choose the last option for it.
These are called in iceberg CheckoutStrategies, and though they are so far
only used for checkouts, they could be used for merge toos.


>
> I found LGitRepository>>#merge:, but it seems not to be used anywhere in
> the image.
>
> Another way would be to implement something like the method below. This:
>   - calculates what changes need to be merged
>   - always takes what is on the left branch (in this case what is on
> master overrides what is on release)
>   - does not call loadChangesInWorkingCopy: to update the working copy as
> the code is already in the image
>   - refreshes the dirty packages in case there are changes between what is
> on the image and what is on disk
>
> ```
> IceMerge>>#executeWithAcceptingLeftOnConflictAndWithoutImageUpdate
> | commitToAdvance |
> mergeCommit validateCanMerge.
> self isAlreadyMerged ifTrue: [ ^ self ].
>
> self calculateChanges.
> self conflictsDo: [ :operation |
> operation selectLeft.
> ].
> commitToAdvance := self updateHead.
> "Do not update the working copy"
> "repository workingCopy loadChangesInWorkingCopy: self
> changesToWorkingCopyTree."
> repository workingCopy refreshDirtyPackages.
> ^ commitToAdvance
> ```
>
> Could something like the above solution work? Or are there other issues to
> take into account?
>

I think something like that would work...
But it would be nice to extract those things to be more reusable?
 - a conflict resolution strategy (with a default "do not solve conflict")
 - a checkout strategy (with a checkout in image strategy).

Anyway you go, I'd write some tests about that, since a broken merge can
lead to super fuzzy behaviour (like losing code...) :)


> Cheers,
> Andrei
>
>
>
>

-- 



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

Re: [Pharo-dev] ConfigurationOfGrease for Pharo8

[Guillermo Polito]

On Mon, Feb 4, 2019 at 9:28 AM Alistair Grant  wrote:

> Hi Stef,
> On Mon, 4 Feb 2019 at 09:20, ducasse  wrote:
> >
> > Hi alistair
> >
> > >> HI alistair
> > >>
> > >> you should use the latest pillar. Was dev-7 and now it is 70
> > >> because this is around six months that we removed the dependency to
> grease.
> > >
> > > I can see the dev-7 branch (which is what I'm using in Pharo 8).
> >
> >
> > And this is the one that broke? Strange.
> > Now we did not try Pillar in Pharo 80.
> > Could you try in Pharo70?
>
> No, the smalltalkhub version was "broken", but that's to be expected
> since it was out of date.
>
> The dev-7 branch loads fine in Pharo 8.
>
> > > But what do you mean by "now it is 70”?
> >
> > I thought that guillermo changed the dev-7 branch.
>

Nope, I think that name is good, and then we manage releases using tags. We
have the following branches:

[image: image.png]


> > Ok I checked and this is a tag. 7.4.1
>
> And that answers my question.
>
> Thanks,
> Alistair
>
>

-- 



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

Re: [Pharo-dev] Debugger opening on user halt and not Object>>halt

[Guillermo Polito]

Hi Thomas,

Check the pragma debuggerCompleteToSender and its users. I think it's
related to that.
BenComan probably can give a better insight since (if I recall correctly)
he introduced it?

Guille

On Wed, Jan 30, 2019 at 5:44 PM Thomas Dupriez 
wrote:

> Hello,
>
> Does someone know which is the code responsible for the debugger opening
> on the halt of the user instead of Object>>halt (see picture)? It's neat
> but it's not the regular behaviour so I'm guessing it is handled somewhere
> specifically for halt messages?
>
>
> Thomas
>


-- 



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

Re: [Pharo-dev] Contribute to pharo8.0 ?

[Guillermo Polito]

Hi,

there is an issue for this problem,

https://github.com/pharo-project/pharo/issues/2379

We have identified the cause, I'll propose a fix now

On Wed, Jan 30, 2019 at 8:44 AM ducasse  wrote:

> >
> > There is currently a bug eating one character of the commit hash. So
> > Iceberg does not find the hash and thinks we need a fetch. So currently
> > we need to checkout Pharo8.0 in order to be in a good state :(
>
> OOPs is there a bug entry?
> >
> >> I also don't understand how to make an issue branch for
> >>
> >> https://github.com/pharo-project/pharo/issues/2395
> >>
> >> Is it Iceberg > Pharo > Create new branch for issue or Iceberg > Github
> > Create new branch for issue ?
> >
> > Just create a branch and choose the option to create a branch from a
> > Github option.
> >
> > The other one was for Manuscript and is now useless for Pharo 8. I
> > opened an issue in Iceberg to remove it but I did not got the time to
> > contribute the change.
> >
> >> What is the difference ?
> >> What about the Remote ?
> >> Can I work with only an issue on GitHub ?
> >>
> >
> > Yes!
> >
> > What I am doing currently:
> >
> > - Open an issue XX
> > - Sync my fork Pharo8.0 branch via command line (This is optional and
> > can also be done in Pharo. I just do it via command line because I like
> > it better that way)
>
> how do you do it? Pull?
>
> > - Download a Pharo 8 image
> > - Checkout the Pharo8.0 branch to get in a clean state because of the
> > hash eating bug I mentioned earlier
> > - Create a new branch from a github issue of the pharo remote
> > - Do the changes and commit. I add `Fixes #XX` in the commit message to
> > close automatically the issue when the PR is merged.
> > - Push to my remote
> > - Open a PR against Pharo8.0 through Iceberg > GitHub > Create new pull
> > request
>
> and checkout the pharo 8 branch to fix the next one.
> >
> >> Is the documentation
> >>
> >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo
> >>
> >> really up to date ?
> >>
> >
> > No
> >
> > We should correct the hash eating bug before updating it I think.
> >
> >> Sven
> >>
> >>
> >
> >
> > --
> > Cyril Ferlicot
> > https://ferlicot.fr
> >
>
>
>
>

-- 



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