November 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Zinc HTTP Components version 3.0.1

by Norbert Hartl

Great!!!! That removes a decent disruption we had. Thank you very much! Norbert > Am 22.11.2018 um 21:55 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > I finally merged and synced all Zinc HTTP Components repos and did a full release on Pharo versions 3 to 7. > > https://github.com/svenvc/zinc/releases/tag/v3.0.1 > > Main README was updated > > https://github.com/svenvc/zinc > > Green build for Pharo 7 RC1 (linux 64-bit) using BaselineOfZincHTTPComponents > > https://travis-ci.org/svenvc/zinc > > Green builds for Pharo 3, 4, 5 and 6 using ConfigurationOfZincHTTPComponents (#stable 3.0.1) > > https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/ > > If there are any problems or issues, don't hesitate to ask. > > Sven > > > >

Nov. 22, 2018

Zinc HTTP Components version 3.0.1

by Sven Van Caekenberghe

I finally merged and synced all Zinc HTTP Components repos and did a full release on Pharo versions 3 to 7. https://github.com/svenvc/zinc/releases/tag/v3.0.1 Main README was updated https://github.com/svenvc/zinc Green build for Pharo 7 RC1 (linux 64-bit) using BaselineOfZincHTTPComponents https://travis-ci.org/svenvc/zinc Green builds for Pharo 3, 4, 5 and 6 using ConfigurationOfZincHTTPComponents (#stable 3.0.1) https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/ If there are any problems or issues, don't hesitate to ask. Sven

Nov. 22, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Christophe Demarey

> Le 22 nov. 2018 Ã 13:25, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > >> On 22 Nov 2018, at 13:21, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >>> On 22 Nov 2018, at 12:48, Christophe Demarey <Christophe.Demarey(a)inria.fr <mailto:Christophe.Demarey@inria.fr>> wrote: >>> >>> Hi, >>> >>> Why not following git flow? >>> Keep the development branch for dev and open a 70-release branch to prepare the release. >>> This way, there is no change for most people. >> >> Because our scripts are automated in branch and tag basis. >> dev-7.0 will generate SNAPSHOT versions for files.pharo.org/70 <http://files.pharo.org/70> and tags (v7.0.0-rc1, for example) will generate a release. maybe not for now but we can update the scripts to check: - master branch => release (only release tags there) - development branch => snapshot - release branch => snapshots or realease (rcx) if a tag is defined - all other branches => do nothing >> >> We could have another flow, but this was what we decided last week and we will try it (maybe this is wrong and we will need to change it, but wellâ¦ weâll seeâ¦ good part of having a process is that we can iterate on it :P) > > Btw, Iâm not complete happy with this either: as it is previewed now, there will not be stable branch, and I feel this is incorrect. But againâ¦ good thing is we can iterate, weâll see if this works. we could use the master branch for that => commits to master are only merges from release branches and hotfix branches.

Nov. 22, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Esteban Lorenzano

> On 22 Nov 2018, at 13:21, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 22 Nov 2018, at 12:48, Christophe Demarey <Christophe.Demarey(a)inria.fr <mailto:Christophe.Demarey@inria.fr>> wrote: >> >> Hi, >> >> Why not following git flow? >> Keep the development branch for dev and open a 70-release branch to prepare the release. >> This way, there is no change for most people. > > Because our scripts are automated in branch and tag basis. > dev-7.0 will generate SNAPSHOT versions for files.pharo.org/70 <http://files.pharo.org/70> and tags (v7.0.0-rc1, for example) will generate a release. > > We could have another flow, but this was what we decided last week and we will try it (maybe this is wrong and we will need to change it, but wellâ¦ weâll seeâ¦ good part of having a process is that we can iterate on it :P) Btw, Iâm not complete happy with this either: as it is previewed now, there will not be stable branch, and I feel this is incorrect. But againâ¦ good thing is we can iterate, weâll see if this works. Esteban > > Esteban > >> >> Christophe >> >>> Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : >>> >>> Hi list, >>> >>> Well, subject says pretty much all. >>> We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. >>> Then, it will be a âdev-8.0â and so onâ¦ >>> >>> So, be prepared to submit your PRs to dev-7.0 instead development :) >>> >>> Cheers, >>> Esteban >> >> >

Nov. 22, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Esteban Lorenzano

> On 22 Nov 2018, at 12:48, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Hi, > > Why not following git flow? > Keep the development branch for dev and open a 70-release branch to prepare the release. > This way, there is no change for most people. Because our scripts are automated in branch and tag basis. dev-7.0 will generate SNAPSHOT versions for files.pharo.org/70 <http://files.pharo.org/70> and tags (v7.0.0-rc1, for example) will generate a release. We could have another flow, but this was what we decided last week and we will try it (maybe this is wrong and we will need to change it, but wellâ¦ weâll seeâ¦ good part of having a process is that we can iterate on it :P) Esteban > > Christophe > >> Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : >> >> Hi list, >> >> Well, subject says pretty much all. >> We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. >> Then, it will be a âdev-8.0â and so onâ¦ >> >> So, be prepared to submit your PRs to dev-7.0 instead development :) >> >> Cheers, >> Esteban > >

Nov. 22, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Christophe Demarey

Hi, Why not following git flow? Keep the development branch for dev and open a 70-release branch to prepare the release. This way, there is no change for most people. Christophe > Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > > Hi list, > > Well, subject says pretty much all. > We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. > Then, it will be a âdev-8.0â and so onâ¦ > > So, be prepared to submit your PRs to dev-7.0 instead development :) > > Cheers, > Esteban

Nov. 22, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Julien

Cool, thanks for all this work ! :-) Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 22 nov. 2018 Ã 12:00, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > > Once we open dev-8.0, yes :) > > Esteban > >> On 22 Nov 2018, at 11:51, Julien <julien.delplanque(a)inria.fr <mailto:julien.delplanque@inria.fr>> wrote: >> >> Hi, >> >> Should we submit PR concerning non-stabilisation changes (like refactoring or new features) to another branch like dev-8.0 then? >> >> Cheers, >> >> Julien >> >> --- >> Julien Delplanque >> Doctorant Ã lâUniversitÃ© de Lille >> http://juliendelplanque.be/phd.html <http://juliendelplanque.be/phd.html> >> Equipe Rmod, Inria >> BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq >> NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 >> >>> Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : >>> >>> Hi list, >>> >>> Well, subject says pretty much all. >>> We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. >>> Then, it will be a âdev-8.0â and so onâ¦ >>> >>> So, be prepared to submit your PRs to dev-7.0 instead development :) >>> >>> Cheers, >>> Esteban >> >

