January 2016 - Pharo-dev - lists.pharo.org

[ann] spotter processors as settings

by Tudor Girba

Hi, We now have a new little feature in Spotter. Take a look: Basically, you will get a setting for each processor defined in the image. This happens dynamically. If you disable the setting, the processor will not be available anymore. Please give this a try and let us know what you think. We would also like a code review related to the way we deal with dynamic settings. Right now, the magic is done in GTSpotterExtensionSettings (this is real magic - read the class comment), but the current solution relies on a doesNotUnderstand: to maintain the list of disabled processors. I would more prefer it if we could create a DynamicSettingDeclaration that would be able to pass arguments to one central selector. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

Jan. 22, 2016

Re: [Pharo-dev] Pharo bootstrap

by phil＠highoctane.be

Craig, Apologies for being blunt, but supercool stuff that I know about but am not able to use is not of any use to me. >From my perspective, I am very frustrated to not be able to use: - Context in Pharo - Your remote running of tiny images in my Pharo browser (including the sonar ping sound when messages are landing remotely) - Using WebDav for looking into my images using your WebDav component That's a hell of a lot of super great tech that hasn't seen the light of day in the Pharo community (think being able to explore the image as a filesystem, edit the methods in Vim in a terminal [yes, this is actually cool to me], drag and drop binaries in these folders to import/export binary resources into the image). It is frustrating to see that what could turn into a superb capability of the tooling is running on your box but is not available for use by us (me) the common people. It is your code, you do what you want. I'd live to see it running (even super badly, which I don't think would be the case) on Pharo. Peace, Phil On Thu, Jan 21, 2016 at 7:39 PM, Craig Latta <craig(a)netjam.org> wrote: > > Hi Phil-- > > > ...prior art is not running on my environment. So, it is irrelevant > > for my current activities. > > You weren't talking about your current activities before, you were > talking about some allegedly innovative capability. > > At any rate, I do have versions of Context for Pharo and other > Smalltalks, which I intend to release this year. I wanted to deal with > SqueakJS after Squeak, then Pharo, then VisualWorks, etc. > > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > >

Jan. 22, 2016

Re: [Pharo-dev] another spotter question

by Ben Coman

On Fri, Jan 22, 2016 at 5:27 AM, stepharo <stepharo(a)free.fr> wrote: > > > 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> 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. For a while I have thought it would benefit from a thin grey triangle line, just to add a bit more feature to draw the attention. cheers -ben

Jan. 22, 2016

Re: [Pharo-dev] Use cases for methods with optional parameters

by Ben Coman

On Wed, Jan 20, 2016 at 11:08 PM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > Hi, > > I would like to study the impact of adding optional parameters to > keyword methods in Pharo. The goal of optional parameters is to > facilitate the implementation of methods where some parameters are > optional. For example, Seaside has: > > WAComponent>>request: aRequestString label: aLabelString > default: aDefaultString onAnswer: aBlock > > ... > > This method of 4 arguments has only 1 required argument (aRequestString) > and 3 optional ones. In the current implementation, this results in 7 > additional methods that only delegate directly or indirectly to the one > above: > > - request: > - request:default: > - request:default:onAnswer: > - request:label: > - request:label:default: > - request:label:onAnswer: > - request:onAnswer: > > Before starting to implement anything, I need to know if it makes sense. > If you want to help me, please send me all the use cases you have by > giving me: > > - the library name (and URL if not in Catalog), or "pharo" if it's in > Pharo > - the class where this happens > - the range of selectors that make sense > > For the example above, this would be: > > - Seaside > - WAComponent > - request:* I don't have any use cases right now, but I'll keep my eyes open. But an example (that is maybe too basic to mess with) is the #at:ifAbsent: pattern. For example, the following would be "deleted" Dictionary>>.at: key ^ self at: key ifAbsent: [self errorKeyNotFound: key] and you would only have.... Dictionary>>at: key ifAbsent: aBlock <optional: ifAbsent default: [ self errorKeyNotFound: key]> The big in-Image example would be... TClass>> subclass: aName uses: aTraitCompositionOrArray instanceVariableNames: someInstanceVariableNames classVariableNames: someClassVariableNames poolDictionaries: someSharedPoolNames package: aCategory <optional: uses default: {}> <optional: instanceVariableNames default: ''> <optional: classVariableNames default: ''> <optional: poolDictionaries default:''> <optional: package 'Unclassified'> Now I wonder about senders & implementers searchability, and if "virtual" methods are generated in all combinations of optional parameters and show up in the system browser list, but show the "main" method as their source. Maybe it works a little like traits. cheers -ben

Jan. 22, 2016

Re: [Pharo-dev] Pharo bootstrap

by Craig Latta

> > I am pretty sure that the people behind the Pharo Bootstrap project > > are aware of the existing literature. > > oh yes and even of things that were not written in papers. :) Papers are no longer the only way to publish, and paper-writers are still obligated to cite prior work however they become acquainted with it. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Jan. 21, 2016

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