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) 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. 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
Rick Kitts wrote
Iâm futzing about with the Duration class... itâs really easy to crash Pharo if I break that class
Yes, it can be frustrating to work in the deep innards ;) Rick Kitts wrote
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
I'm assuming that it doesn't work because when you delete the original, you break the image. How about this modification: copy, modify, fileout, in text editor change all references to MyCopiedDuration to Duration, file back in. Not sure if that would work, but that'd be my next attempt - working directly on the kernel classes usually sucks enough to get creative. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Advice-for-a-newb-tp4759632p4759634.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Rick, Change sets and changes file will save you no matter how you crash your image. Saving your image after development is dangerous, I donât recommend it. What I do is make a change set. Iâll develop and then when Iâm ready to start testing Iâll file it out. Iâll do some testing blow up develop more. If I forget to file out the change set the changes file is your friend. World menu -> changes⦠-> recently logged changes ⦠will give you a nice list of the last things you did. Itâs quite easy to filter out stuff and get a nice list of changes, and file them in. It is very hard to lose code. When you get to a good point and want to save your state always start from your last saved image. Load your change set, save your changes to Monticello, or your own favorite repo. Exit, load your changes from your repo, clean your image and save. Now your recently logged changes will have another nice clean entry. Rinse and repeat. Hope that helps. All the best, Ron Teitelbaum Head Of Engineering 3d Immersive Collaboration Consulting ron@3dicc.com Follow Me On Twitter: @RonTeitelbaum <https://twitter.com/RonTeitelbaum> www.3dicc.com <http://www.3dicc.com/> https://www.google.com/+3dicc From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Rick Kitts Sent: Monday, May 19, 2014 10:41 PM To: Pharo Development List Subject: [Pharo-dev] Advice for a newb 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) 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. 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
Thanks for the advice. I have spent some quality time with Monticello. In the end Iâve made a copy of Duration and DurationTest and Iâm working on that. Iâm not doing the image juggling you describe below however. I donât really understand why that workflow is worth the cost so Iâll just keep getting closer to the stove until I get burned. Iâll (probably) learn then. âRick On May 19, 2014 at 8:53:10 PM, Ron Teitelbaum (ron@usmedrec.com) wrote: Hi Rick,  Change sets and changes file will save you no matter how you crash your image. Saving your image after development is dangerous, I donât recommend it.  What I do is make a change set. Iâll develop and then when Iâm ready to start testing Iâll file it out. Iâll do some testing blow up develop more. If I forget to file out the change set the changes file is your friend.   World menu -> changes⦠-> recently logged changes ⦠will give you a nice list of the last things you did. Itâs quite easy to filter out stuff and get a nice list of changes, and file them in. It is very hard to lose code.  When you get to a good point and want to save your state always start from your last saved image. Load your change set, save your changes to Monticello, or your own favorite repo. Exit, load your changes from your repo, clean your image and save. Now your recently logged changes will have another nice clean entry. Rinse and repeat.  Hope that helps.  All the best,  Ron Teitelbaum Head Of Engineering 3d Immersive Collaboration Consulting ron@3dicc.com Follow Me On Twitter: @RonTeitelbaum www.3dicc.com https://www.google.com/+3dicc    From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Rick Kitts Sent: Monday, May 19, 2014 10:41 PM To: Pharo Development List Subject: [Pharo-dev] Advice for a newb  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) 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.  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 Â
Hi Rick, Actually that makes sense. The change set dance and the changes file for recovering code after a crash are really about keeping your repo clean. Itâs helpful for larger groups of developers that donât want to have to track everything you do that doesnât work J. It also prevents people from loading code that breaks the system. For me I only post my final work to the repo. You can also do that with Monticello using the local cache. Then you only post to the main repo by merging your versions into the trunk and releasing those. It just takes longer than using a change set. Monticello also has a config map but still you have to version every package and then load all of your packages again at startup. With the change set itâs file out, restart, file in. Good luck with it! All the best, Ron Teitelbaum From: Rick Kitts [mailto:rkitts@loudhouse.org] Sent: Tuesday, May 20, 2014 11:45 PM To: Pharo Development List; Ron Teitelbaum Subject: Re: [Pharo-dev] Advice for a newb Thanks for the advice. I have spent some quality time with Monticello. In the end Iâve made a copy of Duration and DurationTest and Iâm working on that. Iâm not doing the image juggling you describe below however. I donât really understand why that workflow is worth the cost so Iâll just keep getting closer to the stove until I get burned. Iâll (probably) learn then. âRick On May 19, 2014 at 8:53:10 PM, Ron Teitelbaum (ron@usmedrec.com) wrote: Hi Rick, Change sets and changes file will save you no matter how you crash your image. Saving your image after development is dangerous, I donât recommend it. What I do is make a change set. Iâll develop and then when Iâm ready to start testing Iâll file it out. Iâll do some testing blow up develop more. If I forget to file out the change set the changes file is your friend. World menu -> changes⦠-> recently logged changes ⦠will give you a nice list of the last things you did. Itâs quite easy to filter out stuff and get a nice list of changes, and file them in. It is very hard to lose code. When you get to a good point and want to save your state always start from your last saved image. Load your change set, save your changes to Monticello, or your own favorite repo. Exit, load your changes from your repo, clean your image and save. Now your recently logged changes will have another nice clean entry. Rinse and repeat. Hope that helps. All the best, Ron Teitelbaum Head Of Engineering 3d Immersive Collaboration Consulting ron@3dicc.com Follow Me On Twitter: @RonTeitelbaum <https://twitter.com/RonTeitelbaum> www.3dicc.com <http://www.3dicc.com/> https://www.google.com/+3dicc From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Rick Kitts Sent: Monday, May 19, 2014 10:41 PM To: Pharo Development List Subject: [Pharo-dev] Advice for a newb 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) 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. 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
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. 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
On Fri, May 23, 2014 at 12:47 PM, stepharo <stepharo@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
On Fri, May 23, 2014 at 02:30:36PM -0700, Eliot Miranda wrote:
On Fri, May 23, 2014 at 12:47 PM, stepharo <stepharo@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.
Indeed, the Squeak update stream is wonderful. I remember being initially worried that MC was too heavyweight to use as a replacement for the change set update stream. But I was wrong, it works very well and also brings the benefits of Monticello versioning along for the ride. It's not just good in theory, either. In practice, I'm usually using a trunk image, and I am in the habit of doing regular updates from the trunk stream to make sure I am in sync. It works very well and problems are rare. This is an interesting contrast with the work flows that I see discussed on the Pharo list. There, the emphasis seems to be more on the code, so the idea seems to be to build images that developers will open as fresh environments into which they will load their code. The working images are treated as transient artifacts, with the code living in Monticello or git repositories. It's a perfectly valid approach, and it might well be preferred for large project teams doing coordinated development. For me personally, I tend to look at things the other way around. It took me a long time to unlearn some habits from C and Fortran and sccs and such. But finally I more or less got the hang of it, and I am now quite comfortable working within a living image and using the source code tools to take care of the source code. The thing that really makes this work for me is the update stream. That is what makes it effortless to maintain a working image, while still keeping fully in sync with the latest community updates. Dave
Hi I ***know*** remember that I was the guy that pushed the use of MC to manage 3.9. still there are some cases were MC does not work. Stef
On Fri, May 23, 2014 at 11:11 PM, stepharo <stepharo@free.fr> wrote:
Hi
I ***know*** remember that I was the guy that pushed the use of MC to manage 3.9. still there are some cases were MC does not work.
and those would be? Are you sure that it is MC to blame? If one *doesn't* install an update when making a change one can of course break the system. But that isn't MC's fault. That is the author of the change failing to deliver it appropriately, a mistake I suspect everyone whose made major changes to critical Smalltalk infrastructure has made at some point. Stef
-- best, Eliot
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.
Yes
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. Yes but it depends which changes he is doing. Imagine a change that break MC.
Stef
On Fri, May 23, 2014 at 11:12 PM, stepharo <stepharo@free.fr> wrote:
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.
Yes
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.
Yes but it depends which changes he is doing. Imagine a change that break MC.
If it is possible to make the change in the image it is possible to make it in MC. One can always order the changes into a set of package versions that can be loaded, even if each package modifies only one method. One has the post-load script as a place to change things after snapshot manipulation, etc. I don't believe that MC can't operate on itself. We do this constantly in Squeak trunk. We have yet to break MC such that it can't be updated. -- best, Eliot
And by coincidence... On Sat, May 24, 2014 at 3:05 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Fri, May 23, 2014 at 11:12 PM, stepharo <stepharo@free.fr> wrote:
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.
Yes
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.
Yes but it depends which changes he is doing. Imagine a change that break MC.
If it is possible to make the change in the image it is possible to make it in MC. One can always order the changes into a set of package versions that can be loaded, even if each package modifies only one method. One has the post-load script as a place to change things after snapshot manipulation, etc. I don't believe that MC can't operate on itself. We do this constantly in Squeak trunk. We have yet to break MC such that it can't be updated.
Here is a case where MC has been broken (but please read down to the end): ---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Date: Sat, May 24, 2014 at 3:06 PM Subject: [squeak-dev] Re: What's up on build.squeak.org To: The general-purpose Squeak developers list < squeak-dev@lists.squeakfoundation.org> Ah, no, the build is still failing! Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem with: MCClassDefinition>>createClass I encountered this one while updating some of my old trunk images. The definition changed in Monticello-cwp.589: + inEnvironment: (CurrentEnvironment signal ifNil: [superClass environment]) - inEnvironment: (EnvironmentRequest signal ifNil: [superClass environment]) But there is no EnvironmentRequest anymore when loading this definition, so we signal nil, and the load fails. We would have expected this, it's just be renamed in: Environments-cwp.47 Time: 22 March 2014, 7:53:17.666 pm Rename EnvironmentRequest to CurrentEnvironment and use it to implement Environment class>>current. To be safe, the rename should have been performed in two stages: 1) create the new class and migrate customers from the old to the new one. 2) remove the old one It would thus have required two updates.mcm and not a single one (MC lacks a semantic #rename: so it does not work like in-image-tools) Unfortunately, update-cwp.48 did perform the two operations at once... Curiously, if I take an artefact from build server and update, the upgrade is then processing fine... Don't ask why. Since no one complained, I told to myself that it was me not following the standard process, I patched my images manually and restarted the upgrade. But I now see that it's not just me, there is a CI machine too using Squeak trunk (anyone else???) I have to cheat again with mcm surgery: - publish an Environments-nice.47 that adds the CurrentEnvironment, but not removes EnvironmentRequest - patch update-cwp.48 to point to Environments-nice.47 rather than Environments-cwp.47 That'll be in a few minutes... ----------End Forwarded message ---------- so the fix is.... package versions and updates. Yet another thing one can do is edit updates after the fact. Very powerful. So here is a case where a broken MC update is fixed after the fact. (and thank you Nicolas!) 2014-05-24 22:58 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2014-05-24 22:36 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Hi,
it seems that most of the builds are red for 2 months. I checked the last artefact for squeak trunk: http://build.squeak.org/job/SqueakTrunk/853/
It's still blocked with the [Warning signal: 'About to serialize an empty package.'] With this warning, a test never time out (I don't know why exactly, but it seems that theProcess monitored by the timeout watchdog is already suspended by the Warning) As a result, the tests do never complete and are aborted after 20 minutes...
Chris has fixed the problem since, but it seems that the CI does not upload latest trunk. Why? It seems to be the same problem as the TestRunner: updating triggers the same [Warning signal: 'About to serialize an empty package.'] Ah Chris, it's irony that it's you who precisely keep on fighting modal UI ;)
Now the question: how do we escape from this situation? Shall I cheat and modify the update that is blocking?
So I decided to cheat: I brought update-eem.279 to the surgery block and reverted CommandLine-fbs.3 -> CommandLine-fbs.2 CommandLine-fbs.3 tried to be smart and workaround the Warning problem, but before it had a chance to load, it precisely triggered this Warning!!! Since this update is also bringing Chris fix, let's defer CommandLine-fbs.3 to next update (eem-280) and cross fingers...
-- best, Eliot
2014-05-25 0:11 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
And by coincidence...
On Sat, May 24, 2014 at 3:05 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, May 23, 2014 at 11:12 PM, stepharo <stepharo@free.fr> wrote:
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.
Yes
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.
Yes but it depends which changes he is doing. Imagine a change that break MC.
If it is possible to make the change in the image it is possible to make it in MC. One can always order the changes into a set of package versions that can be loaded, even if each package modifies only one method. One has the post-load script as a place to change things after snapshot manipulation, etc. I don't believe that MC can't operate on itself. We do this constantly in Squeak trunk. We have yet to break MC such that it can't be updated.
Here is a case where MC has been broken (but please read down to the end):
Yep, I completely agree with what Eliot and David said. I value the update-stream very much, and I think it's a mistake to abandon such a golden feature. An image is not just made of code... Even in case we just use it for coding, some code is too experimental to be shared, too tiny to be published (it means maintaining many feature branches) but too valuable to throw away. For me, the best place for those is experiments is in image: - Because I have the right tools to list/find/browse those experiments, I don't want to store them in a file somewhere then forget about them. - Because I have the right tools to maintain those experiments up to date with trunk, I don't want them to rot somewhere on a hard disk. - Because I don't need to deal with load order again and again (I'm often messing with Kernel things), the discipline for building a reloadable configuration for a bunch of small things is not sustainable and has no value as long as it's just for myself. But as we can see, the update stream is not working magically. One has to put his hands in those configurations from time to time. Pharo is using a descendant of Squeak3.9 process rather than mcm, but the problem is more or less the same. It takes time to do it right... And I suspect that the official procedure aimed at making the process repeatable is bypassed sometimes. Because Pharo users value the "throw and rebuild your image" paradigm, the upgrade just has to succeed once, and it does not really matters if the team cheated, as long as they deliver fast. When the image will be truly rebuilt from scratch, this will be even less of a problem anyway. I've been upset (and frustrated) many times when wanting to use Pharo update stream, but now I take it as it is, I can perfectly understand that it's not a priority. My Pharo images are throwaway. Anyway, I experiment in Squeak.
---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Date: Sat, May 24, 2014 at 3:06 PM Subject: [squeak-dev] Re: What's up on build.squeak.org To: The general-purpose Squeak developers list < squeak-dev@lists.squeakfoundation.org>
Ah, no, the build is still failing! Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem with:
MCClassDefinition>>createClass
I encountered this one while updating some of my old trunk images. The definition changed in Monticello-cwp.589: + inEnvironment: (CurrentEnvironment signal ifNil: [superClass environment]) - inEnvironment: (EnvironmentRequest signal ifNil: [superClass environment])
But there is no EnvironmentRequest anymore when loading this definition, so we signal nil, and the load fails. We would have expected this, it's just be renamed in:
Environments-cwp.47 Time: 22 March 2014, 7:53:17.666 pm Rename EnvironmentRequest to CurrentEnvironment and use it to implement Environment class>>current.
To be safe, the rename should have been performed in two stages: 1) create the new class and migrate customers from the old to the new one. 2) remove the old one It would thus have required two updates.mcm and not a single one (MC lacks a semantic #rename: so it does not work like in-image-tools) Unfortunately, update-cwp.48 did perform the two operations at once...
Curiously, if I take an artefact from build server and update, the upgrade is then processing fine... Don't ask why. Since no one complained, I told to myself that it was me not following the standard process, I patched my images manually and restarted the upgrade. But I now see that it's not just me, there is a CI machine too using Squeak trunk (anyone else???)
I have to cheat again with mcm surgery: - publish an Environments-nice.47 that adds the CurrentEnvironment, but not removes EnvironmentRequest - patch update-cwp.48 to point to Environments-nice.47 rather than Environments-cwp.47 That'll be in a few minutes... ----------End Forwarded message ----------
so the fix is.... package versions and updates. Yet another thing one can do is edit updates after the fact. Very powerful. So here is a case where a broken MC update is fixed after the fact. (and thank you Nicolas!)
2014-05-24 22:58 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2014-05-24 22:36 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Hi,
it seems that most of the builds are red for 2 months. I checked the last artefact for squeak trunk: http://build.squeak.org/job/SqueakTrunk/853/
It's still blocked with the [Warning signal: 'About to serialize an empty package.'] With this warning, a test never time out (I don't know why exactly, but it seems that theProcess monitored by the timeout watchdog is already suspended by the Warning) As a result, the tests do never complete and are aborted after 20 minutes...
Chris has fixed the problem since, but it seems that the CI does not upload latest trunk. Why? It seems to be the same problem as the TestRunner: updating triggers the same [Warning signal: 'About to serialize an empty package.'] Ah Chris, it's irony that it's you who precisely keep on fighting modal UI ;)
Now the question: how do we escape from this situation? Shall I cheat and modify the update that is blocking?
So I decided to cheat: I brought update-eem.279 to the surgery block and reverted CommandLine-fbs.3 -> CommandLine-fbs.2 CommandLine-fbs.3 tried to be smart and workaround the Warning problem, but before it had a chance to load, it precisely triggered this Warning!!! Since this update is also bringing Chris fix, let's defer CommandLine-fbs.3 to next update (eem-280) and cross fingers...
-- best, Eliot
participants (7)
-
David T. Lewis -
Eliot Miranda -
Nicolas Cellier -
Rick Kitts -
Ron Teitelbaum -
Sean P. DeNigris -
stepharo