--- Begin Message ---
This would be very useful.
Sent from my iPhone
> On Feb 8, 2019, at 8:04 AM, Alexandre Bergel <alexandre.ber...@me.com> wrote:
>
> 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 ---
