August 2022 - Pharo-dev - lists.pharo.org

Platform Packages vs. Git Branches

by sean＠clipperadams.com

Iâve always supported multiple platforms (e.g. different Pharo versions) via packages like MyProject-Plaform-Pharo9. Thinking back, the primary reason is that is how I saw it done by other projects. Also, I adopted the practice well before git was in wide use in the Pharo world. However, Jan Bliznicenko recently suggested an alternate workflow which sounds like how Pharo itself is managed: use git branches, with the primary branch supporting only latest Pharo, and other branches only getting critical bug fixes backported. Not sure how that would work for projects that support other dialects e.g. Gemstone and Squeak, since there would then be multiple âlatest versionsâ. Iâm interested in opinions about these options as I feel that Magritte is an important community asses and want to keep it compatible on as many platforms as possible (with as little work as possible)! I also get the feeling that many people keep ancient systems in production, and I wonder which they would prefer - a project that is stable on a Pharo version (more or less) when that version is released or having the latest commits, especially bug fixes. Thoughts?

Aug. 25, 2022

Re: Status update of Libgit2 and CI issues

by Nicolas Anquetil

yes indeed thanks a lot for handling this during ESUG ! nicolas On 23/08/2022 17:07, Guillermo Polito wrote: > Hi all, > > * after some hiccups, CI servers are up un running. > > See for example: > > https://github.com/moosetechnology/Moose/runs/7976358526?check_suite_focus=… > > * 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 > > Please, tell us if you find some other problem. > G > >> El 19 ago 2022, a las 21:31, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> 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 >> (<guillermopolito(a)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. >> >> 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-Par… >> https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Pa… >> https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-P… >> https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-P… >> >> Libgit bindings Upgrade >> Â Â changes: >> https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c… >> Â Â 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 >> > -- Nicolas Anquetil RMod team -- Inria Lille

Aug. 23, 2022

Re: What, exactly, does `#=` mean?

by Nicolas Cellier

The general expectations are that = should be an equivalence relation - reflexive (a = a) = true - symmetric (a = b) = (b = a) - transitive (a = b) & (b = c) ==> (a = c) https://en.wikipedia.org/wiki/Equivalence_relation Note that = is currently not an equivalence relation for Float, because of (Float nan = Float nan) = false. Also note that Number = means that the values are equal, not necessarily that the behavior is identical. For example (1/2) = 0.5, but (1/2) printString ~= 0.5 printString, and 0.5 does not understand #denominator for example... We expect the behavior to match to some degree, but it's very application specific... In some dialects (1/10) = 0.1 even if those numbers don't share the same value (and this obviously breaks the transitivity rule). Another questionable example is (1 to: 3) = #(1 2 3). The answer might differ across Smalltalk dialects. A point of view is that they behave similarly as two sequenceable collections with equal elements. Another point of view is that the implementation cost is too high, for example for maintaining hash implication (a = b) ==> (a hash = b hash). Even, 'foobar' = #foobar is dialect specific (a false answer enables hash optimization by using identityHash for Symbol). A clear sign that there is not a unique definition... If it is about cached state, I see it as an implementation detail (an optimization), and best efforts should be made so that the optimization remains a detail, and does not leak into behavioral differences... Well, except in well known and well documented cases if we can't avoid it. Nicolas Le mar. 23 aoÃ»t 2022 Ã 15:59, James Foster <Smalltalk(a)jgfoster.net> a Ã©crit : > I donât think there is a formal definition. Iâve heard it described as > âanswers the same result when sent the same messageâ but that wouldnât work > for #âidentityHashâ, so I think it is whatever you say it is in your domain. > > By the way, I try to avoid the term âequalâ and use âequivalentâ and > âidenticalâ to describe #â=â and #â==â respectively. > > James > > On Aug 23, 2022, at 3:48 PM, sean(a)clipperadams.com wrote: > > Anyone know of a book that goes in depth explaining `#=`? > > I've always wondered what "equal" is supposed to mean. > > For example, if I have two objects representing the same person, but one > has their webpage cached as state, they represent the same entity, and are > interchangeable in many contexts, but also have a difference that may be > important in other contexts. > > Is âequalâ whatever you say it is in your domain, or is it a Smalltalk > object system concept? If the latter, what is the exact expectation? > > >

Aug. 23, 2022

