- Pharo-dev - lists.pharo.org

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

by Eliot Miranda

On Sat, Nov 24, 2018 at 7:40 AM Luciano Notarfrancesco <luchiano(a)gmail.com> wrote: > On Fri, Nov 23, 2018 at 12:36 AM Chris Muller <asqueaker(a)gmail.com> wrote: > >> > >> I'm a bit puzzled. I thought (small)Integers being their own hash >> is a good thing? >> >> I was wondering exactly the same thing! >> >> > > I would call it simple but not necessarily good. >> > > The problem with it is that consecutive numbers generate long chains >> in HashedCollections: >> > > >> > > a := (1 to: 1000) asArray. >> > > s := Set withAll: a. >> > > [ 1 to: 1000000 do: [ :each | s includes: each ] ] timeToRun. >> > > "==> 7014" >> > > >> > > The solution in Squeak is to use PluggableSet instead of Set, because >> it applies #hashMultiply on the hash value: >> > > >> > > ps := PluggableSet integerSet. >> > > ps addAll: a. >> > > [ 1 to: 1000000 do: [ :each | ps includes: each ] ] timeToRun. >> > > "==> 95" >> > > >> > > IIRC in Pharo SmallInteger's hash is based on #hashMultiply to avoid >> the long chains. That was probably the main reason for the push to make >> #hashMultply a numbered primitive. >> > > >> > >> > Interesting! >> >> Indeed! When making a #hash methods, one always focuses on hash >> distribution and finding the elements, but its easy to forget about >> performance of NOT finding an element. >> >> > Yes! I had this problem blow in my face a couple of years ago, and Juan > agreed to include the change in Cuis to make SmallIntegers NOT their own > hash. > This seems to be a basic error. The idea of a hash function is to produce a well-distributed set of integers for some set of values. Since the SmallIntegers are themselves perfectly distributed (each unique SmallInteger is a unique value), it is impossible to produce a better distributed hash function than the integers themselves. For some application it may indeed be possible to produce a better distributed set of hashes for the integers; for example an application which considers only powers of two could use the log base 2 to produce a smaller and better distributed set fo values modulo N than the integers themselves. But in general the integers are definitionally well-distributed. In fact, unless one has a perfect hash function one is in danger of producing a less well-distributed set of values from a hash function than the SmallIntegers themselves. This argument doesn't apply as integers grow beyond the SmallInteger, but not because we want better distribution of values than the large integers themselves, but b because we want to avoid large integer arithmetic. > I think it is a good idea in general when programming a hash method in > Smalltalk to make it somewhat random. > As I've indicated, I think this is impossible in general. It is only in specific applications, using specific subsets of the SmallIn tigers for which a better hash function could be derived, but this would be specific to that application. For purposes such as these we have PluggableDictionary et al which can exploit an application-specific hash. But in general the SmallIntegers are ideal values for their own hashes. > It will never be perfect for every use case, and it doesn't need to be > cryptographically secure, but there shouldn't be simple use cases (e.g., > consecutive integers) that produce hashes that are not uniformly > distributed. This can be achieved with minimal performance impact (and > potentially big performance gains in hashed collections) quite simply by > sending some hashMultiply message in your hash method. > > Regards, > Luciano > _,,,^..^,,,_ best, Eliot

Nov. 24, 2018

[ANN] Live type information for Smalltalk

by Hernan Wilkinson

