- Pharo-dev - lists.pharo.org

[Pharo-project] New pharo dev

by Damien Cassou

Based on 10213: https://gforge.inria.fr/frs/download.php/16049/pharo0.1-10213dev09.01.3.zip -- Damien Cassou http://damiencassou.seasidehosting.st

Jan. 27, 2009

Re: [Pharo-project] Writing a conditions for breakpoint

by Igor Stasenko

2009/1/27 Gary Chambers <gazzaguru2(a)btinternet.com>: > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, January 27, 2009 12:01 AM > Subject: Re: [Pharo-project] Writing a conditions for breakpoint > > >> 2009/1/27 Igor Stasenko <siguctua(a)gmail.com>: >>> 2009/1/27 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>> If I remember rightly the existing breakpoint scheme just recompiled the >>>> method without source logging. Naturally you could get into a horrible >>>> mess >>>> with the source not matching the bytecodes. >>>> >>>> Just a thought. Since that, I believe, was why "breakpoints" were >>>> considered >>>> broken. >>>> >>> >>> I'm using different approach by changing the method in method's >>> dictionary without doing any change in original compiled method. > > > Isn't replacing the method dictionary entry the same as replacing the > compiled method? > nearly the same, except that you don't need to deal with bytecodes and hack method to get what you need. I forgot to add - i'm using a squeak's 'object as method' feature, so it not requires to do hard work with compiler or generating synthetic method with custom bytecodes, which doesn't match the source. > >>> Then, once your program runs to the point of method invocation - its >>> intercepted ,and there are a number of choices: >>> - break into debugger >>> - continue running as usual >>> etc. >>> >>> This is enough for start (you can set a breakpoint on method >>> entry/exit, but can't place break inside of method's body). >>> For more advanced, it would require step by step execution of method's >>> bytecodes (in same way as debugger doing this), then you can pick any >>> bytecode position to place a break there. This can be possible only in >>> a good cooperation with debugger - because for placing breakpoint >>> inside a method body you need to provide a UI to select the place by >>> showing a user the method source, and then interpreting user's input >>> to a bytecode position. >>> >>> I think being able to break at method entry/exit is well enough to >>> cover about 99% of all cases where you need breakpoints (remember - >>> this is smalltalk and methods tend to be very short). >>> The rest 1% you may require only if you want to debug a bytecodes. >>> >> >> Even more, i think going so deep (enable breaks in method's body) its >> not worth efforts - in the end, user can always choose to write 'self >> halt' at any place he may need to. Without any extra efforts from our >> side :) >> >>>> Regards, Gary. >>>> >>>> ----- Original Message ----- >>>> From: Mariano Martinez Peck >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Sent: Monday, January 26, 2009 9:33 PM >>>> Subject: Re: [Pharo-project] Writing a conditions for breakpoint >>>> >>>>> >>>>> here, i'm speaking about setting breakpoints using UI i.e. without >>>>> changing the method. >>>>> I wrote a simple OB-based breakpoint manager, where you can edit >>>>> breakpoints list and possibly set a condition to break. >>>>> Of course, you can always put 'wand isZapped ifTrue: [self halt]' in >>>>> any method, but this having one huge drawback: >>>>> once you modify the method, a change is recorded into .changes, as >>>>> well as many other parts of the system get notified about such change. >>>>> But we don't want to mark packages modified, nor unnecessary pollute >>>>> .changes file only because we need to test some functionality (by >>>>> putting a breakpoint), right? >>>>> Because such practice makes harder to manage the source code (you >>>>> forced to always get back to places where you put the halt to remove >>>>> it, and this is a bit annoying). >>>> >>>> >>>> +1 100% >>>> >>>>> >>>>> > -- >>>>> > Damien Cassou >>>>> > http://damiencassou.seasidehosting.st >>>>> > >>>>> > _______________________________________________ >>>>> > Pharo-project mailing list >>>>> > Pharo-project(a)lists.gforge.inria.fr >>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> > >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> ________________________________ >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 27, 2009

Re: [Pharo-project] Writing a conditions for breakpoint

by Gary Chambers