Nov. 22, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Esteban Lorenzano

Once we open dev-8.0, yes :) Esteban > On 22 Nov 2018, at 11:51, Julien <julien.delplanque(a)inria.fr> wrote: > > Hi, > > Should we submit PR concerning non-stabilisation changes (like refactoring or new features) to another branch like dev-8.0 then? > > Cheers, > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html <http://juliendelplanque.be/phd.html> > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > >> Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : >> >> Hi list, >> >> Well, subject says pretty much all. >> We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. >> Then, it will be a âdev-8.0â and so onâ¦ >> >> So, be prepared to submit your PRs to dev-7.0 instead development :) >> >> Cheers, >> Esteban >

Nov. 22, 2018

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Julien

Hi, Should we submit PR concerning non-stabilisation changes (like refactoring or new features) to another branch like dev-8.0 then? Cheers, Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 22 nov. 2018 Ã 11:40, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > > Hi list, > > Well, subject says pretty much all. > We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. > Then, it will be a âdev-8.0â and so onâ¦ > > So, be prepared to submit your PRs to dev-7.0 instead development :) > > Cheers, > Esteban

Nov. 22, 2018

Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

by Esteban Lorenzano

Hi list, Well, subject says pretty much all. We are planning to release Pharo 7.0 very soon now, and while preparing the release process, we came to the conclusion that we will need a branch for version to develop, and because of that we will need to rename what is not âdevelopmentâ to âdev-7.0â. Then, it will be a âdev-8.0â and so onâ¦ So, be prepared to submit your PRs to dev-7.0 instead development :) Cheers, Esteban

Nov. 22, 2018

Re: [Pharo-dev] 32 vs 64 bits and large integer hash

by Marcus Denker

> On 22 Nov 2018, at 10:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 21 Nov 2018, at 19:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi All, >> >> right now we have the following definition of Large(Positive)Integer>>hash: >> >> hash >> ^ByteArray hashBytes: self startingWith: self species hash >> >> which means that for all integers outside of the 32-bit SmallInteger range (-2 ^ 30 to 2 ^ 30 - 1), the 32-bit system and the 64-bit system answer different values for hash. >> >> e.g. in 64 bits: (2 raisedTo: 30) hash 1073741824 >> but in 32 bits: (2 raisedTo: 30) hash 230045764 >> >> This is unsatisfactory. I propose changing Large(Positive)Integer>>hash to >> >> hash >> ^self digitLength <= 8 >> ifTrue: [self] >> ifFalse: [ByteArray hashBytes: self startingWith: self species hash] >> >> > > Thanks, I added an issue tracker entry: > > https://pharo.fogbugz.com/f/cases/22690/32-vs-64-bits-and-large-integer-hash > > I will do a pull request later (if not someone else is faster to do it). https://github.com/pharo-project/pharo/pull/2009 <https://github.com/pharo-project/pharo/pull/2009> > > -- > Marcus Denker -- marcus(a)2denker.de > http://www.zweidenker.de

Nov. 22, 2018

Re: [Pharo-dev] 32 vs 64 bits and large integer hash

by Marcus Denker

> On 21 Nov 2018, at 19:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > right now we have the following definition of Large(Positive)Integer>>hash: > > hash > ^ByteArray hashBytes: self startingWith: self species hash > > which means that for all integers outside of the 32-bit SmallInteger range (-2 ^ 30 to 2 ^ 30 - 1), the 32-bit system and the 64-bit system answer different values for hash. > > e.g. in 64 bits: (2 raisedTo: 30) hash 1073741824 > but in 32 bits: (2 raisedTo: 30) hash 230045764 > > This is unsatisfactory. I propose changing Large(Positive)Integer>>hash to > > hash > ^self digitLength <= 8 > ifTrue: [self] > ifFalse: [ByteArray hashBytes: self startingWith: self species hash] > > Thanks, I added an issue tracker entry: https://pharo.fogbugz.com/f/cases/22690/32-vs-64-bits-and-large-integer-hash I will do a pull request later (if not someone else is faster to do it). Marcus -- Marcus Denker -- marcus(a)2denker.de http://www.zweidenker.de

Nov. 22, 2018

Re: [Pharo-dev] ZnCharacterReadWriteStream is missing #tab

by Sven Van Caekenberghe

Do you load from https://github.com/svenvc/zinc using the baseline ? I mostly moved to GitHub (well I try to support both). See the Travis CI build as well. > On 22 Nov 2018, at 00:17, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Sven, > > in latest P7 I get an error when loading my Bootstrap 4 project: > > https://github.com/astares/Seaside-Bootstrap4 > > about > > MessageNotUnderstood: ZnCharacterReadWriteStream>>tab > > This is sent from STONWriter>>newlineIndent. > > To reproduce please use the following load expression: > > Metacello new > baseline:'Bootstrap4'; > repository: 'github://astares/Seaside-Bootstrap4:master/src'; > load > > > If the missing method in ZnCharacterReadWriteStream is implemented like > > tab > writeStream tab > > it works. > > As I'm constantly unclear about how Zinc (and some other externally maintained packages) > are managed now I would kindly ask you to integrate it. Thanks in advance! > > Bye > T. >

Nov. 22, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Chris Muller

> That's "one should not rename classes and expect things to work", isn't > it? Not really, since that is already true anyway. If you rename a class, all references to that class will be broken.

Nov. 22, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Chris Muller

Hi Levente, > >> My questions related to this: > >> - why does Behavior >> #hash rely on the name instead of identity? > > > > If you mean #identityHash, then its because involving an unstable > > value in a #hash calculation is never a good idea. #identityHash can > > be different for the same class between two different images, or if > > the class was ever becomed or reloaded into a new image, etc. > > Is there an actual user of that feature? Several actually. If your primary motivation is improving performance then we could cache the hash value, possibly even straight in the CompiledMethod itself (hard-coded). But we _must not_ destroy stable and deterministic hashes. It would be a huge blow to existing users and even future potential possibilities of future implementations of things. Anything that would try to share #hash calculations between images... Possibly Croquet. It's easy to imagine some things! MagmaDictionary is just a Dictionary except the internal array grows on disk providing size scalability while sparing RAM. The #hash of the objects put into it are calculated by the clients -- it must be consistent between users. source.squeak.org uses a MagmaDictionary for the revision history. It was the best way to introduce the capability without invading Monticello's code at all. > Bob found out that #hash had been changed during the developement of > Squeak 3.9. Therefore this issue is not present in Cuis (forked from 3.7). > And I just checked Pharo and found that Behavior >> #hash had been removed > from there. I think that's a big mistake. There's no need for us to cross the line of a stable hash to a volatile one. We can cache it.

