On Fri, 8 Feb 2019 at 02:03, [email protected] <[email protected]> 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 <[email protected] 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? >> >
