- Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #63: 2476-Cleaning-initialize-categorisation

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

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

Feb. 11, 2019

Re: [Pharo-dev] Esteban's ChangeLog week of 4 February 2019

by Sean P. DeNigris

NorbertHartl wrote >> Or FixedLayout :P. Because actually it's not absolute, it's relative to >> its parent xD. > > The layout is absolute for the component it is applied to. Doesnât matter > if the component itself is layouted relative to something else. We donât > need to try hard to come up with new terms just be different to e.g. CSS Only skimmed the thread, but +1 to leaning heavily to accepted domain terms even if they are not "perfect". IMHO, for common domains, the tower of babel creates more accidental complexity than imperfect names. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 11, 2019

[Pharo 8.0] Build #62: 2486-Class-builder-should-call-initializeSlot-on-instance-migration

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

There is a new Pharo build available! The status of the build #62 was: FAILURE. The Pull Request #2487 was integrated: "2486-Class-builder-should-call-initializeSlot-on-instance-migration" Pull request url: https://github.com/pharo-project/pharo/pull/2487 Issue Url: https://pharo.fogbugz.com/f/cases/2486 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 11, 2019

Re: [Pharo-dev] Esteban's ChangeLog week of 4 February 2019

by Norbert Hartl

> Am 11.02.2019 um 10:32 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > > > On Mon, Feb 11, 2019 at 9:54 AM Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > > >> Am 11.02.2019 um 09:22 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> >> >> >>> On 11 Feb 2019, at 09:20, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >>> >>> >>> >>> Le lun. 11 fÃ©vr. 2019 Ã 08:45, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> a Ã©crit : >>> >>> >>> > Am 11.02.2019 um 08:00 schrieb estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>: >>> > >>> > Hello! >>> > >>> > This is my weekly ChangeLog, from 4 February 2019 to 10 February 2019. >>> > You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=4/2/2019&to=10/2/2019 <http://log.smallworks.eu/web/search?from=4/2/2019&to=10/2/2019> >>> > >>> > ChangeLog >>> > ========= >>> > >>> > 9 February 2019: >>> > ---------------- >>> > >>> > * === On layouts >>> > As you know, I've been working on layouts for Spec 2. The basic layouts I want to have available next week(s) are four: >>> > >>> > * +SpecBoxLayout+ : A simple way to place components horizontally or vertically >>> > * +SpecPanedLayout+ : Same as box layout, but with a resizable splitter (and it will allow just two... if you want more you will need to compose). >>> > * +SpecGridLayout+ : To place components in a grid (x,y coordinates and spans) >>> > * +SpecXYLayout+ : This could be renamed as +SpecAbsoluteLayout+ and it's name says all, it will allow absolute location of components (obviously, in relation with its parent). >>> > >>> > For a second phase there will be a couple more +SpecFlowLayout+ and a kasowari layout (without name yet :P). >>> > >>> Apple and others call it auto layout. I donât like that name as it isnât really clear. It could be called ConstraintLayout. >>> >>> +1 for ConstraintLayout >> >> Ok, Constraint will be :) >> (But it will not arrive until half part of P8 development :P) >> > No problem if you remember then ;) In the meantime you can rename XYLayout to AbsoluteLayout :D > > Or FixedLayout :P. Because actually it's not absolute, it's relative to its parent xD. The layout is absolute for the component it is applied to. Doesnât matter if the component itself is layouted relative to something else. We donât need to try hard to come up with new terms just be different to e.g. CSS Norbert > > > Norbert > >> Esteban >> >>> >>> Norbert >>> > The ones on first phase are the most important ones. In particular, we have detected that with >>> > first three (Box, Paned, Grid) we can reproduce everything we have currently in Pharo. The second phase >>> > will add possibilities for the future. >>> > >>> > Anyway, I have "kind-of-working" the first three, but I have problems when applying layouts here and there, because >>> > morphic time to time wants to behave differently than asked. >>> > >>> > One of the problems is that for this layouts, to make them behave correctly (and without a lot of work from users), >>> > I will need to add the concept of "minimum, preferred and maximum" extent. Reason why I'm playing with a small >>> > implementation of styling... which most probably will go away once I find the best way to handle this constraints. >>> > >>> > So, this week I have nothing finished, just a pointer to my current work: [https://github.com/estebanlm/Spec/tree/dev-2.0](https://github.com/estebanl… <https://github.com/estebanlm/Spec/tree/dev-2.0%5D(https://github.com/esteba…> >>> > >>> > >>> > 7 February 2019: >>> > ---------------- >>> > >>> > * Small fix-a-day: [https://github.com/pharo-project/pharo/pull/2452](https://github.com/pharo-… <https://github.com/pharo-project/pharo/pull/2452%5D(https://github.com/phar…> >>> > >>> > >>> > cheers! >>> > Esteban >>> > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Feb. 11, 2019

