[Pharo-dev] Roadmap for Pharo 8.0

Paul DeBruicker pdebruic at gmail.com
Fri Feb 8 17:54:40 EST 2019

Hi - 

Looks interesting.   Is sista still a thing that is in the pipeline?

Thanks for all your effort.


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

More information about the Pharo-dev mailing list