[Pharo-dev] Roadmap for Pharo 8.0

phil at highoctane.be phil at highoctane.be
Thu Feb 7 13:01:48 EST 2019


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 at 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?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190207/0e4ec34c/attachment.html>


More information about the Pharo-dev mailing list