----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, January 27, 2009 12:01 AM Subject: Re: [Pharo-project] Writing a conditions for breakpoint > 2009/1/27 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/1/27 Gary Chambers <gazzaguru2(a)btinternet.com>: >>> If I remember rightly the existing breakpoint scheme just recompiled the >>> method without source logging. Naturally you could get into a horrible >>> mess >>> with the source not matching the bytecodes. >>> >>> Just a thought. Since that, I believe, was why "breakpoints" were >>> considered >>> broken. >>> >> >> I'm using different approach by changing the method in method's >> dictionary without doing any change in original compiled method. Isn't replacing the method dictionary entry the same as replacing the compiled method? >> Then, once your program runs to the point of method invocation - its >> intercepted ,and there are a number of choices: >> - break into debugger >> - continue running as usual >> etc. >> >> This is enough for start (you can set a breakpoint on method >> entry/exit, but can't place break inside of method's body). >> For more advanced, it would require step by step execution of method's >> bytecodes (in same way as debugger doing this), then you can pick any >> bytecode position to place a break there. This can be possible only in >> a good cooperation with debugger - because for placing breakpoint >> inside a method body you need to provide a UI to select the place by >> showing a user the method source, and then interpreting user's input >> to a bytecode position. >> >> I think being able to break at method entry/exit is well enough to >> cover about 99% of all cases where you need breakpoints (remember - >> this is smalltalk and methods tend to be very short). >> The rest 1% you may require only if you want to debug a bytecodes. >> > > Even more, i think going so deep (enable breaks in method's body) its > not worth efforts - in the end, user can always choose to write 'self > halt' at any place he may need to. Without any extra efforts from our > side :) > >>> Regards, Gary. >>> >>> ----- Original Message ----- >>> From: Mariano Martinez Peck >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Sent: Monday, January 26, 2009 9:33 PM >>> Subject: Re: [Pharo-project] Writing a conditions for breakpoint >>> >>>> >>>> here, i'm speaking about setting breakpoints using UI i.e. without >>>> changing the method. >>>> I wrote a simple OB-based breakpoint manager, where you can edit >>>> breakpoints list and possibly set a condition to break. >>>> Of course, you can always put 'wand isZapped ifTrue: [self halt]' in >>>> any method, but this having one huge drawback: >>>> once you modify the method, a change is recorded into .changes, as >>>> well as many other parts of the system get notified about such change. >>>> But we don't want to mark packages modified, nor unnecessary pollute >>>> .changes file only because we need to test some functionality (by >>>> putting a breakpoint), right? >>>> Because such practice makes harder to manage the source code (you >>>> forced to always get back to places where you put the halt to remove >>>> it, and this is a bit annoying). >>> >>> >>> +1 100% >>> >>>> >>>> > -- >>>> > Damien Cassou >>>> > http://damiencassou.seasidehosting.st >>>> > >>>> > _______________________________________________ >>>> > Pharo-project mailing list >>>> > Pharo-project(a)lists.gforge.inria.fr >>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> > >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> ________________________________ >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 27, 2009

Re: [Pharo-project] Writing a conditions for breakpoint

by Igor Stasenko