Nov. 22, 2018

Fwd: 32 vs 64 bits and large integer hash

by Sean P. DeNigris

>From Squeak-Dev, seems to be an issue on Pharo as well... Eliot Miranda-2 wrote > Hi All, > > right now we have the following definition of > Large(Positive)Integer>>hash: > > hash > ^ByteArray hashBytes: self startingWith: self species hash > > which means that for all integers outside of the 32-bit SmallInteger range > (-2 ^ 30 to 2 ^ 30 - 1), the 32-bit system and the 64-bit system answer > different values for hash. > > e.g. in 64 bits: (2 raisedTo: 30) hash 1073741824 > but in 32 bits: (2 raisedTo: 30) hash 230045764 > > This is unsatisfactory. I propose changing Large(Positive)Integer>>hash > to > > hash > ^self digitLength <= 8 > ifTrue: [self] > ifFalse: [ByteArray hashBytes: self startingWith: self species hash] > > > P.S. Note that this will not break Float hash, which is defined as > > Float>>hash > "Hash is reimplemented because = is implemented. Both words of the float > are used. (The bitShift:'s ensure that the intermediate results do not > become a large integer.) Care is taken to answer same hash as an equal > Integer." > > (self isFinite and: [self fractionPart = 0.0]) ifTrue: [^self truncated > hash]. > ^ ((self basicAt: 1) bitShift: -4) + > ((self basicAt: 2) bitShift: -4) > > P.P.S. I *think* that "(self isFinite and: [self fractionPart = 0.0])" is > equivalent to "self - self = self fractionPart" ;-) > > _,,,^..^,,,_ > best, Eliot ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 22, 2018

ZnCharacterReadWriteStream is missing #tab

by Torsten Bergmann

Hi Sven, in latest P7 I get an error when loading my Bootstrap 4 project: https://github.com/astares/Seaside-Bootstrap4 about MessageNotUnderstood: ZnCharacterReadWriteStream>>tab This is sent from STONWriter>>newlineIndent. To reproduce please use the following load expression: Metacello new baseline:'Bootstrap4'; repository: 'github://astares/Seaside-Bootstrap4:master/src'; load If the missing method in ZnCharacterReadWriteStream is implemented like tab writeStream tab it works. As I'm constantly unclear about how Zinc (and some other externally maintained packages) are managed now I would kindly ask you to integrate it. Thanks in advance! Bye T.

Nov. 21, 2018

32 vs 64 bits and large integer hash

by Eliot Miranda

Hi All, right now we have the following definition of Large(Positive)Integer>>hash: hash ^ByteArray hashBytes: self startingWith: self species hash which means that for all integers outside of the 32-bit SmallInteger range (-2 ^ 30 to 2 ^ 30 - 1), the 32-bit system and the 64-bit system answer different values for hash. e.g. in 64 bits: (2 raisedTo: 30) hash 1073741824 but in 32 bits: (2 raisedTo: 30) hash 230045764 This is unsatisfactory. I propose changing Large(Positive)Integer>>hash to hash ^self digitLength <= 8 ifTrue: [self] ifFalse: [ByteArray hashBytes: self startingWith: self species hash] P.S. Note that this will not break Float hash, which is defined as Float>>hash "Hash is reimplemented because = is implemented. Both words of the float are used. (The bitShift:'s ensure that the intermediate results do not become a large integer.) Care is taken to answer same hash as an equal Integer." (self isFinite and: [self fractionPart = 0.0]) ifTrue: [^self truncated hash]. ^ ((self basicAt: 1) bitShift: -4) + ((self basicAt: 2) bitShift: -4) P.P.S. I *think* that "(self isFinite and: [self fractionPart = 0.0])" is equivalent to "self - self = self fractionPart" ;-) _,,,^..^,,,_ best, Eliot

Nov. 21, 2018

[Pharo 7.0-dev] Build #1411: 22689-support-reification-value-and-operation-on-LiteralArray

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1411 was: SUCCESS. The Pull Request #2007 was integrated: "22689-support-reification-value-and-operation-on-LiteralArray" Pull request url: https://github.com/pharo-project/pharo/pull/2007 Issue Url: https://pharo.fogbugz.com/f/cases/22689 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 21, 2018

[Pharo 7.0-dev] Build #1410: 22678-Update-calypso-to-v0130

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1410 was: SUCCESS. The Pull Request #1998 was integrated: "22678-Update-calypso-to-v0130" Pull request url: https://github.com/pharo-project/pharo/pull/1998 Issue Url: https://pharo.fogbugz.com/f/cases/22678 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 21, 2018

Re: [Pharo-dev] [Pharo-users] glamorous toolkit alpha.3

by Tim Mackinnon

Itâs very exciting watching the progress both in these email updates and the excellent more visual tweets. This and the progress on Pharo 7 will make for a great Xmas! Tim Sent from my iPhone > On 20 Nov 2018, at 23:08, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Another month has swooshed and now itâs time for Glamorous Toolkit alpha.3: > https://feenk.com/gt > > The key things that changed are as follows: > > - We rewrote Documenter. This was challenge, but the results are more than worth it. > One visible thing is that now the previews get cached, and as a consequence we can actually work inside the document. > But, perhaps the more impactful thing is that we can now toggle the visibility of Pillar markup. We think it significantly improves the experience and consequently, the value of the live documents. > > <gt-documenter-toggle-markup-small.gif> > > > - We advanced the work on the method Coder. To explore the boundaries, we reimagined the extract method refactoring. Thatâs : > https://twitter.com/feenkcom/status/1064823381407748096 > > - We enhanced the navigation in Playground / Inspector: > https://twitter.com/feenkcom/status/1064823381407748096 > > > A more complete list of issues we addressed is found here: > https://github.com/feenkcom/gtoolkit/milestone/1?closed=1 > > > > Have fun, > The feenk team > > -- > www.feenk.com > > âHow do you feenk today?" >