Hi all!, I wanted to let you know that I have implemented a "feature" to have type information "live". Currently it is implemented on Cuis but the idea is to port it to Pharo and Squeak as well. This feature is based on a few changes on the VM that collects the class of the object assigned to a variable, a parameter or when returning from a method. That information is available from the image and allows to improve the tools radically, like the autocompletion on the browser, looking for senders/implementors and even "scoping" the refactorings based on the type info. I presented it at the last Smalltalks (the argentinean smalltalk conference) and I'm happy to announce its alpha version (1/1000) asFloat :-) Here is a link to the repo that has the VM and a Cuis image to play with it: https://github.com/hernanwilkinson/Cuis-Smalltalk-DynamicTypeInformation It also has the source of the VM's changes if you want to see how it is implemented. Currently it is implemented only in the stack VM and the VMs I compiled and uploaded to the repo are 64 bits for MacOs and Linux. (I don't have a Windows machine to compile it :-) ) Here is a link to a video that shows how it is implemented and how to use it: https://t.co/n8FQuo7pKZ If you want to see the slides of the presentation, here is the link: https://www.slideshare.net/hernanwilkinson/dynamic-type-information I would love for you to try it and get feedback, ideas, etc. I really believe it is a "killer feature", something that could take Smalltalk one step further and show the way to other dynamically typed languages. Cheers! Hernan -- *HernÃ¡n WilkinsonAgile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125 *Mobile: +54 - 911 - 4470 - 7207email: hernan.wilkinson(a)10Pines.comsite: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Nov. 24, 2018

[Pharo 7.0-dev] Build #1413: 22686-Open-browser-fails-without-sources-file-

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

There is a new Pharo build available! The status of the build #1413 was: SUCCESS. The Pull Request #2008 was integrated: "22686-Open-browser-fails-without-sources-file-" Pull request url: https://github.com/pharo-project/pharo/pull/2008 Issue Url: https://pharo.fogbugz.com/f/cases/22686 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 23, 2018

[Pharo 7.0-dev] Build #1412: 22692-Improve-after-operation-for-Array

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

There is a new Pharo build available! The status of the build #1412 was: FAILURE. The Pull Request #2011 was integrated: "22692-Improve-after-operation-for-Array" Pull request url: https://github.com/pharo-project/pharo/pull/2011 Issue Url: https://pharo.fogbugz.com/f/cases/22692 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 23, 2018

[ANN] Next Pharo Sprint: Nov 30

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Nov 30, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Pharo 7 issues Remote Sprint: Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come https://association.pharo.org/event-2973626

Nov. 23, 2018

Re: [Pharo-dev] [squeakland] strategies and tools for a comeback of Smalltalk using Scratch as entrance

by Bernhard HÃ¶fner

Hello Tim and the group thank you for your reply. It is very good to hear, that it is effort in the Smalltalk Scratch, especially when it has such good results. By the way: can I see it as the new Smalltalk Scratch version also for other platforms than Raspberry Pi? I ask, because also other Smalltalk based implementations could profit from it, for example the ipad-version Pyonkee or the Version with Smalltalk-code-view Phratch. Speed would be a matter when programming serious Apps for tablets or smartphones. By using all its sensors children could make nice tools with it and they experiment not only with Software but with the real world objects (which also brings them closer to Smalltalks object orientation). But this detaches me from my real concern: how is it possible to bundle all the initiatives and power to have realized such a continuous Scratch / Smalltalk tool, that I tried to describe with my Topic. Unfortunately nobody answered on my question if such a tool is welcome. Maybe I am the only one with that vision. Best Regards, Bernhard I just replied in the squeak-list, that I shift the discussion to pharo list. I wrote there: â...Because there is no discussion started about my underlying question, I try to continue it on pharo list. I think, many of the participants in squeak list are also participants there. Further I think, that scratch could be a good starting point Tobias mentioned the https://programmieren.wdrmaus.de <https://programmieren.wdrmaus.de/> project which again shows that Scratch is spread and willingly used. Maybe it is not such important, which porting is used as long the "project" code is interchangeable, which means that the Smalltalk-based implementation should be maintained and always be up to date. I dont know if someone takes care about that." > Am 03.11.2018 um 04:27 schrieb tim Rowledge <tim(a)rowledge.org>: > > > >> On 2018-11-02, at 3:22 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> >> Hi Tim >> >> I think you do not read the Pharo list. > > This is true. Only so much time in one life... > >> >> Below post from somebody who is not aware that you ported Scratch to >> the freshly release Squeak 5.2 easily loadable through SqueakMap.... > > Hi Bernhard - I spent some time working for the Raspberry Pi Foundation to significantly rewrite the original Scratch/Squeak implementation so it would perform well on the Pi (back then of course the original Pi with the single core 700MHz cpu) and I was able to make it really quite a lot faster. I also made it possible to run on a modern version of Squeak and indeed it currently runs on Squeak 5.2 - which makes it *very* nice on a Pi3B+. > > You can find it on SqueakMap as 'nuscratch' along with the gpio server and gpio driver libraries I developed. You might also be interested in the 'Whiskers' project by someone I only know as 'NoMod'; google is your friend in this case. They developed some further extensions to read .sb2 files, change the UI to closely match that of Scratch 2 (which as you likely know was a rewrite by MIT in *Flash*, of all horrible things) and add some new blocks. > > > tim > -- > tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: CBA: Compare if Biorhythms Amenable > >

Nov. 23, 2018

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