2009/1/27 Igor Stasenko <siguctua(a)gmail.com>: > 2009/1/27 Gary Chambers <gazzaguru2(a)btinternet.com>: >> If I remember rightly the existing breakpoint scheme just recompiled the >> method without source logging. Naturally you could get into a horrible mess >> with the source not matching the bytecodes. >> >> Just a thought. Since that, I believe, was why "breakpoints" were considered >> broken. >> > > I'm using different approach by changing the method in method's > dictionary without doing any change in original compiled method. > Then, once your program runs to the point of method invocation - its > intercepted ,and there are a number of choices: > - break into debugger > - continue running as usual > etc. > > This is enough for start (you can set a breakpoint on method > entry/exit, but can't place break inside of method's body). > For more advanced, it would require step by step execution of method's > bytecodes (in same way as debugger doing this), then you can pick any > bytecode position to place a break there. This can be possible only in > a good cooperation with debugger - because for placing breakpoint > inside a method body you need to provide a UI to select the place by > showing a user the method source, and then interpreting user's input > to a bytecode position. > > I think being able to break at method entry/exit is well enough to > cover about 99% of all cases where you need breakpoints (remember - > this is smalltalk and methods tend to be very short). > The rest 1% you may require only if you want to debug a bytecodes. > Even more, i think going so deep (enable breaks in method's body) its not worth efforts - in the end, user can always choose to write 'self halt' at any place he may need to. Without any extra efforts from our side :) >> Regards, Gary. >> >> ----- Original Message ----- >> From: Mariano Martinez Peck >> To: Pharo-project(a)lists.gforge.inria.fr >> Sent: Monday, January 26, 2009 9:33 PM >> Subject: Re: [Pharo-project] Writing a conditions for breakpoint >> >>> >>> here, i'm speaking about setting breakpoints using UI i.e. without >>> changing the method. >>> I wrote a simple OB-based breakpoint manager, where you can edit >>> breakpoints list and possibly set a condition to break. >>> Of course, you can always put 'wand isZapped ifTrue: [self halt]' in >>> any method, but this having one huge drawback: >>> once you modify the method, a change is recorded into .changes, as >>> well as many other parts of the system get notified about such change. >>> But we don't want to mark packages modified, nor unnecessary pollute >>> .changes file only because we need to test some functionality (by >>> putting a breakpoint), right? >>> Because such practice makes harder to manage the source code (you >>> forced to always get back to places where you put the halt to remove >>> it, and this is a bit annoying). >> >> >> +1 100% >> >>> >>> > -- >>> > Damien Cassou >>> > http://damiencassou.seasidehosting.st >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ________________________________ >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Jan. 27, 2009

Re: [Pharo-project] Writing a conditions for breakpoint

by Igor Stasenko

2009/1/27 Gary Chambers <gazzaguru2(a)btinternet.com>: > If I remember rightly the existing breakpoint scheme just recompiled the > method without source logging. Naturally you could get into a horrible mess > with the source not matching the bytecodes. > > Just a thought. Since that, I believe, was why "breakpoints" were considered > broken. > I'm using different approach by changing the method in method's dictionary without doing any change in original compiled method. Then, once your program runs to the point of method invocation - its intercepted ,and there are a number of choices: - break into debugger - continue running as usual etc. This is enough for start (you can set a breakpoint on method entry/exit, but can't place break inside of method's body). For more advanced, it would require step by step execution of method's bytecodes (in same way as debugger doing this), then you can pick any bytecode position to place a break there. This can be possible only in a good cooperation with debugger - because for placing breakpoint inside a method body you need to provide a UI to select the place by showing a user the method source, and then interpreting user's input to a bytecode position. I think being able to break at method entry/exit is well enough to cover about 99% of all cases where you need breakpoints (remember - this is smalltalk and methods tend to be very short). The rest 1% you may require only if you want to debug a bytecodes. > Regards, Gary. > > ----- Original Message ----- > From: Mariano Martinez Peck > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Monday, January 26, 2009 9:33 PM > Subject: Re: [Pharo-project] Writing a conditions for breakpoint > >> >> here, i'm speaking about setting breakpoints using UI i.e. without >> changing the method. >> I wrote a simple OB-based breakpoint manager, where you can edit >> breakpoints list and possibly set a condition to break. >> Of course, you can always put 'wand isZapped ifTrue: [self halt]' in >> any method, but this having one huge drawback: >> once you modify the method, a change is recorded into .changes, as >> well as many other parts of the system get notified about such change. >> But we don't want to mark packages modified, nor unnecessary pollute >> .changes file only because we need to test some functionality (by >> putting a breakpoint), right? >> Because such practice makes harder to manage the source code (you >> forced to always get back to places where you put the halt to remove >> it, and this is a bit annoying). > > > +1 100% > >> >> > -- >> > Damien Cassou >> > http://damiencassou.seasidehosting.st >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ________________________________ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 26, 2009

Re: [Pharo-project] Writing a conditions for breakpoint

by Gary Chambers

If I remember rightly the existing breakpoint scheme just recompiled the method without source logging. Naturally you could get into a horrible mess with the source not matching the bytecodes. Just a thought. Since that, I believe, was why "breakpoints" were considered broken. Regards, Gary. ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, January 26, 2009 9:33 PM Subject: Re: [Pharo-project] Writing a conditions for breakpoint here, i'm speaking about setting breakpoints using UI i.e. without changing the method. I wrote a simple OB-based breakpoint manager, where you can edit breakpoints list and possibly set a condition to break. Of course, you can always put 'wand isZapped ifTrue: [self halt]' in any method, but this having one huge drawback: once you modify the method, a change is recorded into .changes, as well as many other parts of the system get notified about such change. But we don't want to mark packages modified, nor unnecessary pollute .changes file only because we need to test some functionality (by putting a breakpoint), right? Because such practice makes harder to manage the source code (you forced to always get back to places where you put the halt to remove it, and this is a bit annoying). +1 100% > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 26, 2009

Re: [Pharo-project] Writing a conditions for breakpoint

by Mariano Martinez Peck

> > here, i'm speaking about setting breakpoints using UI i.e. without > changing the method. > I wrote a simple OB-based breakpoint manager, where you can edit > breakpoints list and possibly set a condition to break. > Of course, you can always put 'wand isZapped ifTrue: [self halt]' in > any method, but this having one huge drawback: > once you modify the method, a change is recorded into .changes, as > well as many other parts of the system get notified about such change. > But we don't want to mark packages modified, nor unnecessary pollute > .changes file only because we need to test some functionality (by > putting a breakpoint), right? > Because such practice makes harder to manage the source code (you > forced to always get back to places where you put the halt to remove > it, and this is a bit annoying). > +1 100% > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 26, 2009

Re: [Pharo-project] Plugin organization

by bryce＠kampjes.demon.co.uk

Michael Rueger writes: > bryce(a)kampjes.demon.co.uk wrote: > > > Why not just add the plugin's to the VMMaker package? > > > > I don't see any gain for having another official plugin package besides > > VMMaker. It'll have the main problem and advantage of VMMaker of > > central ownership. > > That's not what I suggested, just a naming scheme. > > I also don't think that all plugins will be centrally maintained, as > that would require write access of every plugin maintainer to the VM > repository. > > Michael But Monticello packages are just a naming scheme. Your statement: "That would also allow to simply load all plugins into a VMMaker image by using a package 'Plugin'.". Seems to indicate to me that using the naming convention you suggested would lead to all the packages being part of a single Monticello package. Bryce

Jan. 26, 2009

Re: [Pharo-project] Writing a conditions for breakpoint

by Igor Stasenko

2009/1/26 Damien Cassou <damien.cassou(a)gmail.com>: > On Mon, Jan 26, 2009 at 7:17 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> Igor: Sorry not beeing able to help you. I am still learning squeak. >> However, I would really like conditional breakpoints. I found them very >> useful in Eclipse IDE. Let me know if you could get them working. > > What about #haltIf:? That's already useful. > here, i'm speaking about setting breakpoints using UI i.e. without changing the method. I wrote a simple OB-based breakpoint manager, where you can edit breakpoints list and possibly set a condition to break. Of course, you can always put 'wand isZapped ifTrue: [self halt]' in any method, but this having one huge drawback: once you modify the method, a change is recorded into .changes, as well as many other parts of the system get notified about such change. But we don't want to mark packages modified, nor unnecessary pollute .changes file only because we need to test some functionality (by putting a breakpoint), right? Because such practice makes harder to manage the source code (you forced to always get back to places where you put the halt to remove it, and this is a bit annoying). > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 26, 2009

Re: [Pharo-project] Issue 465 - Pharo dev

by Damien Cassou

On Mon, Jan 26, 2009 at 7:36 PM, Francois Stephany <tulipe.moutarde(a)gmail.com> wrote: > Small bug found in Pharo-dev in OTToolset class. > See issue 465. I've incorporated your fix. Thank you. -- Damien Cassou http://damiencassou.seasidehosting.st

Jan. 26, 2009