How to restore image upgrade? was New Year Wishlist (2018) ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

How to restore image upgrade? was New Year Wishlist (2018) ?

Nicolas Cellier


2017-12-24 2:59 GMT+01:00 Alexandre Bergel <[hidden email]>:
My four wishes, in no particular order:
        - Better code completion
        - Git in Pharo as easy as using Git for other languages
The recipe is easy: turn pharo into a file based edit-compile-run language and expunge those live object burden ;)
Let me explain why it's not just trolling.
Currently we have to download an image made by a bot.
Pharo has gradually lost the power to upgrade the image (it's not new).

If we recognize that an image acts like a workspace, and want to let the pull/branch switch/etc work again...
IOW going from one point to any other in source code graph
and experience the full power of git like any other language,
that means, in a live IDE, at least solving those two problems:
- changing the tools that are used to upgrade the image (Compiler, MethodDictionary, Array, etc...)
- correctly initialize all the states (including stange loops)
If pharo has not managed to solve this with a linear one way history (the regularly broken update image option),
how do you think this is going to be solved in the more general case?
I call this the universal boostrap problem.

IMO the logical next step is to separate the IDE
(the Inanimate Desintegrated Environment of any other language).

Maybe we don't have to bend Pharo too much to git if it does not fit.
The goal: as easy might be not that easy.


        - Bloc on Steroid
        - Being able to interrupt any process and endless loop using Cmd-.

Merry Christmas to all of you!
Alexandre



> On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <[hidden email]> wrote:
>
> Hi everybody,
>
> This looks like a good moment of the year to ask all of you what would you want to see in Pharo next year.
> Features, improvements, radical changes, etc…. whatever you want.
>
> Of course, this list will not be a roadmap and it does not means we will implement all of it (as always, time drives our possibilities), but is a good moment for us a a community to check where we are and where we wan to go next :)
>
> So, let’s those wishes come!
>
> cheers,
> Esteban



Reply | Threaded
Open this post in threaded view
|

Re: How to restore image upgrade? was New Year Wishlist (2018) ?

Stephane Ducasse-3
Nicolas

We want to keep the live part of Pharo and incremental loading and it
is key for us. Now we should not be naive.
Most of the time we do not have the garantee that a change will work
when loaded.

We proposed Pablo to work since two years on a really working dynamic
code loader and
Pablo has really nice results. But it takes time to evaluate if/how we
integrate its changes.
Pablo has an atomic coder loader and an incremental and modular class builder.
He also designed a modular shutdown/startup list manager (in production).

We want to be able to have a **real** and robust incremental load.
Right now as you know it and as in ANY smalltalk I can break the
system super easily.
There is no magic. I do not see how we can make sure that any piece of
code will be loaded
and do not break the system.
So our objective is to have a new infrastructure that we can updates
(like method hashes for example without having to
twists our mind and do five updates).

Now about git, we want and we will have our lovely image as a working
directory but this requires engineering
because the image is another artefact that other languages do not have
to worry.
We will get there.

Stef


On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier
<[hidden email]> wrote:

>
>
> 2017-12-24 2:59 GMT+01:00 Alexandre Bergel <[hidden email]>:
>>
>> My four wishes, in no particular order:
>>         - Better code completion
>>         - Git in Pharo as easy as using Git for other languages
>
> The recipe is easy: turn pharo into a file based edit-compile-run language
> and expunge those live object burden ;)
> Let me explain why it's not just trolling.
> Currently we have to download an image made by a bot.
> Pharo has gradually lost the power to upgrade the image (it's not new).
>
> If we recognize that an image acts like a workspace, and want to let the
> pull/branch switch/etc work again...
> IOW going from one point to any other in source code graph
> and experience the full power of git like any other language,
> that means, in a live IDE, at least solving those two problems:
> - changing the tools that are used to upgrade the image (Compiler,
> MethodDictionary, Array, etc...)
> - correctly initialize all the states (including stange loops)
> If pharo has not managed to solve this with a linear one way history (the
> regularly broken update image option),
> how do you think this is going to be solved in the more general case?
> I call this the universal boostrap problem.
>
> IMO the logical next step is to separate the IDE
> (the Inanimate Desintegrated Environment of any other language).
>
> Maybe we don't have to bend Pharo too much to git if it does not fit.
> The goal: as easy might be not that easy.
>
>
>>         - Bloc on Steroid
>>         - Being able to interrupt any process and endless loop using Cmd-.
>>
>> Merry Christmas to all of you!
>> Alexandre
>>
>>
>>
>> > On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <[hidden email]>
>> > wrote:
>> >
>> > Hi everybody,
>> >
>> > This looks like a good moment of the year to ask all of you what would
>> > you want to see in Pharo next year.
>> > Features, improvements, radical changes, etc…. whatever you want.
>> >
>> > Of course, this list will not be a roadmap and it does not means we will
>> > implement all of it (as always, time drives our possibilities), but is a
>> > good moment for us a a community to check where we are and where we wan to
>> > go next :)
>> >
>> > So, let’s those wishes come!
>> >
>> > cheers,
>> > Esteban
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: How to restore image upgrade? was New Year Wishlist (2018) ?

