- Pharo-dev - lists.pharo.org

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

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

by Dale Henrichs

Stef, We are all on the same side ... I like to say that we are in "screaming agreement"... Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 2:50:51 PM | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk] | | 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

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by StÃ©phane Ducasse

Thanks! I really want to have a look at your changes to learned. I cleaned the <on> <off> menu items handling. Now no string generation and string parsing anymore :) I let the code to be compatible and in 2.1 we can flush them. Stef > Finally found the time to package out. > Have tested a bit after fixing some conflicts. > A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). > > Attached cs and description of changes > > Regards, Gary > <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>

April 24, 2012

Re: [Pharo-project] Tirade!

by Dale Henrichs

Stef, It is starting to look like STON will be a good option ... it has the advantage of having an existing implementation and provides much more functionality than a simple literal array parser ... Oh and it looks a lot like Smalltalk ... BTW, I am still interested in seeing how Tirade would provide the same functionality as STON... I suggest that you take a deep breath and relax a bit:) Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 2:52:05 PM | Subject: Re: [Pharo-project] Tirade! | | 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] Tirade!

by StÃ©phane Ducasse

I do not think it works for gemstone because apparently they cannot access the parser or at least wants to make sure that you cannot write code that can break the server scenario: you are mean that you write a strange meta data that is executed on the server so I will take tirade parser and make sure that we get one that only parse literal arrays. On Apr 24, 2012, at 3:23 PM, Igor Stasenko wrote: > Here the the snippet to parse array literals.. based on existing parser.. > i only had to add a #parseNode accessor to Parser to make it work: > > > | parser| > parser := > (Parser new > init: '#(1 2 3 (ab bc de))' readStream notifying: nil failBlock: [] > ). > > parser encoder initScopeAndLiteralTables. > parser primaryExpression. > parser parseNode key > > > > On 24 April 2012 15:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> goran could I extract the parser? and rename it in another package? >> >> Stef >> >> On Apr 24, 2012, at 12:00 PM, GÃ¶ran Krampe wrote: >> >>> On 04/24/2012 11:52 AM, GÃ¶ran Krampe wrote: >>>> On 04/24/2012 11:51 AM, GÃ¶ran Krampe wrote: >>>>> On 04/24/2012 11:46 AM, StÃ©phane Ducasse wrote: >>>>>> Where is the code? >>>>> >>>>> On SS. But it seems... down? Project is called "Tirade". >>>> >>>> http://www.squeaksource.com/Tirade.html >>> >>> Eh, oops. I just realized that TiradeParser uses dynamic arrays { } and does not have current support for literal Arrays. Duh. Sorry about that, but feel free to use the code anyways, adding #parseLiteralArray should not be hard. >>> >>> regards, GÃ¶ran >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

April 24, 2012