April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo and the rest of the ecosystem

by Igor Stasenko

Want X run on Y? Do it. Port it, implement it. Why asking or blaming someone for not paying attention to your needs if you can do it yourself? I find this approach strange. Do original authors of pharo/cuis/whatever owe you something? -- Best regards, Igor Stasenko.

April 24, 2012

Re: [Pharo-project] Block questions

by Eliot Miranda

On Sat, Apr 21, 2012 at 12:51 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Thanks eliot > > I'm refreshing my fuzzy understanding of closure implementation details (I > would love to avoid to have students, kids, bosses and â¦ around to get some > calm time :). > > I will start rereading your blog. > > > tempAt: in Method context uses <primitive: 210>, which is failing. > Maybe there is a new primitive we are not aware of for Blocks... > > > > No, 210 is what is needed. The issue is my implementation of temporary > initialization in blocks, which simply uses pushNil to allocate and > initialize each temp. So if one inspects [|a|a:=2] and sends it self method > symbolic you get: > > > > 13 <8F 00 00 05> closureNumCopied: 0 numArgs: 0 bytes 17 to 21 > > 17 <73> pushConstant: nil > > 18 <77> pushConstant: 2 > > 19 <81 40> storeIntoTemp: 0 > > 21 <7D> blockReturn > > 22 <7C> returnTop > > > > And when you say self asContext pc you get 17, which is *before* the nil > is pushed. So you'll want to modify tempNamed: to compare the index of the > temporary with the stack pointer and answer nil if the index is beyond the > stack pointer. > > Is it correct? I think so but I'm learning ContextPart > > tempNamed: aName > "Returns the value of the temporaries, aName." > "Implementation notes: > temporary initialization in blocks simply uses pushNil to allocate > and initialize each temp. So if one inspects [|a|a:=2] and sends it self > method symbolic you get: > > 13 <8F 00 00 05> closureNumCopied: 0 numArgs: 0 bytes 17 to 21 > 17 <73> pushConstant: nil > 18 <77> pushConstant: 2 > 19 <81 40> storeIntoTemp: 0 > 21 <7D> blockReturn > 22 <7C> returnTop > > And when we check self asContext pc we get 17, which is *before* the nil > is pushed. Therefore we should pay attention when querying a temporary if > the temporary allocation was executed." > > | index | > index := (self tempNames indexOf: aName). > ^ index >= stackp > ifTrue: [ nil] > ifFalse: [self tempAt: (self tempNames indexOf: aName)] > > > > > > > The same bug exists in Squeak, e.g. the below gave an error until I > fixed DebuggerMethodMap>>namedTempAt:in: > > > I checked and this method is the same in pharo and latest squeak > namedTempAt: index in: aContext > "Answer the value of the temp at index in aContext where index is > relative > to the array of temp names answered by tempNamesForContext:" > ^self > privateTempAt: index > in: aContext > startpcsToBlockExtents: aContext method > startpcsToBlockExtents > > > > > | b | > > b := [ |a| a:=2 ]. > > { b asContext tempNames. b method debuggerMap tempsAndValuesForContext: > b asContext } > > #(#('b' 'a') 'b: [closure] in UndefinedObject>>DoIt > > a: nil > > ') > > > > > > Why did I use pushNil to allocate temps? It was not a good choice; it > means for example that to determine how many temps a block has one has to > parse all the bytecodes and see where the stack pointer is at the end > (since initial pushNils are ambiguous; an initial pushNil might be > producing a parameter or result or initializing a temp). But not using > pushNil would have meant a more complex bytecode for closure creation plus > another inst var in BlockClosure. I made another similar misstep in not > storing the method in a BlockClosure, hence preventing simple > implementation of clean blocks (one needs to synthesize an outerContext > also). We live and learn. > > Do you mean that the closure cannot access directly method but should do > go to its outer context to access the methods. > When this is needed to set the instruction pointer? > > > > Another thoughts while writing the chapter on block execution.. > > Am I correct to say: we need contexts (to me contexts are activation > objects by opposition to bindings which could be used to represent scope) > to query local temps of a closure because they will be allocated at > execution while > the temporaries that are shared are defined in their defining environment > (now the trick is that in Smalltalk environment is represented as a > context). > > I get why I'm often slow because I did not implemented closure in > Smalltalk only in lisp > > foo > > |b| > b := 3. > ^ [ |a | a :=2. a] > > In my stupid lisp implementation an environment is represented by bindings > and closure points to their own environment > so > [ |a | a :=2. a] > points to > (b.3) (toplevel) (and not top-level) > > and for closure execution we just added temporaly a binding for a to the > closure environment. > eval a:=2. a in (a) (b.3) (toplevel) > This is the wrong example. You need to consider how to implement this example: Object subclass: #AbstractSuperclass AbstractSuperclass>>computeV | v | v := 0. self maybeCapture: [v := v + 1. v]. ^self maybeBlock: v AbstractSuperclass subclass: #CaptureBlock instanceVariableNames: 'block' CaptureBlock>>maybeCapture: aBlock block := aBlock CaptureBlock>>maybeBlock: value ^block AbstractSubclass subclass: #DontCaptureBlock DontCaptureBlock>>maybeCapture: aBlock DontCaptureBlock>>maybeBlock: value ^value Then | thingOne thingTwo | thingOne := CaptureBlock computeV. thingTwo := DontCaptureBlock computeV. (1 to: 10) collect: [:ignore| { thingOne value. thingTwo value }] should answer #((1 0) (2 0) (3 0) ... (10 0)) right? So where does the l-value for v in computeV live? Iy must be an l-value since it is assigned to in the block in computeV. It must outlive the activation of computeV since CaptureBlock>maybeCapture: captures the block and CaptureBlock>>maybeBlock: answers it and the doit evaluates it. If it lives on the stack of the activation of computeV then there is no problem in a Context VM, but in a VM that maps activations to stack frames something special (and slow) has to happen when returning from computeV. However, if the l-value lives in a separate Array (as it does in my VisualWorks and Squeak closure implementations, and as happens in some Lisp implementations), nothing special has to happen. The block refers to the Array, *not* to the activation of computeV. Make sense now? -- best, Eliot