Nov. 21, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Chris Muller

> To make things more clear, the current implementation of Behavior >> #hash > has two negative side effects: > - behaviors stored in collections relying on the hash value (e.g. Set, > Dictionary) will have to be rehashed whenever a behavior is renamed > - objects using Behavior >> #hash to implement their own #hash, like what > Eliot just did to Message will suffer from the same issue. So Sets and > Dictionaries holding those kind of objects will have to be rehashed as > well upon the rename of the behavior. > > My questions related to this: > - why does Behavior >> #hash rely on the name instead of identity? If you mean #identityHash, then its because involving an unstable value in a #hash calculation is never a good idea. #identityHash can be different for the same class between two different images, or if the class was ever becomed or reloaded into a new image, etc. > - do we want to fix those issues mentioned above or do we just say that > one should not rename classes and expect things to work? Neither. We just say that when one renames a class to rehash all relevant HashedCollections. - Chris

Nov. 21, 2018

Re: [Pharo-dev] glamorous toolkit alpha.3

by Sean P. DeNigris

Tudor Girba-2 wrote > we can now toggle the visibility of Pillar markup Bravo!!! :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 21, 2018

Re: [Pharo-dev] [Cuis-dev] Message>>#= & Message>>#hash

by Eliot Miranda

Hi Juan, On Tue, Nov 20, 2018 at 8:00 AM Juan Vuletich <juan(a)jvuletich.org> wrote: > Hi Eliot, > > (below) > On 19/11/2018 02:32 p.m., Eliot Miranda via Cuis-dev wrote: > > Hi All, > > In VisualWorks Message implements #= & #hash naturally; two messages > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > comparison. This is, to say the least, annoying. Any objections to > implementing comparing in Message to match VisualWorks? > > _,,,^..^,,,_ > best, Eliot > > > Just added these implementations to Cuis: > > = aMessage > "Any object is equal to itself" > self == aMessage ifTrue: [ ^ true ]. > self class == aMessage class ifFalse: [ ^false ]. > selector = aMessage selector ifFalse: [ ^false ]. > lookupClass = aMessage lookupClass ifFalse: [ ^false ]. > ^args = aMessage arguments > this last line should be ^args literalEqual: aMessage arguments and this is very important :-) > > hash > "Hash is reimplemented because = is implemented." > ^selector hash bitXor: args hash > > Do they look ok? (I considered lookupClass for #=, but not for hash, as > collisions because of that seem unlikely, and in any case, grouping them > that way could be useful). > > Cheers, > > -- > Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smallt… > @JuanVuletich > > -- _,,,^..^,,,_ best, Eliot

Nov. 20, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Chris Muller

Wait, Message is the one used internally by the system. It doesn't have #= and #hash because it didn't need it. *MessageSend* is the one for external use, and it already defines #= and #hash. On Mon, Nov 19, 2018 at 11:32 AM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > In VisualWorks Message implements #= & #hash naturally; two messages whose selectors and arguments are #= are also equal. But in Cuis, Squeak and Pharo Message inherits #= and #hash from Object, i.e. uses identity comparison. This is, to say the least, annoying. Any objections to implementing comparing in Message to match VisualWorks? > > _,,,^..^,,,_ > best, Eliot >

Nov. 20, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Chris Muller

It sounds good, but an Inbox submission would go a long way to understanding exactly what you mean esp. re: understanding this special condition with the lookupClass being nil... and whether it deserves a first-class name or not... On Tue, Nov 20, 2018 at 4:10 AM Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > > On Mon, 19 Nov 2018, Eliot Miranda wrote: > > > Hi David, > > > > On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote: > > > Hi All, > > > > > > In VisualWorks Message implements #= & #hash naturally; two messages > > > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > > > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > > > comparison. This is, to say the least, annoying. Any objections to > > > implementing comparing in Message to match VisualWorks? > > > > > > > That sounds like an obviously good thing to do :-) > > > > Is the lookupClass instance variable relevant for comparisons? I am > > guessing not, since we already have #analogousCodeTo: for that type of > > comparison. > > > > > > For me it is relevant. Two messages with different lookupClasses, e.g. one with nil and one with a specific class, represent different messages, one a normal send one a super send. So my changes in > > waiting include lookupClass in both hash and =. I don't think it makes much difference, but the incompatibility with VisualWorks, while regrettable, feels correct to me. > > What about Behavior >> #hash? It uses the name of the class, which is fine > as long as you don't rename your classes while you store them in hashed > collections. > > Levente > > > > > Dave > > > > > > _,,,^..^,,,_ > > best, Eliot > > > >

Nov. 20, 2018

[Pharo 7.0-dev] Build #1409: 22685-add-value-reification-support-for-Literal-node

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1409 was: FAILURE. The Pull Request #2005 was integrated: "22685-add-value-reification-support-for-Literal-node" Pull request url: https://github.com/pharo-project/pharo/pull/2005 Issue Url: https://pharo.fogbugz.com/f/cases/22685 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 20, 2018

glamorous toolkit alpha.3

by Tudor Girba

Hi, Another month has swooshed and now itâs time for Glamorous Toolkit alpha.3: https://feenk.com/gt The key things that changed are as follows: - We rewrote Documenter. This was challenge, but the results are more than worth it. One visible thing is that now the previews get cached, and as a consequence we can actually work inside the document. But, perhaps the more impactful thing is that we can now toggle the visibility of Pillar markup. We think it significantly improves the experience and consequently, the value of the live documents. - We advanced the work on the method Coder. To explore the boundaries, we reimagined the extract method refactoring. Thatâs : https://twitter.com/feenkcom/status/1064823381407748096 - We enhanced the navigation in Playground / Inspector: https://twitter.com/feenkcom/status/1064823381407748096 A more complete list of issues we addressed is found here: https://github.com/feenkcom/gtoolkit/milestone/1?closed=1 Have fun, The feenk team -- www.feenk.com âHow do you feenk today?"

Nov. 20, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1408: Add AST dump from an existing AST

by Marcus Denker

> On 20 Nov 2018, at 11:20, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #1408 was: SUCCESS. > > The Pull Request #2001 was integrated: "Add AST dump from an existing AST" > Pull request url: https://github.com/pharo-project/pharo/pull/2001 > This is a very useful addition done by Vincent Aranega. It adds to the AST the feature to print out an expression that re-creates the AST. It adds a pane to the inspector (here it is the AST of OrderedCollection>>#do:

