Re: [Pharo-dev] Roadmap for Pharo 8.0

[Paul DeBruicker]

Hi - 


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

Thanks for all your effort.

Paul


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

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Sean P. DeNigris]

NorbertHartl wrote
> On the one hand we could benefit from powerful code documentation. But
> this could conflict with the minimum image we provide where people work on
> and these tools would be missing.

Yes, this can be a complex problem. For me the key question is what's the
point of having a Dynabook if we can't even use it ourselves as developers?!
However, isn't the use case for the minimum image more for deployment? I
would think that most devs would/could work in the full image and then
deploy to the minimal, where interactive documentation would be presumably
less important. Also IIUC, in GT the interactive documentation is just
pillar underneath and so could be read in static form even if the UI engine
wasn't present e.g. as class comments. Also, it seems the full docs should
be loadable onto minimal if needed, no?

OT: I was happy to see the recent announcement of a GH-based project
catalog, but at the same time was disappointed to see it seemingly
implemented as text. I wasn't going to say anything because I didn't want to
complain about a nice gift, but since this subject is mildly related, I'll
just mention that IMHO it makes much more sense to have something that is a
static dump of a dynamic system like the Pharo Catalog than to have two
competing systems - one live and one not.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Tim Mackinnon]

+1 (with proviso there is that minimal image you can use to build up from)

> On 8 Feb 2019, at 15:57, Norbert Hartl  wrote:
> 
> 
> 
>> Am 08.02.2019 um 16:47 schrieb Serge Stinckwich > >:
>> 
>> 
>> 
>> On Fri, Feb 8, 2019 at 4:41 PM Alexandre Bergel via Pharo-dev 
>> mailto:pharo-dev@lists.pharo.org>> 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?
>> 
>> 
>> I will not be be strongly against it because I see benefits, but IHMO we 
>> need to reduce the size of Pharo image.
>> Might be interesting to have charts included in the base.
>> A+
>> 
> I don’t agree. Why should we reduce the size of the default image? It should 
> show a lot of things you can do with pharo. As everything is loaded from 
> bootstrap we can have now every size of the image we want. I would rather see 
> an official minimal image that people will download for building their 
> software. But the development should contain everything that eases 
> development and shows what pharo can do.
> The critical border to me is what we provide in documentation. On the one 
> hand we could benefit from powerful code documentation. But this could 
> conflict with the minimum image we provide where people work on and these 
> tools would be missing.
> 
> Norbert
> 
>> -- 
>> Serge Stinckwich
>> Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO)
>> Sorbonne University (SU)
>> French National Research Institute for Sustainable Development (IRD)
>> University of Yaoundé I, Cameroun
>> "Programs must be written for people to read, and only incidentally for 
>> machines to execute."
>> https://twitter.com/SergeStinckwich 
> 

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Norbert Hartl]

> Am 08.02.2019 um 16:47 schrieb Serge Stinckwich :
> 
> 
> 
> On Fri, Feb 8, 2019 at 4:41 PM Alexandre Bergel via Pharo-dev 
> mailto:pharo-dev@lists.pharo.org>> 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?
> 
> 
> I will not be be strongly against it because I see benefits, but IHMO we need 
> to reduce the size of Pharo image.
> Might be interesting to have charts included in the base.
> A+
> 
I don’t agree. Why should we reduce the size of the default image? It should 
show a lot of things you can do with pharo. As everything is loaded from 
bootstrap we can have now every size of the image we want. I would rather see 
an official minimal image that people will download for building their 
software. But the development should contain everything that eases development 
and shows what pharo can do.
The critical border to me is what we provide in documentation. On the one hand 
we could benefit from powerful code documentation. But this could conflict with 
the minimum image we provide where people work on and these tools would be 
missing.

Norbert

> -- 
> Serge Stinckwich
> Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO)
> Sorbonne University (SU)
> French National Research Institute for Sustainable Development (IRD)
> University of Yaoundé I, Cameroun
> "Programs must be written for people to read, and only incidentally for 
> machines to execute."
> https://twitter.com/SergeStinckwich 

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Serge Stinckwich]

On Fri, Feb 8, 2019 at 4:41 PM Alexandre Bergel via Pharo-dev <
pharo-dev@lists.pharo.org> 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?
>
>
I will not be be strongly against it because I see benefits, but IHMO we
need to reduce the size of Pharo image.
Might be interesting to have charts included in the base.
A+

-- 
Serge Stinckwic
h

Int. Research Unit
 on Modelling/Simulation of Complex Systems (UMMISCO)
Sorbonne University
 (SU)
French National Research Institute for Sustainable Development (IRD)
U
niversity of Yaoundé I, Cameroun
"Programs must be written for people to read, and only incidentally for
machines to execute."
https://twitter.com/SergeStinckwich

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Esteban Lorenzano]

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  wrote:
> 
> 
> 
>> Am 08.02.2019 um 14:04 schrieb Alexandre Bergel via Pharo-dev 
>> mailto:pharo-dev@lists.pharo.org>>:
>> 
>> 
>> Von: Alexandre Bergel > <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 > <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 >> <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?

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Norbert Hartl]

> Am 08.02.2019 um 14:04 schrieb Alexandre Bergel via Pharo-dev 
> :
> 
> 
> Von: Alexandre Bergel 
> Betreff: Aw: [Pharo-dev] Roadmap for Pharo 8.0
> Datum: 8. Februar 2019 um 14:04:24 MEZ
> An: Pharo Development List 
> 
> 
> 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  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?
>> 
>> 
> 
> 
> 
> 

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Reg Krock via Pharo-dev]

--- Begin Message ---
This would be very useful.

Sent from my iPhone

> On Feb 8, 2019, at 8:04 AM, Alexandre Bergel  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  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 ---

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Alexandre Bergel via Pharo-dev]

--- Begin Message ---
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  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 ---

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Ben Coman]

On Fri, 8 Feb 2019 at 02:03, p...@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 
>> 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?
>>
>

Re: [Pharo-dev] Roadmap for Pharo 8.0

[p...@highoctane.be]

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  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?
>
>
>

Re: [Pharo-dev] Roadmap for Pharo 8.0

[Alistair Grant]

Hi Esteban,

On Thu, 7 Feb 2019 at 16:09, Esteban Lorenzano  wrote:
>
> 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".

Is there somewhere I can read more about this?

(I'm not disagreeing, just interested in what it means).

Thanks,
Alistair

[Pharo-dev] Roadmap for Pharo 8.0

[Esteban Lorenzano]

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?