September 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Building a run loop that can continue after an unhanded exception

by Joe Rickerby

Not really. Proceed would take me back to where the exception was signalled. I want to resume at the point of the catch of the exception, no matter what happens regarding the exception. On 7 Sep 2012, at 09:40, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 07.09.2012 10:17, Joe Rickerby wrote: >> Hi all, >> >> I'm having a problem trying to build a run loop. If an exception is signalled within one of the run loop tasks, the exception escapes through the loop and terminates the process. >> >> I know I can catch the exception, and do something like print the message on the Transcript, but I was hoping to build something that was more helpful in development, allowing me to look through the stack, but if I press 'abandon' on that dialog, the run loop would continue from where I caught the exception. >> >> > Isn't that exactly what happens if you don't handle the error, and use the proceed button in (pre and normal) debugger windows? > > Cheers, > Henry

Sept. 7, 2012

[Pharo-project] git support

by Camillo Bruni

who will help? max and I, stimulated by ESUG, worked on the latest version of FS-Git to make it stable again. we are very close to have a complete set of git tools written in pharo ready! missing ======= - a better mc integration - a cypress compatible fileout format - complete interaction with the git protocol - a direct way to commit stuff as always my time is somewhat limited as well and we're the only two developers working on it... The current work is available here: http://ss3.gemstone.com/ss/FSGit-Experimental.html https://github.com/dalehenrich/FSGit best cami

Sept. 7, 2012

[Pharo-project] integration/review process

by Camillo Bruni

previously: [Pharo-project] nil key in last literal in instance side methods (reproducible) > No, I'm just suggesting a poor man's simple diff in a mailing list, > like squeak trunk. > -1) inbox diff : you open a review to the whole community for comments, ok, why not on a separate mailing list that might make sense > -2) commit phase (whatever the checks you perform now are unchanged, > except you have to take above review into account) > -3) trunk diff : you open a last chance review (or post mortem > analysis) to retract/correct commits that is (almost) up and running with our github export: https://github.com/PharoProject/pharo-core > It's totally informal, and why would it work? You have to answer this > question first: > - how many people have ubiquitous web access to read the code and > qualified enough to emit a useful comment? > - how many people are downloading an image, updating to some version, > opening a MC browser, browsing the diffs? > > You are proposing a much more ellaborated process to review code > before integration. > I agree, this information belongs to issue tracker. > But formalizing and programming this process is involving (think about > concurrent solution, roles, requests/answers timelines etc...) > As you said, who will do it? > From pragmatic POV, I prefer a light process that provides some help, > than no help at all (which is close to what you get with current state > of issue tracker). > The code producing the diff and sendig the mail already exist, (you'll > have to handle SLICE though)... Bonus: it's Smalltalk code. > > If you prefer to wait for something better, then let's wait... well the solution would be to simply switch to git for the whole version management. github.com provides an excellent example of how to deal with you aforementioned issues. - pull requests - single commits - full history plus - everything can be commented / annotated from within the website => 0 setup needed so for me something like github is the future for development.

Sept. 7, 2012

Re: [Pharo-project] nil key in last literal in instance side methods (reproducible)

by Nicolas Cellier

2012/9/7 Camillo Bruni <camillobruni(a)gmail.com>: > > On 2012-09-06, at 22:26, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> 2012/9/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> >>> >>> On Thu, Sep 6, 2012 at 9:45 PM, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> A bot providing simple diffs would help more eyes reviewing code... >>>> By now this important work is restricted to a narrow team of busy >>>> active developpers. >>>> Of course, CI may help a bit, but monkeys don't read code they just >>>> evaluate it. >>>> >>> >>> I am not sure if the changes in this slice are important. I think it just >>> happens that for certain reason, we have this problem of the last literal. >>> >> >> I just can't tell if it would help or not, without diff I'm totally blind ;) >> But sure, a correct code can uncover a bug elsewhere... > > Sorry I don't get it? where do you want a diff? on the google code website? > -> we thought once about writing an external website doing that > - list the changes > - list the results from code review > - list the test results > > basically each bugfix should result in a "review" image which can be downloaded > and checked... > > but then again, somebody has to write it... > No, I'm just suggesting a poor man's simple diff in a mailing list, like squeak trunk. -1) inbox diff : you open a review to the whole community for comments, -2) commit phase (whatever the checks you perform now are unchanged, except you have to take above review into account) -3) trunk diff : you open a last chance review (or post mortem analysis) to retract/correct commits It's totally informal, and why would it work? You have to answer this question first: - how many people have ubiquitous web access to read the code and qualified enough to emit a useful comment? - how many people are downloading an image, updating to some version, opening a MC browser, browsing the diffs? You are proposing a much more ellaborated process to review code before integration. I agree, this information belongs to issue tracker. But formalizing and programming this process is involving (think about concurrent solution, roles, requests/answers timelines etc...) As you said, who will do it? >From pragmatic POV, I prefer a light process that provides some help, than no help at all (which is close to what you get with current state of issue tracker). The code producing the diff and sendig the mail already exist, (you'll have to handle SLICE though)... Bonus: it's Smalltalk code. If you prefer to wait for something better, then let's wait... Nicolas