April 24, 2012

Re: [Pharo-project] Editor focus & hotkeys

by Benjamin

right arrow :) Ben On Apr 24, 2012, at 7:51 PM, blake wrote: > So, I'm entering code into a browser (Nautilus browser, though I don't > think this behavior is specific to Nautilus), press Ctrl+S to save > and... > > ...the code editor loses focus. Looks like it goes to the method pane, > which seems reasonable. But now, to enter my next method, I have to > take my hands off the keyboard and click the mouse. Nautilus seems > insensate to the Tab key...how do I get from the method pane back to > the code editor sans mouse? > > ===Blake=== >

April 24, 2012

Re: [Pharo-project] Slime with Nautilus?

by Sean P. DeNigris

blake wrote > > Yo, > What up ;-) blake wrote > I don't see > "refactoring scope" in my menu options. I'm guessing "Browse > restricted" serves the same purpose. > Correct. I don't know about your other question. Sean -- View this message in context: http://forum.world.st/Slime-with-Nautilus-tp4584783p4584890.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 24, 2012

Re: [Pharo-project] SimpleLiteralArrayParser

by StÃ©phane Ducasse

Mariano read the metacello mailing list mails I sent. I hate hate hate repeating myself. I started to work on the LIteralArrayParser so that we do not have the problem in the future. Stef On Apr 24, 2012, at 12:52 PM, Mariano Martinez Peck wrote: > > > On Tue, Apr 24, 2012 at 12:43 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Hi guys > > > > We should develop a simple Literal Array parser that is dialect independant > > so that we can avoid using JSON for meta data. So I will start to develop. I will start to write some tests and do it test first. > > > > Gofer new > > repository: 'http://ss3.gemstone.com/ss/SimpleLiteralArrayParser'; > > package: 'SimpleLiteralArrayParser'; > > load > > > > Now I still wonder what do we do about floats. May be the situation changed but Squeak and VW floats were not the same. > > > > I don't get it. You define your own float format, and then each dialect parses it and converts it to their correspondant format... Now, I do not know the format > > differences so I do not know which one take :). > > It can work for simple scenario but if you save a float with e120 and save it and you get e70 > then you are in trouble. > > You are not in trouble. And if you are, then you are exactlty the same as if you were using a literal parser. > You have a specification. You say that floats are written in THIS XXX text representation. Nobody cares how your floats are represented inside your Smalltalk. For JSON you write floats in a particular way, explained by the JSON specification. > Then, when you code the parser, you will need to crate an instance of Float from the string. Each dialect will know how to do that. > So, again, where is the problem? > And how the literal parser would solve it? because I think it will happen the same. > > Cheers, > > > > Stef > > > > -- > Mariano > http://marianopeck.wordpress.com >

April 24, 2012

Re: [Pharo-project] Do we get rid of the KeyDecodeTable in InputEventSensor?

by Mark Smith