Ben Coman
As a half-way house, consider that "upgrade" scripts could be a good mechanism 
post-Release when changes should be less-deep/less-arduous on the system.
This might avoid Esteban's time being needed to re-Release for each upgrade,
with post-Release moving to a more community supported mechanism.
This could scale better as we gain more users interested in long term support
of their applications on a stable-release than the moving target of the development-edge.

cheers -ben

On 25 December 2017 at 23:11, Stephane Ducasse <[hidden email]> wrote:
Nicolas

We want to keep the live part of Pharo and incremental loading and it
is key for us. Now we should not be naive.
Most of the time we do not have the garantee that a change will work
when loaded.

We proposed Pablo to work since two years on a really working dynamic
code loader and
Pablo has really nice results. But it takes time to evaluate if/how we
integrate its changes.
Pablo has an atomic coder loader and an incremental and modular class builder.
He also designed a modular shutdown/startup list manager (in production).

We want to be able to have a **real** and robust incremental load.
Right now as you know it and as in ANY smalltalk I can break the
system super easily.
There is no magic. I do not see how we can make sure that any piece of
code will be loaded
and do not break the system.
So our objective is to have a new infrastructure that we can updates
(like method hashes for example without having to
twists our mind and do five updates).

Now about git, we want and we will have our lovely image as a working
directory but this requires engineering
because the image is another artefact that other languages do not have
to worry.
We will get there.

Stef


On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier
<[hidden email]> wrote:
>
>
> 2017-12-24 2:59 GMT+01:00 Alexandre Bergel <[hidden email]>:
>>
>> My four wishes, in no particular order:
>>         - Better code completion
>>         - Git in Pharo as easy as using Git for other languages
>
> The recipe is easy: turn pharo into a file based edit-compile-run language
> and expunge those live object burden ;)
> Let me explain why it's not just trolling.
> Currently we have to download an image made by a bot.
> Pharo has gradually lost the power to upgrade the image (it's not new).
>
> If we recognize that an image acts like a workspace, and want to let the
> pull/branch switch/etc work again...
> IOW going from one point to any other in source code graph
> and experience the full power of git like any other language,
> that means, in a live IDE, at least solving those two problems:
> - changing the tools that are used to upgrade the image (Compiler,
> MethodDictionary, Array, etc...)
> - correctly initialize all the states (including stange loops)
> If pharo has not managed to solve this with a linear one way history (the
> regularly broken update image option),
> how do you think this is going to be solved in the more general case?
> I call this the universal boostrap problem.
>
> IMO the logical next step is to separate the IDE
> (the Inanimate Desintegrated Environment of any other language).
>
> Maybe we don't have to bend Pharo too much to git if it does not fit.
> The goal: as easy might be not that easy.
>
>
>>         - Bloc on Steroid
>>         - Being able to interrupt any process and endless loop using Cmd-.
>>
>> Merry Christmas to all of you!
>> Alexandre
>>
>>
>>
>> > On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <[hidden email]>
>> > wrote:
>> >
>> > Hi everybody,
>> >
>> > This looks like a good moment of the year to ask all of you what would
>> > you want to see in Pharo next year.
>> > Features, improvements, radical changes, etc…. whatever you want.
>> >
>> > Of course, this list will not be a roadmap and it does not means we will
>> > implement all of it (as always, time drives our possibilities), but is a
>> > good moment for us a a community to check where we are and where we wan to
>> > go next :)
>> >
>> > So, let’s those wishes come!
>> >
>> > cheers,
>> > Esteban
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: How to restore image upgrade? was New Year Wishlist (2018) ?

