- 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 Stephane and all! > > On 05/09/2012 08:29 AM, StÃ©phane Ducasse wrote: >>>> 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. >> >> yes so using literal array does not bring any security problems. >> Or we should say stupidly using the compiler introduces security problems >> and so far I never advocate for that. > > Good, agreement. :) > >>> [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. >> >> Not in my compiler :) > > ...then why did you write "then this is not a literal array anymore". I > was presuming that you meant "because => is not a literal syntax, it is > a message". But perhaps you meant something else? > >>> 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. >> >> and what else? >> >> So people want ANSI compatibility and at the same time new syntax > > Ok, regarding changing the syntax of Smalltalk: > > - Personally I don't care that much for ANSI. It's dead. I think > Smalltalk needs to evolve and bloody hell, you have *Traits* in Pharo, > that is a HUGE difference compared to a bit of literal changes. ;) > > - If we *do* decide to "Hey, let's take a look at our literal syntax", > then we should probably see if we can harmonize a bit. Again, see my > article for some thoughts in that area. > > I agree that Smalltalk literals are quite powerful but I think they can > be improved. > >>> 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. >> >> Not only arrays and dictionaries. Just plain objects and this is a key >> difference!!!!! >> Dictionaries are not objects in Smalltalk so adding dictionary looks to me >> like a patch. > > I don't follow. JavaScript has literal syntax for Arrays and Objects. > And yes, "Dictionaries" and Objects are the same in js, although it's > limited to only string keys etc. > > In Smalltalk we have literal syntax for Arrays (three different ones > even) but none for Dictionaries. Why do you say that adding syntax for > Dictionaries looks like a "patch" but having syntax for Arrays is > perfectly fine? What is the distinguishing feature of Array that makes > them so different? > >>>> 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. >> >> ok I was talking about the syntactic aspect of having { } instead of >> writing Array new: >> because this is what you want >> {|% >> instead of Dictionary newFrom: > > How do you know "what I want" when you don't read the article? Or have > you read it now? > >>>> 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. >> >> You could also say quite limited because you can only put dictionary >> inside dictionary and literals. so no objects. > > Sure, limited. But that is the whole point of literals, that they are > limited. And in the case of Smalltalk of course - that they are actually > evaluated and constructed at *compile time* and not at run time, that is > also a very important aspect. > >> but in that case why don't we use literal syntax for objects? >> Why stopping at Dictionary. > > This kind of argument is not fruitful. > >> If you ask me I would remove #() as a syntactic elements because most of >> the time { } is what you want. > > Well... The fact that #() are constructed at compile time is a BIG > difference. So I still think both constructs are useful. > >>>> 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? >> >> so Dictionary and Set and why not objectsâ¦. > > Again, not fruitful. > >>> 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? >> >> Because I do not care if you want to use STON, JSON XML for your own >> program this is your choice. I care that I will have >> to load JSON, STON in core to load or save code and that I have to use a >> different syntax to look at code in Git. > > I know, but I/we are not discussing that here. Ok? I know it was the > seed of all these threads but THIS thread is not about that. > > For me personally this sums it up fairly well: > > - It would be nice with a strong, heavily supported fast and slick > implementation of JSON. If STON can be that (superset of JSON) then I > support Sven all the way to the moon! For Smalltalk source code meta > data? No, personally I would also prefer literals I guess. Or Tirade :) > > - Tirade covers a different spectra. People get stuck on its name, for > whatever reason, call it "Cascade" if it makes you happy. +1, makes sense and it partially self-explaining. I think it is > quite interesting in its capabilities and if anyone wants to help me > evolve it more, please do. It was after all created because I felt the > need for a good format for Deltas and JSON failed the test (strings in > JSON can't have linefeeds!!!). > > - Smalltalk should not be set in stone. The literal syntax of Smalltalk > has a bit of "warts" and it would be awesome if Pharo (with all its > momentum) could go forward and say "Hey, let's take another step > forward!" and try to bring it up a notch. That would involve both > perhaps simplifying, harmonizing and making it a tad more powerful. > > This last part is something that got evident to me after working with > Tirade (felt the lack of Associations there) and later with Amber (which > also felt a strong lacking in the same area when trying to mix with js). > I will try to write some kind of separate posting on that subject, and > see if it "sticks to the wall". > > Now... Stef - I like you a lot and if you want to discuss this last part > constructively I am all game. But hey, if you just want to shoot down > everything we say, without even giving it a second thought or (gasp!) > taking the time to read - then I do have better things to do. > > regards, GÃ¶ran > >

May 9, 2012

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

by Mariano Martinez Peck

>>> >>> >> 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. > > Ok, so I will re-do the slice adding your stuff and I will put it as FixToInclude :) > >> >>> 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, >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> >> > > > -- Mariano http://marianopeck.wordpress.com

