>>> - Lukas went over the WeakAnnouncements implementation to get the WeakMessageSend working. The code is in PharoTaskForces
>> >> should we take action on this one? >> I mean integrating it. > > It can be integrated, because the base code works in the same way as before. > > Currently, the solution is implemented through a WeakAnnouncer which subclasses Announcer. I wanted the weak thing to be merged, because the clients of announcements should benefit from the Weak implementation, but Lukas says that he does not trust the Weak support in Pharo and that if you have many WeakAnnouncers it somehow does not scale. ok so ...? > The problem with the current approach is that models have to take an explicit stand of whether they want weak or non weak when instantiating the announcer. Unfortunately, I do have enough technical knowledge for this. It would be cool if someone with better knowledge in this area would take a look. > >>> - Lukas worked on getting OB work with the changes in TextMorph from Pharo 1.2. >>> >>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of Glamour. They got a first version working that is able to do basic actions: step, restart, step into. The challenge was to get to understand the model, and to figure out that <primitive: 19> is used for marking that a method should not be debugged. In any case, working with Glamour seemed to work quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did I get it right? :) >>> >>> - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. >> >> is the widget only for glamour because I think that a widget with search list integrated should be used everywhere? >> We were discussing with alain to have a look at the one in OB and push it/rewrite it as a core widget > > Neither the OB nor the Glamour widgets depend on Glamour, so they can be used independently. You just need to take the Request and the Dialog together. ok where is the code? |
Hi,
On 27 Feb 2011, at 12:04, Stéphane Ducasse wrote: >>>> - Lukas went over the WeakAnnouncements implementation to get the WeakMessageSend working. The code is in PharoTaskForces >>> >>> should we take action on this one? >>> I mean integrating it. >> >> It can be integrated, because the base code works in the same way as before. >> >> Currently, the solution is implemented through a WeakAnnouncer which subclasses Announcer. I wanted the weak thing to be merged, because the clients of announcements should benefit from the Weak implementation, but Lukas says that he does not trust the Weak support in Pharo and that if you have many WeakAnnouncers it somehow does not scale. > > ok so ...? So, we need to investigate more :). It would be cool if someone with more knowledge would take a look, too. Igor, would you have a bit of time to look into it? I will probably also give it a look to see how it works in the context of Glamour. I hope that Esteban will join me again. Esteban, what do you say :)? >> The problem with the current approach is that models have to take an explicit stand of whether they want weak or non weak when instantiating the announcer. Unfortunately, I do have enough technical knowledge for this. It would be cool if someone with better knowledge in this area would take a look. >> >>>> - Lukas worked on getting OB work with the changes in TextMorph from Pharo 1.2. >>>> >>>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of Glamour. They got a first version working that is able to do basic actions: step, restart, step into. The challenge was to get to understand the model, and to figure out that <primitive: 19> is used for marking that a method should not be debugged. In any case, working with Glamour seemed to work quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did I get it right? :) >>>> >>>> - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. >>> >>> is the widget only for glamour because I think that a widget with search list integrated should be used everywhere? >>> We were discussing with alain to have a look at the one in OB and push it/rewrite it as a core widget >> >> Neither the OB nor the Glamour widgets depend on Glamour, so they can be used independently. You just need to take the Request and the Dialog together. > > > ok where is the code? OBCompletionDialog / OBCompletionRequest come with the OB from Pharo 1.2. The way to use it is like: OBCompletionRequest new prompt: 'Find Class'; searchBlock: [ :string | OBCmdFindClass new findClassIn: Smalltalk pattern: string ]; labelBlock: [ :class | class name ]; iconBlock: [ :class | class browserIcon ]; signal. The GLMSpotterRequest / GLMMorphicSpotterDialog are in Glamour-Morphic-Renderer. You can use them like | composite classRequest methodRequest thirdRequest | composite := GLMSpotterRequest new. classRequest := GLMSingleSpotterRequest new prompt: 'Find Class'; searchBlock: [ :string | OBCmdFindClass new findClassIn: Smalltalk pattern: string ]; labelBlock: [ :class | class name ]; iconBlock: [ :class | class browserIcon ]. methodRequest := GLMSingleSpotterRequest new prompt: 'Object Selectors'; searchBlock: [ :string | Object selectors select: [:e| string, '*' match: e asString] ]; labelBlock: [ :e | e ]. thirdRequest := GLMSingleSpotterRequest new prompt: 'Other Selectors'; searchBlock: [ :string | Class selectors select: [:e| string, '*' match: e asString] ]; labelBlock: [ :e | e ]. composite add: classRequest; add: methodRequest; add: thirdRequest; signal Cheers, Doru -- www.tudorgirba.com "Reasonable is what we are accustomed with." |
Hi,
Yes I'm willing to join you to another "glamour work day" :) Let's say next saturday? best, Esteban El 27/02/2011, a las 11:36a.m., Tudor Girba escribió: > Hi, > > On 27 Feb 2011, at 12:04, Stéphane Ducasse wrote: > >>>>> - Lukas went over the WeakAnnouncements implementation to get the WeakMessageSend working. The code is in PharoTaskForces >>>> >>>> should we take action on this one? >>>> I mean integrating it. >>> >>> It can be integrated, because the base code works in the same way as before. >>> >>> Currently, the solution is implemented through a WeakAnnouncer which subclasses Announcer. I wanted the weak thing to be merged, because the clients of announcements should benefit from the Weak implementation, but Lukas says that he does not trust the Weak support in Pharo and that if you have many WeakAnnouncers it somehow does not scale. >> >> ok so ...? > > So, we need to investigate more :). It would be cool if someone with more knowledge would take a look, too. Igor, would you have a bit of time to look into it? > > I will probably also give it a look to see how it works in the context of Glamour. I hope that Esteban will join me again. Esteban, what do you say :)? > > >>> The problem with the current approach is that models have to take an explicit stand of whether they want weak or non weak when instantiating the announcer. Unfortunately, I do have enough technical knowledge for this. It would be cool if someone with better knowledge in this area would take a look. >>> >>>>> - Lukas worked on getting OB work with the changes in TextMorph from Pharo 1.2. >>>>> >>>>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of Glamour. They got a first version working that is able to do basic actions: step, restart, step into. The challenge was to get to understand the model, and to figure out that <primitive: 19> is used for marking that a method should not be debugged. In any case, working with Glamour seemed to work quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did I get it right? :) >>>>> >>>>> - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. >>>> >>>> is the widget only for glamour because I think that a widget with search list integrated should be used everywhere? >>>> We were discussing with alain to have a look at the one in OB and push it/rewrite it as a core widget >>> >>> Neither the OB nor the Glamour widgets depend on Glamour, so they can be used independently. You just need to take the Request and the Dialog together. >> >> >> ok where is the code? > > > OBCompletionDialog / OBCompletionRequest come with the OB from Pharo 1.2. The way to use it is like: > > OBCompletionRequest new > prompt: 'Find Class'; > searchBlock: [ :string | OBCmdFindClass new findClassIn: Smalltalk pattern: string ]; > labelBlock: [ :class | class name ]; > iconBlock: [ :class | class browserIcon ]; > signal. > > The GLMSpotterRequest / GLMMorphicSpotterDialog are in Glamour-Morphic-Renderer. You can use them like > > | composite classRequest methodRequest thirdRequest | > composite := GLMSpotterRequest new. > > classRequest := GLMSingleSpotterRequest new > prompt: 'Find Class'; > searchBlock: [ :string | OBCmdFindClass new findClassIn: Smalltalk pattern: string ]; > labelBlock: [ :class | class name ]; > iconBlock: [ :class | class browserIcon ]. > > methodRequest := GLMSingleSpotterRequest new > prompt: 'Object Selectors'; > searchBlock: [ :string | Object selectors select: [:e| string, '*' match: e asString] ]; > labelBlock: [ :e | e ]. > > thirdRequest := GLMSingleSpotterRequest new > prompt: 'Other Selectors'; > searchBlock: [ :string | Class selectors select: [:e| string, '*' match: e asString] ]; > labelBlock: [ :e | e ]. > > composite > add: classRequest; > add: methodRequest; > add: thirdRequest; > signal > > > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > |
Great! Let's give it a try :)
Cheers, Doru On 28 Feb 2011, at 22:58, Esteban Lorenzano wrote: > Hi, > Yes I'm willing to join you to another "glamour work day" :) > Let's say next saturday? > > best, > Esteban > > El 27/02/2011, a las 11:36a.m., Tudor Girba escribió: > >> Hi, >> >> On 27 Feb 2011, at 12:04, Stéphane Ducasse wrote: >> >>>>>> - Lukas went over the WeakAnnouncements implementation to get the WeakMessageSend working. The code is in PharoTaskForces >>>>> >>>>> should we take action on this one? >>>>> I mean integrating it. >>>> >>>> It can be integrated, because the base code works in the same way as before. >>>> >>>> Currently, the solution is implemented through a WeakAnnouncer which subclasses Announcer. I wanted the weak thing to be merged, because the clients of announcements should benefit from the Weak implementation, but Lukas says that he does not trust the Weak support in Pharo and that if you have many WeakAnnouncers it somehow does not scale. >>> >>> ok so ...? >> >> So, we need to investigate more :). It would be cool if someone with more knowledge would take a look, too. Igor, would you have a bit of time to look into it? >> >> I will probably also give it a look to see how it works in the context of Glamour. I hope that Esteban will join me again. Esteban, what do you say :)? >> >> >>>> The problem with the current approach is that models have to take an explicit stand of whether they want weak or non weak when instantiating the announcer. Unfortunately, I do have enough technical knowledge for this. It would be cool if someone with better knowledge in this area would take a look. >>>> >>>>>> - Lukas worked on getting OB work with the changes in TextMorph from Pharo 1.2. >>>>>> >>>>>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of Glamour. They got a first version working that is able to do basic actions: step, restart, step into. The challenge was to get to understand the model, and to figure out that <primitive: 19> is used for marking that a method should not be debugged. In any case, working with Glamour seemed to work quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did I get it right? :) >>>>>> >>>>>> - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. >>>>> >>>>> is the widget only for glamour because I think that a widget with search list integrated should be used everywhere? >>>>> We were discussing with alain to have a look at the one in OB and push it/rewrite it as a core widget >>>> >>>> Neither the OB nor the Glamour widgets depend on Glamour, so they can be used independently. You just need to take the Request and the Dialog together. >>> >>> >>> ok where is the code? >> >> >> OBCompletionDialog / OBCompletionRequest come with the OB from Pharo 1.2. The way to use it is like: >> >> OBCompletionRequest new >> prompt: 'Find Class'; >> searchBlock: [ :string | OBCmdFindClass new findClassIn: Smalltalk pattern: string ]; >> labelBlock: [ :class | class name ]; >> iconBlock: [ :class | class browserIcon ]; >> signal. >> >> The GLMSpotterRequest / GLMMorphicSpotterDialog are in Glamour-Morphic-Renderer. You can use them like >> >> | composite classRequest methodRequest thirdRequest | >> composite := GLMSpotterRequest new. >> >> classRequest := GLMSingleSpotterRequest new >> prompt: 'Find Class'; >> searchBlock: [ :string | OBCmdFindClass new findClassIn: Smalltalk pattern: string ]; >> labelBlock: [ :class | class name ]; >> iconBlock: [ :class | class browserIcon ]. >> >> methodRequest := GLMSingleSpotterRequest new >> prompt: 'Object Selectors'; >> searchBlock: [ :string | Object selectors select: [:e| string, '*' match: e asString] ]; >> labelBlock: [ :e | e ]. >> >> thirdRequest := GLMSingleSpotterRequest new >> prompt: 'Other Selectors'; >> searchBlock: [ :string | Class selectors select: [:e| string, '*' match: e asString] ]; >> labelBlock: [ :e | e ]. >> >> composite >> add: classRequest; >> add: methodRequest; >> add: thirdRequest; >> signal >> >> >> Cheers, >> Doru >> >> >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> >> > -- www.tudorgirba.com "Every thing should have the right to be different." |
In reply to this post by Tudor Girba
Hi,
2011/2/26 Tudor Girba <[hidden email]> Hi, Nick in CC worked a lot to understand the model part of the Debugger. He has worked on a remote debugger. @Nick, you should have a look probably at this implementation of a debugger in Glamour.
AFAICR the Debugger code really mixes the model, the GUI, the Debugees, ... so perhaps you can all join forces and propose a cleaner and extensible debugger ;-)
Cheers, #Luc - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. |
On Mar 2, 2011, at 20:33 , Luc Fabresse wrote:
>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of >> Glamour. They got a first version working that is able to do basic actions: >> step, restart, step into. The challenge was to get to understand the model, >> and to figure out that <primitive: 19> is used for marking that a method >> should not be debugged. In any case, working with Glamour seemed to work >> quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did >> I get it right? :) >> > > Nick in CC worked a lot to understand the model part of the Debugger. > He has worked on a remote debugger. > @Nick, you should have a look probably at this implementation of a debugger > in Glamour. > AFAICR the Debugger code really mixes the model, the GUI, the Debugees, ... > so perhaps you can all join forces and propose a cleaner and extensible > debugger ;-) Indeed, an independent model would make a lot of sense. Since the original logic is mixed with the GUI code, we just copied parts of it over to our new prototype. By factoring this out into an independent model we would not end up multiple copies for the original debugger, the Glomour debugger, the OB debugger, the remote debugger etc. Adrian |
+ 1
>>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of >>> Glamour. They got a first version working that is able to do basic actions: >>> step, restart, step into. The challenge was to get to understand the model, >>> and to figure out that <primitive: 19> is used for marking that a method >>> should not be debugged. In any case, working with Glamour seemed to work >>> quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did >>> I get it right? :) >>> >> >> Nick in CC worked a lot to understand the model part of the Debugger. >> He has worked on a remote debugger. >> @Nick, you should have a look probably at this implementation of a debugger >> in Glamour. >> AFAICR the Debugger code really mixes the model, the GUI, the Debugees, ... >> so perhaps you can all join forces and propose a cleaner and extensible >> debugger ;-) > > Indeed, an independent model would make a lot of sense. Since the original logic is mixed with the GUI code, we just copied parts of it over to our new prototype. By factoring this out into an independent model we would not end up multiple copies for the original debugger, the Glomour debugger, the OB debugger, the remote debugger etc. > > Adrian |
In reply to this post by Adrian Lienhard
On 2 March 2011 20:56, Adrian Lienhard <[hidden email]> wrote:
> On Mar 2, 2011, at 20:33 , Luc Fabresse wrote: > >>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of >>> Glamour. They got a first version working that is able to do basic actions: >>> step, restart, step into. The challenge was to get to understand the model, >>> and to figure out that <primitive: 19> is used for marking that a method >>> should not be debugged. In any case, working with Glamour seemed to work >>> quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did >>> I get it right? :) >>> >> >> Nick in CC worked a lot to understand the model part of the Debugger. >> He has worked on a remote debugger. >> @Nick, you should have a look probably at this implementation of a debugger >> in Glamour. >> AFAICR the Debugger code really mixes the model, the GUI, the Debugees, ... >> so perhaps you can all join forces and propose a cleaner and extensible >> debugger ;-) > > Indeed, an independent model would make a lot of sense. Since the original logic is mixed with the GUI code, we just copied parts of it over to our new prototype. By factoring this out into an independent model we would not end up multiple copies for the original debugger, the Glomour debugger, the OB debugger, the remote debugger etc. > even if you copy it, we still badly need remote tools. :) Because we really cannot rely on having RFB installed on every headless image. It could be much more nicer and sexier to have small kernel image with small dispatcher to which you can connect and communicate with image remotely, without need of carrying Morphic blob inside it. > Adrian > -- Best regards, Igor Stasenko AKA sig. |
I'm working on extracting everything to a model. DebuggerMethodMap is a
mess so we'll also have our own version of that class. Other methods that I found too messy are rewritten in the model. Still work to be done, and Cog for linux doesn't like me committing code to MC (it just crashes when I click save); so ... But it'll get there ;) Most of the functionality is already there. Making it all remote shouldn't be too much of a problem. The debugger just relies on the debugger model and a list of objects that represent the stack. All actual evaluating actions can easily be forwarded over a proxy to the remote model. cheers, Toon On 03/13/2011 01:31 AM, Igor Stasenko wrote: > On 2 March 2011 20:56, Adrian Lienhard<[hidden email]> wrote: >> On Mar 2, 2011, at 20:33 , Luc Fabresse wrote: >> >>>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of >>>> Glamour. They got a first version working that is able to do basic actions: >>>> step, restart, step into. The challenge was to get to understand the model, >>>> and to figure out that<primitive: 19> is used for marking that a method >>>> should not be debugged. In any case, working with Glamour seemed to work >>>> quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did >>>> I get it right? :) >>>> >>> Nick in CC worked a lot to understand the model part of the Debugger. >>> He has worked on a remote debugger. >>> @Nick, you should have a look probably at this implementation of a debugger >>> in Glamour. >>> AFAICR the Debugger code really mixes the model, the GUI, the Debugees, ... >>> so perhaps you can all join forces and propose a cleaner and extensible >>> debugger ;-) >> Indeed, an independent model would make a lot of sense. Since the original logic is mixed with the GUI code, we just copied parts of it over to our new prototype. By factoring this out into an independent model we would not end up multiple copies for the original debugger, the Glomour debugger, the OB debugger, the remote debugger etc. >> > even if you copy it, we still badly need remote tools. :) > Because we really cannot rely on having RFB installed on every > headless image. It could be much more nicer and sexier > to have small kernel image with small dispatcher to which you can > connect and communicate with image remotely, > without need of carrying Morphic blob inside it. |
On 13 March 2011 02:17, Toon Verwaest <[hidden email]> wrote:
> I'm working on extracting everything to a model. DebuggerMethodMap is a mess > so we'll also have our own version of that class. Other methods that I found > too messy are rewritten in the model. > > Still work to be done, and Cog for linux doesn't like me committing code to > MC (it just crashes when I click save); so ... But it'll get there ;) Most > of the functionality is already there. You can use Stack interpreter VM https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Stack%20VM%20Unix/ which can open images saved by JIT-based one, and see if it can do things which leading to crash under JIT. > > Making it all remote shouldn't be too much of a problem. The debugger just > relies on the debugger model and a list of objects that represent the stack. > All actual evaluating actions can easily be forwarded over a proxy to the > remote model. > > cheers, > Toon > > On 03/13/2011 01:31 AM, Igor Stasenko wrote: >> >> On 2 March 2011 20:56, Adrian Lienhard<[hidden email]> wrote: >>> >>> On Mar 2, 2011, at 20:33 , Luc Fabresse wrote: >>> >>>>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of >>>>> Glamour. They got a first version working that is able to do basic >>>>> actions: >>>>> step, restart, step into. The challenge was to get to understand the >>>>> model, >>>>> and to figure out that<primitive: 19> is used for marking that a >>>>> method >>>>> should not be debugged. In any case, working with Glamour seemed to >>>>> work >>>>> quite smoothly. The code is available in the Glamorous Toolkit. Adrian, >>>>> did >>>>> I get it right? :) >>>>> >>>> Nick in CC worked a lot to understand the model part of the Debugger. >>>> He has worked on a remote debugger. >>>> @Nick, you should have a look probably at this implementation of a >>>> debugger >>>> in Glamour. >>>> AFAICR the Debugger code really mixes the model, the GUI, the Debugees, >>>> ... >>>> so perhaps you can all join forces and propose a cleaner and extensible >>>> debugger ;-) >>> >>> Indeed, an independent model would make a lot of sense. Since the >>> original logic is mixed with the GUI code, we just copied parts of it over >>> to our new prototype. By factoring this out into an independent model we >>> would not end up multiple copies for the original debugger, the Glomour >>> debugger, the OB debugger, the remote debugger etc. >>> >> even if you copy it, we still badly need remote tools. :) >> Because we really cannot rely on having RFB installed on every >> headless image. It could be much more nicer and sexier >> to have small kernel image with small dispatcher to which you can >> connect and communicate with image remotely, >> without need of carrying Morphic blob inside it. > > > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |