- Pharo-dev - lists.pharo.org

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by H. Hirzel

On 5/9/12, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > Hi all! > > First - I am not fighting nor pushing in any direction. I just find the > subject interesting. > > On 05/08/2012 10:59 PM, StÃ©phane Ducasse wrote: >>>> :) there is no security problem just that gemstone does not have a >>>> parser. Because parsing cannot be a security hole >>>> this is blind data interpretation that is a problem. This is why Github >>>> got problems and I imagine that the code was probably passed in JSON or >>>> similar format. >>> >>> Mmm, well, if you rely on full Compiler to parse literals, it is a >>> security problem. But if you use the technique Igor showed to only parse >>> array literals - then yes, that's safe, I agree. I forgot about his >>> post. >> >> Parsing and compiling + execution are three different actions. >> Parsing: stream -> tokens* but you know it. > > Of course. What I mean is that depending on how you "parse" a Smalltalk > literal you may or may not be susceptible to a security hole. If you > just blindly use the full Compiler to do the whole thing - then you have > a hole. If you do not, then you don't. Igor showed a neat way to only > use the literal array part of the parser - fine, no hole. But if you > just use full Compiler - not fine. > > > [SNIP] >>> My point is that it would be nice if we actually had proper syntax for >>> Associations (and or Dictionaries). >> >> OK I see. But what I want to say is that then this is not a literal array >> anymore. >> Literal means that you only need a parser and no execution to get the >> information. Parse time. > > But Stephane... please *read* what I write in the article. Let me repeat: > > #-> is a message in Smalltalk, not a literal syntax. We all know that. > > BUT... there is nothing preventing us from adding support in the > Smalltalk parser to handle this as a *literal* syntax that creates an > Association. Tirade has support for it and a large part of the article > talks about this, but I presume you have not read it. > >> Now I would like to know the use case for a dictionary syntax or >> association. > > There are TONS of use cases. The whole success behind JSON is IMHO based > on the fact that it has explicit syntax for *both* arrays and > dictionaries (called "objects" in JavaScript). Nested structures of > these two building blocks is a very potent combination. And Smalltalk > literal arrays only give us ONE of them. > >> May be you mean that you want to have the equivalent of { } but for >> dictionary, why not. > > Sigh. "Maybe"? Ok, things would be MUCH simpler if you actually read the > article you know. And no, not really, because {} is a *dynamic* array > with expressions in it and I am talking about (primarily) *literal* > dictionaries. > >> Having a syntax for a syntax is not really exciting. > > What? > >> Now I think that the key problem is dealing with reference between >> elements. for that STON can be better because why stopping at dictionary? >> But then the next question if we go down this >> road is why don't we add this syntax to smalltalk so that we can create >> literals objects like in Javascript. >> I mean without message send because this is exactly that no? >> What is the difference between >> Dictionary new add: #flop put: 33 ;yourself >> and >> {|% flop : 33 %|} >> >> or Person { >> name : 'stef' >> } > > The difference? Well, the first is an imperative Smalltalk program > (fully insecure of course since I presume you would parse and execute it > as full Smalltalk) and the second two are declarative literal syntaxes > that are safe to parse. > >> then this is not really Smalltalk anymore and we cannot say that we only >> have messages and the parser and â¦. >> have to be changedâ¦. This is why I asked what is the use case. > > Your reasoning is very... confusing. What do you mean "only have > messages" - we *already* have a whole bunch of literal syntax for > creating objects. What makes a Dictionary so special compared to Arrays? > > And "not really Smalltalk anymore"... ehm, I give up. > > Anyway, my article mainly says that Smalltalk literals go a long way BUT > without the support for Dictionaries they fall short of JSON, and that > is a bit of a shame I think. But still - the article was mainly food for > thought - I am not fighting a battle here, I am just exploring. > >> Finally and I still did not get a clear answer: why there is a need for >> dictionary syntax to store method meta data. > > Can you please stop referring to "method meta data" all the time? This > thread is about an article I wrote that you haven't read and it has > nothing to do with that use case. Ok? I agree but the discussion started out from the question how to do meta data exchange. Dale H. uses JSON for that at the moment. I do recommend to everybody to actually _read_ the article http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/. In the context of meta data exchange I agree with Stephane D. that literal arrays (something like s-expressions) can do the job; however the syntax is not well defined across dialects and as Dale points out with the nails and screws comparison it might not be all that user friendly. In terms of general data exchange I value this discussion of JSON, STON and Tirade. It is very useful for my work. So we actually have two use cases 1) exchange of meta data 2) exchange of general data with literal objects. This leads to the discussion: How are object literals done in Smalltalk? --Hannes > regards, GÃ¶ran > >

