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

[Pharo 8.0] Build #54: CommandLineUIManager >> syntaxErrorNotificationDefaultAction comment typo

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

There is a new Pharo build available! The status of the build #54 was: FAILURE. The Pull Request #2457 was integrated: "CommandLineUIManager >> syntaxErrorNotificationDefaultAction comment typo" Pull request url: https://github.com/pharo-project/pharo/pull/2457 Issue Url: https://pharo.fogbugz.com/f/cases/patch 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 Ben Coman

On Fri, 8 Feb 2019 at 02:03, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Sounds awesome. > > Getting the basics rock solid and as a first class server citizen. Sweet! > > Phil > > On Thu, Feb 7, 2019, 16:09 Esteban Lorenzano <estebanlm(a)gmail.com 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. >> >> yay, yay and yay! This should be great for smaller IoT devices. One cool thing of this is that we will -finally- be able to clean the event >> handling, which is ugly (and works bad). >> > Could the scope of the headless vm encompass embed-ability? @community, are there any use cases you might like to work on to provide a practical test of such an interface? e.g. events might need to come from a game engine for that integration to work properly. 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. >> > cool. that might help with embedding in a game engine? cheers -ben > 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? >> >

Feb. 8, 2019

Re: [Pharo-dev] Roadmap for Pharo 8.0

by phil＠highoctane.be

Sounds awesome. Getting the basics rock solid and as a first class server citizen. Sweet! Phil On Thu, Feb 7, 2019, 16:09 Esteban Lorenzano <estebanlm(a)gmail.com 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? > > >

Feb. 7, 2019

Re: [Pharo-dev] Roadmap for Pharo 8.0

by Alistair Grant

Hi Esteban, On Thu, 7 Feb 2019 at 16:09, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > 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". Is there somewhere I can read more about this? (I'm not disagreeing, just interested in what it means). Thanks, Alistair

Feb. 7, 2019

Roadmap for Pharo 8.0

by Esteban Lorenzano

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?

Feb. 7, 2019

[Pharo 8.0] Build #52: 2338 GT Extensions should also be visible on empty directories

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

There is a new Pharo build available! The status of the build #52 was: SUCCESS. The Pull Request #2339 was integrated: "2338 GT Extensions should also be visible on empty directories" Pull request url: https://github.com/pharo-project/pharo/pull/2339 Issue Url: https://pharo.fogbugz.com/f/cases/2338 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 7, 2019

Re: [Pharo-dev] shortcut to browser ref to a class

by Denis Kudriashov

Hi Stef. cmd+n does not work for you? Ð²Ñ, 5 ÑÐµÐ²Ñ. 2019 Ð³., 19:21 ducasse stepharo(a)netcourrier.com: > Hi > > Is it me or we lost cmd + shift B to browse refs to class in Calypso? > > Stef > > > >

Feb. 6, 2019

[Pharo 7.0] Build #148: Ensure subMenu is opened (backport)

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

There is a new Pharo build available! The status of the build #148 was: FAILURE. The Pull Request #2376 was integrated: "Ensure subMenu is opened (backport)" Pull request url: https://github.com/pharo-project/pharo/pull/2376 Issue Url: https://pharo.fogbugz.com/f/cases/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 6, 2019

Re: [Pharo-dev] pharo.prg is down

by Christophe Demarey

There is a documentation I wrote when preparing server migration (none before) hosted at https://gitlab.inria.fr/RMOD/servers. It is a private repository as it contains sensitive information. > Le 5 fÃ©vr. 2019 Ã 14:58, ducasse <stepharo(a)netcourrier.com> a Ã©crit : > > Do we have a document somwhere to know what to do > if knowing people are in vacation? > > > >> On 5 Feb 2019, at 13:57, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: >> >> Thanks for the report. >> I restarted the service. It is now back on line. >> >> Cheers, >> Christophe >> >>> Le 5 fÃ©vr. 2019 Ã 13:41, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >>> >>> Hi, >>> >>> pharo.org looks down: >>> https://downforeveryoneorjustme.com/pharo.org >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.feenk.com >>> >>> âHow do you feenk today?" >>> >>> >> >> > > >

Feb. 5, 2019

shortcut to browser ref to a class

by ducasse

Hi Is it me or we lost cmd + shift B to browse refs to class in Calypso? Stef

Feb. 5, 2019