May 9, 2012

[Pharo-project] MC, Ring and RPackage dependencies

by Pavel Krivanek

Hi, I yesterday put Pharo Kernel Gofer 2.0 job into operation (together with some other dependent like Seaside and OSProcess evaluator). But unfortunatelly I have to say it was quite complicated and I had to do some ugly hacks because we do not have solved dependencies between Monticello, Ring and RPackage. The loading order we use now is: 'Monticello' 'MonticelloConfigurations' 'Ring-Core-Kernel' 'RPackage-Core' 'RPackage-SystemIntegration' Authors of this packages should know that this are primitive packages that cannot be loaded in one bundle via Monticello but must be loaded one by one as standard *.st files. That means that that we have to have well known and working loading order. As an example, currently the initialization of the package 'RPackage-Core' is dependent on presence of 'RPackage-SystemIntegration'. Cheers, -- Pavel

May 9, 2012

[Pharo-project] [update 2.0] #20061

by Marcus Denker

20061 ----- Issue 5848: Updating broken because DNU #removeHTTPRepositoryLocationNamed: http://code.google.com/p/pharo/issues/detail?id=5848 Issue 5844: newSpecialArray fixes http://code.google.com/p/pharo/issues/detail?id=5844 Issue 5843: Nautilus DNU on context menu on Class http://code.google.com/p/pharo/issues/detail?id=5843 Issue 5842: remove browse it here http://code.google.com/p/pharo/issues/detail?id=5842 Issue 5841: referredInstVars http://code.google.com/p/pharo/issues/detail?id=5841 Issue 3639: Remove ServerDirectory http://code.google.com/p/pharo/issues/detail?id=3639 -- Marcus Denker -- http://marcusdenker.de

May 9, 2012

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

by GÃ¶ran Krampe