Re: [Pharo-dev] atRandom & integer agnosticism

by Nicolas Cellier

Thanks for this link. Note that there are quite good classical PRNG already programmed for Pharo in package Polymath including a Mersenne twister and Marsaglia KISS as used in gfortran... (I did not check recently but there should be a catalog entry for Polymath). The one programmed in Squeak is a Mersenne Twister I think, carefully written for maximizing performance for 32bits VM (with 31bit SmallIntegers). IMO, the Park-Miller PRNG was a good default choice in the 70s when it was introduced in Smalltalk. But now, we have fast enough machines to not bother with its limitations. Le lun. 11 fÃ©vr. 2019 Ã 15:58, David Richards < david.i.richards.iii(a)gmail.com> a Ã©crit : > Thanks Nicolas and Henry, > > For now, simple alternative expressions can easily generate the values I > need for my project, such as: > > (String new: 32) collect: [ :each | '0123456789abcdef' atRandom ] > > Maybe in a few months (or years!) from now I will have acquired enough > ambient familiarity with Pharo to attempt a fix. But, for the time being, > I'll just avoid stepping on the landmine. > > In doing some research on this problem I spotted this, which seemed to > possibly point a way toward a cutting edge RNG implementation for Pharo: > > http://xoshiro.di.unimi.it/#intro > > [image: image.png] > > David > > On Sun, 10 Feb 2019 at 23:21, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Try it in Squeak and pick the relevant methods. Open a bug report and >> commit the fix. Of course, original authorship will somehow be spoiled, so >> be kind and cite them in commit message. >> >> Le lun. 11 fÃ©vr. 2019 Ã 07:59, David Richards < >> david.i.richards.iii(a)gmail.com> a Ã©crit : >> >>> Hello community. >>> >>> Kindly consider: >>> >>> | n i r | >>> n := ( 2 ** 256 ) - 1 . "the largest 256-bit value" >>> i := ( 0 to: n ) . "the interval 0 to 2**256-1" >>> "Produce three sets of computed test results." >>> 3 timesRepeat: [ >>> Transcript show: ( r := i atRandom ) ; cr . >>> Transcript show: ( r asByteArray hex ) ; cr . ] >>> >>> According to comments in Pharo library code, atRandom fails for integer >>> magnitudes greater than 2**30 . A reason for this limitation is not given, >>> and it's not clear to a novice such as myself why the computed result of >>> atRandom is permitted to sometimes be in conflict with the semantics of >>> atRandom . >>> >>> Can anyone provide a basic explanation of the rationale for a 'broken' >>> atRandom ? >>> >>> Alternatively, is this a known bug? >>> >>> Thanks. >>> dr >>> >>

Feb. 11, 2019

[Pharo 8.0] Build #61: 2480-Remove-GTSpotterDoubleLinkedList

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

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

Feb. 11, 2019

Re: [Pharo-dev] atRandom & integer agnosticism

by David Richards