Nicolas Cellier


2017-12-25 23:54 GMT+01:00 Ben Coman <[hidden email]>:
As a half-way house, consider that "upgrade" scripts could be a good mechanism 
post-Release when changes should be less-deep/less-arduous on the system.
This might avoid Esteban's time being needed to re-Release for each upgrade,
with post-Release moving to a more community supported mechanism.
This could scale better as we gain more users interested in long term support
of their applications on a stable-release than the moving target of the development-edge.

cheers -ben

Hi Ben,
upgrade scripts is what is used by Squeak trunk (as available via Monticello).
it's difficult to write correctly, and difficult to test (clearly a job for a bot).
Every intermediate script has to be replayed (or not, but who knows?) and this is done via MonticelloConfigurationMap.
Can you imagine that transposed to git?

It's not reversible (we don't provide the reverse scripts).
It might fail due to specific changes in the image (let's say dirty workspace), and not only code changes.

So it's very very far from git smoothness.
Fortunately, those scripts are rarely needed (as a percentage of commits).
Unfortunately, they are regularly needed (several times a year).
Remind that Pharo is supposed to change Kernel classes a bit faster than Squeak ;)


On 25 December 2017 at 23:11, Stephane Ducasse <[hidden email]> wrote:
Nicolas

We want to keep the live part of Pharo and incremental loading and it
is key for us. Now we should not be naive.

Hi Steph,
Not every provocation deserves an answer ;)
I hope everyone here wants a lively thing, otherwise why use Pharo?
 
Most of the time we do not have the garantee that a change will work
when loaded.

We have bots passing tests for rejecting broken code.
But the problem is that correct code can also be rejected

We proposed Pablo to work since two years on a really working dynamic
code loader and
Pablo has really nice results. But it takes time to evaluate if/how we
integrate its changes.
Pablo has an atomic coder loader and an incremental and modular class builder.
He also designed a modular shutdown/startup list manager (in production).

Glad to ear that. I hope to read publications on this subject one day then.
Two years for nice intermediate results just confirms that the problem is very tough as we all know...

We want to be able to have a **real** and robust incremental load.
Right now as you know it and as in ANY smalltalk I can break the
system super easily.
There is no magic. I do not see how we can make sure that any piece of
code will be loaded
and do not break the system.
So our objective is to have a new infrastructure that we can updates
(like method hashes for example without having to
twists our mind and do five updates).

Now about git, we want and we will have our lovely image as a working
directory but this requires engineering
because the image is another artefact that other languages do not have
to worry.
We will get there.


Agree with all you said,

My point is that git is not going to help you solving the problems others don't have.
If we have seemless integration for bootstrap free code, that will already be something...
For the rest, it's a bit too much wishful thinking to my taste.
As said above, because bootstrap problems happen rarely, but regularly,
I can predict that pharo development won't be as smooth as dreamed of for some time.
We have to accept that and work hard to find acceptable trade offs.
I'm interested in seeing which solution will emerge.


Stef


On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier
<[hidden email]> wrote:
>
>
> 2017-12-24 2:59 GMT+01:00 Alexandre Bergel <[hidden email]>:
>>
>> My four wishes, in no particular order:
>>         - Better code completion
>>         - Git in Pharo as easy as using Git for other languages
>
> The recipe is easy: turn pharo into a file based edit-compile-run language
> and expunge those live object burden ;)
> Let me explain why it's not just trolling.
> Currently we have to download an image made by a bot.
> Pharo has gradually lost the power to upgrade the image (it's not new).
>
> If we recognize that an image acts like a workspace, and want to let the
> pull/branch switch/etc work again...
> IOW going from one point to any other in source code graph
> and experience the full power of git like any other language,
> that means, in a live IDE, at least solving those two problems:
> - changing the tools that are used to upgrade the image (Compiler,
> MethodDictionary, Array, etc...)
> - correctly initialize all the states (including stange loops)
> If pharo has not managed to solve this with a linear one way history (the
> regularly broken update image option),
> how do you think this is going to be solved in the more general case?
> I call this the universal boostrap problem.
>
> IMO the logical next step is to separate the IDE
> (the Inanimate Desintegrated Environment of any other language).
>
> Maybe we don't have to bend Pharo too much to git if it does not fit.
> The goal: as easy might be not that easy.
>
>
>>         - Bloc on Steroid
>>         - Being able to interrupt any process and endless loop using Cmd-.
>>
>> Merry Christmas to all of you!
>> Alexandre
>>
>>
>>
>> > On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <[hidden email]>
>> > wrote:
>> >
>> > Hi everybody,
>> >
>> > This looks like a good moment of the year to ask all of you what would
>> > you want to see in Pharo next year.
>> > Features, improvements, radical changes, etc…. whatever you want.
>> >
>> > Of course, this list will not be a roadmap and it does not means we will
>> > implement all of it (as always, time drives our possibilities), but is a
>> > good moment for us a a community to check where we are and where we wan to
>> > go next :)
>> >
>> > So, let’s those wishes come!
>> >
>> > cheers,
>> > Esteban
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: How to restore image upgrade? was New Year Wishlist (2018) ?