Nov. 20, 2018

[Pharo 7.0-dev] Build #1408: Add AST dump from an existing AST

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1408 was: SUCCESS. The Pull Request #2001 was integrated: "Add AST dump from an existing AST" Pull request url: https://github.com/pharo-project/pharo/pull/2001 Issue Url: https://pharo.fogbugz.com/f/cases/feature/parseDump Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 20, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Marcus Denker

> On 20 Nov 2018, at 01:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi David, > > On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis(a)mail.msen.com <mailto:lewis@mail.msen.com>> wrote: > On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote: > > Hi All, > > > > In VisualWorks Message implements #= & #hash naturally; two messages > > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > > comparison. This is, to say the least, annoying. Any objections to > > implementing comparing in Message to match VisualWorks? > > > > That sounds like an obviously good thing to do :-) > > Is the lookupClass instance variable relevant for comparisons? I am > guessing not, since we already have #analogousCodeTo: for that type of > comparison. > > For me it is relevant. Two messages with different lookupClasses, e.g. one with nil and one with a specific class, represent different messages, one a normal send one a super send. So my changes in waiting include lookupClass in both hash and =. I don't think it makes much difference, but the incompatibility with VisualWorks, while regrettable, feels correct to me. > To me this looks like a good change, yes. Marcus

Nov. 20, 2018

Re: [Pharo-dev] [Cuis-dev] [squeak-dev] Message>>#= & Message>>#hash

by David T. Lewis

On Mon, Nov 19, 2018 at 04:16:51PM -0800, Eliot Miranda via Cuis-dev wrote: > Hi David, > > On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis(a)mail.msen.com> wrote: > > > On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote: > > > Hi All, > > > > > > In VisualWorks Message implements #= & #hash naturally; two messages > > > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > > > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > > > comparison. This is, to say the least, annoying. Any objections to > > > implementing comparing in Message to match VisualWorks? > > > > > > > That sounds like an obviously good thing to do :-) > > > > Is the lookupClass instance variable relevant for comparisons? I am > > guessing not, since we already have #analogousCodeTo: for that type of > > comparison. > > > > For me it is relevant. Two messages with different lookupClasses, e.g. one > with nil and one with a specific class, represent different messages, one a > normal send one a super send. So my changes in waiting include lookupClass > in both hash and =. I don't think it makes much difference, but the > incompatibility with VisualWorks, while regrettable, feels correct to me. That feels correct to me also. But implementation details and bikeshedding aside, I would be happy if "Message allInstances asSet asArray" could answer a reasonably small collection of different-looking things. So +1 to the change, with or without consideration of lookupClass. Dave

Nov. 20, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Eliot Miranda

Hi David, On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis(a)mail.msen.com> wrote: > On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote: > > Hi All, > > > > In VisualWorks Message implements #= & #hash naturally; two messages > > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > > comparison. This is, to say the least, annoying. Any objections to > > implementing comparing in Message to match VisualWorks? > > > > That sounds like an obviously good thing to do :-) > > Is the lookupClass instance variable relevant for comparisons? I am > guessing not, since we already have #analogousCodeTo: for that type of > comparison. > For me it is relevant. Two messages with different lookupClasses, e.g. one with nil and one with a specific class, represent different messages, one a normal send one a super send. So my changes in waiting include lookupClass in both hash and =. I don't think it makes much difference, but the incompatibility with VisualWorks, while regrettable, feels correct to me. Dave > _,,,^..^,,,_ best, Eliot

Nov. 20, 2018

Re: [Pharo-dev] Contributor license agreement via modern transport?

by Gabriel Cotelli

On 2008 I printed the document, signed it, scanned it with the signature and then sent a signed digital copy. I think the same procedure still applies. On Mon, Nov 19, 2018 at 5:15 PM Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: > Hi, do you know whether StÃ©phane will accept contributor license agreements > as scanned and e-mailed documents (can be digitally signed using PGP as > well)? > Or does one really have to print out and mail a piece of dead tree? :-) > > Cheers, > Hans-Martin > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Nov. 19, 2018

Contributor license agreement via modern transport?

by Hans-Martin

Hi, do you know whether StÃ©phane will accept contributor license agreements as scanned and e-mailed documents (can be digitally signed using PGP as well)? Or does one really have to print out and mail a piece of dead tree? :-) Cheers, Hans-Martin -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 19, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by David T. Lewis

On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote: > Hi All, > > In VisualWorks Message implements #= & #hash naturally; two messages > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > comparison. This is, to say the least, annoying. Any objections to > implementing comparing in Message to match VisualWorks? > That sounds like an obviously good thing to do :-) Is the lookkupClass instance variable relevant for comparisons? I am guessing not, since we already have #analogousCodeTo: for that type of comparison. Dave

Nov. 19, 2018

Message>>#= & Message>>#hash

by Eliot Miranda

Hi All, In VisualWorks Message implements #= & #hash naturally; two messages whose selectors and arguments are #= are also equal. But in Cuis, Squeak and Pharo Message inherits #= and #hash from Object, i.e. uses identity comparison. This is, to say the least, annoying. Any objections to implementing comparing in Message to match VisualWorks? _,,,^..^,,,_ best, Eliot

Nov. 19, 2018

Re: [Pharo-dev] Pharo 7 speed compared to VW

by Eliot Miranda

