- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Smalltalk website tricks

by Craig Latta

> Please guys use the Pharo-user mailing-list. I chose pharo-devel for the original post because I think it's relevant here. Pharo object memories could, should, and will be running on that virtual machine, too. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Jan. 21, 2016

Re: [Pharo-dev] Spotter suggestions

by stepharo

> You already stated your reasoning, and I understand it. I was just > making noise for people like Stef and me, who never use Shift unless > they HAVE TO. I like that I'm not alone. > >>>> The short list of implementors at the top level is usually noise >>>> and might have confused Stef. It becomes relevant once the message >>>> is fully specified. >>>> >>>> Diving in should be done with right arrow when at the end of the >>>> command line. >>>> Diving out with left arrow at the start of the command line. >>> I was wondering what is the benefit to have cmd - shit arrow vs arrow > > Not overloading unmodified right/left arrows sounds like an obvious > good idea. > > But as you already mentioned, Spotter is a special context, so one > needs to take a step back to evaluate the interaction possibilities. > > Typically, in the Spotter command line, I never use left-right arrows, > and I think this is common. If people mistype something, and have > immediate feedback, they tend to use backspace to fix it, instead of > in-line editing. > > Spotter is also very similar to a class browser like Nautilus, where > left-right arrows are the primary way to dive in and out of packages, > classes, protocols, methods. That makes right and left arrows > intuitive to dive in and out in Spotter. > > If right and left arrows dive in and out, it's very easy to cancel a > mistake, just immediately press the opposite arrow. That also means > that dive-out should remember what was the search line, so immediately > diving back in does not lose the previous input, as is the current > behaviour. Can you fix that? > > Cmd-arrows and Cmd-shift-arrows is uncommon, and it takes a conscious > effort to remember, it's not intuitive in any way. Yes luc told me that he never remembers. Me too :) And I would not say that luc is a newbie more a power user. > > Cmd-arrows and Cmd-shift-arrows are slow and hard to reach combinations. T 100% right > hey require me to move my left arm from the shoulder so left hand goes > to the modifier keys corner. Reaching arrows already requires me to > move my right arm so my right hand gets over the arrow pad. So every > time I want to dive in or out, I need to move both arms and completely > lose kinaesthetic connection with the home row. Then to continue > filtering I need to find the home row again. Repetitive switching > between home row and cmd-shift-arrows is frustrating at a deep, motor > level. That kind of frustration leads to angry people and the Dark Side. Me too :) No Luc I'm not your father (sorry a personal joke - ... luc will not read because of bandwidth problem but still). > > One could consider using Tab and Shift-Tab instead, but that would be > a bad choice. Tab should mean "autocomplete this", and in the context > of Spotter you cannot overload this with navigation. (I could expand > on that) > > I am not sure what you mean by "not contextual": I type some words, > use up/down arrows to choose the line I want, which is often not the > first one, then use right arrow to dive in. That is contextual: I am > looking at the list, I already have my hand on the arrow pad, I did a > vertical motion action and now I want to do an horizontal motion action. > > If you insist right-left arrow should not be overloaded in the search > line, then you could use the first down arrow to move out of "command > context" and into "matches context". Other actions like Enter and > Backspace need not depend on the context. But I am convinced it is not > necessary to make a distinction between command context and matches > context. > > At the very least, I would like some reassurance that the Spotter UI > machinery would make it easy for people like me to hack in the > interaction behaviour they expect from arrow keys. > >>>> >>>> When a list of paginated (only first N items), then the category >>>> line should be accessible with arrows, so we can dive into a >>>> category just with arrows. >> >> We explicitly chose not to do that because we did not want to mingle >> different kinds of elements in the same list. So, like this, when you >> press Cmd+Right, you will always dive in one single element, and not >> in many by mistake. > > I understand that. But I think it is the wrong trade-off. > > Diving into the wrong element with right arrow is cheap, just press > left arrow to dive out. That's easy to do and totally intuitive. > > To prevent a cheap, easily corrected mistake, you make one of the most > common actions significantly harder. That is bad UI design, sorry to > be harsh. > >> Actually, our original goal was to have a way to expand the list in >> place (not only to dive in category). For this we wanted a â¦ line and >> clicking on that would expand the list in place. We did not get to do >> it yet, but I think this would solve quite some of the reported problems. > > Expanding in place is a bad idea. Please do not do that. > > Categories often have dozens, sometimes hundreds of items. Once you > have expanded such a category, the rest of the list is essentially > lost, you need an easy way to cancel that, and that easy way is diving > out. Also when you are scrolling a long expanded list, you do NOT want > to scroll past the end and into another category, that would be > annoying, and not useful. > > What you do need is to make it easier NOT to have browse the full > categories at all. For that: > > * Prefix matches should be sorted in lexicographic order *of the > thing being matched* first, and its container second. > o "items" in the top search, should show implementors only for > "#items", there are a lot of them, and not things like > DialogGroupManagerUI>>#itemSelected. > * When a category is fully specified by #word ("items #i"), it > should display the full list. There should still be the ability to > dive into the category (retaining "items" in the command line), > But there is NO benefit in adding a layer of indirection. > * Non-prefix matches, or matches for a line containing multiple > words need fuzzy search relevance sorting with history > sensitivity. For exemple: > o "if else" should find ifNil:else:, ifTrue:else: etc. > o "m m" should find MenuMorph as one of the first results. Only > other classes whose two first two words start with M should > come before. > o "menu morph items" should find "#Implementors: MenuMorph>>#items" > > > Here's another few, unrelated, suggestion. For the top-level list: > > * When the line is empty: > o Display a short graphic cheat sheet. Not a wall of plain text, > something pretty with boxes and small bits of text that the > eye wants to read. > o That should explain # words and important action keys. > o That should provide a way to immediately dive into categories. > o Provide an easy way to disable the cheat sheet: a button "Do > not show me this" > * Do not use separate lists per category, but one list with all > matches, sorted by search proximity and with history sensitivity > o History sensitivity here is very beneficial, it effectively > lets one define custom shortcuts, by always using the same > letters to reach to frequently used items. For example in > Alfred on my Mac, "sl" finds "Sleep" first and "Slack" second. > o Categories can be displayed again by typing a single #. > * Keep the categories separated in the list after diving in, it is > essential for things like senders/implementors. > > > And some suggestion for all lists: > > * Please, please, GET RID OF VERTICAL WRAP AROUND, thanks. When I > hit the bottom of the list, I want to know I got there. > * When a non matching #word is typed ("#x"), the available #words > should be displayed, not the empty list. > * When moving into category with arrow up/down, please scroll more. > If the category list is long compared to the scroller viewport, at > 50-75% of the viewport should display the category I just moved in. > * Scrolling should probably be a bit optimistic. Unless we are at > the end of the list, the current line should never be the first or > last displayed, unless the viewport is very small. > * When the current category name is out of the viewport, it should > stick at the top, maybe with some transparency gradient over the > first item, I need to know what category I am in. It is especially > important when scrolling up, after overshooting. > > I hope you are familiar with Alfred (Mac only) and Sublime Text. They > both provide very useful fuzzy search with history sensitivity. > >> But, please do keep challenging. And give it a try with writing your >> own processors. It would help us a lot. > > Right now, I keep bouncing in all sorts of bugs in other packages. Which one? We should kill them. > So I am rather happy to just provide feedback for enhancements, so I > can spend more time fixing the actual bugs. :-) > > Regards.