Re: Status update of Libgit2 and CI issues

by 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=… <https://github.com/moosetechnology/Moose/runs/7976358526?check_suite_focus=…> * 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 <hernan.morales(a)gmail.com> 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 (<guillermopolito(a)gmail.com <mailto:guillermopolito@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-Par… <https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-ARM64-Third-Par…> > https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Pa… <https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Pa…> > https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-P… <https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-P…> > https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-P… <https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-P…> > > Libgit bindings Upgrade > changes: https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c… <https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c…> > 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

Aug. 23, 2022

Re: What, exactly, does `#=` mean?

by James Foster

I donât think there is a formal definition. Iâve heard it described as âanswers the same result when sent the same messageâ but that wouldnât work for #âidentityHashâ, so I think it is whatever you say it is in your domain. By the way, I try to avoid the term âequalâ and use âequivalentâ and âidenticalâ to describe #â=â and #â==â respectively. James > On Aug 23, 2022, at 3:48 PM, sean(a)clipperadams.com wrote: > > Anyone know of a book that goes in depth explaining `#=`? > > I've always wondered what "equal" is supposed to mean. > > For example, if I have two objects representing the same person, but one has their webpage cached as state, they represent the same entity, and are interchangeable in many contexts, but also have a difference that may be important in other contexts. > > Is âequalâ whatever you say it is in your domain, or is it a Smalltalk object system concept? If the latter, what is the exact expectation? >

Aug. 23, 2022

What, exactly, does `#=` mean?

by sean＠clipperadams.com

Anyone know of a book that goes in depth explaining \`#=\`? I've always wondered what "equal" is supposed to mean. For example, if I have two objects representing the same person, but one has their webpage cached as state, they represent the same entity, and are interchangeable in many contexts, but also have a difference that may be important in other contexts. Is âequalâ whatever you say it is in your domain, or is it a Smalltalk object system concept? If the latter, what is the exact expectation?

Aug. 23, 2022

Re: about object serialization and deserialization

by CÃ©drick BÃ©ler

Maybe a bit off topic, I found preserves from Tony Garnock-Jones who btw managed to run squeak on smartphone ;) * Preserves is a new data model and serialization format in many ways comparable to JSON, XML, S-expressions, CBOR, ASN.1 BER, and so on. https://preserves.dev/ https://git.syndicate-lang.org/tonyg/squeak-phone https://eighty-twenty.org/tag/squeak-phone/ Happy ESUG for those in Navi Sad, Cedrick > Le 16 aoÃ»t 2022 Ã 12:11, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > ï»¿Hi Stef, > >> On 15 Aug 2022, at 20:25, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Hi guys >> >> It is interesting to think about the design and use of object deserializers. >> >> https://www.slideshare.net/frohoff1/deserialize-my-shorts-or-how-i-learned-… >> >> <2204.09388.pdf> > > Interesting, and indeed, a big problem (especially denial of service attacks). > > Step one is to be conscious of the problem (which exists across all language/formats). > > Step two could be to add some sanity checks (limits) to parsers. > > Would be a nice subject for a (student) project. > > Sven

Aug. 21, 2022

Re: Status update of Libgit2 and CI issues

by HernÃ¡n Morales Durand

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 (< guillermopolito(a)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. > > 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-Par… > > https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Pa… > > https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-P… > > https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-P… > > Libgit bindings Upgrade > changes: > https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c… > 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

Aug. 19, 2022

Re: Status update of Libgit2 and CI issues

by Gabriel Cotelli

Thank you for the update. Once the new VM and image versions are built by the CI I will update also the ba-st docker Pharo images, so they start working flawlessly again. On Fri, Aug 19, 2022 at 11:45 AM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > 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-Par… > > https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Pa… > > https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-P… > > https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-P… > > Libgit bindings Upgrade > changes: > https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c… > 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

Aug. 19, 2022

Status update of Libgit2 and CI issues

by 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-Par… https://github.com/pharo-project/pharo-vm/wiki/Building-OSX-X86_64-Third-Pa… https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM64-Third-P… https://github.com/pharo-project/pharo-vm/wiki/Building-Linux-ARM32-Third-P… Libgit bindings Upgrade changes: https://github.com/pharo-vcs/libgit2-pharo-bindings/commit/0e0100f7d0f3a11c… 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

Aug. 19, 2022