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

Re: [Pharo-project] AnnotationPanePlugin for Nautilus

by Benjamin

On Apr 25, 2012, at 12:15 AM, Esteban Lorenzano wrote: > ahhh.... > > On Apr 24, 2012, at 11:49 PM, Mariano Martinez Peck wrote: > >> 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 } > > ...and: > > AnnotationPanePlugin class>>#pluginSettings: builder > <nautilusPlugin> > builder add: self at: #middle. > > > looks a LOT better for me :) > > Esteban > > ps: yes, I know... I'm annoying today :P It doesn't work like that. You can choose dynamically where you wanna put the plugin, and if you want to activate it or not. With pragmas, I do not think it can work :) Ben > > >> >> cheers, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

April 24, 2012

Re: [Pharo-project] Block questions

by StÃ©phane Ducasse

Following eliot feedback, I fixed it see the bug tracker. But my question was totally stupid because when you have [ |a | a;=2 . ^ a ] | a | exists only when executed. and the reflective model of block does not let us simply gets the information. Stef On Apr 15, 2012, at 10:22 AM, Guillermo Polito wrote: > b := [ |a| a:=2 ]. > b asContext tempNames -> #('a') > b asContext tempNamed: 'a' -> Boom in MethodContext>>#tempAt: primitive > > tempAt: in Method context uses <primitive: 210>, which is failing. Maybe there is a new primitive we are not aware of for Blocks... > > On Sat, Apr 14, 2012 at 1:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I'm taking some times to go back the block closure chapter and I was wondering how I can get access to block temporaries > > [ |a | a :=2. a] > > for example I tried > > [ |a | a :=2. a] > > outerContext contextForLocalVariables tempAt: 1 and variations but none worked. > > Stef > > > >

April 24, 2012

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

by H. Hirzel

On 4/24/12, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Very cool! > > Let's see ... export the pharo implementation of STON in Cypress package > format (using FileTree), then port STON to other dialects and voila:) the > next generation of Cypress can use STON in place of JSON! > > Dale Yes, this is promising. First of all STON has a good name 'Smalltalk Object Notation'. People who know JSON will be instantly familiar with the general idea. Sven writes this in the document attached as a PDF at the beginning of this thread. [1] Second STON offers more than JSON shared objects and cycles in the object graph are supported in STON. more data types Third STON seems to be superset of JSON. Sven writes above that he implemented this today in a new version. Fourth It is literal Smalltalk if we accept a dictionary type {} as done in Amber Smalltalk. -- Hannes [1] Sven Van Caekenberghe If you have ever seen JSON (Javascript Object Notation) 1 , you will be instantly familiar with Smaltalk Object Notation. It uses similar primitive values, with the addition of a symbol type. Some details are slightly different though. For object values an optional class tag precedes a representation that is either a list of values or a map of keys and values. Exactly how each class is represented is up to the implementation, although this document suggests some conventions for well known classes. > ----- Original Message ----- > | From: "Sven Van Caekenberghe" <sven(a)beta9.be> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Tuesday, April 24, 2012 1:14:08 PM > | Subject: Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec) > | > | > | On 24 Apr 2012, at 21:40, Sven Van Caekenberghe wrote: > | > | > Apart from the fact that I used single quotes for strings in STON, > | > it already works (and I could enhance the parser to accept both I > | > guess). > | > | --- > | Name: Ston-Core-SvenVanCaekenberghe.27 > | Author: SvenVanCaekenberghe > | Time: 24 April 2012, 10:13:07 pm > | UUID: dd7c16b2-950c-4246-bf60-130de447cddf > | Ancestors: Ston-Core-SvenVanCaekenberghe.26 > | > | extended the parser to allow either single or double quotes as String > | delimiters which gives us JSON backward compatibilty ! (thanks Dale > | Henrichs for this great idea). > | --- > | > | > | > | > >

April 24, 2012

Re: [Pharo-project] SimpleLiteralArray Spec

by Dale Henrichs

April 24, 2012

Re: [Pharo-project] AnnotationPanePlugin for Nautilus

by Esteban Lorenzano

ahhh.... On Apr 24, 2012, at 11:49 PM, Mariano Martinez Peck wrote: > 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 } ...and: AnnotationPanePlugin class>>#pluginSettings: builder <nautilusPlugin> builder add: self at: #middle. looks a LOT better for me :) Esteban ps: yes, I know... I'm annoying today :P > > cheers, > > -- > Mariano > http://marianopeck.wordpress.com >

April 24, 2012

Re: [Pharo-project] AnnotationPanePlugin for Nautilus

by Esteban Lorenzano