On 22 Apr 2012, at 21:41, StÃ©phane Ducasse wrote: > > On Apr 22, 2012, at 8:13 PM, phil(a)highoctane.be wrote: > >> May I add that some Cmd-Q on OSX really sucks for autocompletion? > > indeed :) > This is why ecompletion and ocompletion propose other ways > >> >> And Alt-Shift for Halos when you have multiple keyboards setup in Windows? (It is the system shortcut for toggle language (like FR->EN). Using the middle button like in Cuis would be much better methinks. > > no it was like that in squeak and it always went in our way. > now in Pharo20 we will change revisit all the logic of key mapping and probably use the work on guillermo to be able to plug the binding people want. I want emacs binding for text for example :) +50 for emacs-style keybindings. I would love feel as fluid in Pharo as I do in emacs :). Mark >> >> Phil >> >> 2012/4/22 Guillermo Polito <guillermopolito(a)gmail.com> >> It's supposed to do some conversions, but sometimes, it just screws up the use input. It's main responsibility is to change ctrl into alt: >> >> installDuplicateKeyEntryFor: c >> | key | >> key := c asInteger. >> "first do control->alt key" >> KeyDecodeTable at: { key bitAnd: 16r9F . 2 } put: { key . 8 }. >> "then alt->alt key" >> KeyDecodeTable at: { key . 8 } put: { key . 8 } >> >> >> And then it confuses stuff. For example, Ctrl + tab is decoded as ctrl + $i, since >> >> $i asInteger bitAnd: 16r9F = Character tab asInteger >> >> >> And btw, I love my ctrl key and want to have more fancy and sexy shortcuts, so this F*** table is bothering :). >> >> Opinions? >> Guille >> >> >> >> -- >> Philippe Back >> "Helping you hit the top 3 outcomes you really want to achieve" >> >> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: >> http://philippeback.be >> >> High Octane SPRL >> rue cour Boisacq 101 >> 1301 Bierges >> > >

April 24, 2012

Re: [Pharo-project] Do we get rid of the KeyDecodeTable in InputEventSensor?

by Mark Smith

On 22 Apr 2012, at 19:13, phil(a)highoctane.be wrote: > May I add that some Cmd-Q on OSX really sucks for autocompletion? > > And Alt-Shift for Halos when you have multiple keyboards setup in Windows? (It is the system shortcut for toggle language (like FR->EN). Using the middle button like in Cuis would be much better methinks. +1, although I don't have a middle button on my trackpad :). Cmd-click would be good for halos on OS X. It i recall this is used in Xcode (interface builder) when manipulating graphical elements etc. > Phil > > 2012/4/22 Guillermo Polito <guillermopolito(a)gmail.com> > It's supposed to do some conversions, but sometimes, it just screws up the use input. It's main responsibility is to change ctrl into alt: > > installDuplicateKeyEntryFor: c > | key | > key := c asInteger. > "first do control->alt key" > KeyDecodeTable at: { key bitAnd: 16r9F . 2 } put: { key . 8 }. > "then alt->alt key" > KeyDecodeTable at: { key . 8 } put: { key . 8 } > > > And then it confuses stuff. For example, Ctrl + tab is decoded as ctrl + $i, since > > $i asInteger bitAnd: 16r9F = Character tab asInteger > > > And btw, I love my ctrl key and want to have more fancy and sexy shortcuts, so this F*** table is bothering :). > > Opinions? > Guille > > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges >

April 24, 2012

Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec)

by Sven Van Caekenberghe

