On Fri, May 23, 2014 at 12:47 PM, stepharo <stepharo at free.fr> wrote:

>
> On 20/5/14 04:41, Rick Kitts wrote:
>
> Hello. I was wondering if anyone could point me to or otherwise suggest
> some best practices for working on Kernel code. I’m futzing about with the
> Duration class (in the interest of fixing 13215)
>
> Thanks!
>
>  and have discovered that it’s really easy to crash Pharo if I break that
> class. I assume there are other classes that would exhibit the same
> behavior.
>
> Yes like Array or OrderedCollection.
>
> We are working on a bootstrap of pharo and it could help for brain surgery
> (but in that case the system may simply not build at all).
> So the suggestion of Ron to use ChangeSet is a good one.
>

But it is also possible to do it with Monticello, using "updates", which
are really baseline versions of a package.   The idea is to make the
necessary changes that support your next, potentially suicidal step, commit
a baseline for that support, and then commit the change that depends on the
support.  The Monticello update scheme ensures that the baseline is loaded
before your second commit.  This process can be repeated as many times as
necessary to make a sequence of interdependent changes happen in order.

For example, I've just added multiple bytecode support to Squeak trunk.
 That needed some code on Squeak's BytecodeEncoder and subclasses, which
are in the Compiler package, *before* loading the Kernel code that depended
on that BytecodeEncoder support.  If things don't happen in the right order
the compiler, debugger, and tool facilities such as references &
assignments would break.

By all means use the change list for crash recovery, or even change sets.
 But unlike change sets, Monticello's updates provide support for any
number of steps.  Typically with a change set you have to manually reorder
things.  I've used change sets a lot in the past to pull off a number of
"adventurous" system changes.  But now I'm familiar with Monticello it
feels like its by far the best way.


>
> Now once I got change that crash (just a tight endless loop) as soon as
> you change anything and there you have to rollback and turn around the self
> referencing aspect.
>
>
>  I suppose I could just be really cautious and save my image after every
> change but that seems so error prone that I’m hoping that there are
> idiomatic ways of working on kernel code (beyond just save ones image early
> and often) so I don’t lose work. I’m asking because the naive solution
> (copy the original class, modify it to suit, delete the original and rename
> the new class to the original) of course doesn’t work.
>
>  TIA for any suggestions or assistance and apologies in advance if this
> is RTFM, I didn’t see anything (didn’t look very hard either though).
>
>  —Rick
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140523/65d2d4e3/attachment.htm