May 9, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by H. Hirzel

On 5/8/12, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > StÃ©phane, > > On 08 May 2012, at 22:59, StÃ©phane Ducasse wrote: > >> Finally and I still did not get a clear answer: why there is a need for >> dictionary syntax to store method meta data. > > (I still think we are all discussing different things, and I do understand > your point, and I myself don't want to force STON on anybody). > > But a quick question then, since I know you also know Lisp. > > Do you then see array literal syntax as s-expressions ? Yes, I see them as such and for that I agree with Stephane D. that they may serve to store the meta data. But they are not all that readable and the semantics is not so easy to deduct. However that's a matter of taste. > So that dictionaries/maps are like Lisp plists ? Yes. And BTW, thank you all for this interesting discussion. We'll see where it leads to. It will help us all to get more insight into the matter of data exchange in a human readable and sustainable way. (i.e. parsers are available in various dialects and languages) --Hannes > Dictionary new > at: #x put: 1; > at: #y put; 2; > yourself. > > would then be encoded like > > #( x 1 y 2 ) > > ? > > Eventually doing a > > Dictionary newFromPairs:: #( x 1 y 2 ) > > ? > > It would certainly work, with the know limitation that one has to know or > understand the semantics upfront. > > Sven >

May 9, 2012

Re: [Pharo-project] Running in background with OSProcess

by David T. Lewis

On Tue, May 08, 2012 at 08:20:38AM -0700, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote > > > > How do I circumvent all the processing and tell OSP what args to actually > > pass to the underlying system? > > > > I found a solution: > env := CommandShell new environment. > pwd := '/'. > args := Array > with: '-DJENKINS_HOME=/path with spaces/.jenkins' > with: '-jar' > with: '/path/with/another space/jenkins.war' > with: '--httpPort=####' > with: '--ajp13Port=####'. > desc := (Array with: nil with: nil with: nil). > p := PipeableOSProcess > new: '/usr/bin/java' > arguments: args > environment: env > descriptors: desc > workingDir: pwd > errorPipelineStream: nil. > > Since I'm not doing any redirecting, this works. If you have to redirect, it > looks like the best move would be to go through ProxyPipeline, like Dave > suggested, but define and plugin a custom ShellSyntax that does not do any > string processing... Sean, This is a good solution. It does exactly what you want, and the command parameters are clearly specified without relying on either /bin/sh or ShellSyntax to do the parsing. One last pointer: When Jenkins is done and your external process exits, it is good practice to close any open file descriptors (p closePipes). This will prevent file handle leaks if you run Jenkins on a regularly scheduled basis. Dave

May 9, 2012

Re: [Pharo-project] Improved version of StartupPreferences (+Windows)

by Ben Coman

Mariano Martinez Peck wrote: > On Tue, May 8, 2012 at 7:21 PM, Ben Coman <btc(a)openinworld.com> wrote: > > >> Mariano Martinez Peck wrote: >> >> >>> Hi guys. After playing a little bit with StartupPreferences, and >>> continuing >>> the effort of Ben (thanks Ben for yet another great tool), I generate a >>> improved (from my point of view) version of the tool. >>> >>> The main changes are: >>> >>> a) Previously the tool searched files 1) first in image directory, 2) then >>> in the preference folder and 3) finally in the general preference folder. >>> As soon as it found at least one file, I didn't continue with the rest of >>> the places. Now, it starts the other way around, from the most general to >>> the most spceific. Starts in 3), then 2) and finally 1) >>> >>> >> Moreover, it does >> >>> not stop when it finds files in any of them. So all are searched and >>> executed. It works or or less the same way as variables in UNIX with >>> .bashrc /etc/envirorment, etc... >>> >>> >>> >> Did it actually work like that? >> > > > yes > > > >> I thought it had worked for me processing more than one file from each >> preferences folders. >> > > > No. See the previous version: > > PreferenceHandler >> perform > > actions do: [:each | > > each value ifNotNil: [:res | ^ res ] > ]. > > ^#() > > > then the value was not nil (therefore, when there were found files), the > method just returned. > > > > >> It seemed only the image folder was restricted to a single specific file ' >> startup.st' I assume this was to avoid processing any other random .st >> files that might happen appear in the image folder. I had been considering >> a refactoring like your #lookInFolder, but was concerned about picking up >> random .st files in the image folder. >> >> >> > I copy paste here part of my future blog post (once this is integrated I > will publish it). This is how it works NOW in ORDER: > > > 1. The image folder: The startup only searches for a file called â > startup.stâ. So if you have such a file in the same directory where the > image is, then such script will be executed automatically. This type of > startup is usually used to do something that is application-specific or > something that only makes sense for the specific image you are using. > 2. Preference folder: This is a specific folder for a specific Pharo > version. This folder is in the $HOME (kind of) of the current OSâ user. > Therefore, this folder is shared for all the images you open. To know the > real value, print the result of âFileDirectory preferencesFolderâ. In my > case (in MaxOSX) and Pharo 2.0, it is â/Users/mariano/.config/pharo/2.0â². > In this place, StartupLoader will load ALL existing .st files. This type of > startup is useful when we have something to execute for all images of a > specific Pharo version. > 3. General preferences folder: this is similar to the previous one with > the difference that it is general for all Pharo versions. To know the > value, print âFileDirectory preferencesGeneralFolderâ, which in my case is > â/Users/mariano/.config/pharo/generalâ. This type of startup is useful when > we have something to execute for all images of any Pharo version. > > > > > >> I haven't gone through the your new methods in detail, but I've expanded >> your changes to the existing architecture to also resolve the issue with >> Windows. >> Basically I've thrown away what I was trying to do putting the configs >> into standard Microsoft locations. That was mainly to deal the location of >> config folders being hardcoded at two level down from root, which I have >> now removed this constraint. The config folder can now be located anywhere >> in the parent path from the image up to root. >> >> The key addition is #ascendingSearchForDirectory for which you can try >> these out... >> FileDirectory default ascendingSearchForDirectory: 'mariano' >> FileDirectory default ascendingSearchForDirectory: 'Users' >> FileDirectory default ascendingSearchForDirectory: 'Contents' "Valid >> for one-click image" >> FileDirectory default ascendingSearchForDirectory: FileDirectory >> configFolderLocalName FileDirectory preferencesGeneralFolder >> FileDirectory preferencesFolder >> >> >> > > Excellent. So it means that then it is working for Windows also? > > Yes. It works for Windows - now with the same (modified) logic as Unix. > >> b) I have created several class side methods (addAtStartup*) to create >> >>> given actions into the current directory. Previously, files were created >>> in >>> 2 folders at the same time and there were only the possibility to create >>> only in one place. Now you can add startup actions in any of the 3 places >>> mentioned in a) >>> >>> c) Added a whole protocol (remove* and clean*) to remove script files from >>> all folders of a) and also to clean the internal stored actions. >>> >>> d) Lots of internal refactors to reuse code and less hardcoding. >>> >>> Does someone want to take a look to the slice ? >>> Slice in inbox: http://code.google.com/p/**pharo/issues/detail?id=5835<http://code.google.com/p/pharo/issues/detail?id=5835> >>> >>> Cheers, >>> >>> >>> >>> >> >> > > >

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by GÃ¶ran Krampe

