February 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #65: [IGNORE]2466-Remove-unused-variables

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

There is a new Pharo build available! The status of the build #65 was: FAILURE. The Pull Request #2468 was integrated: "[IGNORE]2466-Remove-unused-variables" Pull request url: https://github.com/pharo-project/pharo/pull/2468 Issue Url: https://pharo.fogbugz.com/f/cases/2466 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 12, 2019

Re: [Pharo-dev] PharoLauncher - upgrading to 1.6 on Windows

by Franz Josef Konrad

Am 12.02.2019 um 08:17 schrieb Petr Fischer via Pharo-dev: > > PharoLauncher - upgrading to 1.6 on Windows.eml > > Betreff: > PharoLauncher - upgrading to 1.6 on Windows > Von: > Petr Fischer <petr.fischer(a)me.com> > Datum: > 12.02.2019, 08:17 > > An: > pharo-dev(a)lists.pharo.org > > > Hello. > > I thought I'd try PharoLauncher again after some time and I really have a bad luck with this product. > > I have a PharoLauncher version 1.5.1 installed. If I run new 1.6 installer, this error occurs: > > "A more recent version of PharoLauncher is already installed on this computer" > https://app.box.com/s/rbn1n12zvx5rvy4zb1s0fujhkbzwvone > > "More recent?..." Really? > > I uninstalled old version manually of course, but... PharoLauncher can't update itself? > > Platform: Windows 10 Pro [1809] > > pf > I had the same problem and deleted the Pharo entries in the registry manually with regedit. After that I was able to use the installer. I suspect that the PharoLauncher does not yet contain the correct version information in the registry or that it is not evaluated correctly. Franz Josef

Feb. 12, 2019

PharoLauncher - upgrading to 1.6 on Windows

by Petr Fischer

Hello. I thought I'd try PharoLauncher again after some time and I really have a bad luck with this product. I have a PharoLauncher version 1.5.1 installed. If I run new 1.6 installer, this error occurs: "A more recent version of PharoLauncher is already installed on this computer" https://app.box.com/s/rbn1n12zvx5rvy4zb1s0fujhkbzwvone "More recent?..." Really? I uninstalled old version manually of course, but... PharoLauncher can't update itself? Platform: Windows 10 Pro [1809] pf

Feb. 12, 2019

[Pharo 8.0] Build #64: 2489-DatePrintFormatTester-should-be-removed

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

There is a new Pharo build available! The status of the build #64 was: FAILURE. The Pull Request #2490 was integrated: "2489-DatePrintFormatTester-should-be-removed" Pull request url: https://github.com/pharo-project/pharo/pull/2490 Issue Url: https://pharo.fogbugz.com/f/cases/2489 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 11, 2019

[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