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

halos

by Stephan Eggermont

What happened with halos in Pharo 7? They donât show up anymore Stephan

Nov. 26, 2018

[Pharo 7.0-dev] Build #1414: 22690-32-vs-64-bits-and-large-integer-hash

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

There is a new Pharo build available! The status of the build #1414 was: FAILURE. The Pull Request #2009 was integrated: "22690-32-vs-64-bits-and-large-integer-hash" Pull request url: https://github.com/pharo-project/pharo/pull/2009 Issue Url: https://pharo.fogbugz.com/f/cases/22690 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 26, 2018

Esteban's ChangeLog week of 19 November 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 19 November 2018 to 25 November 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=19/11/2018&to=25/11/2018 ChangeLog ========= 22 November 2018: ----------------- * I made a change in the VM to modify [freetype version to 2.9.1](https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/307). We have the suspicion that some bugs we are finding in our use of freetype fonts may be already fixed on newer versions of freetype library (we were using 2.6.5). And well, if that is not the case, at least we will be up-to-date :) 19 November 2018: ----------------- * I made a [PR](https://github.com/pharo-project/pharo/pull/2002) to improve the logic in callbacks. They were not returning in case of error, and that was leading to a system crash almost inevitably. cheers! Esteban

Nov. 26, 2018

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

by Luciano Notarfrancesco

Hi Eliot! On Sat, Nov 24, 2018 at 9:18 PM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > On Sat, Nov 24, 2018 at 7:40 AM Luciano Notarfrancesco <luchiano(a)gmail.com> > wrote: > >> >> 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. > > The problem I see is that sequences of SmallIntegers that we humans tend add to hashed collections are not usually uniformly distributed. Hopefully they have some meaning, and thus some patterns to them, most of the time they don't look random, and thus if they are their own hash the performance of hashed collections will most likely suffer. I found this problem when profiling my code. I guess some people might assume that Sets or Dictionaries are fast and use them with SmallIntegers without much care, and never discover that their code could be orders of magnitude faster. So, another option might be to modify scanFor: to randomize the hash of the argument (for example sending an additional hashMultiply). This is because scanFor: is assuming the arguments of successive calls will have uniformly distributed hashes: start := anObject hash \\ array size + 1. the algorithm needs 'start' to be uniformly distributed between 1 and array size, and in the case of SmallIntegers current hash this is very unlikely and lookups degenerate in linear searches. Also, any cryptographic hash will do great in pretty much ALL use cases. Finding a sequence of integers that produces non-uniform hashes is very hard, and is equivalent to breaking the cryptographic hash and make it unusable for cryptography. This is a sort of silver bullet, I seem to remember that Java does this now, but I think it is overkill and something like hashMultiply is enough (plus, it is cheaper). My 2 maos, Luciano

Nov. 25, 2018

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