Hi all! First - I am not fighting nor pushing in any direction. I just find the subject interesting. On 05/08/2012 10:59 PM, StÃ©phane Ducasse wrote: >>> :) there is no security problem just that gemstone does not have a parser. Because parsing cannot be a security hole >>> this is blind data interpretation that is a problem. This is why Github got problems and I imagine that the code was probably passed in JSON or similar format. >> >> Mmm, well, if you rely on full Compiler to parse literals, it is a security problem. But if you use the technique Igor showed to only parse array literals - then yes, that's safe, I agree. I forgot about his post. > > Parsing and compiling + execution are three different actions. > Parsing: stream -> tokens* but you know it. Of course. What I mean is that depending on how you "parse" a Smalltalk literal you may or may not be susceptible to a security hole. If you just blindly use the full Compiler to do the whole thing - then you have a hole. If you do not, then you don't. Igor showed a neat way to only use the literal array part of the parser - fine, no hole. But if you just use full Compiler - not fine. [SNIP] >> My point is that it would be nice if we actually had proper syntax for Associations (and or Dictionaries). > > OK I see. But what I want to say is that then this is not a literal array anymore. > Literal means that you only need a parser and no execution to get the information. Parse time. But Stephane... please *read* what I write in the article. Let me repeat: #-> is a message in Smalltalk, not a literal syntax. We all know that. BUT... there is nothing preventing us from adding support in the Smalltalk parser to handle this as a *literal* syntax that creates an Association. Tirade has support for it and a large part of the article talks about this, but I presume you have not read it. > Now I would like to know the use case for a dictionary syntax or association. There are TONS of use cases. The whole success behind JSON is IMHO based on the fact that it has explicit syntax for *both* arrays and dictionaries (called "objects" in JavaScript). Nested structures of these two building blocks is a very potent combination. And Smalltalk literal arrays only give us ONE of them. > May be you mean that you want to have the equivalent of { } but for dictionary, why not. Sigh. "Maybe"? Ok, things would be MUCH simpler if you actually read the article you know. And no, not really, because {} is a *dynamic* array with expressions in it and I am talking about (primarily) *literal* dictionaries. > Having a syntax for a syntax is not really exciting. What? > Now I think that the key problem is dealing with reference between > elements. for that STON can be better because why stopping at dictionary? But then the next question if we go down this > road is why don't we add this syntax to smalltalk so that we can create literals objects like in Javascript. > I mean without message send because this is exactly that no? > What is the difference between > Dictionary new add: #flop put: 33 ;yourself > and > {|% flop : 33 %|} > > or Person { > name : 'stef' > } The difference? Well, the first is an imperative Smalltalk program (fully insecure of course since I presume you would parse and execute it as full Smalltalk) and the second two are declarative literal syntaxes that are safe to parse. > then this is not really Smalltalk anymore and we cannot say that we only have messages and the parser and â¦. > have to be changedâ¦. This is why I asked what is the use case. Your reasoning is very... confusing. What do you mean "only have messages" - we *already* have a whole bunch of literal syntax for creating objects. What makes a Dictionary so special compared to Arrays? And "not really Smalltalk anymore"... ehm, I give up. Anyway, my article mainly says that Smalltalk literals go a long way BUT without the support for Dictionaries they fall short of JSON, and that is a bit of a shame I think. But still - the article was mainly food for thought - I am not fighting a battle here, I am just exploring. > Finally and I still did not get a clear answer: why there is a need for dictionary syntax to store method meta data. Can you please stop referring to "method meta data" all the time? This thread is about an article I wrote that you haven't read and it has nothing to do with that use case. Ok? regards, GÃ¶ran