Philippe, On 24 Apr 2012, at 22:20, Philippe Back wrote: > How to ship binary around? It works ;-) But I must say that this is/was not my primary use case. I think that a binary format like Fuel is better (more efficient, better/deeper system integration). Anyway, here is an example: Here is the Pharo logo ZnEasy get: 'http://www.pharo-project.org/images/pharo.png' This is a PNG of about 180Kb. Now get is as a form ZnEasy getPng: 'http://www.pharo-project.org/images/pharo.png' If you already want to look at it now (ZnEasy getPng: 'http://www.pharo-project.org/images/pharo.png') asMorph openInHand Now serialize it in STON STON toStringPretty: (ZnEasy getPng: 'http://www.pharo-project.org/images/pharo.png') Or directly to a file FileStream newFileNamed: '/tmp/form.ston' do: [ :stream | stream lineEndConvention: #lf. STON put: (ZnEasy getPng: 'http://www.pharo-project.org/images/pharo.png') onStreamPretty: stream ] The result is 200Kb text file that looks like ColorForm { #bits : Bitmap [ 4294967295, 4294967295, 4294967295, ... 4294967295, 4294967040 ], #width : 375, #height : 135, #depth : 8, #offset : nil, #colors : [ TranslucentColor { #rgb : 1010156636, #cachedDepth : nil, #cachedBitPattern : nil, #alpha : 241 â¦ TranslucentColor { #rgb : 0, #cachedDepth : nil, #cachedBitPattern : nil, #alpha : 0 } ], #cachedDepth : nil, #cachedColormap : nil } It goes on with numbers in between for a very long time. Note that this is strictly based on the generic serialization behavior. I attach a bzip2 compressed copy of the file to this mail (form.ston.bz2). Uncompress it with bunzip2 and try (FileStream oldFileNamed: '/tmp/form.ston' do: [ :stream | STON fromStream: stream ]) asMorph openInHand Let me know if that works for you. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 24, 2012

[Pharo-project] Slime with Nautilus?

by blake

Yo, I'm trying to run Slime (per the Seaside book) but I don't see "refactoring scope" in my menu options. I'm guessing "Browse restricted" serves the same purpose. But with (or without) that open, I don't have a "code critics" in my browser submenu. I'm not really sure I even have Slime installed. I do have the following classes installed: GRSlimeBlockLintRule GRSlimeParseTreeLintRule GRSlimeTest GRSlimeTransformationRule WASlime WASlimeTest ===Blake===

April 24, 2012

Re: [Pharo-project] Suggestion: introducing a fixme/issue/todo pragma

by Mark Smith

On 22 Apr 2012, at 19:10, phil(a)highoctane.be wrote: > I kind of like dirty corners. Especially for cleaning them up and turn them into shiny new orbs of glory. > > Jokes aside, there is an awful lot of potential in Pharo. Just being exposed to it for a while shows in my other coding activities (other languages). > > I would be perfect if we could grasp the whole system given enough attention (like the "Feel of Cuis" which is real). The challenge is to hit the sweet spot. Too much convolutions and we are doomed. Too little features and we can't be considered a contender. Agreed, but I'm fine with loading the features I want. The more features there are at the core of the system the more we need to fit into our heads. I would like to see a small and `tidy' core (not dissimilar to that defined for Spoon :)). Mark. > KR > Philippe > > 2012/4/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Sun, Apr 22, 2012 at 3:53 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Ok. > > Looks like there is still a lot of dirty corners under the hood by looking at this list of senders... > > Indeed. But the first step is to identify them, right? So at least we know those dirty corners ;) > > > > Phil > > 2012/4/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Sun, Apr 22, 2012 at 11:55 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > we use self flag: #fixMe > you can then query either #fixMe or flag: > > and yes this is a good idea to mark things and create bug entries. > > Stef > > > On Apr 22, 2012, at 11:18 AM, phil(a)highoctane.be wrote: > > > While looking around in the image, I am in need of knowing where I found thngs that either puzzle me or are "wrong" (well, a code smell). > > > > What I do is that I put pragmas in there like this (not that this sample is meant to be representative) > > > > privCleanTextConstants > > <fixme> > > TextConstants TextSharedInformation removeKey: #DefaultTextStyle. > > TextConstants TextSharedInformation removeKey: #DefaultMultiStyle. > > TextConstants TextSharedInformation removeKey: #DefaultFixedTextStyle. > > TextConstants TextSharedInformation removeKey: StrikeFont defaultFontKey. > > > > Smalltalk allClasses select: [:c | c sharedPools includes: TextConstants] thenDo: [:c | c compileAll ]. > > > > And I can then find back the things with: > > > > pc := (PragmaCollector filter: [:prg | prg keyword = 'fixme']) reset. > > pc collected size. "(Print It: 1)" > > pc collected explore. > > > > And then finding back the Class and Method Name > > > > Building upon that, why not do what is done in other environments (well, I've got that in PHP, Java, ...) and use: > > > > <todo:do this and that> or plain <todo> > > <fixme: this and that> or plain <fixme> > > <issue:issue#> > > > > As Stef said, we usually use #flag: Normal cases are #flag:todo, #flag:fixMe, etc .. and the browser is aware of that and shows you a flag in the icon of the method. > > > > > And have a specific tool to help the navigation (explore is fine for a moment but...) > > > > This would allow us to have an idea on the technical debt inside the system, broken down by areas if we start leveraging Packages. > > > > What I do not know is how much stress this would put on the system. Are pragmas eating a lot or a just markers? > > > > Phil > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges >

April 24, 2012