On 17 September 2013 08:40, Frank Shearar <[hidden email]> wrote:
> I really do need to take the time to look at that guy... So I should, for the moment, just need to catch the PIEs to log? I tried that but maybe I did it wrong. I'll take another run at it. We definitely do need a command line processor in trunk, at any rate. Loads of the CI work is working around our lack thereof. Well, I haven't managed to log updates, but I _have_ finally managed to fix the CI update scripts. A merge conflict caused an MCMergeBrowser to pop up and halt the world. CI assumed the task had hung (which it had, effectively), and hilarity ensued. http://build.squeak.org/job/SqueakTrunk/532/console shows a properly working update. (I have no idea where all those empty lines are coming from... unless they're progress indications?? Could be!) The script didn't just bail because an MCMergeResolutionRequest has a #defaultAction (to bring up the dialog). Since the script doesn't catch that exception, the #defaultAction triggers, popping up the dialog. Without having thought it through, one possible solution is to _never_ create dialogs directly, but always through ToolSet. (So Monticello would extend ToolSet's API, for instance.) That way, a CommandLineToolSet could bail with a decent error message, while (in this case) the StandardToolSet could pop up a MCMergeBrowser. frank |
On 20 September 2013 12:29, Frank Shearar <[hidden email]> wrote:
> On 17 September 2013 08:40, Frank Shearar <[hidden email]> wrote: > (I have no idea where all those empty lines are coming > from... unless they're progress indications?? Could be!) They are! ProgressInitiationExceptions don't have useful messageTexts though, so I hacked in logging "e instVarNamed: 'progressTitle'", which now gives much better output: Downloading Graphics-tpr.225(fbs.221).mcd Downloading Balloon-eem.23(fbs.22).mcd and so on! frank |
In reply to this post by Frank Shearar-3
See Installer>>#primMerge:. You may want to do something similar in
the CI scripts. Then again, isn't CI supposed to tell us when something with the trunk needs attention? If something needs merged then it need attention and CI could/should report on that shouldn't it? On Fri, Sep 20, 2013 at 6:29 AM, Frank Shearar <[hidden email]> wrote: > On 17 September 2013 08:40, Frank Shearar <[hidden email]> wrote: >> I really do need to take the time to look at that guy... So I should, for the moment, just need to catch the PIEs to log? I tried that but maybe I did it wrong. I'll take another run at it. We definitely do need a command line processor in trunk, at any rate. Loads of the CI work is working around our lack thereof. > > Well, I haven't managed to log updates, but I _have_ finally managed > to fix the CI update scripts. A merge conflict caused an > MCMergeBrowser to pop up and halt the world. CI assumed the task had > hung (which it had, effectively), and hilarity ensued. > > http://build.squeak.org/job/SqueakTrunk/532/console shows a properly > working update. (I have no idea where all those empty lines are coming > from... unless they're progress indications?? Could be!) > > The script didn't just bail because an MCMergeResolutionRequest has a > #defaultAction (to bring up the dialog). Since the script doesn't > catch that exception, the #defaultAction triggers, popping up the > dialog. > > Without having thought it through, one possible solution is to _never_ > create dialogs directly, but always through ToolSet. (So Monticello > would extend ToolSet's API, for instance.) That way, a > CommandLineToolSet could bail with a decent error message, while (in > this case) the StandardToolSet could pop up a MCMergeBrowser. > > frank |
On 20 September 2013 16:01, Chris Muller <[hidden email]> wrote:
> See Installer>>#primMerge:. You may want to do something similar in > the CI scripts. Yep! > Then again, isn't CI supposed to tell us when something with the trunk > needs attention? If something needs merged then it need attention and > CI could/should report on that shouldn't it? In this particular case the merge is entirely of my own making. Merges will show up in the console. There may be other occasions when merge conflicts might arise (although I can't think of any right now). At the moment we can't abort the test run anyway, because we lack Levente's #snapshot:andQuitWithExitCode: work in the Inbox. So while I take your point, I'm happy with the current state of affairs, for the moment at least. frank > On Fri, Sep 20, 2013 at 6:29 AM, Frank Shearar <[hidden email]> wrote: >> On 17 September 2013 08:40, Frank Shearar <[hidden email]> wrote: >>> I really do need to take the time to look at that guy... So I should, for the moment, just need to catch the PIEs to log? I tried that but maybe I did it wrong. I'll take another run at it. We definitely do need a command line processor in trunk, at any rate. Loads of the CI work is working around our lack thereof. >> >> Well, I haven't managed to log updates, but I _have_ finally managed >> to fix the CI update scripts. A merge conflict caused an >> MCMergeBrowser to pop up and halt the world. CI assumed the task had >> hung (which it had, effectively), and hilarity ensued. >> >> http://build.squeak.org/job/SqueakTrunk/532/console shows a properly >> working update. (I have no idea where all those empty lines are coming >> from... unless they're progress indications?? Could be!) >> >> The script didn't just bail because an MCMergeResolutionRequest has a >> #defaultAction (to bring up the dialog). Since the script doesn't >> catch that exception, the #defaultAction triggers, popping up the >> dialog. >> >> Without having thought it through, one possible solution is to _never_ >> create dialogs directly, but always through ToolSet. (So Monticello >> would extend ToolSet's API, for instance.) That way, a >> CommandLineToolSet could bail with a decent error message, while (in >> this case) the StandardToolSet could pop up a MCMergeBrowser. >> >> frank |
Free forum by Nabble | Edit this page |