Hi Shaping, On Mon, Nov 19, 2018 at 5:04 AM Shaping <shaping(a)uurda.org> wrote: > (Second try in 6 days. Does anyone have recent performance data for Pharo > 7 relative to VW 7.10 or later?) > I don't have access to recent vnc versions beyond 7.7. If you have access perhaps you could run the computer language shootout benchmarks ( https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/smalltal…) and report the results. > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Shaping > *Sent:* Tuesday, November 13, 2018 00:33 > *To:* 'Pharo Development List' <pharo-dev(a)lists.pharo.org> > *Subject:* [Pharo-dev] Pharo 7 speed compared to VW (was: The STON > Specification, Cog speed, and namespaces/modules) > > > > Does anyone know whether Pharo 7 is as fast as VW 7.10 or later? > > > > Do we have recent comparative benchmarks? > > > > The comparison should ignore potential GPU-based improvement in my algo; > that will happen later. The test should involve some math, file streaming, > and the parsing that entailsâan ordinary mix of macrobenchmarks. The > comparison should be based on both Pharo 7 and VW each running a single > Smalltalk Process (one time-slice of one OS thread in one OS process). I > need Pharo 7 speed to be comparable or better to justify the port. > > > > Pharo is definitely looking and working better. Iâve spend more time with > it last few weeks than during the previous decade. Thanks to everyone for > the effort and improvements. > > > > > > Shaping > > > > *From:* Shaping [mailto:shaping@uurda.org <shaping(a)uurda.org>] > *Sent:* Wednesday, November 7, 2018 00:41 > *To:* 'Pharo Development List' <pharo-dev(a)lists.pharo.org> > *Subject:* RE: [Pharo-dev] [ANN] The STON Specification, Cog speed, and > namespaces/modules > > > > Hi Eliot. > > > > Pharo (& Squeak & Cuis) Float subclass BoxedFloat64 maps exactly to > VW's Double. In 64-bit SmallFloat64 maps exactly to SmallDouble. But I > wonder whether there is any issue here. STON would use the print strings > for (PSC) Float / (VW) Double, and so deseerialization on Pharo would > automatically produce the right class. Going in the other direction might > need some help. APF needs support in PSC before one can port, but are > representable as suitably-sized word arrays. > > > > There is no support for __float128 anywhere in the VM (e.g. not even in > the FFI) on PSC as yet. > > > > I see Pharoâs WordArray. Iâll work on an APF for Pharo, as time permits. > Iâm using APFs in VW in the 300-bit range, and want to reduce the needed > precision to 64 bits, to save space and time on large (5 million+) scalar > time-series, both on the heap and during BOSSing (25 m save-time now). > The problem is not so much an issue for the JulianDayNumber > (JDN)-precision, which is adequate in this app at 14 to 15 digits (even > though my JDN class subclasses APF, for now). Other calculations need the > more extreme precision. I think I can make 128-bit floats work, and would > really like to see a small, fast, boxed 128-bit float implementation in > Pharo or VW. The APFs are big and slow. Where in the queue of planned > improvements to Pharo does such a task lie? I suspect itâs not a very > popular item. > > > > Broadening the issue somewhat, Iâm trying to find as many good reasons as > possible to justify the work needed to port all my VW stuff to Pharo. > > > > Iâve seen the references to Cogâs speed and coming speed-up. Are there > recent (say, in the last year) benchmarks comparing VW and Pharo? Any > details here would be very much appreciated. > > > > Having no namespaces in Pharo is, I think, the biggest impediment. I > prefer not to prefix class names, but there may be fewer name-collisions > than I suppose--maybe none. Still, I need to know how VW and Pharo > classes map in order to place overrides and extensions correctly. Besides > the mentioned float-class mappings is there a reference on this? > > > > Object allSubclasses > > > > in Pharo 7 64-bit, produces 14946 classes. Pharo is a little bigger than > it used to be. > > > > I suppose I donât need to check all unloaded packages because all classes > in each of those will have the same unique prefix. Is that correct? Or, I > could just load every package I can find, before I check names. But that > little experiment has never gone well in the past. > > > > Is the Pharo-with-namespaces issue dead or merely suspended, awaiting a > more fitting idea than what VW currently offers? > > > > > > Shaping > > > > > > On Tue, Nov 6, 2018 at 12:56 AM Shaping <shaping(a)uurda.org> wrote: > > STON is able to serialise Pharoâs Floats, what do you mean by double ? > > > > Floating-point numbers in IEEE 64-bit format, 14 or 15 significant digits, > with a range between =10^307 and 10^307. > > > > Additionally, I recently asked Sven if t would be possible to store > ScaledDecimals (I think it implements what you call > ArbitraryPrecisionFloats) without loss of precision. > > > > Iâm referring to VWâs Double (and SmallDouble in 64-bit engines/images). > APFs are binary representations that can be arbitrarily large, using > Integers (LargePositiveIntegers for example) to model the bits of the > mantissa. > > > > Before, because STON extends JSON, it was storing all kind of numbers > either as float or integer. > > > > Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of > precision through serialisation as float, what was done before). > > > > But I do not know if this change is integrated in recent images yet. > > > > â¦.. > > > > Number subclass: #Float > > instanceVariableNames: '' > > classVariableNames: 'E Epsilon Halfpi Infinity Ln10 Ln2 > MaxVal MaxValLn MinValLogBase2 NaN NegativeInfinity NegativeZero Pi > RadiansPerDegree Sqrt2 ThreePi Twopi' > > poolDictionaries: '' > > category: 'Kernel-Numbers' > > > > > > My instances represent IEEE-754 floating-point double-precision numbers. > They have about 16 digits of accuracy and their range is between plus and > minus 10^307. Some valid examples are: > > > > 8.0 13.3 0.3 2.5e6 1.27e-30 1.27e-31 -12.987654e12 > > â¦. > > > > I see that Pharoâs Float is VWâs Double. So then I just need to be able > to serialize APF. > > > > â¦. > > FIFloatType subclass: #FFIFloat128 > > instanceVariableNames: '' > > classVariableNames: '' > > poolDictionaries: '' > > category: 'UnifiedFFI-Types' > > > > > > I'm a 128bits (cuadruple precision) float. > > It is usually not used, but some compiler modes support it (__float128 in > gcc) > > > > THIS IS NOT YET SUPPORTED > > â¦. > > > > The class above is also from the Pharo 7 image. This is the largest of > the c-type FFIFloats. Any Float classes of this size and larger for the > Smalltalk heap on 64-bit Pharo? > > > > > > Cheers, > > > > Shaping > > > > > > Le 6 nov. 2018 Ã 06:58, Shaping <shaping(a)uurda.org> a Ã©crit : > > > > (Having domain problems recently. Please excuse this posting if you have > seen it twice. I've not seen it appear yet on the list.) > > > Can STON be extended to handle Doubles and ArbitraryPrecisionFloats? > > Shaping > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] On Behalf Of > David T. Lewis > Sent: Wednesday, October 31, 2018 14:58 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] [ANN] The STON Specification > > This is very clear and well written. > > Dave > > Hi, > > Since there can never be enough documentation I finally took some time > to write a more formal description of STON as a data format. > > https://github.com/svenvc/ston/blob/master/ston-spec.md > > The idea is to let this stabilise a bit and to then update the two > other documents describing STON, where necessary: > > https://github.com/svenvc/ston/blob/master/ston-paper.md > > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc > cessfulBuild/artifact/book-result/STON/STON.html > > Also, the latest changes in STON have to make their way to the Pharo > image as well. > > https://github.com/svenvc/ston > > All feedback is welcome. > > Sven > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > -- _,,,^..^,,,_ best, Eliot

