;)
We will get there. I want live update V2.0 for real.
On Tue, Dec 26, 2017 at 11:36 PM, Nicolas Cellier
<[email protected]> wrote:
>
>
> 2017-12-25 23:54 GMT+01:00 Ben Coman <[email protected]>:
>>
>> 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 <[email protected]>
>> 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
>>> <[email protected]> wrote:
>>> >
>>> >
>>> > 2017-12-24 2:59 GMT+01:00 Alexandre Bergel <[email protected]>:
>>> >>
>>> >> 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 <[email protected]>
>>> >> > 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
>>> >>
>>> >>
>>> >
>>>
>>
>