Jan. 21, 2016

Re: [Pharo-dev] [ANN] Pharo bootstrap

by Tudor Girba

Hi, > On Jan 21, 2016, at 9:48 PM, stepharo <stepharo(a)free.fr> wrote: > > reducing also the number of classes in the kernel could help. > But first it should work and then we start to optimize > Now this is true that 10 h is insane :) Itâs not insane. Itâs a first solution :) Doru > > Le 20/1/16 09:08, Christophe Demarey a Ã©crit : >> Hi Pavel, >> >> Le 19 janv. 2016 Ã 19:53, Pavel Krivanek a Ã©crit : >> >>> Hi, >>> >>> amazing! Do you have any idea how to speed up it? The bootstrap process is now running on my machine about one and half hour and it is still far from finish. >> >> The process is indeed far too long (takes around 10 hours) on the CI server. >> Reasons are: >> - we use a stack interpreter VM >> - we modified it and is a bit slower than a classical stack VM >> - we use AST interpretation to build the bootstrap and it is very slow. Guille already did some speed improvements by avoiding to interpret loops by example. >> >> I did not yet spend time on this point because I first wanted to have something working. >> Definitely, this problem will be tackled when we will put in production the bootstrap. >> >> Cheers, >> Christophe >> >> >>> Cheers, >>> -- Pavel >>> >>> 2016-01-19 15:29 GMT+01:00 Christophe Demarey <christophe.demarey(a)inria.fr>: >>> Hi all, >>> >>> In case you do not know, we work on bootstrapping Pharo, i.e. create a Pharo image from sources, not based on a previous image (well, we use a pharo image to produce it but no code / state from it). >>> >>> This process will allow to define a minimal Pharo kernel (currently 52 packages but we could have it far smaller) and to modularize the whole image (currently packages have too much dependencies on packages already loaded into the image). >>> The bootstrap process also allows to write down the recipe to initialize a new image from scratch (some code is missing in the image or is wrong). In addition, I think we will clean a lot of historical objects that are not used anymore. >>> >>> With the amazing work done by Guillermo Polito during his Phd (around Espell, Oz): https://guillep.github.io/files/publications/Poli15Thesis.pdf, we succeeded to get a first prototype of a bootstraped Pharo 5 image (from 5.392). >>> This prototype is able to run an eval command line handler and to log output / errors. Not all classes are yet initialized and you cannot yet save / restart this image but it is a big step forward. >>> It is a 4 mb image (could be half the size without unicode data). You can download it at: http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/pharo-bootstrap/pharo-…. >>> >>> Next steps are to have a bootstrapped image fully working, then to load packages on top of it (like network, sunit) to produce a minimal image. >>> Then, we need to implement an Oz VM on top of Spur. >>> After that, we need to work on a reliable way to build the bootstrap (not too sensitive to changes in the image). >>> >>> Christophe. >>> >>> ------- >>> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ ../pharo bootstrap.image --no-default-preferences eval "1 + 1" >>> 2 >>> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ ../pharo bootstrap.image --no-default-preferences eval "'a' , 'b'" >>> 'ab' >>> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ ../pharo bootstrap.image --no-default-preferences eval "1 / 0" >>> ZeroDivide >>> SmallInteger>>/ >>> UndefinedObject>>DoIt >>> OpalCompiler>>evaluate >>> OpalCompiler(AbstractCompiler)>>evaluate: >>> SmalltalkImage>>evaluate: >>> >>> EvaluateCommandLineHandler>>no (source is Undeclared) >>> no source in EvaluateCommandLineHandler>>evaluate: in Block: no source >>> BlockClosure>>on:do: >>> EvaluateCommandLineHandler>>evaluate: >>> EvaluateCommandLineHandler>>evaluateArguments >>> EvaluateCommandLineHandler>>activate >>> EvaluateCommandLineHandler class(CommandLineHandler class)>>activateWith: >>> >>> BasicCommandLineHandler>>no (source is Undeclared) >>> no source in PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: no source >>> BlockClosure>>on:do: >>> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand >>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: >>> >>> BasicCommandLineHandler>>no (source is Undeclared) >>> no source in PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: no source >>> BlockClosure>>on:do: >>> PharoCommandLineHandler(BasicCommandLineHandler)>>activate >>> PharoCommandLineHandler>>activate >>> PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: >>> >>> PharoCommandLineHandler class>>no (source is Undeclared) >>> no source in PharoCommandLineHandler class>>activateWith: in Block: no source >>> NonInteractiveUIManager(UIManager)>>defer: >>> PharoCommandLineHandler class>>activateWith: >>> no source in BasicCommandLineHandler>>activateSubCommand: in Block: no source >>> BlockClosure>>on:do: >>> BasicCommandLineHandler>>activateSubCommand: >>> BasicCommandLineHandler>>handleSubcommand >>> BasicCommandLineHandler>>handleArgument: >>> no source in BasicCommandLineHandler>>activate in Block: no source >>> >>> SmallInteger>>no (source is Undeclared) >>> >>> UndefinedObject>>no (source is Undeclared) >>> >>> AbstractCompiler>>no (source is Undeclared) >>> >>> SmalltalkImage>>no (source is Undeclared) >>> >>> BlockClosure>>no (source is Undeclared) >>> >>> EvaluateCommandLineHandler>>no (source is Undeclared) >>> >>> EvaluateCommandLineHandler>>no (source is Undeclared) >>> >>> CommandLineHandler class>>no (source is Undeclared) >>> >>> BasicCommandLineHandler>>no (source is Undeclared) >>> >>> BasicCommandLineHandler>>no (source is Undeclared) >>> >>> PharoCommandLineHandler>>no (source is Undeclared) >>> >>> UIManager>>no (source is Undeclared) >>> >>> UndefinedObject>>no (source is Undeclared) >>> >>> CommandLineUIManager>>no (source is Undeclared) >>> >>> SmalltalkImage>>no (source is Undeclared) >>> >>> DelayMicrosecondScheduler>>no (source is Undeclared) >>> >>> BlockClosure>>no (source is Undeclared) >>> >>> SmalltalkImage>>no (source is Undeclared) >>> >>> WeakArray class>>no (source is Undeclared) >>> >>> >>> ps: source cannot be displayed because there is no formatter available in the bootstrap >>> >>> >> > -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

