[Pharo-project] [OT] Great job guys
see http://mue.tideland.biz/2009/01/great-job-guys.html -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
cool thanks for the pointer. we hope also to have Pharo by Example in the future and especially Pharo by Example volume 2 :) Stef On Jan 7, 2009, at 10:24 PM, Torsten Bergmann wrote:
see http://mue.tideland.biz/2009/01/great-job-guys.html -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This is a very positive post. Thanks for sharing with us Alexandre On 7 Jan 2009, at 18:24, Torsten Bergmann wrote:
see http://mue.tideland.biz/2009/01/great-job-guys.html -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2009/1/7 Torsten Bergmann <astares@gmx.de>:
see http://mue.tideland.biz/2009/01/great-job-guys.html -- Since this is alredy OT ...
by coincidence, i'm currently also working on GLASS, but still using old squeak image. :) Any success installing gemtools into pharo to use improved OB-based look&feel?
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
by coincidence, i'm currently also working on GLASS, but still using old squeak image. :) Any success installing gemtools into pharo to use improved OB-based look&feel?
And when you are already doing that, introduce also breakpoints back in Pharo as they are on GLASS GemTools. Very intuitive and the same as on most other Smalltalks. If they can be supported in GemTools, why aren't yet in Pharo? Any technical reason? I know that breakpoints are somehow supported in Squeak, but my point is to be supported the same way as on GemTools, and other Smalltalks. Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
----- "Janko Mivšek" <janko.mivsek@eranova.si> wrote: | And when you are already doing that, introduce also breakpoints back in | Pharo as they are on GLASS GemTools. Very intuitive and the same as on | most other Smalltalks. If they can be supported in GemTools, why | aren't yet in Pharo? Any technical reason? Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm. Dale
Dale Henrichs wrote:
----- "Janko Mivšek" <janko.mivsek@eranova.si> wrote:
| And when you are already doing that, introduce also breakpoints back in | Pharo as they are on GLASS GemTools. Very intuitive and the same as on | most other Smalltalks. If they can be supported in GemTools, why | aren't yet in Pharo? Any technical reason?
Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm.
What I like about breakpoints in GemTools is the simplicity from usability standpoint. And similarity of use to other Smalltaltalks. And because their UI part is implemented in OmniBrowser on GemTools, they should be easily ported back to Pharo OmniBrowser, even that breakpoints in GS/S are implemented differently than in Squeak. In other words, let we port the UI for breakpoints first, on top of whatever Squeak supports for breakpoints currently. Later breakpoints can be enhanced on VM level as well. Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
2009/1/9 Janko Mivšek <janko.mivsek@eranova.si>:
Dale Henrichs wrote:
----- "Janko Mivšek" <janko.mivsek@eranova.si> wrote:
| And when you are already doing that, introduce also breakpoints back in | Pharo as they are on GLASS GemTools. Very intuitive and the same as on | most other Smalltalks. If they can be supported in GemTools, why | aren't yet in Pharo? Any technical reason?
Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm.
What I like about breakpoints in GemTools is the simplicity from usability standpoint. And similarity of use to other Smalltaltalks.
And because their UI part is implemented in OmniBrowser on GemTools, they should be easily ported back to Pharo OmniBrowser, even that breakpoints in GS/S are implemented differently than in Squeak.
In other words, let we port the UI for breakpoints first, on top of whatever Squeak supports for breakpoints currently. Later breakpoints can be enhanced on VM level as well.
There is no need in any enhancement from VM side. Here attached the scratch implementation of breakpoints for squeak, took about 15 minutes to implement. Usage: BreakPointAgent class:<yourclass> selector: <yourselector> "will install a breakpoint on that method" BreakPointAgent removeAll "remove all breaks from system" BreakPointTestClass test " a simple test " :) now you can subclass it and create a conditional breakpoints, which will halt only if some criteria met. It is trivial to add new ivar (criteriaBlock) and change run: aSelector with: arguments in: aReceiver to halt only if criteriaBlock evaluates to true. There is No limits to fantasy :) To not hide the actual method (when browsing) BreakPointAgent could be extended to act as a proxy while it active e.g. simply redirect messages like #literals and so on to compiled method it replaced.
Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Btw, with this trick its not necessary to break before invocation of method. You can put break just after method returns. Think , how powerfull it can be: (example) BreakPointAgent breakOnLeave: #isString class: Object condition: [:receiver :arguments: :result | Transcript show: receiver printString, '>>isString returns: ', result asString; cr. false "do not break" ]. 2009/1/9 Igor Stasenko <siguctua@gmail.com>:
2009/1/9 Janko Mivšek <janko.mivsek@eranova.si>:
Dale Henrichs wrote:
----- "Janko Mivšek" <janko.mivsek@eranova.si> wrote:
| And when you are already doing that, introduce also breakpoints back in | Pharo as they are on GLASS GemTools. Very intuitive and the same as on | most other Smalltalks. If they can be supported in GemTools, why | aren't yet in Pharo? Any technical reason?
Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm.
What I like about breakpoints in GemTools is the simplicity from usability standpoint. And similarity of use to other Smalltaltalks.
And because their UI part is implemented in OmniBrowser on GemTools, they should be easily ported back to Pharo OmniBrowser, even that breakpoints in GS/S are implemented differently than in Squeak.
In other words, let we port the UI for breakpoints first, on top of whatever Squeak supports for breakpoints currently. Later breakpoints can be enhanced on VM level as well.
There is no need in any enhancement from VM side.
Here attached the scratch implementation of breakpoints for squeak, took about 15 minutes to implement.
Usage:
BreakPointAgent class:<yourclass> selector: <yourselector> "will install a breakpoint on that method"
BreakPointAgent removeAll "remove all breaks from system"
BreakPointTestClass test " a simple test " :)
now you can subclass it and create a conditional breakpoints, which will halt only if some criteria met. It is trivial to add new ivar (criteriaBlock) and change run: aSelector with: arguments in: aReceiver to halt only if criteriaBlock evaluates to true. There is No limits to fantasy :)
To not hide the actual method (when browsing) BreakPointAgent could be extended to act as a proxy while it active e.g. simply redirect messages like #literals and so on to compiled method it replaced.
Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
_______________________________________________ Pharo-project mailing list Pharo-project@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.
Even more smart-ass patching , to make OB happier :) Now if you open browser on BreakPointTestClass>>testMethod you will see an icon in method list changing when you installing/deinstalling the breakpoint by doing: BreakPointAgent class: BreakPointTestClass selector: #testMethod BreakPointAgent removeAll :) -- Best regards, Igor Stasenko AKA sig.
one of the point about breakpoint is that they should not get the method dirty. I know that some breakpoint code has been harvested but I do not remember how to use it. Stef On Jan 9, 2009, at 10:27 AM, Janko Mivšek wrote:
Dale Henrichs wrote:
----- "Janko Mivšek" <janko.mivsek@eranova.si> wrote:
| And when you are already doing that, introduce also breakpoints back in | Pharo as they are on GLASS GemTools. Very intuitive and the same as on | most other Smalltalks. If they can be supported in GemTools, why | aren't yet in Pharo? Any technical reason?
Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm.
What I like about breakpoints in GemTools is the simplicity from usability standpoint. And similarity of use to other Smalltaltalks.
And because their UI part is implemented in OmniBrowser on GemTools, they should be easily ported back to Pharo OmniBrowser, even that breakpoints in GS/S are implemented differently than in Squeak.
In other words, let we port the UI for breakpoints first, on top of whatever Squeak supports for breakpoints currently. Later breakpoints can be enhanced on VM level as well.
Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 09.01.2009, at 16:19, Stéphane Ducasse wrote:
one of the point about breakpoint is that they should not get the method dirty. I know that some breakpoint code has been harvested but I do not remember how to use it.
There is a very simple breakpoint mechanism in Pharo (in Squeak, too, but it was a bit broken there). To try: There is a "toggle break on entry" item in the menu of methods in the old browser. Technically, this just recompiles the method with a call to #break at the beginning. Could be improved a lot. Marcus
Stef
On Jan 9, 2009, at 10:27 AM, Janko Mivšek wrote:
Dale Henrichs wrote:
----- "Janko Mivšek" <janko.mivsek@eranova.si> wrote:
| And when you are already doing that, introduce also breakpoints back in | Pharo as they are on GLASS GemTools. Very intuitive and the same as on | most other Smalltalks. If they can be supported in GemTools, why | aren't yet in Pharo? Any technical reason?
Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm.
What I like about breakpoints in GemTools is the simplicity from usability standpoint. And similarity of use to other Smalltaltalks.
And because their UI part is implemented in OmniBrowser on GemTools, they should be easily ported back to Pharo OmniBrowser, even that breakpoints in GS/S are implemented differently than in Squeak.
In other words, let we port the UI for breakpoints first, on top of whatever Squeak supports for breakpoints currently. Later breakpoints can be enhanced on VM level as well.
Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/1/13 Marcus Denker <denker@iam.unibe.ch>:
On 09.01.2009, at 16:19, Stéphane Ducasse wrote:
one of the point about breakpoint is that they should not get the method dirty. I know that some breakpoint code has been harvested but I do not remember how to use it.
There is a very simple breakpoint mechanism in Pharo (in Squeak, too, but it was a bit broken there).
To try: There is a "toggle break on entry" item in the menu of methods in the old browser.
Technically, this just recompiles the method with a call to #break at the beginning.
is it better than doing a trick with method dictionary, as i showed in example?
Could be improved a lot.
Marcus
Stef
On Jan 9, 2009, at 10:27 AM, Janko Mivšek wrote:
Dale Henrichs wrote:
----- "Janko Mivšek" <janko.mivsek@eranova.si> wrote:
| And when you are already doing that, introduce also breakpoints back in | Pharo as they are on GLASS GemTools. Very intuitive and the same as on | most other Smalltalks. If they can be supported in GemTools, why | aren't yet in Pharo? Any technical reason?
Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm.
What I like about breakpoints in GemTools is the simplicity from usability standpoint. And similarity of use to other Smalltaltalks.
And because their UI part is implemented in OmniBrowser on GemTools, they should be easily ported back to Pharo OmniBrowser, even that breakpoints in GS/S are implemented differently than in Squeak.
In other words, let we port the UI for breakpoints first, on top of whatever Squeak supports for breakpoints currently. Later breakpoints can be enhanced on VM level as well.
Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I have to check your trick because it seems to be a nice example of meta prog for a chapter I'm have in mind. stef On Jan 13, 2009, at 3:51 PM, Igor Stasenko wrote:
2009/1/13 Marcus Denker <denker@iam.unibe.ch>:
On 09.01.2009, at 16:19, Stéphane Ducasse wrote:
one of the point about breakpoint is that they should not get the method dirty. I know that some breakpoint code has been harvested but I do not remember how to use it.
There is a very simple breakpoint mechanism in Pharo (in Squeak, too, but it was a bit broken there).
To try: There is a "toggle break on entry" item in the menu of methods in the old browser.
Technically, this just recompiles the method with a call to #break at the beginning.
is it better than doing a trick with method dictionary, as i showed in example?
Could be improved a lot.
Marcus
Stef
On Jan 9, 2009, at 10:27 AM, Janko Mivšek wrote:
Dale Henrichs wrote:
----- "Janko Mivšek" <janko.mivsek@eranova.si> wrote:
| And when you are already doing that, introduce also breakpoints back in | Pharo as they are on GLASS GemTools. Very intuitive and the same as on | most other Smalltalks. If they can be supported in GemTools, why | aren't yet in Pharo? Any technical reason?
Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm.
What I like about breakpoints in GemTools is the simplicity from usability standpoint. And similarity of use to other Smalltaltalks.
And because their UI part is implemented in OmniBrowser on GemTools, they should be easily ported back to Pharo OmniBrowser, even that breakpoints in GS/S are implemented differently than in Squeak.
In other words, let we port the UI for breakpoints first, on top of whatever Squeak supports for breakpoints currently. Later breakpoints can be enhanced on VM level as well.
Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/1/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I have to check your trick because it seems to be a nice example of meta prog for a chapter I'm have in mind.
btw, i started to write some UI, using OB tools. A simple window with a list of breakpoints, and some functionality, like remove/disable/enable breakpoint(s) later it could be extended with 'add condition' or 'set pass count' and other stuff. Not sure how to extend a menu for a method definition in OB. If someone could give me a hint, i will add a 'break on entry' item(s). Or even a submenu with different ways to set up a break, and open a breakpoints manager.
stef On Jan 13, 2009, at 3:51 PM, Igor Stasenko wrote:
2009/1/13 Marcus Denker <denker@iam.unibe.ch>:
On 09.01.2009, at 16:19, Stéphane Ducasse wrote:
one of the point about breakpoint is that they should not get the method dirty. I know that some breakpoint code has been harvested but I do not remember how to use it.
There is a very simple breakpoint mechanism in Pharo (in Squeak, too, but it was a bit broken there).
To try: There is a "toggle break on entry" item in the menu of methods in the old browser.
Technically, this just recompiles the method with a call to #break at the beginning.
is it better than doing a trick with method dictionary, as i showed in example?
Could be improved a lot.
Marcus
Stef
On Jan 9, 2009, at 10:27 AM, Janko Mivšek wrote:
Dale Henrichs wrote:
----- "Janko Mivšek" <janko.mivsek@eranova.si> wrote:
| And when you are already doing that, introduce also breakpoints back in | Pharo as they are on GLASS GemTools. Very intuitive and the same as on | most other Smalltalks. If they can be supported in GemTools, why | aren't yet in Pharo? Any technical reason?
Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm.
What I like about breakpoints in GemTools is the simplicity from usability standpoint. And similarity of use to other Smalltaltalks.
And because their UI part is implemented in OmniBrowser on GemTools, they should be easily ported back to Pharo OmniBrowser, even that breakpoints in GS/S are implemented differently than in Squeak.
In other words, let we port the UI for breakpoints first, on top of whatever Squeak supports for breakpoints currently. Later breakpoints can be enhanced on VM level as well.
Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Marcus Denker wrote:
On 09.01.2009, at 16:19, Stéphane Ducasse wrote:
one of the point about breakpoint is that they should not get the method dirty. I know that some breakpoint code has been harvested but I do not remember how to use it.
There is a very simple breakpoint mechanism in Pharo (in Squeak, too, but it was a bit broken there).
To try: There is a "toggle break on entry" item in the menu of methods in the old browser.
Technically, this just recompiles the method with a call to #break at the beginning.
Could be improved a lot.
And the simplest improvement would be to just rename it to 'Set breakpoint' so that everyone will recognize its meaning immediatelly. Next thing is to put a breakpoint mark at the beginning of the method. All this is already done by Dale in GemTools so in theory it just needs to be copied from there... Janko
On Jan 9, 2009, at 10:27 AM, Janko Mivšek wrote:
Dale Henrichs wrote:
----- "Janko Mivšek" <janko.mivsek@eranova.si> wrote:
| And when you are already doing that, introduce also breakpoints back in | Pharo as they are on GLASS GemTools. Very intuitive and the same as on | most other Smalltalks. If they can be supported in GemTools, why | aren't yet in Pharo? Any technical reason?
Breakpoints in GLASS/GemTools are taking advantage of the breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are used as an OmniBrowser client for GLASS -- the debugger is running in a GemStone vm and the UI is running in the Squeak/Pharo vm. What I like about breakpoints in GemTools is the simplicity from usability standpoint. And similarity of use to other Smalltaltalks.
And because their UI part is implemented in OmniBrowser on GemTools, they should be easily ported back to Pharo OmniBrowser, even that breakpoints in GS/S are implemented differently than in Squeak.
In other words, let we port the UI for breakpoints first, on top of whatever Squeak supports for breakpoints currently. Later breakpoints can be enhanced on VM level as well.
Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
On 13.01.2009, at 15:51, Igor Stasenko wrote:
2009/1/13 Marcus Denker <denker@iam.unibe.ch>:
On 09.01.2009, at 16:19, Stéphane Ducasse wrote:
one of the point about breakpoint is that they should not get the method dirty. I know that some breakpoint code has been harvested but I do not remember how to use it.
There is a very simple breakpoint mechanism in Pharo (in Squeak, too, but it was a bit broken there).
To try: There is a "toggle break on entry" item in the menu of methods in the old browser.
Technically, this just recompiles the method with a call to #break at the beginning.
is it better than doing a trick with method dictionary, as i showed in example?
I did not check your example... but it sounds that it is at least as good. Maybe the source-manipulation was done to later support breakpoint anywhere in the code (not only the beginning) Marcus
2009/1/14 Marcus Denker <denker@iam.unibe.ch>:
On 13.01.2009, at 15:51, Igor Stasenko wrote:
2009/1/13 Marcus Denker <denker@iam.unibe.ch>:
On 09.01.2009, at 16:19, Stéphane Ducasse wrote:
one of the point about breakpoint is that they should not get the method dirty. I know that some breakpoint code has been harvested but I do not remember how to use it.
There is a very simple breakpoint mechanism in Pharo (in Squeak, too, but it was a bit broken there).
To try: There is a "toggle break on entry" item in the menu of methods in the old browser.
Technically, this just recompiles the method with a call to #break at the beginning.
is it better than doing a trick with method dictionary, as i showed in example?
I did not check your example... but it sounds that it is at least as good. Maybe the source-manipulation was done to later support breakpoint anywhere in the code (not only the beginning)
well, i don't see a need in inruding into a source code anyway. For breaking in the middle of method, one can do following: - intercept entry to a method (in a way like i doing) - step bytecodes manually and break if IP equal to designated value where breakpoint is set. similar to what debugger does, if i'm not mistaken. A more easy to implement could be a breakpoints like 'break at seding a message #xxxx from given method' this can be done by replacing selector #xxxx in given method with special #breakHerePlease and implement #breakHerePlease method properly.
Marcus
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 14.01.2009, at 10:57, Igor Stasenko wrote:
2009/1/14 Marcus Denker <denker@iam.unibe.ch>: well, i don't see a need in inruding into a source code anyway.
For breaking in the middle of method, one can do following: - intercept entry to a method (in a way like i doing) - step bytecodes manually and break if IP equal to designated value where breakpoint is set. similar to what debugger does, if i'm not mistaken.
Yes, nice idea! Marcus
A more easy to implement could be a breakpoints like 'break at seding a message #xxxx from given method' this can be done by replacing selector #xxxx in given method with special #breakHerePlease and implement #breakHerePlease method properly.
Marcus
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Alexandre Bergel -
Dale Henrichs -
Hilaire Fernandes -
Igor Stasenko -
Janko Mivšek -
Marcus Denker -
Stéphane Ducasse -
Torsten Bergmann