Stephane Ducasse-3
;)
We will get there. I want live update V2.0 for real.

On Tue, Dec 26, 2017 at 11:36 PM, Nicolas Cellier
<[hidden email]> wrote:

>
>
> 2017-12-25 23:54 GMT+01:00 Ben Coman <[hidden email]>:
>>
>> As a half-way house, consider that "upgrade" scripts could be a good
>> mechanism
>> post-Release when changes should be less-deep/less-arduous on the system.
>> This might avoid Esteban's time being needed to re-Release for each
>> upgrade,
>> with post-Release moving to a more community supported mechanism.
>> This could scale better as we gain more users interested in long term
>> support
>> of their applications on a stable-release than the moving target of the
>> development-edge.
>>
>> cheers -ben
>
>
> Hi Ben,
> upgrade scripts is what is used by Squeak trunk (as available via
> Monticello).
> it's difficult to write correctly, and difficult to test (clearly a job for
> a bot).
> Every intermediate script has to be replayed (or not, but who knows?) and
> this is done via MonticelloConfigurationMap.
> Can you imagine that transposed to git?
>
> It's not reversible (we don't provide the reverse scripts).
> It might fail due to specific changes in the image (let's say dirty
> workspace), and not only code changes.
>
> So it's very very far from git smoothness.
> Fortunately, those scripts are rarely needed (as a percentage of commits).
> Unfortunately, they are regularly needed (several times a year).
> Remind that Pharo is supposed to change Kernel classes a bit faster than
> Squeak ;)
>
>>
>> On 25 December 2017 at 23:11, Stephane Ducasse <[hidden email]>
>> wrote:
>>>
>>> Nicolas
>>>
>>> We want to keep the live part of Pharo and incremental loading and it
>>> is key for us. Now we should not be naive.
>
>
> Hi Steph,
> Not every provocation deserves an answer ;)
> I hope everyone here wants a lively thing, otherwise why use Pharo?
>
>>>
>>> Most of the time we do not have the garantee that a change will work
>>> when loaded.
>>>
> We have bots passing tests for rejecting broken code.
> But the problem is that correct code can also be rejected
>
>>> We proposed Pablo to work since two years on a really working dynamic
>>> code loader and
>>> Pablo has really nice results. But it takes time to evaluate if/how we
>>> integrate its changes.
>>> Pablo has an atomic coder loader and an incremental and modular class
>>> builder.
>>> He also designed a modular shutdown/startup list manager (in production).
>>>
> Glad to ear that. I hope to read publications on this subject one day then.
> Two years for nice intermediate results just confirms that the problem is
> very tough as we all know...
>
>>> We want to be able to have a **real** and robust incremental load.
>>> Right now as you know it and as in ANY smalltalk I can break the
>>> system super easily.
>>> There is no magic. I do not see how we can make sure that any piece of
>>> code will be loaded
>>> and do not break the system.
>>> So our objective is to have a new infrastructure that we can updates
>>> (like method hashes for example without having to
>>> twists our mind and do five updates).
>>>
>>> Now about git, we want and we will have our lovely image as a working
>>> directory but this requires engineering
>>> because the image is another artefact that other languages do not have
>>> to worry.
>>> We will get there.
>>>
>
> Agree with all you said,
>
> My point is that git is not going to help you solving the problems others
> don't have.
> If we have seemless integration for bootstrap free code, that will already
> be something...
> For the rest, it's a bit too much wishful thinking to my taste.
> As said above, because bootstrap problems happen rarely, but regularly,
> I can predict that pharo development won't be as smooth as dreamed of for
> some time.
> We have to accept that and work hard to find acceptable trade offs.
> I'm interested in seeing which solution will emerge.
>
>
>>> Stef
>>>
>>>
>>> On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier
>>> <[hidden email]> wrote:
>>> >
>>> >
>>> > 2017-12-24 2:59 GMT+01:00 Alexandre Bergel <[hidden email]>:
>>> >>
>>> >> My four wishes, in no particular order:
>>> >>         - Better code completion
>>> >>         - Git in Pharo as easy as using Git for other languages
>>> >
>>> > The recipe is easy: turn pharo into a file based edit-compile-run
>>> > language
>>> > and expunge those live object burden ;)
>>> > Let me explain why it's not just trolling.
>>> > Currently we have to download an image made by a bot.
>>> > Pharo has gradually lost the power to upgrade the image (it's not new).
>>> >
>>> > If we recognize that an image acts like a workspace, and want to let
>>> > the
>>> > pull/branch switch/etc work again...
>>> > IOW going from one point to any other in source code graph
>>> > and experience the full power of git like any other language,
>>> > that means, in a live IDE, at least solving those two problems:
>>> > - changing the tools that are used to upgrade the image (Compiler,
>>> > MethodDictionary, Array, etc...)
>>> > - correctly initialize all the states (including stange loops)
>>> > If pharo has not managed to solve this with a linear one way history
>>> > (the
>>> > regularly broken update image option),
>>> > how do you think this is going to be solved in the more general case?
>>> > I call this the universal boostrap problem.
>>> >
>>> > IMO the logical next step is to separate the IDE
>>> > (the Inanimate Desintegrated Environment of any other language).
>>> >
>>> > Maybe we don't have to bend Pharo too much to git if it does not fit.
>>> > The goal: as easy might be not that easy.
>>> >
>>> >
>>> >>         - Bloc on Steroid
>>> >>         - Being able to interrupt any process and endless loop using
>>> >> Cmd-.
>>> >>
>>> >> Merry Christmas to all of you!
>>> >> Alexandre
>>> >>
>>> >>
>>> >>
>>> >> > On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <[hidden email]>
>>> >> > wrote:
>>> >> >
>>> >> > Hi everybody,
>>> >> >
>>> >> > This looks like a good moment of the year to ask all of you what
>>> >> > would
>>> >> > you want to see in Pharo next year.
>>> >> > Features, improvements, radical changes, etc…. whatever you want.
>>> >> >
>>> >> > Of course, this list will not be a roadmap and it does not means we
>>> >> > will
>>> >> > implement all of it (as always, time drives our possibilities), but
>>> >> > is a
>>> >> > good moment for us a a community to check where we are and where we
>>> >> > wan to
>>> >> > go next :)
>>> >> >
>>> >> > So, let’s those wishes come!
>>> >> >
>>> >> > cheers,
>>> >> > Esteban
>>> >>
>>> >>
>>> >
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: How to restore image upgrade? was New Year Wishlist (2018) ?