Hi Stephane and all! On 05/09/2012 08:29 AM, StÃ©phane Ducasse wrote: >>> 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. > > yes so using literal array does not bring any security problems. > Or we should say stupidly using the compiler introduces security problems and so far I never advocate for that. Good, agreement. :) >> [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. > > Not in my compiler :) ...then why did you write "then this is not a literal array anymore". I was presuming that you meant "because => is not a literal syntax, it is a message". But perhaps you meant something else? >> 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. > > and what else? > > So people want ANSI compatibility and at the same time new syntax Ok, regarding changing the syntax of Smalltalk: - Personally I don't care that much for ANSI. It's dead. I think Smalltalk needs to evolve and bloody hell, you have *Traits* in Pharo, that is a HUGE difference compared to a bit of literal changes. ;) - If we *do* decide to "Hey, let's take a look at our literal syntax", then we should probably see if we can harmonize a bit. Again, see my article for some thoughts in that area. I agree that Smalltalk literals are quite powerful but I think they can be improved. >> 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. > > Not only arrays and dictionaries. Just plain objects and this is a key difference!!!!! > Dictionaries are not objects in Smalltalk so adding dictionary looks to me like a patch. I don't follow. JavaScript has literal syntax for Arrays and Objects. And yes, "Dictionaries" and Objects are the same in js, although it's limited to only string keys etc. In Smalltalk we have literal syntax for Arrays (three different ones even) but none for Dictionaries. Why do you say that adding syntax for Dictionaries looks like a "patch" but having syntax for Arrays is perfectly fine? What is the distinguishing feature of Array that makes them so different? >>> 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. > > ok I was talking about the syntactic aspect of having { } instead of writing Array new: > because this is what you want > {|% > instead of Dictionary newFrom: How do you know "what I want" when you don't read the article? Or have you read it now? >>> 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. > > You could also say quite limited because you can only put dictionary inside dictionary and literals. so no objects. Sure, limited. But that is the whole point of literals, that they are limited. And in the case of Smalltalk of course - that they are actually evaluated and constructed at *compile time* and not at run time, that is also a very important aspect. > but in that case why don't we use literal syntax for objects? > Why stopping at Dictionary. This kind of argument is not fruitful. > If you ask me I would remove #() as a syntactic elements because most of the time { } is what you want. Well... The fact that #() are constructed at compile time is a BIG difference. So I still think both constructs are useful. >>> 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? > > so Dictionary and Set and why not objectsâ¦. Again, not fruitful. >> 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? > > Because I do not care if you want to use STON, JSON XML for your own program this is your choice. I care that I will have > to load JSON, STON in core to load or save code and that I have to use a different syntax to look at code in Git. I know, but I/we are not discussing that here. Ok? I know it was the seed of all these threads but THIS thread is not about that. For me personally this sums it up fairly well: - It would be nice with a strong, heavily supported fast and slick implementation of JSON. If STON can be that (superset of JSON) then I support Sven all the way to the moon! For Smalltalk source code meta data? No, personally I would also prefer literals I guess. Or Tirade :) - Tirade covers a different spectra. People get stuck on its name, for whatever reason, call it "Cascade" if it makes you happy. I think it is quite interesting in its capabilities and if anyone wants to help me evolve it more, please do. It was after all created because I felt the need for a good format for Deltas and JSON failed the test (strings in JSON can't have linefeeds!!!). - Smalltalk should not be set in stone. The literal syntax of Smalltalk has a bit of "warts" and it would be awesome if Pharo (with all its momentum) could go forward and say "Hey, let's take another step forward!" and try to bring it up a notch. That would involve both perhaps simplifying, harmonizing and making it a tad more powerful. This last part is something that got evident to me after working with Tirade (felt the lack of Associations there) and later with Amber (which also felt a strong lacking in the same area when trying to mix with js). I will try to write some kind of separate posting on that subject, and see if it "sticks to the wall". Now... Stef - I like you a lot and if you want to discuss this last part constructively I am all game. But hey, if you just want to shoot down everything we say, without even giving it a second thought or (gasp!) taking the time to read - then I do have better things to do. regards, GÃ¶ran

May 9, 2012

[Pharo-project] DrGeo Android release

by Hilaire Fernandes

Hello, A small note to let you know we release a free version of DrGeo on Google Play. https://play.google.com/store/apps/details?id=eu.drgeo.android +1 for Smalltalk :) A complete version will follow in a few days. Hilaire & Dimitry -- Dr. Geo -- http://www.drgeo.eu

May 9, 2012

Re: [Pharo-project] Strangest object ever seen?

by StÃ©phane Ducasse

> 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 In 20060 I got 4 elements and the first one is apparently Metaclass but I do not understand why self first class Metaclass self first class superclass ClassDescription Now I do not understand why this guy cannot get printed. I do not see why ClassDescription>>printOn: aStream aStream nextPutAll: self name Metaclass>>name "Answer a String that is the name of the receiver, either 'Metaclass' or the name of the receiver's class followed by ' class'." thisClass == nil ifTrue: [^'a Metaclass'] ifFalse: [^thisClass name , ' class'] self first soleInstance printString -> leads to have emergency debugger. Stef

May 9, 2012

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

by StÃ©phane Ducasse

>> >> 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. yes so using literal array does not bring any security problems. Or we should say stupidly using the compiler introduces security problems and so far I never advocate for that. > [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. Not in my compiler :) > 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. and what else? So people want ANSI compatibility and at the same time new syntax > 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. Not only arrays and dictionaries. Just plain objects and this is a key difference!!!!! Dictionaries are not objects in Smalltalk so adding dictionary looks to me like a patch. > >> 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. ok I was talking about the syntactic aspect of having { } instead of writing Array new: because this is what you want {|% instead of Dictionary newFrom: >> 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. You could also say quite limited because you can only put dictionary inside dictionary and literals. so no objects. but in that case why don't we use literal syntax for objects? Why stopping at Dictionary. If you ask me I would remove #() as a syntactic elements because most of the time { } is what you want. >> 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? so Dictionary and Set and why not objectsâ¦. > > 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? Because I do not care if you want to use STON, JSON XML for your own program this is your choice. I care that I will have to load JSON, STON in core to load or save code and that I have to use a different syntax to look at code in Git. > > regards, GÃ¶ran

May 9, 2012

Re: [Pharo-project] smallUML news: towards autogenerated diagrams

by StÃ©phane Ducasse

Hi carla why do you need to pass a block? > > > You will notice that what I've got so far is: > â¢ Drawing the classes involved in the evaluation of that block, with the messages that were sent during that block > â¢ Drawing the superclasses involved along with the inheritance arrow. Superclasses are included only if there are inherited methods excecuted. > â¢ Drawing the association relationships between instances! That's my favorite part, and the one that was not trivial to achieve. The code still sucks, but it's working. You can see that the association relationships between the Ship, the Pirate and the Mission are drawn, and Collections are 'skipped' as in a regular class diagram using the cardinality annotation * over the arrow. > What's interesting about this last point, is resolving these (still pending) issues: > â¢ If an object form class A has a collection where the elements are of different classes, or if it has an attribute that could point to different polimorfic objects, there should be just one association arrow from class A to: > â¢ the superclass of those different classes, or > â¢ the inferred type those different classes share: this comes along with some questions, like 'what will the type name be?' > â¢ What will be the scope of the diagram? Objects can have attributes ponting to numbers, strings, blocks, booleans, etc. Are we interested in showing those classes in a class diagram? usually it does not really work to display primitive types using arrow a type annotation of the instance variable would be enough. A design diagram is usually focusing on relation between domain entities > I guess, it depends. The diagram scope should not be hard coded (as it is now :P), because if we want to document a core package, some core classes will have to appear instead of being ignored like we would prefere in a 'domain specific' diagram. > â¢ Collections are 'skipped' in the diagrams. That means that if an object A points to a collection, that points to several objects of class B, in the diagram only the classes A and B are shown with the classical 'one to many' arrow. This will mess up diagrams of the collection packages themselves :P > So, I invite you to think about how could these issues be resolved, and also play a little bit with what I've got so far, executing [your block code] asClassDiagram openQuickView. > > I hope that the GSoC project of Santiago will help with the type inferences part :) but if you do a dynamic analysis then you already get the concrete type of objects so you will not gain much more. Can you show us the way nodes are created? I mean that is the model because what I would like is a class and relations model that we can navigate to draw morphic or other objects. Stef > > Cheers! > Carla. > >

May 9, 2012

Re: [Pharo-project] [squeak-dev] Re: [ANN] STON - Smalltalk Object Notation

by H. Hirzel

On 5/5/12, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Hi Hannes, > > On 05 May 2012, at 11:53, H. Hirzel wrote: > >> Thank you Sven for your follow up of the recent JSON/STON/Tirade >> discussion by providing an STON implementation for Squeak 4.3 and >> working with Dale to get it to other Smalltalks (github). [1] >> >> I think your STON implementation will be very useful for my work. It >> works fine in Squeak 4.3 updated to the latest change [2]. > > Thanks for the feedback and the encouragement. > >> There is a class STON used as a singleton. I assume this is the >> equivalent of the JSON object in web browsers, right? > > I am afraid I am not familiar enough with how JSON is handled in > Javascript/Webbrowsers, so I cannot compare. > > But the STON object in the current implementation is a class facade API to > read/write to/from streams/strings while hiding the actual parser or writer > classes. It is a central access point, but it is very thin: using STONReader > or STONWriter directly is perfectly OK too. Maybe I should add some > invocation examples to the paper to explain the API. > > Sven Hi again, Sven, Thank you for this explanation and the updating of the documentation on github. For the JSON object in web browsers ECMAScript 5.1 specification: chapter 15.12 <citation> The JSON object is a single object that contains two functions, parse and stringify, that are used to parse and construct JSON texts. The JSON Data Interchange Format is described in RFC 4627 <http://www.ietf.org/rfc/rfc4627.txt>. </citation> And https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/JSON Regards Hannes

May 9, 2012