May 8, 2012

[Pharo-project] Strangest object ever seen?

by Pavel Krivanek

Hi, If you take the latest Pharo 2.0 image from Jenkins (20059) and you execute the expression: (Metaclass allInstances select: [:c | c superclass = ProtoObject class]) inspect you will get an collection inspector where the first object is very strange one. It is very hard to get any useful information about the origin of this evil object. The only thing we know exactly is that it causes virtual machine segmentation faults while trying to export class ScrollBar via Fuel. Not only CogVM but even StackVM. Can you, please, try to help us to get as much information as possible about this object? I named it "dzindzik" :-) Cheers, -- Pavel

May 8, 2012

Re: [Pharo-project] dependency injection

by Stephan Eggermont

Philippe wrote: > On 05/05/2012 10:04 AM, Milan Mimica wrote: >> What are you feelings about dependency injection? > > Oh oh, you brought up "the topic". We have about six different ways in > Seaside how we look up implementation classes. Anything from writing > them to a class variable to iterating over the subclasses and class > extensions. It would be really nice if we could replace them with one > approach. So that would be: afraid/angry, confused, despairing/hopeful? :)

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by Igor Stasenko

i agree with Stef.. about method metadata. imo array literals is more than enough to encode any data. yes, it may require a separate layer to convert it into instances of other classes ,like Dictionary, Author, Timestamp, PreviousVersionLink (+ add what you desire). So, you basically need to write a parser (or decoder) of array data. Which is imo much more simpler than parsing textual representation like JSON, STON and even smalltalk syntax. But lets stop fighting. Nothing is better a working solution, even if it not flawless. I would just use fuel to serialize any additional data associated with method. With some version information, so that i can make sure that i will be able to read it 10 years later. I don't care that humans will not be able to read it, because we have tools for that. End of story. -- Best regards, Igor Stasenko.

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by StÃ©phane Ducasse