Jan. 21, 2016

Re: [Pharo-dev] Spotter suggestions

by stepharo

Le 20/1/16 10:39, David Allouche a Ã©crit : > Since you asked to keep challengingâ¦ > > Preamble: Sorry, I did one of those long messages again. I hope I am > not annoying people with that. Not at all thanks for sharing that. I appreciate that you take the time to write it because I'm a lot more intuitive and have not the time fully develop my gut feeling. So I sound harsh and at the end I do not use the features. And people get sad when I say it. Stef

Jan. 21, 2016

Re: [Pharo-dev] another spotter question

by stepharo

Le 20/1/16 14:30, Aliaksei Syrel a Ã©crit : > On Wed, Jan 20, 2016 at 12:59 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > +1. Its annoying that it takes two clicks to dive into categories > like "Implementors" (one to click an item under the category to > make the arrow appear, and then another to click on it) when it > would only take one if that arrow for each category was always > visible. > > > Doru is right, always visible arrows would pollute UI. I do not see why. A user interface is not something that we should click randomly at to learn how to use it. > A compromise solution would be to show them on mouse hover - one click > + not overcrowded interface. may be but you can ask yourselves why so many people do not get how to use Spotter. I asked again today to people how to show the pane on the right and nobody knew obviously. > > Cheers, > Alex

