- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1414: 22690-32-vs-64-bits-and-large-integer-hash
by ci-pharo-ci-jenkins2＠inria.fr Nov. 26, 2018

Nov. 26, 2018

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…

1 0

Esteban's ChangeLog week of 19 November 2018
by estebanlm＠gmail.com Nov. 26, 2018

Nov. 26, 2018

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

1 0

Re: [Pharo-dev] [squeak-dev] 32 vs 64 bits and large integer hash
by Eliot Miranda Nov. 25, 2018

Nov. 25, 2018

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

2 1

[ANN] Live type information for Smalltalk
by Hernan Wilkinson Nov. 24, 2018

Nov. 24, 2018

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

1 0

[Pharo 7.0-dev] Build #1413: 22686-Open-browser-fails-without-sources-file-
by ci-pharo-ci-jenkins2＠inria.fr Nov. 23, 2018

Nov. 23, 2018

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…

1 0

[Pharo 7.0-dev] Build #1412: 22692-Improve-after-operation-for-Array
by ci-pharo-ci-jenkins2＠inria.fr Nov. 23, 2018

Nov. 23, 2018

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…

1 0

[ANN] Next Pharo Sprint: Nov 30
by Marcus Denker Nov. 23, 2018

Nov. 23, 2018

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

1 0

Re: [Pharo-dev] [squeakland] strategies and tools for a comeback of Smalltalk using Scratch as entrance
by Bernhard HÃ¶fner Nov. 23, 2018

Nov. 23, 2018

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 > >

1 0

Zinc HTTP Components version 3.0.1
by Sven Van Caekenberghe Nov. 22, 2018

Nov. 22, 2018

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

2 1

32 vs 64 bits and large integer hash
by Eliot Miranda Nov. 22, 2018

Nov. 22, 2018

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

2 2