> >> Finally and I still did not get a clear answer: why there is a need for dictionary syntax to store method meta data. > > (I still think we are all discussing different things, and I do understand your point, and I myself don't want to force STON on anybody). Yes this is not what I meant but I wanted to understand what people really want because so far this is still unclear to me. > But a quick question then, since I know you also know Lisp. Yes I still like its sexpressions style :) > Do you then see array literal syntax as s-expressions ? I do not know what you mean by that. The problem is that for objects it does not work (this is what we tried to do with selfEvaluating objects - it was to get as close as possible as true => true # (1 2 3) => #(1 2 3) {(10 @20) . (20@ 20)} => {(10 @20) . (20@ 20)} but {Person new} => anOrderedCollection (â¦.) > So that dictionaries/maps are like Lisp plists ? Yes kind of > > Dictionary new > at: #x put: 1; > at: #y put; 2; > yourself. > > would then be encoded like > > #( x 1 y 2 ) > yes or #((x 1) (y 2)) > ? > > Eventually doing a > > Dictionary newFromPairs:: #( x 1 y 2 ) > > ? > It would certainly work, with the know limitation that one has to know or understand the semantics upfront. Yessssssss :) And the plus that we do not have to have a new parser. the syntax for dictionary does just that. (ok it can be something big and important) but my question is what is the cost and the use case. Stef > > Sven

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by Sven Van Caekenberghe

StÃ©phane, On 08 May 2012, at 22:59, StÃ©phane Ducasse wrote: > Finally and I still did not get a clear answer: why there is a need for dictionary syntax to store method meta data. (I still think we are all discussing different things, and I do understand your point, and I myself don't want to force STON on anybody). But a quick question then, since I know you also know Lisp. Do you then see array literal syntax as s-expressions ? So that dictionaries/maps are like Lisp plists ? Dictionary new at: #x put: 1; at: #y put; 2; yourself. would then be encoded like #( x 1 y 2 ) ? Eventually doing a Dictionary newFromPairs:: #( x 1 y 2 ) ? It would certainly work, with the know limitation that one has to know or understand the semantics upfront. Sven

May 8, 2012