Jan. 21, 2016

Re: [Pharo-dev] Rationale for RGClassDefinition>>definition?

by stepharo

016-01-21 9:07 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > > I do not know now I would have love that veronica believed in tests. > the difference is the following > > > a RG cna either > - wrap and point to a living entity > - acts a dead one (representing a class on a disk) > > > Yes, I was about to add a check for isActive/isPassive for > RGClassDefinition, but this isAcitve/isPassive is only > defined for Ringmethods not for Ring class (or behavior) definitions. I think that we should add it to classes too. In fact we should consider ring as a first try and it is in our plan to revisit it but too busy.

Jan. 21, 2016

Re: [Pharo-dev] Bad layoutFrame>>#hash

by stepharo

It is neat :) Le 21/1/16 11:18, Henrik Nergaard a Ã©crit : > What about something like this? > > > ^self species hash hashComposer > add: leftFraction; > add: leftOffset; > add: topFraction; > add: topOffset; > add: rightOffset; > add: bottomFraction; > add: bottomOffset > > HashComposer>>#add: anObject > > ^hash := (hash + anObject hash) hashMultiply > > > Best regards, > Henrik > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont > Sent: Wednesday, January 13, 2016 8:34 PM > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Bad layoutFrame>>#hash > > On 13-01-16 18:38, David Allouche wrote: >> Why did you use a single expression instead of using a temporary variable? I find it harder to understand. > I did find it very slightly easier to understand. It is not a strong opinion however. > > The ideomatic smalltalk would be > > ^#(leftFraction leftOffset topFraction topOffset rightFraction rightOffset bottomFraction bottomOffset) > inject: self species hash into: [:hashValue :selector | > (hashValue + self perform: selector) hashMultiply ] > > but that would be slower. > > I would be tempted to add a binary message > > Integer>>+** aNumber > ^(aNumber +self hash) hashMultiply > > (I'd prefer +#*, but that doesn't parse) > > hash > ^self species hash +** > leftFraction +** leftOffset +** > topFraction +** topOffset +** > rightFraction +** rightOffset +** > bottomFraction +** bottomOffset > > > > Stephan > > > >