Thanks Nicolas and Henry, For now, simple alternative expressions can easily generate the values I need for my project, such as: (String new: 32) collect: [ :each | '0123456789abcdef' atRandom ] Maybe in a few months (or years!) from now I will have acquired enough ambient familiarity with Pharo to attempt a fix. But, for the time being, I'll just avoid stepping on the landmine. In doing some research on this problem I spotted this, which seemed to possibly point a way toward a cutting edge RNG implementation for Pharo: http://xoshiro.di.unimi.it/#intro [image: image.png] David On Sun, 10 Feb 2019 at 23:21, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Try it in Squeak and pick the relevant methods. Open a bug report and > commit the fix. Of course, original authorship will somehow be spoiled, so > be kind and cite them in commit message. > > Le lun. 11 fÃ©vr. 2019 Ã 07:59, David Richards < > david.i.richards.iii(a)gmail.com> a Ã©crit : > >> Hello community. >> >> Kindly consider: >> >> | n i r | >> n := ( 2 ** 256 ) - 1 . "the largest 256-bit value" >> i := ( 0 to: n ) . "the interval 0 to 2**256-1" >> "Produce three sets of computed test results." >> 3 timesRepeat: [ >> Transcript show: ( r := i atRandom ) ; cr . >> Transcript show: ( r asByteArray hex ) ; cr . ] >> >> According to comments in Pharo library code, atRandom fails for integer >> magnitudes greater than 2**30 . A reason for this limitation is not given, >> and it's not clear to a novice such as myself why the computed result of >> atRandom is permitted to sometimes be in conflict with the semantics of >> atRandom . >> >> Can anyone provide a basic explanation of the rationale for a 'broken' >> atRandom ? >> >> Alternatively, is this a known bug? >> >> Thanks. >> dr >> >

Feb. 11, 2019

[ANN] Registration for Pharo Days 2019 open!

by Esteban Lorenzano

Dear all, I am pleased to announce that registration for Pharo Days 2019 is now open! Pharo days is a gathering of the Pharo community to exchange, discuss and code with your online colleagues. Join us to share your experiences and help to make a better Pharo! To register, please proceed to the Pharo Days 2019 web page: https://pharo.org/2019PharoDays <https://pharo.org/2019PharoDays>, or go directly to the association event: https://association.pharo.org/event-3255426 <https://association.pharo.org/event-3255426>. (Yes, the schedule is still to be defined, stay tuned). If there are any questions or problems, I am happy to answer them. Esteban Ps: Iâm sorry for multiple posts ;)

Feb. 11, 2019

Re: [Pharo-dev] atRandom & integer agnosticism

by Henrik Sperre Johansen

The "random" index for atRandom is, basically, computed prngOutput mod: selectionRange. For large selection ranges, it fails because the period of the PRNG used by atRandom is 2^30th, with the output an integer in the range 1 - 2^30th. (in other words, the prng is a repeating sequence of every number between 1 and 2^30th) That means: - There will be bias when the range you pick from approaches 2^30th. - There will be gaps (indexes that won't ever be picked) once you pass 2^30th. The reason is techical; the default RNG is a reasonable compromise between speed, memory, and usable range. If the intended use requires a larger range, an appropriate random number generator can be provided using atRandom: It certainly could give an error and/or select another RNG automatically if outside applicable range, but no one has been bothered enough to do either, yet. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 11, 2019

Re: [Pharo-dev] Pillar branch names (was: ConfigurationOfGrease for Pharo8)

by Guillermo Polito

On Sat, Feb 9, 2019 at 5:32 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Guille, > > On Mon, 4 Feb 2019 at 09:43, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > On Mon, Feb 4, 2019 at 9:28 AM Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> > >> Hi Stef, > >> On Mon, 4 Feb 2019 at 09:20, ducasse <stepharo(a)netcourrier.com> wrote: > >> > > >> > >> The dev-7 branch loads fine in Pharo 8. > >> > >> > > But what do you mean by "now it is 70â? > >> > > >> > I thought that guillermo changed the dev-7 branch. > > > > Nope, I think that name is good, and then we manage releases using tags. > We have the following branches: > > What do you think of following the same naming convention as > pharo-project/pharo, i.e. using branch names Pharo7.0 instead of > dev-7? > I think that would make it easier for newcomers. > Well, not necessarily pillar version 7 is for Pharo version 7, or pillar version 6 is for pharo 6. Until now, those namings were a bit accidental... Actually, between pillar 6 and 7, the major change (user-wise, and not implementation wise) is that it can be built without makefiles and works on windows. But the pillar parser and ASTs do not change (or not that I'm aware of). > Cheers, > Alistair > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Feb. 11, 2019