- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Editor focus & hotkeys

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > > right arrow :) > Hmm... why not tab? Kind of the gold standard. Also, it's not consistent because left doesn't go back (and obviously can't if you're in the middle somewhere). Maybe both (could be nice to have a left and right hand option on the keyboard)? Also, it'd be nice if the first element in the list is automatically selected when the focus goes there. The border is hard to see (maybe a different issue) and it makes for smoother navigation (like Mac finder). Sean -- View this message in context: http://forum.world.st/Editor-focus-hotkeys-tp4584350p4584934.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 24, 2012

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

Thanks. I saw that #(tire ) is interpreted as true so I will check and improve that. tef On Apr 24, 2012, at 3:18 PM, GÃ¶ran Krampe wrote: > Ok, I spent some time adding support for literal arrays to Tirade. > It probably has bugs and I haven't written tests for them but it does parse this correctly: > > > (TiradeParser parse: 'keyword: #(1 -2 3.4 -4.5 ''asd'' (2 nil true false 3) #jupp jupp jupp:tup: #''ju li'' jup:tu 2).') last value first > > ...produces this: > > #(1 -2 3.4 -4.5 'asd' #(2 nil true false 3) #jupp #jupp #jupp:tup: #'ju li' #'jup:tu' 2) > > So it handles integers, floats, nil, true, false, nested literal arrays and symbols. In fact it does handle some more than a true literal array does since Tirade supports { bla . bla } arrays also (but only of literals) and also treats key -> value as a literal syntax. > > Thus for example these work too: > > (TiradeParser parse: 'keyword: #(1->2 3->#ad).') last value first > > (TiradeParser parse: 'keyword: #({2 . 4}).') last value first > > > regards, GÃ¶ran

April 24, 2012

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

I saw and I started to extract parts that I need and writing some texts. Stef > On 04/24/2012 12:57 PM, StÃ©phane Ducasse wrote: >> Ok I will have a look. Because it would solve our problem. > > I just added first stab at supporting literal arrays, the following works: > > (TiradeParser parse: 'keyword: #(1 3.4 ''asd'' #jupp 2).') last value first print it => > > #(1 3.4 'asd' #jupp 2) > > The "last value first" is just because the result from TiradeParser contains Associations between the keyword and an array of arguments. It could in fact return instances of Message, that might be nice :) > > ...but nesting needs a bit more thought since one can ommit the # when nesting literal arrays inside literal arrays. > > regards, GÃ¶ran

April 24, 2012

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

Give us a break! Stef On Apr 24, 2012, at 1:39 PM, GÃ¶ran Krampe wrote: > On 04/24/2012 01:06 PM, H. Hirzel wrote: >> On 4/24/12, Igor Stasenko<siguctua(a)gmail.com> wrote: >>> can you name just one which can be useful in this context??? >>> what tools, except written in smalltalk and used by smalltalkers you >>> are expecting to use >>> with smalltalk source code stored in source code repositories? >> >> JavaScript :-) in connection with Amber. And couchDB. > > I do notice that Igor mentions a specific use case here, but let me ignore that and just reflect on JSON in general: > > And Riak. And quite a few other NoSQL dbs use JSON. And lots of RESTful RPC backends tend to use JSON, we do in our C# backend here at my customer. And almost all web APIs on the net use JSON. > > And JSON pops up everywhere in fact. So personally, while I did actually implement Tirade, JSON is still a very nice format due to its ubiquity. > > The main reason I made Tirade was because JSON didn't handle linefeeds in strings so I couldn't store source code in JSON in a reasonably readable way. At least not per true JSON spec. > > Also, Tirade supports more atomic Smalltalk datatypes. And since it encodes keyword messages it simply offers more structure than JSON does. And it is streamable. And perhaps one or two more things. > > But in summary - JSON is generally a very good choice and IMHO Pharo should be *great* at handling JSON. It's not going away :) > > regards, GÃ¶ran >

April 24, 2012

Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by StÃ©phane Ducasse

We will write a parser because we do not want a JSON syntax. I started and I will continue. Hannes I think that igor did a lot for us and that he knows probably more than you what is to work for the community. Because Igor could be working for Google right now without any problem. So let us appreciate to have guys like him in our community. Stef > Igor, > > Let me rephrase the context. It is that you started this thread > yesterday Monday Apr 23, 2012 at 11:34 .You said that you are not > pleased with storing Smalltalk meta data in JSON format. > > You gave the example > > { > "category" : "Cypress-Tests", > "classinstvars" : [ > ], > "classtraitcomposition" : "{}", > "classvars" : [ > ], > "commentStamp" : "", > "instvars" : [ > ], > "name" : "CypressPatchTest", > "pools" : [ > ], > "super" : "CypressAbstractTest", > "traitcomposition" : "{}", > "type" : "normal" } > > The cypress project URL is > > https://github.com/CampSmalltalk/Cypress > > This is Dale Henrichs' work. > > Cypress uses JSON for storing the meta data. > > There is a button called 'Fork' on the git hub project. > > Dale is willing to take arguments if they are based on code. > For many people JSON is fine. > > HTH :-) > > Hannes > > On 4/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 24 April 2012 14:17, Herby VojÄÃk <herby(a)mailbox.sk> wrote: >>> >>> >>> Igor Stasenko wrote: >>>> >>>> On 24 April 2012 11:54, Dale Henrichs<dhenrich(a)vmware.com> wrote: >>>>> >>>>> Stef, >>>>> >>>>> There is no Parser class and there is no Compiler class. There is a >>>>> primitive call that takes method source, class, methodDictionary, etc. >>>>> and >>>>> produces a method installed in the methodDictionary. >>>>> >>>> so you can take 1st literal from such method and you done. or you >>>> cannot access method's literals? >>>> it of course not as simple as parsing the source, but if you cannot >>>> avoid compilation.. >>>> >>>>> ... JSON is and was a pragmatic choice... >>>>> >>>> well, i did not realized that GemStone have no own parser/compiler >>>> written in smalltalk. >>> >>> >>> Neither does Amber in deploy mode, unless I am mistaken. >>> >>> Why do you ever think there must be a Smalltalk parser in any Smalltalk? >>> You >>> get used to it, I understand, but it is by no means a required thing. >>> Smalltalk is Smalltalk without parser as well. >>> >>> JSON is great choice. Much better than anything proprietary, because of >>> world-wide interoperability. >>> >> >> Sorry, but you seem even more out of the context than me. >> We're talking about tools for storing and loading smalltalk code.. >> which implies having a working smalltalk >> parser and compiler toolchain. >> How else you can load smalltalk source code without having the way to parse >> it? >> If you don't parse nor compile it, it is just a bunch of letters. >> >>> Herby >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >

April 24, 2012

[Pharo-project] AnnotationPanePlugin for Nautilus

by Mariano Martinez Peck

Hi Igor/Ben. I don't know if it was the correct path, but I commited NautilusCommon-MarianoMartinezPeck.58 which adds a new plugin: AnnotationPanePlugin. It is based on Igors one and taken the class from OB. For me this is really usful beacuse it shows for each method its author, timestamp, mcz version, category, number of implementors, etc. It does not show the number of senders because it is slow. So...is that fine? ahh btw, if you wonder how to do a script to enable plugins: Nautilus pluginClasses add: { AnnotationPanePlugin. #middle } cheers, -- Mariano http://marianopeck.wordpress.com

April 24, 2012

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