Hi, On Apr 24, 2012, at 11:49 PM, Mariano Martinez Peck wrote: > 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 } something like: Nautilus addPlugin: AnnotationPanePlugin at: #middle. looks better for me :) Esteban > > cheers, > > -- > Mariano > http://marianopeck.wordpress.com >

April 24, 2012

Re: [Pharo-project] SimpleLiteralArray Spec

by StÃ©phane Ducasse

On Apr 24, 2012, at 1:26 PM, Sven Van Caekenberghe wrote: > OK, just to get started, let try to write a spec for SimpleLiteralArray, this is based on JSON (and my own STON, not ready for public consumption). It will soon become clear that this is slightly harder than expected, IMO a writer is needed as well. > > S y n t a x > > value > primitive-value > list > nil > primitive-value > number > true > false > symbol > string > classname In a literal array a class name is just a symbol #(Foo) first #Foo > list > #() > #( elements ) > elements > value > value , elements > string > '' > ' chars ' > chars > char > char chars > char > any-printable-ASCII-character- > except-"-or-\ > \" > \\ > \/ > \b > \f > \n > \r > \t > \u four-hex-digits why do we need that? > symbol > # chars-limited > # ' chars ' > chars-limited > char-limited > char-limited chars-limited > char-limited > a-z A-Z 0-9 - _ . / > classname > uppercase-alpha-char alphanumeric-char there is not need for classname as element classname is just a pair that the interpretation should handle if necessary > number > int > int frac > int exp > int frac exp > int > digit > digit1-9 digits > - digit > - digit1-9 digits > frac > . digits > exp > e digits > digits > digit > digit digits > e > e > e+ > e- > E > E+ > E- > > > Questions remain: > > - is the escaping OK ? I do not know but in literal array there is no escaping. Now if you want to put a cr into a string you probably need that > - what about symbols without a leading # ? #(foo) -> #(#foo) #(true nil false 1 'n') -> #(true nil false 1 'n') > - what should be allowed in unquoted symbols ? I did not get the question > - what should be allowed for classnames ? Nothing > - what about namespaces ? Nothing no need I do not think that they are in literal arrays. (may be in VW but I did not check) > - do we allow infinite precision integers ? Yes > - maybe the toplevel should always be an array ? I would say so else this is not a literalArray but a literal. > > > Now: shoot! > > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > >

April 24, 2012

[Pharo-project] Please ADOPT a class ...

by James Ladd

Please adopt a class for Redline Smalltalk to help a class get a new home. http://www.redline.st/blog/2011/12/22/adopt-a-class.html

April 24, 2012

[Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4

by Francois Stephany

I'm updating some Metacello configurations and I'm wondering how to declare the dependencies on stuff that have been integrated into Pharo 1.4 (e.g., Zinc, FS). Should I declare those dependencies into my configuration? If yes, against with version? My gut feeling is that I should create a new baseline that does not require any Zinc of FS. That becomes a pain in the ass when developing in parallel for 1.3 and 1.4. Is the only place where I can differentiate 1.3 and 1.4 is in the stable symbolic version, right? What are people generally doing? Cheers, Francois

April 24, 2012

Re: [Pharo-project] JSON, Smalltalk parser and no-point wars

by StÃ©phane Ducasse

On Apr 24, 2012, at 5:34 PM, Miguel CobÃ¡ wrote: > Friends, > > what energy! But I don't know why are we discussing this point of JSON > choice so long. > It is an implementation detail. > If he choose to use XML, so be. It is Dale's time and Dale's code. > Remember his projects is not to build a inter-dialect metadata format. > His project is all about building an inter-dialect package format to > store smalltalk. And in that goal he is succeeding! Lets no make a flame > war about his choices. > What is matters now is to show to as many smalltalk dialects as > possible, that code interchange is possible. That is the fucking point. No! Because really fast we will have a lot of Smalltalk code on github and we will have to have JSON parser to build tools. While we can simply use our parser. So I'm writing a parser not for us but for gemstone basically right now. > If after that, because the implementation is slow, or some other real > after-use problem is detected, then is the time to discuss how to better > address that specific problem. Until then, this is a bikeshedding like > inane problem. > > Remember make it work, make it right, make it fast! Yes but in that case using the gemstone parser should have worked too. I thought that making it secure was after make it work. > Dale is in make it work. > Every other not putting code on the project is trying to make it right > (intelectually and upfront). > > Lets not stop the work of others by discussing the best way to do it > instead of doing it. Some famous people around here made an analogy > about a mountain and the people trying to climb it. Don't forget that! Do you think that we forget when we are daily improving our system? > > Cheer to all. > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

April 24, 2012