Sept. 7, 2012

[Pharo-project] [update 2.0] #20278

by Esteban Lorenzano

20278 ----- Issue 6649: Promote NetworkSystemSettings over HTTPSocket http://code.google.com/p/pharo/issues/detail?id=6649 Issue 6645: Deprecate SystemVersion>>majorMinor http://code.google.com/p/pharo/issues/detail?id=6645 Issue 6643: Update CI http://code.google.com/p/pharo/issues/detail?id=6643

Sept. 7, 2012

Re: [Pharo-project] Process browser: next generation

by Mariano Martinez Peck

On Thu, Sep 6, 2012 at 3:54 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > > What are the features you would like to see in it? > > > > Have a working CPUWatcher > > Did it work on some point? Yes. > I read the documentation but could not find out how to give a meaning to > it. The idea is that you can enable a process who's goal is to watch the CPU usage and if it goes over, say 80%, then it halts and tries to stop that process. It is useful when there is an infinitive loop or something like that. > Looks like a half-finished thing. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 7, 2012

Re: [Pharo-project] [update 2.0] #20278

by Camillo Bruni

most probably the MC stuff... On 2012-09-07, at 11:35, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > rolling back this change, something went wrong in jenkins > > On Sep 7, 2012, at 11:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> 20278 >> ----- >> >> Issue 6649: Promote NetworkSystemSettings over HTTPSocket >> http://code.google.com/p/pharo/issues/detail?id=6649 >> >> Issue 6645: Deprecate SystemVersion>>majorMinor >> http://code.google.com/p/pharo/issues/detail?id=6645 >> >> Issue 6643: Update CI >> http://code.google.com/p/pharo/issues/detail?id=6643 >> >> Issue 6449: [ENH]: MCHttpRepository Authentication >> http://code.google.com/p/pharo/issues/detail?id=6449 > >

Sept. 7, 2012

Re: [Pharo-project] [update 2.0] #20278

by Esteban Lorenzano

rolling back this change, something went wrong in jenkins On Sep 7, 2012, at 11:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 20278 > ----- > > Issue 6649: Promote NetworkSystemSettings over HTTPSocket > http://code.google.com/p/pharo/issues/detail?id=6649 > > Issue 6645: Deprecate SystemVersion>>majorMinor > http://code.google.com/p/pharo/issues/detail?id=6645 > > Issue 6643: Update CI > http://code.google.com/p/pharo/issues/detail?id=6643 > > Issue 6449: [ENH]: MCHttpRepository Authentication > http://code.google.com/p/pharo/issues/detail?id=6449

Sept. 7, 2012

[Pharo-project] [update 2.0] #20278

by Esteban Lorenzano

20278 ----- Issue 6649: Promote NetworkSystemSettings over HTTPSocket http://code.google.com/p/pharo/issues/detail?id=6649 Issue 6645: Deprecate SystemVersion>>majorMinor http://code.google.com/p/pharo/issues/detail?id=6645 Issue 6643: Update CI http://code.google.com/p/pharo/issues/detail?id=6643 Issue 6449: [ENH]: MCHttpRepository Authentication http://code.google.com/p/pharo/issues/detail?id=6449

Sept. 7, 2012

Re: [Pharo-project] Building a run loop that can continue after an unhanded exception

by Camillo Bruni

On 2012-09-07, at 10:40, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 07.09.2012 10:17, Joe Rickerby wrote: >> Hi all, >> >> I'm having a problem trying to build a run loop. If an exception is signalled within one of the run loop tasks, the exception escapes through the loop and terminates the process. >> >> I know I can catch the exception, and do something like print the message on the Transcript, but I was hoping to build something that was more helpful in development, allowing me to look through the stack, but if I press 'abandon' on that dialog, the run loop would continue from where I caught the exception. >> >> > Isn't that exactly what happens if you don't handle the error, and use the proceed button in (pre and normal) debugger windows? exactly! If you are using 2.0 you can rely on the #debug message [ Error signal: 'Boom' ] on: Error do: [ :error| error debug ]. otherwise simply do Error signal: 'Boom' and you'll get the debugger... If you want to print the stack explicitly try the debugStack: error signalContext printDebugOn: aStream

Sept. 7, 2012