- Pharo-dev - lists.pharo.org

Re: halos

by Stephan Eggermont

Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Then you need to be a bit more precise than just saying âit does not works anymoreâ :) > > Anyway, I canât reproduce your problem. > > Pharo-7.0.0+rc1.build.1411.sha.56c2a7682674715623d89e8a16669397a1454e43 (64bit) > > And latestVM, still works for me on windows. > PharoLauncher Pharo 7 (development version) list isnât updated anymore, stuck at 1384. 1411 works for me too. Thanks, Stephan

Nov. 26, 2018

Re: [Pharo-dev] halos

by Esteban Lorenzano

Then you need to be a bit more precise than just saying âit does not works anymoreâ :) Anyway, I canât reproduce your problem. Pharo-7.0.0+rc1.build.1411.sha.56c2a7682674715623d89e8a16669397a1454e43 (64bit) And latestVM, still works for me on windows. Esteban > On 26 Nov 2018, at 14:31, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> They work for me. >> Same combination as always (alt+shift+click) > > Not on 1384-64 in Windows with the latest vm > > Stephan > > > > >

Nov. 26, 2018

Re: [Pharo-dev] Fuel update for UTCDateAndTime

by Max Leske

Thanks Dave! I've opened an issue on Github: https://github.com/theseion/Fuel/issues/235. Max On 26 Nov 2018, at 14:20, David T. Lewis wrote: > The Fuel serializer is loadable in Squeak 5.2 from the SqueakMap loader, > and is supported for Pharo, Squeak, and Cuis (great kudos to the > maintainers for doing this). > > In order to change DateAndTime to a simpler UTC-based implementation in > Squeak, with two instance variables rather than four, an update will be > needed for Fuel to understand the new format. > > The attached change set provides the necessary support, while maintaining > compatibility with the traditional DateAndTime and interoperability > between images that support either format. For example, an image can > serialize a traditional DateAndTime with Fuel, and another image with > UTC DateAndTime can materialize it in the new UTC format. > > I am not yet sure how to submit this to the Fuel maintainers, so I'm > posting it here as a change set for now. > > Dave

Nov. 26, 2018

Re: [Pharo-dev] halos

by Stephan Eggermont

Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > They work for me. > Same combination as always (alt+shift+click) Not on 1384-64 in Windows with the latest vm Stephan

Nov. 26, 2018

Fuel update for UTCDateAndTime

by David T. Lewis

The Fuel serializer is loadable in Squeak 5.2 from the SqueakMap loader, and is supported for Pharo, Squeak, and Cuis (great kudos to the maintainers for doing this). In order to change DateAndTime to a simpler UTC-based implementation in Squeak, with two instance variables rather than four, an update will be needed for Fuel to understand the new format. The attached change set provides the necessary support, while maintaining compatibility with the traditional DateAndTime and interoperability between images that support either format. For example, an image can serialize a traditional DateAndTime with Fuel, and another image with UTC DateAndTime can materialize it in the new UTC format. I am not yet sure how to submit this to the Fuel maintainers, so I'm posting it here as a change set for now. Dave

Nov. 26, 2018

Re: [Pharo-dev] halos

by Esteban Lorenzano

They work for me. Same combination as always (alt+shift+click) Esteban > On 26 Nov 2018, at 13:48, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > > What happened with halos in Pharo 7? They donât show up anymore > > Stephan > >

Nov. 26, 2018

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