Jan. 21, 2016

Re: [Pharo-dev] ESUG '16?

by stepharo

I will take place at Prague and the dates are about to be announced because there were some bugs in the hotel quotes! Le 21/1/16 14:42, Alexandre Bergel a Ã©crit : > Hi! > > Anyone know when ESUGâ16 will take place? > > Alexandre

Jan. 21, 2016

Re: [Pharo-dev] [ANN] GitHub API Bindings: new version

by stepharo

Excellent Job Skip!!! Great Documentation. Stef Le 21/1/16 11:30, Skip Lentz a Ã©crit : > Hi everyone, > > I am announcing a new version for the API bindings to GitHub in Pharo. > For documentation and information on how to load it, see the new > project homepage: > > https://balletie.github.io/GitHub/ (generated with Pillar. Plug for > Damien and Cyril) > > For a list of changes in this release, follow this link: > https://github.com/Balletie/GitHub/releases/tag/v0.5 > > To load absolutely everything, including the tests and the tool, evaluate: > > Metacello new > baseline: 'GitHub'; > repository: 'github://Balletie/GitHub:master' > <github://Balletie/GitHub:master%27>; > load: #(tests tool) > > If you have loaded the tool, it can be opened via the world > menu, under âToolsâ. > > Feedback welcome :)

Jan. 21, 2016

Re: [Pharo-dev] [ANN] Pharo bootstrap

by stepharo