Nov. 19, 2018

[Pharo 7.0-dev] Build #1407: 22684-testNoUnusedTemporaryVariablesLeft-uses-all-CompiledMethod-instances

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1407 was: FAILURE. The Pull Request #2003 was integrated: "22684-testNoUnusedTemporaryVariablesLeft-uses-all-CompiledMethod-instances" Pull request url: https://github.com/pharo-project/pharo/pull/2003 Issue Url: https://pharo.fogbugz.com/f/cases/22684 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 19, 2018

[Pharo 7.0-dev] Build #1406: 22682-when-callback-fails-a-default-value-should-be-returned-to-prevent-crashes

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1406 was: SUCCESS. The Pull Request #2002 was integrated: "22682-when-callback-fails-a-default-value-should-be-returned-to-prevent-crashes" Pull request url: https://github.com/pharo-project/pharo/pull/2002 Issue Url: https://pharo.fogbugz.com/f/cases/22682 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 19, 2018

Pharo 7 speed compared to VW

by Shaping

(Second try in 6 days. Does anyone have recent performance data for Pharo 7 relative to VW 7.10 or later?) From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Shaping Sent: Tuesday, November 13, 2018 00:33 To: 'Pharo Development List' <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] Pharo 7 speed compared to VW (was: The STON Specification, Cog speed, and namespaces/modules) Does anyone know whether Pharo 7 is as fast as VW 7.10 or later? Do we have recent comparative benchmarks? The comparison should ignore potential GPU-based improvement in my algo; that will happen later. The test should involve some math, file streaming, and the parsing that entailsâan ordinary mix of macrobenchmarks. The comparison should be based on both Pharo 7 and VW each running a single Smalltalk Process (one time-slice of one OS thread in one OS process). I need Pharo 7 speed to be comparable or better to justify the port. Pharo is definitely looking and working better. Iâve spend more time with it last few weeks than during the previous decade. Thanks to everyone for the effort and improvements. Shaping From: Shaping [mailto:shaping@uurda.org] Sent: Wednesday, November 7, 2018 00:41 To: 'Pharo Development List' <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: RE: [Pharo-dev] [ANN] The STON Specification, Cog speed, and namespaces/modules Hi Eliot. Pharo (& Squeak & Cuis) Float subclass BoxedFloat64 maps exactly to VW's Double. In 64-bit SmallFloat64 maps exactly to SmallDouble. But I wonder whether there is any issue here. STON would use the print strings for (PSC) Float / (VW) Double, and so deseerialization on Pharo would automatically produce the right class. Going in the other direction might need some help. APF needs support in PSC before one can port, but are representable as suitably-sized word arrays. There is no support for __float128 anywhere in the VM (e.g. not even in the FFI) on PSC as yet. I see Pharoâs WordArray. Iâll work on an APF for Pharo, as time permits. Iâm using APFs in VW in the 300-bit range, and want to reduce the needed precision to 64 bits, to save space and time on large (5 million+) scalar time-series, both on the heap and during BOSSing (25 m save-time now). The problem is not so much an issue for the JulianDayNumber (JDN)-precision, which is adequate in this app at 14 to 15 digits (even though my JDN class subclasses APF, for now). Other calculations need the more extreme precision. I think I can make 128-bit floats work, and would really like to see a small, fast, boxed 128-bit float implementation in Pharo or VW. The APFs are big and slow. Where in the queue of planned improvements to Pharo does such a task lie? I suspect itâs not a very popular item. Broadening the issue somewhat, Iâm trying to find as many good reasons as possible to justify the work needed to port all my VW stuff to Pharo. Iâve seen the references to Cogâs speed and coming speed-up. Are there recent (say, in the last year) benchmarks comparing VW and Pharo? Any details here would be very much appreciated. Having no namespaces in Pharo is, I think, the biggest impediment. I prefer not to prefix class names, but there may be fewer name-collisions than I suppose--maybe none. Still, I need to know how VW and Pharo classes map in order to place overrides and extensions correctly. Besides the mentioned float-class mappings is there a reference on this? Object allSubclasses in Pharo 7 64-bit, produces 14946 classes. Pharo is a little bigger than it used to be. I suppose I donât need to check all unloaded packages because all classes in each of those will have the same unique prefix. Is that correct? Or, I could just load every package I can find, before I check names. But that little experiment has never gone well in the past. Is the Pharo-with-namespaces issue dead or merely suspended, awaiting a more fitting idea than what VW currently offers? Shaping On Tue, Nov 6, 2018 at 12:56 AM Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: STON is able to serialise Pharoâs Floats, what do you mean by double ? Floating-point numbers in IEEE 64-bit format, 14 or 15 significant digits, with a range between =10^307 and 10^307. Additionally, I recently asked Sven if t would be possible to store ScaledDecimals (I think it implements what you call ArbitraryPrecisionFloats) without loss of precision. Iâm referring to VWâs Double (and SmallDouble in 64-bit engines/images). APFs are binary representations that can be arbitrarily large, using Integers (LargePositiveIntegers for example) to model the bits of the mantissa. Before, because STON extends JSON, it was storing all kind of numbers either as float or integer. Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of precision through serialisation as float, what was done before). But I do not know if this change is integrated in recent images yet. â¦.. Number subclass: #Float instanceVariableNames: '' classVariableNames: 'E Epsilon Halfpi Infinity Ln10 Ln2 MaxVal MaxValLn MinValLogBase2 NaN NegativeInfinity NegativeZero Pi RadiansPerDegree Sqrt2 ThreePi Twopi' poolDictionaries: '' category: 'Kernel-Numbers' My instances represent IEEE-754 floating-point double-precision numbers. They have about 16 digits of accuracy and their range is between plus and minus 10^307. Some valid examples are: 8.0 13.3 0.3 2.5e6 1.27e-30 1.27e-31 -12.987654e12 â¦. I see that Pharoâs Float is VWâs Double. So then I just need to be able to serialize APF. â¦. FIFloatType subclass: #FFIFloat128 instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'UnifiedFFI-Types' I'm a 128bits (cuadruple precision) float. It is usually not used, but some compiler modes support it (__float128 in gcc) THIS IS NOT YET SUPPORTED â¦. The class above is also from the Pharo 7 image. This is the largest of the c-type FFIFloats. Any Float classes of this size and larger for the Smalltalk heap on 64-bit Pharo? Cheers, Shaping Le 6 nov. 2018 Ã 06:58, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > a Ã©crit : (Having domain problems recently. Please excuse this posting if you have seen it twice. I've not seen it appear yet on the list.) Can STON be extended to handle Doubles and ArbitraryPrecisionFloats? Shaping -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of David T. Lewis Sent: Wednesday, October 31, 2018 14:58 To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] [ANN] The STON Specification This is very clear and well written. Dave Hi, Since there can never be enough documentation I finally took some time to write a more formal description of STON as a data format. https://github.com/svenvc/ston/blob/master/ston-spec.md The idea is to let this stabilise a bit and to then update the two other documents describing STON, where necessary: https://github.com/svenvc/ston/blob/master/ston-paper.md https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc cessfulBuild/artifact/book-result/STON/STON.html Also, the latest changes in STON have to make their way to the Pharo image as well. https://github.com/svenvc/ston All feedback is welcome. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org -- _,,,^..^,,,_ best, Eliot

Nov. 19, 2018

[Pharo 7.0-dev] Build #1405: 22643-Image-not-opening---portability-

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1405 was: SUCCESS. The Pull Request #1996 was integrated: "22643-Image-not-opening---portability-" Pull request url: https://github.com/pharo-project/pharo/pull/1996 Issue Url: https://pharo.fogbugz.com/f/cases/22643 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 19, 2018

Esteban's ChangeLog week of 12 November 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 12 November 2018 to 18 November 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=12/11/2018&to=18/11/2018 ChangeLog ========= 16 November 2018: ----------------- * I made a [pull request](https://github.com/pharo-project/pharo/pull/1998) to update Calypso to [version 0.13.0](https://github.com/pharo-ide/Calypso/releases/tag/v0.13.0) 14 November 2018: ----------------- * I needed to revisit [case: 22659](https://pharo.fogbugz.com/f/cases/22659) (and it took last two days to fix it properly :P) But well, now we should be having correct file names for all versions. 13 November 2018: ----------------- * I fixed [case: 22659](https://pharo.fogbugz.com/f/cases/22659), with this [pull request](https://github.com/pharo-project/pharo/pull/1975). Problem was that tagging system was correctly naming version inside the image, but it was not doing anything with file names (then the filenames were hardcoded to Pharo7.0-alpha). cheers! Esteban

Nov. 19, 2018

Re: [Pharo-dev] [ANN] Camp Smalltalk 2019 in Charlotte, NC

by Mariano Martinez Peck

Itâs in the same state as the organizers (us) and we already did one in Raleigh Durham. This is also a location with an international airport. Hope you can attend.. On Sun, Nov 18, 2018, 17:29 Sean P. DeNigris <sean(a)clipperadams.com wrote: > Mariano Martinez Peck wrote > > Camp Smalltalk, March 29th... in Charlotte, North Carolina > > Cool! Out of curiosity, why Charlotte? (Not that it's not a great city!) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Nov. 18, 2018

Re: [Pharo-dev] [ANN] Camp Smalltalk 2019 in Charlotte, NC

by Sean P. DeNigris

Mariano Martinez Peck wrote > Camp Smalltalk, March 29th... in Charlotte, North Carolina Cool! Out of curiosity, why Charlotte? (Not that it's not a great city!) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 18, 2018

Re: [Pharo-dev] Windows lack of ssh-agent versus Default Custom SSH Keys

by Esteban Lorenzano

Hi, > On 18 Nov 2018, at 16:30, Ben Coman <btc(a)openinworld.com> wrote: > > For Iceberg. what is the likely hood that soon something like ssh-agent will be working on Windows? So that "Custom SSH Keys" doesn't need to be set every time a new image is started? Well, for âsomething like ssh-agentâ, we believe in fact we will need to implement the proper ssh provider for each platform. Means ssh-agent for linux. âSecurity Frameworkâ for Mac. And I donât know the name for Windows :S In theory, libgit2 allows to be compiled against this different ssh frameworks, but it will require some time and effort to get there (and to be honest, right no one who worked with iceberg has the time to do it). Butâ¦ since we are trying to improve support for windows platforms, it has to be there at some point. Esteban > > If "Custom SSH Keys" will be the main option for the foreseeable future, > would it make sense to enabled it by default to make one less thing to trip up newcomers? > > cheers -ben

Nov. 18, 2018

Windows lack of ssh-agent versus Default Custom SSH Keys

by Ben Coman

For Iceberg. what is the likely hood that soon something like ssh-agent will be working on Windows? So that "Custom SSH Keys" doesn't need to be set every time a new image is started? If "Custom SSH Keys" will be the main option for the foreseeable future, would it make sense to enabled it by default to make one less thing to trip up newcomers? cheers -ben

Nov. 18, 2018

[Pharo 7.0-dev] Build #1404: 22680-add-support-for-operation-types-assignment-return-Some-cleanups

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1404 was: SUCCESS. The Pull Request #2000 was integrated: "22680-add-support-for-operation-types-assignment-return-Some-cleanups" Pull request url: https://github.com/pharo-project/pharo/pull/2000 Issue Url: https://pharo.fogbugz.com/f/cases/22680 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 18, 2018

[Pharo 7.0-dev] Build #1403: Add pattern to #expandMacros supporting line feeds

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1403 was: SUCCESS. The Pull Request #1997 was integrated: "Add pattern to #expandMacros supporting line feeds" Pull request url: https://github.com/pharo-project/pharo/pull/1997 Issue Url: https://pharo.fogbugz.com/f/cases/22674 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 16, 2018

[Pharo 7.0-dev] Build #1402: 22673-OCNewCompilerWithChangesFunctionalTeststestBlockReturning-is-failing

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1402 was: FAILURE. The Pull Request #1995 was integrated: "22673-OCNewCompilerWithChangesFunctionalTeststestBlockReturning-is-failing" Pull request url: https://github.com/pharo-project/pharo/pull/1995 Issue Url: https://pharo.fogbugz.com/f/cases/22673 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 15, 2018