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

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

[Pharo 8.0] Build #59: 2441-Less-Smalltalk-ui-theme-Part-1

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

There is a new Pharo build available! The status of the build #59 was: SUCCESS. The Pull Request #2473 was integrated: "2441-Less-Smalltalk-ui-theme-Part-1" Pull request url: https://github.com/pharo-project/pharo/pull/2473 Issue Url: https://pharo.fogbugz.com/f/cases/2441 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 8, 2019

[Pharo 8.0] Build #58: 2294-Halt-on-count-logic-fix

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

There is a new Pharo build available! The status of the build #58 was: FAILURE. The Pull Request #2281 was integrated: "2294-Halt-on-count-logic-fix" Pull request url: https://github.com/pharo-project/pharo/pull/2281 Issue Url: https://pharo.fogbugz.com/f/cases/HaltOnCountFix Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 8, 2019

Re: [Pharo-dev] Roadmap for Pharo 8.0

by Sean P. DeNigris

NorbertHartl wrote > On the one hand we could benefit from powerful code documentation. But > this could conflict with the minimum image we provide where people work on > and these tools would be missing. Yes, this can be a complex problem. For me the key question is what's the point of having a Dynabook if we can't even use it ourselves as developers?! However, isn't the use case for the minimum image more for deployment? I would think that most devs would/could work in the full image and then deploy to the minimal, where interactive documentation would be presumably less important. Also IIUC, in GT the interactive documentation is just pillar underneath and so could be read in static form even if the UI engine wasn't present e.g. as class comments. Also, it seems the full docs should be loadable onto minimal if needed, no? OT: I was happy to see the recent announcement of a GH-based project catalog, but at the same time was disappointed to see it seemingly implemented as text. I wasn't going to say anything because I didn't want to complain about a nice gift, but since this subject is mildly related, I'll just mention that IMHO it makes much more sense to have something that is a static dump of a dynamic system like the Pharo Catalog than to have two competing systems - one live and one not. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 8, 2019

[Pharo 8.0] Build #57: Fix Year>>firstThursday

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

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

Feb. 8, 2019