Guillermo Polito
In reply to this post by Nicolas Cellier


On Tue, Dec 26, 2017 at 11:36 PM, Nicolas Cellier <[hidden email]> wrote:


2017-12-25 23:54 GMT+01:00 Ben Coman <[hidden email]>:
As a half-way house, consider that "upgrade" scripts could be a good mechanism 
post-Release when changes should be less-deep/less-arduous on the system.
This might avoid Esteban's time being needed to re-Release for each upgrade,
with post-Release moving to a more community supported mechanism.
This could scale better as we gain more users interested in long term support
of their applications on a stable-release than the moving target of the development-edge.

cheers -ben

Hi Ben,
upgrade scripts is what is used by Squeak trunk (as available via Monticello).
it's difficult to write correctly, and difficult to test (clearly a job for a bot).
Every intermediate script has to be replayed (or not, but who knows?) and this is done via MonticelloConfigurationMap.
Can you imagine that transposed to git?

It's not reversible (we don't provide the reverse scripts).
It might fail due to specific changes in the image (let's say dirty workspace), and not only code changes.

So it's very very far from git smoothness.
Fortunately, those scripts are rarely needed (as a percentage of commits).
Unfortunately, they are regularly needed (several times a year).
Remind that Pharo is supposed to change Kernel classes a bit faster than Squeak ;)


