Hi, Yes I forget to say that this roadmap is not everything and there are other stuff that can be done/contributed/etc. and we would like to include. And of course we have the “everyday work”, cleanups, enhancements, etc.
Esteban > On 8 Feb 2019, at 15:47, Norbert Hartl <norb...@hartl.name> wrote: > > > >> Am 08.02.2019 um 14:04 schrieb Alexandre Bergel via Pharo-dev >> <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org>>: >> >> >> Von: Alexandre Bergel <alexandre.ber...@me.com >> <mailto:alexandre.ber...@me.com>> >> Betreff: Aw: [Pharo-dev] Roadmap for Pharo 8.0 >> Datum: 8. Februar 2019 um 14:04:24 MEZ >> An: Pharo Development List <pharo-dev@lists.pharo.org >> <mailto:pharo-dev@lists.pharo.org>> >> >> >> 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? >> > That would be nice for the delivered image. With a revamped Connectors > implementation (does anyone remember?) I would only wish a format for > integrating this into pillar that would make documentation super awesome. > > Norbert > >> Cheers, >> Alexandre >> >>> On Feb 7, 2019, at 12:08 PM, Esteban Lorenzano <esteba...@gmail.com >>> <mailto: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?
