Re: [Pharo-dev] Roadmap for Pharo 8.0

[Alexandre Bergel via Pharo-dev]

--- Begin Message ---

Dear All,

At the consortium meeting we discussed the possibility to have a mini-Roassal 
included in Pharo8. Many opportunities exist: displaying graph of commits in 
iceberg, displaying UML within the code browser, visualizing dependencies 
between packages.

We are motivated about it, and we should produce a runnable proposal ready to 
be evaluated by the community within a couple of months. 
Does it make sense? Any thought about it? Do you have a wishlist?

Cheers,
Alexandre

> On Feb 7, 2019, at 12:08 PM, Esteban Lorenzano <esteba...@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?
> 
> 

--- End Message ---