- Pharo-dev - lists.pharo.org

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

by Esteban Lorenzano

> On 11 Feb 2019, at 09:20, Nicolas Cellier <nicolas.cellier.aka.nice(a)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) 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 > >

Feb. 11, 2019

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

by Nicolas Cellier

Le lun. 11 fÃ©vr. 2019 Ã 08:45, Norbert Hartl <norbert(a)hartl.name> a Ã©crit : > > > > Am 11.02.2019 um 08:00 schrieb estebanlm(a)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 > > > > 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 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… > > > > > > 7 February 2019: > > ---------------- > > > > * Small fix-a-day: [ > https://github.com/pharo-project/pharo/pull/2452](https://github.com/pharo-… > > > > > > cheers! > > Esteban > > > > >

Feb. 11, 2019

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

by Norbert Hartl

> Am 11.02.2019 um 08:00 schrieb estebanlm(a)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 > > 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. 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… > > > 7 February 2019: > ---------------- > > * Small fix-a-day: [https://github.com/pharo-project/pharo/pull/2452](https://github.com/pharo-… > > > cheers! > Esteban >

Feb. 11, 2019

Re: [Pharo-dev] atRandom & integer agnosticism

by Nicolas Cellier

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

Esteban's ChangeLog week of 4 February 2019

by 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 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). 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… 7 February 2019: ---------------- * Small fix-a-day: [https://github.com/pharo-project/pharo/pull/2452](https://github.com/pharo-… cheers! Esteban

Feb. 11, 2019

atRandom & integer agnosticism

by David Richards

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

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

by Ben Coman

On Sun, 10 Feb 2019 at 00:32, 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. > Thats what we currently have. Its good for me. https://github.com/pharo-project/pharo/branches cheers -ben

Feb. 10, 2019

Pillar branch names (was: ConfigurationOfGrease for Pharo8)

by Alistair Grant

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. Cheers, Alistair

Feb. 9, 2019

[Pharo 8.0] Build #60: 2474-Cleaning-printing-protocols

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

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

Feb. 9, 2019

Re: [Pharo-dev] Roadmap for Pharo 8.0

by Paul DeBruicker

Hi - Looks interesting. Is sista still a thing that is in the pipeline? Thanks for all your effort. Paul EstebanLM wrote > Hi list, > > We started Pharo 8.0 development and we wanted to share (and discuss, if > needed) what is our current Roadmap for Pharo 8.0. > As you can see, Windows is getting some love, and also UI. > Anyway, here it is: > > Image > === > 1) Missing parts for headless VM to work (explained a bit later) > 2) We need to improve Epicea speed. And in general, source access speed. > We want to remove the old changes file (since Epicea already does that > works and a lot more). > 3) Improve Refactors > 4) Improve Calypso > 5) Introduce Spec2 (our re-work on this framework). > - We also want to migrate our tools to it (Inspector, Debugger, Spotter > and Calypso are the remaining parts). We will see how much of this > migration can be done. > > VM/Low-level side > === > 1) headless vm > We want to have a real headless VM and make it our default VM. > To it, most of the work vm-side is already made by Ronie, but there are > missing parts: > - a build on windows > - image side capabilities: we use SDL2 to start the world, and it mostly > works... but not completely. > > One cool thing of this is that we will -finally- be able to clean the > event handling, which is ugly (and works bad). > > 2) Windows several missing/non working parts: > - file primitives are slow. This is because they rely in old APIs and we > need to put them in "state of the art". > - libgit2 does not processes long paths. We workarounded the problem with > tonel, but at a point we need to take care about this. Real problem with > this is we need to contribute the solution to libgit2, but this is also > good Open Source policy (contributing back). > - OSSubprocess in windows. We believe we need to extend OSSubprocess (our > solution to communicate with system) to windows. And we believe is > possible ;) > > 3) ThreadedFFI. > It is already too much time since we have this in agenda. Is time to make > it real. > > 4) memory policies. > Tweaking the VM to enhance its memory usage is possible, but hard. We want > to adopt an scheme of "memory policies" that will allow users to pick what > they need. > > Process > === > 1) We will add multiple source directories to Iceberg. This is needed to > allow us to put all Pharo sub-projects into an unique project without > breaking modularisations. > > Others > === > 1) Launcher > - Launcher us getting a new UI > - Tests > - It needs to be more solid (in part, that's the reason why we want > OSSubprocess in windows). > 2) Cargo > - We need to revisit cargo (a new dependency manager) and at a point > decide if it will fly or not :) > > Nice to have (most probably not this version, but in our TODO) : > - embedded VM > - event driven VM > - what happens if we split VM into main thread and vm thread? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 8, 2019