reducing also the number of classes in the kernel could help. But first it should work and then we start to optimize Now this is true that 10 h is insane :) Le 20/1/16 09:08, Christophe Demarey a Ã©crit : > Hi Pavel, > > Le 19 janv. 2016 Ã 19:53, Pavel Krivanek a Ã©crit : > >> Hi, >> >> amazing! Do you have any idea how to speed up it? The bootstrap >> process is now running on my machine about one and half hour and it >> is still far from finish. > > The process is indeed far too long (takes around 10 hours) on the CI > server. > Reasons are: > - we use a stack interpreter VM > - we modified it and is a bit slower than a classical stack VM > - we use AST interpretation to build the bootstrap and it is very > slow. Guille already did some speed improvements by avoiding to > interpret loops by example. > > I did not yet spend time on this point because I first wanted to have > something working. > Definitely, this problem will be tackled when we will put in > production the bootstrap. > > Cheers, > Christophe > > >> Cheers, >> -- Pavel >> >> 2016-01-19 15:29 GMT+01:00 Christophe Demarey >> <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>>: >> >> Hi all, >> >> In case you do not know, we work on bootstrapping Pharo, i.e. >> create a Pharo image from sources, not based on a previous image >> (well, we use a pharo image to produce it but no code / state >> from it). >> >> This process will allow to define a minimal Pharo kernel >> (currently 52 packages but we could have it far smaller) and to >> modularize the whole image (currently packages have too much >> dependencies on packages already loaded into the image). >> The bootstrap process also allows to write down the recipe to >> initialize a new image from scratch (some code is missing in the >> image or is wrong). In addition, I think we will clean a lot of >> historical objects that are not used anymore. >> >> With the amazing work done by Guillermo Polito during his Phd >> (around Espell, Oz): >> https://guillep.github.io/files/publications/Poli15Thesis.pdf, >> *we succeeded to get a first prototype of a bootstraped Pharo 5 >> image (from 5.392)*. >> This prototype is able to run an eval command line handler and to >> log output / errors. Not all classes are yet initialized and you >> cannot yet save / restart this image but it is a big step forward. >> It is a 4 mb image (could be half the size without unicode data). >> You can download it at: >> http://chercheurs.lille.inria.fr/~demarey/pmwiki/pub/pharo-bootstrap/pharo-… >> <http://chercheurs.lille.inria.fr/%7Edemarey/pmwiki/pub/pharo-bootstrap/phar…>. >> >> Next steps are to have a bootstrapped image fully working, then >> to load packages on top of it (like network, sunit) to produce a >> minimal image. >> Then, we need to implement an Oz VM on top of Spur. >> After that, we need to work on a reliable way to build the >> bootstrap (not too sensitive to changes in the image). >> >> Christophe. >> >> ------- >> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ >> ../pharo bootstrap.image --no-default-preferences eval "1 + 1" >> 2 >> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ >> ../pharo bootstrap.image --no-default-preferences eval "'a' , 'b'" >> 'ab' >> demarey@193-51-236-143:~/dev/rmod/bootstrap/bootstrap-2016-01-19$ >> ../pharo bootstrap.image --no-default-preferences eval "1 / 0" >> ZeroDivide >> SmallInteger>>/ >> UndefinedObject>>DoIt >> OpalCompiler>>evaluate >> OpalCompiler(AbstractCompiler)>>evaluate: >> SmalltalkImage>>evaluate: >> >> EvaluateCommandLineHandler>>no (source is Undeclared) >> no source in EvaluateCommandLineHandler>>evaluate: in Block: no >> source >> BlockClosure>>on:do: >> EvaluateCommandLineHandler>>evaluate: >> EvaluateCommandLineHandler>>evaluateArguments >> EvaluateCommandLineHandler>>activate >> EvaluateCommandLineHandler class(CommandLineHandler >> class)>>activateWith: >> >> BasicCommandLineHandler>>no (source is Undeclared) >> no source in >> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >> in Block: no source >> BlockClosure>>on:do: >> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: >> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand >> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: >> >> BasicCommandLineHandler>>no (source is Undeclared) >> no source in >> PharoCommandLineHandler(BasicCommandLineHandler)>>activate in >> Block: no source >> BlockClosure>>on:do: >> PharoCommandLineHandler(BasicCommandLineHandler)>>activate >> PharoCommandLineHandler>>activate >> PharoCommandLineHandler class(CommandLineHandler >> class)>>activateWith: >> >> PharoCommandLineHandler class>>no (source is Undeclared) >> no source in PharoCommandLineHandler class>>activateWith: in >> Block: no source >> NonInteractiveUIManager(UIManager)>>defer: >> PharoCommandLineHandler class>>activateWith: >> no source in BasicCommandLineHandler>>activateSubCommand: in >> Block: no source >> BlockClosure>>on:do: >> BasicCommandLineHandler>>activateSubCommand: >> BasicCommandLineHandler>>handleSubcommand >> BasicCommandLineHandler>>handleArgument: >> no source in BasicCommandLineHandler>>activate in Block: no source >> >> SmallInteger>>no (source is Undeclared) >> >> UndefinedObject>>no (source is Undeclared) >> >> AbstractCompiler>>no (source is Undeclared) >> >> SmalltalkImage>>no (source is Undeclared) >> >> BlockClosure>>no (source is Undeclared) >> >> EvaluateCommandLineHandler>>no (source is Undeclared) >> >> EvaluateCommandLineHandler>>no (source is Undeclared) >> >> CommandLineHandler class>>no (source is Undeclared) >> >> BasicCommandLineHandler>>no (source is Undeclared) >> >> BasicCommandLineHandler>>no (source is Undeclared) >> >> PharoCommandLineHandler>>no (source is Undeclared) >> >> UIManager>>no (source is Undeclared) >> >> UndefinedObject>>no (source is Undeclared) >> >> CommandLineUIManager>>no (source is Undeclared) >> >> SmalltalkImage>>no (source is Undeclared) >> >> DelayMicrosecondScheduler>>no (source is Undeclared) >> >> BlockClosure>>no (source is Undeclared) >> >> SmalltalkImage>>no (source is Undeclared) >> >> WeakArray class>>no (source is Undeclared) >> >> >> ps: source cannot be displayed because there is no formatter >> available in the bootstrap >> >> >

Jan. 21, 2016