Hello Ken,
KGB> One thing that really bothered me when first starting out KGB> with Squeak, was the requirement for modifying code in order add KGB> 'self halt' to work with the debugger. select some code, right click and select "Debug it". That's even better than putting "0 halt" (saves 3 keystrokes) into the code as you don't have to select the (usually) second line in the notifier. Took me long to try this :-)) Cheers, Herbert |
--- In [hidden email], Herbert König <herbertkoenig@...> wrote:
> > Hello Ken, > > KGB> One thing that really bothered me when first starting out > KGB> with Squeak, was the requirement for modifying code in order add > KGB> 'self halt' to work with the debugger. > > select some code, right click and select "Debug it". > > That's even better than putting "0 halt" (saves 3 keystrokes) into the > code as you don't have to select the (usually) second line in the > notifier. > > Took me long to try this :-)) > > Cheers, > > Herbert > Yes, that is the way to get started alright. However when first learning about Squeak, I would do that, then step through things in some detail the first time to see what was going on, but once you get so far along, you don't want to go through that long process again, so you still need to insert a self halt from the Debugger at whatever interesting point you are at, so you can get back there again. I don't see any way to set a breakpoint on a method of interest while in the Debugger, maybe I'm missing it. Ken G. Brown |
In reply to this post by Bert Freudenberg
--- In [hidden email], Bert Freudenberg <bert@...> wrote:
> > > On 09.04.2008, at 12:03, Andreas Wacknitz wrote: > > > > Am 09.04.2008 um 18:59 schrieb Ken G. Brown: > > > >> One thing that really bothered me when first starting out with > >> Squeak, was the requirement for modifying code in order add 'self > >> halt' to work with the debugger. > >> I still find that to be bothersome. Intuitively it seems to me that > >> breakpoints should have no way to modify code. > >> > > Yes, that is a point that annoys me, too. > > Even Dolphin Smalltalk has this drawback, but there is a > > sophisticated solution in Tools+ (by Solutions Software) called > > Method Spies. > > > Actually, Squeak has break points. Click on a method in the system > browser, and choose "toggle break on entry". > > Problem is the highlighting in the method list has been broken for > some while, methods with break points used to be marked. > > - Bert - > Well, 'toggle breakpoint on entry' also seems to be missing from the default System Browser in latest 3.10 dev image too. And there isn't any World menu selection to open the regular System Browser that has it. You can overcome that by doing 'Browser open' in a Workspace to get the 'toggle breakpoint on entry' at which point you have two different browsers with the same title, with different functionality. Wonder what the rationale is for the inconsistency in Browser types vs naming? In any case, it would be nice to be able to set a breakpoint on a method whilst in the Debugger. Bet you could whip that up in no time Bert! :) Ken G. Brown |
On 09.04.2008, at 13:19, kengbrown wrote: > --- In [hidden email], Bert Freudenberg <bert@...> wrote: >> >> >> On 09.04.2008, at 12:03, Andreas Wacknitz wrote: >>> >>> Am 09.04.2008 um 18:59 schrieb Ken G. Brown: >>> >>>> One thing that really bothered me when first starting out with >>>> Squeak, was the requirement for modifying code in order add 'self >>>> halt' to work with the debugger. >>>> I still find that to be bothersome. Intuitively it seems to me that >>>> breakpoints should have no way to modify code. >>>> >>> Yes, that is a point that annoys me, too. >>> Even Dolphin Smalltalk has this drawback, but there is a >>> sophisticated solution in Tools+ (by Solutions Software) called >>> Method Spies. >> >> >> Actually, Squeak has break points. Click on a method in the system >> browser, and choose "toggle break on entry". >> >> Problem is the highlighting in the method list has been broken for >> some while, methods with break points used to be marked. >> >> - Bert - >> > > Well, 'toggle breakpoint on entry' also seems to be missing from the > default System > Browser in latest 3.10 dev image too. And there isn't any World > menu selection to open > the regular System Browser that has it. You can overcome that by > doing 'Browser open' in > a Workspace to get the 'toggle breakpoint on entry' at which point > you have two different > browsers with the same title, with different functionality. > > Wonder what the rationale is for the inconsistency in Browser types > vs naming? > > In any case, it would be nice to be able to set a breakpoint on a > method whilst in the > Debugger. Bet you could whip that up in no time Bert! :) That is already there. The same "toggle break on entry" menu item is in the debugger's method list. - Bert - |
--- In [hidden email], Bert Freudenberg <bert@...> wrote:
> > > On 09.04.2008, at 13:19, kengbrown wrote: > > --- In [hidden email], Bert Freudenberg <bert@> wrote: > >> > >> > >> On 09.04.2008, at 12:03, Andreas Wacknitz wrote: > >>> > >>> Am 09.04.2008 um 18:59 schrieb Ken G. Brown: > >>> > >>>> One thing that really bothered me when first starting out with > >>>> Squeak, was the requirement for modifying code in order add 'self > >>>> halt' to work with the debugger. > >>>> I still find that to be bothersome. Intuitively it seems to me that > >>>> breakpoints should have no way to modify code. > >>>> > >>> Yes, that is a point that annoys me, too. > >>> Even Dolphin Smalltalk has this drawback, but there is a > >>> sophisticated solution in Tools+ (by Solutions Software) called > >>> Method Spies. > >> > >> > >> Actually, Squeak has break points. Click on a method in the system > >> browser, and choose "toggle break on entry". > >> > >> Problem is the highlighting in the method list has been broken for > >> some while, methods with break points used to be marked. > >> > >> - Bert - > >> > > > > Well, 'toggle breakpoint on entry' also seems to be missing from the > > default System > > Browser in latest 3.10 dev image too. And there isn't any World > > menu selection to open > > the regular System Browser that has it. You can overcome that by > > doing 'Browser open' in > > a Workspace to get the 'toggle breakpoint on entry' at which point > > you have two different > > browsers with the same title, with different functionality. > > > > Wonder what the rationale is for the inconsistency in Browser types > > vs naming? > > > > In any case, it would be nice to be able to set a breakpoint on a > > method whilst in the > > Debugger. Bet you could whip that up in no time Bert! :) > > > That is already there. The same "toggle break on entry" menu item is > in the debugger's method list. > > - Bert - > Well I just tried that and I don't seem to get it to do anything. eg. OBUBrowser open. , debug it from a Workspace, click 'into', see open in the message list at the top, do 'toggle break on entry' when the 'open' line is highlighted, start over in the debugger or doit from the Workspace again, the operation proceeds to completion. Ken G. Brown |
On 09.04.2008, at 14:10, kengbrown wrote: > --- In [hidden email], Bert Freudenberg <bert@...> wrote: >> >> >> On 09.04.2008, at 13:19, kengbrown wrote: >>> --- In [hidden email], Bert Freudenberg <bert@> wrote: >>>> >>>> >>>> On 09.04.2008, at 12:03, Andreas Wacknitz wrote: >>>>> >>>>> Am 09.04.2008 um 18:59 schrieb Ken G. Brown: >>>>> >>>>>> One thing that really bothered me when first starting out with >>>>>> Squeak, was the requirement for modifying code in order add 'self >>>>>> halt' to work with the debugger. >>>>>> I still find that to be bothersome. Intuitively it seems to me >>>>>> that >>>>>> breakpoints should have no way to modify code. >>>>>> >>>>> Yes, that is a point that annoys me, too. >>>>> Even Dolphin Smalltalk has this drawback, but there is a >>>>> sophisticated solution in Tools+ (by Solutions Software) called >>>>> Method Spies. >>>> >>>> >>>> Actually, Squeak has break points. Click on a method in the system >>>> browser, and choose "toggle break on entry". >>>> >>>> Problem is the highlighting in the method list has been broken for >>>> some while, methods with break points used to be marked. >>>> >>>> - Bert - >>>> >>> >>> Well, 'toggle breakpoint on entry' also seems to be missing from the >>> default System >>> Browser in latest 3.10 dev image too. And there isn't any World >>> menu selection to open >>> the regular System Browser that has it. You can overcome that by >>> doing 'Browser open' in >>> a Workspace to get the 'toggle breakpoint on entry' at which point >>> you have two different >>> browsers with the same title, with different functionality. >>> >>> Wonder what the rationale is for the inconsistency in Browser types >>> vs naming? >>> >>> In any case, it would be nice to be able to set a breakpoint on a >>> method whilst in the >>> Debugger. Bet you could whip that up in no time Bert! :) >> >> >> That is already there. The same "toggle break on entry" menu item is >> in the debugger's method list. >> >> - Bert - >> > > Well I just tried that and I don't seem to get it to do anything. > eg. OBUBrowser open. , debug it from a Workspace, click 'into', see > open in the message > list at the top, do 'toggle break on entry' when the 'open' line is > highlighted, start over in > the debugger or doit from the Workspace again, the operation > proceeds to completion. > > Ken G. Brown Works for me in a 3.8-based image. Guess you need to file a bug ... - Bert - |
In reply to this post by Ken G. Brown
On Wed, Apr 9, 2008 at 5:10 PM, kengbrown <[hidden email]> wrote:
|
In reply to this post by Ken G. Brown
On 09.04.2008 22:19, kengbrown wrote: I'm running Squeak3.10.gamma.7159.--- In [hidden email], Bert Freudenberg [hidden email] wrote:On 09.04.2008, at 12:03, Andreas Wacknitz wrote:Am 09.04.2008 um 18:59 schrieb Ken G. Brown:One thing that really bothered me when first starting out with Squeak, was the requirement for modifying code in order add 'self halt' to work with the debugger. I still find that to be bothersome. Intuitively it seems to me that breakpoints should have no way to modify code.Yes, that is a point that annoys me, too. Even Dolphin Smalltalk has this drawback, but there is a sophisticated solution in Tools+ (by Solutions Software) called Method Spies.Actually, Squeak has break points. Click on a method in the system browser, and choose "toggle break on entry". Problem is the highlighting in the method list has been broken for some while, methods with break points used to be marked. - Bert -Well, 'toggle breakpoint on entry' also seems to be missing from the default System Browser in latest 3.10 dev image too. And there isn't any World menu selection to open the regular System Browser that has it. You can overcome that by doing 'Browser open' in a Workspace to get the 'toggle breakpoint on entry' at which point you have two different browsers with the same title, with different functionality. Wonder what the rationale is for the inconsistency in Browser types vs naming? In any case, it would be nice to be able to set a breakpoint on a method whilst in the Debugger. Bet you could whip that up in no time Bert! :) Ken G. Brown I had no idea that Squeak has a breakpoint feature. The feature doesn't seem to work: I get the good olde Browser from the Tools flap I get the more modern OBBrowser from the world menu open... , selecting 'class browser' Both have the 'toggle break on entry' command in the operations list menu. Nothing happens when I select this command in either browser ??? Does it work at all??? Diving into the code, I find that the entry in the operations list should have turned into italics, but it doesn't I'm not a newcomer, but was turned off from even trying this feature. (BTW: The first I did when I started using Traits in earnest was to change the OBBrowser window title to 'OBBrowser ...' so that I could see the difference.) Cheers --Trygve --
Trygve
Reenskaug mailto: [hidden email] Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378
Oslo Tel: (+47) 22 49 57 27 Norway |
In reply to this post by David Goehrig
On Tue, 08 Apr 2008 00:15:39 +0200, David J. Goehrig wrote:
> Andreas Wacknitz wrote: >> And many of the newcomers get alienated by many aspects of Squeak: >> - it is hard to find documentation >> - it is hard to get used to Morphic (its power isn't obvious but >> its clutter is) >> - it is hard to find a Squeak version with not so many obvious >> bugs and problems > Long time lurker here, > > Short answer: (For those who don't want to read the post) > > Newcomers are turned off by seemingly irreducible complexity of the > system; Squeak need continual refactoring. May I add, w.r.t. the menu item position of "remove (x)" in the other thread. For me as an oldtimer there are only two rules, a] + b], for arranging menu items: a] productivity 1 - adding a new category, class, method, has more productive than anything else 2 - finding a thing you know how to spell 3 - searching for a thing you don't know how to spell 4 - copy,cut,paste & doIt,printIt & other sub-tools 5 - organizing your work (rename, etc) 6 - removing the unwanted b] the divine words of the goods of our language, for example the arrangement of the menu items found in the text editor pane (Transcript or Workspace); they do define the default resp. overrule a]. Rule b] has importance when you consider all the publications, tutorials, etc, in which menu items are mentioned and/or documented. I think that the position of menu items must be as-consistent-as-possible accross all available tools, otherwise the newcomers won't feel comfortable. ------------ That is not to say that there should be no customization possible for the user but, I haven't seen any. ------------ Please do not hesitate and post your suggestions and observations with menu item positions. /Klaus |
> Please do not hesitate and post your suggestions and > observations with > menu item positions. > > /Klaus > Then here is mine: Smalltalk has excellent heuristics scoring by design probably one of the best at programing level but IMHO we seriusly need help of designer/s who understand about usability and UI design and we need to hear their opinions to see where to start stating priorities. This is *a must* lecture, to be made slow and consciously, for any developer whom may build a interface for any piece of software no matter the technology or medium (web, desktop, mobile, etc): http://www.useit.com/papers/heuristic/heuristic_list.html http://www.asktog.com/basics/firstPrinciples.html About the menus I think they have to be reviewed so they demostrate respect to this basic design principles. The goal must be no other than the analogous psychological effect of entering in a shopping center (or any clean and safe environment) where you can read, watch, consume and produce ideas (automated thoughts aka software). I understand the size of the challenge but that does not invalidates the fact squeak has a lot to improve in the field of usability. cheers, Sebastian Sastre |
On Fri, 11 Apr 2008 23:38:14 +0200, Sebastian Sastre wrote:
> >> Please do not hesitate and post your suggestions and >> observations with >> menu item positions. >> >> /Klaus >> > > Then here is mine: Smalltalk has excellent heuristics scoring by design > probably > one of the best at programing level but IMHO we seriusly need help of > designer/s > who understand about usability and UI design and we need to hear their > opinions > to see where to start stating priorities. > > This is *a must* lecture, to be made slow and consciously, for any > developer > whom may build a interface for any piece of software no matter the > technology or > medium (web, desktop, mobile, etc): > > http://www.useit.com/papers/heuristic/heuristic_list.html > http://www.asktog.com/basics/firstPrinciples.html > > About the menus I think they have to be reviewed so they demostrate > respect to > this basic design principles. > > The goal must be no other than the analogous psychological effect of > entering in > a shopping center (or any clean and safe environment) where you can > read, watch, > consume and produce ideas (automated thoughts aka software). A good idea but, design by psychological "rationale" is too far away from my everyday's work (though I *love* psychedelic art :) How about starting with a MenuItemsAndLists Customizer tool, for the hands of UI designers, the model of which every tool must be conformant to ? > I understand the size of the challenge but that does not invalidates the > fact > squeak has a lot to improve in the field of usability. > > cheers, > > Sebastian Sastre > > > |
> The goal must be no other than the analogous psychological
Most probably tools will be useful, but be cautious on doing something too
> effect of > > entering in > > a shopping center (or any clean and safe environment) where > you can > > read, watch, > > consume and produce ideas (automated thoughts aka software). > > A good idea but, design by psychological "rationale" is too > far away from > my everyday's work (though I *love* psychedelic art :) > > How about starting with a MenuItemsAndLists Customizer tool, > for the hands > of UI designers, the model of which every tool must be conformant to ? > early. My previous email was intentionally wrote to sensibilize about the lack of bird's eye about usability. We need more Squeakers (that's us) to be conscious and aware of the big picture of the issue before stating priorities and investing efforts. In the usability subject I see some improvments in the rigth direction: the OmniBrowser-Full(0.25) and eCompletion, shout, and refactory. That's why the public have an inclination to choose Squeak "distros" of Damien C. or Ramon L. they want to consume "one click experiences". If more authors are aware of how to *build* usability we will found N more usability gems like (just to mention one) the #flag: message. Observe its effect in detail: such a simple feature, which draws a little icon on a method, can be the fundation of better comunicability among Squeak developers working on a common project thousands kms/miles away. Have in mind they may be unable to seat face to face to quickly discuss and set next steps and this is a great palliation for that problem. Sounds familiar? And speculating about which consequences will have a Squeak with a high score in usability I can't see other but benefits for all: squeakers, squeaker users, the smalltalk community, smalltalk newcomers and finally the industry. It's an all win situation and is not necessarily onerous. In short all I'm saying is maybe usability is being underestimated by us and if we reflect on this **I'm absolutely confident** we will find the way to do better. Usability can be constructed and we know how to construct things because we where attracted by a machine useful to invent the future. cheers, Sebastian |
In reply to this post by Sebastian Sastre-2
Sebastian Sastre wrote:
> The goal must be no other than the analogous psychological effect of entering in > a shopping center (or any clean and safe environment) where you can read, watch, > consume and produce ideas (automated thoughts aka software). Good idea - but you need to choose which shopping center you want to look like (if not behave like, in certain aspects at least). So, what is going to be the role model? Eclipse/Netbeans? Another Smalltalk (Dolphin, VSE, VAST, VW, ST/X) IDE? I would say Eclipse, for its probably the most commonly used IDE. Speaking of IDE - I am using Seaside together with a WebDev Image, and there is one thing that bothers me. In the standard OBSystemBrowser, if you go to the variables tab, you get the variables browser. Then you add an instance variable, the pane is refreshed. If you add the accessor methods, it is not refreshed, i.e. there is no control refresh after the model update. I tried to find where that might be but failed, unfortunately :( Anyhow, keep up the good work, Squeak is really nice. Cheers, Claus |
In reply to this post by timrowledge
On Mon, Apr 7, 2008 at 8:31 PM, tim Rowledge <[hidden email]> wrote:
> > So far as I can see the only way that major work has been done in/for Squeak > is when someone is funding a sizeable project and it includes a subsystem > that can be spun out for general use. Financial backing is the way most projects get anything useful done. How could it be otherwise. >From http://www.linuxdevices.com/news/NS6925891609.html : "Another interesting finding is that between 70 and 95 percent of contributing developers are paid for their work. Indeed, Linux has become something of a corporate beast over the years,".... |
Free forum by Nabble | Edit this page |