On 25 December 2017 at 23:11, Stephane Ducasse <[hidden email]> wrote:
Nicolas

We want to keep the live part of Pharo and incremental loading and it
is key for us. Now we should not be naive.

Hi Steph,
Not every provocation deserves an answer ;)
I hope everyone here wants a lively thing, otherwise why use Pharo?
 
Most of the time we do not have the garantee that a change will work
when loaded.

We have bots passing tests for rejecting broken code.
But the problem is that correct code can also be rejected

We proposed Pablo to work since two years on a really working dynamic
code loader and
Pablo has really nice results. But it takes time to evaluate if/how we
integrate its changes.
Pablo has an atomic coder loader and an incremental and modular class builder.
He also designed a modular shutdown/startup list manager (in production).

Glad to ear that. I hope to read publications on this subject one day then.
Two years for nice intermediate results just confirms that the problem is very tough as we all know...

We want to be able to have a **real** and robust incremental load.
Right now as you know it and as in ANY smalltalk I can break the
system super easily.
There is no magic. I do not see how we can make sure that any piece of
code will be loaded
and do not break the system.
So our objective is to have a new infrastructure that we can updates
(like method hashes for example without having to
twists our mind and do five updates).

Now about git, we want and we will have our lovely image as a working
directory but this requires engineering
because the image is another artefact that other languages do not have
to worry.
We will get there.


Agree with all you said,

My point is that git is not going to help you solving the problems others don't have.
If we have seemless integration for bootstrap free code, that will already be something...
For the rest, it's a bit too much wishful thinking to my taste.
As said above, because bootstrap problems happen rarely, but regularly,
I can predict that pharo development won't be as smooth as dreamed of for some time.
We have to accept that and work hard to find acceptable trade offs.
I'm interested in seeing which solution will emerge.

In any case, the problem of updating pharo itself is a problem we have had for some time.
And it is not specific to git and it is even shared with monticello.

We lack of an atomic update with (a) object migration rules and (b) correct suspension of processes to avoid stack corruption.
That is really difficult to make explicit manually in a script.
 


Stef


On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier
<[hidden email]> wrote:
>
>
> 2017-12-24 2:59 GMT+01:00 Alexandre Bergel <[hidden email]>:
>>
>> My four wishes, in no particular order:
>>         - Better code completion
>>         - Git in Pharo as easy as using Git for other languages
>
> The recipe is easy: turn pharo into a file based edit-compile-run language
> and expunge those live object burden ;)
> Let me explain why it's not just trolling.
> Currently we have to download an image made by a bot.
> Pharo has gradually lost the power to upgrade the image (it's not new).
>
> If we recognize that an image acts like a workspace, and want to let the
> pull/branch switch/etc work again...
> IOW going from one point to any other in source code graph
> and experience the full power of git like any other language,
> that means, in a live IDE, at least solving those two problems:
> - changing the tools that are used to upgrade the image (Compiler,
> MethodDictionary, Array, etc...)
> - correctly initialize all the states (including stange loops)
> If pharo has not managed to solve this with a linear one way history (the
> regularly broken update image option),
> how do you think this is going to be solved in the more general case?
> I call this the universal boostrap problem.
>
> IMO the logical next step is to separate the IDE
> (the Inanimate Desintegrated Environment of any other language).
>
> Maybe we don't have to bend Pharo too much to git if it does not fit.
> The goal: as easy might be not that easy.
>
>
>>         - Bloc on Steroid
>>         - Being able to interrupt any process and endless loop using Cmd-.
>>
>> Merry Christmas to all of you!
>> Alexandre
>>
>>
>>
>> > On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <[hidden email]>
>> > wrote:
>> >
>> > Hi everybody,
>> >
>> > This looks like a good moment of the year to ask all of you what would
>> > you want to see in Pharo next year.
>> > Features, improvements, radical changes, etc…. whatever you want.
>> >
>> > Of course, this list will not be a roadmap and it does not means we will
>> > implement all of it (as always, time drives our possibilities), but is a
>> > good moment for us a a community to check where we are and where we wan to
>> > go next :)
>> >
>> > So, let’s those wishes come!
>> >
>> > cheers,
>> > Esteban
>>
>>
>






--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13