[Pharo-dev] Roadmap for Pharo 8.0

Ben Coman btc at openinworld.com
Fri Feb 8 01:13:57 EST 2019


On Fri, 8 Feb 2019 at 02:03, phil at highoctane.be <phil at 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 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.
>>
>>
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?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190208/51821cd1/attachment.html>


More information about the Pharo-dev mailing list