- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Improved version of StartupPreferences

by Damien Cassou

Hi Mariano, On Mon, May 7, 2012 at 10:21 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> 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. your changes make sense. Nevertheless, I thought that looking into the preferences folder was disabled. Did you fix that? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 8, 2012

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

by Frank Shearar

On 8 May 2012 10:07, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 08 May 2012, at 09:55, GÃ¶ran Krampe wrote: > >> Sven - sorry for beating down a bit on STON in that article, nothing personal and I love all the stuff you have done, I just have a hard time placing STON in my toolbox. If you can give me good arguments why I am dead wrong - please do! ;) > > No problem, GÃ¶ran, discussion are good. No offense taken. > > I will try to come back with some more feedback on your post and about Tirade once I have more time to read and think about it. But I have little time this month. > > Here are some quick reactions and factual corrections: > > - <disclaimer> I don't want to push STON on anybody, I don't want to go on a crusade promoting it.</disclaimer> > > - please read the, much extended, paper > > Â Â Â Â https://github.com/svenvc/ston/blob/master/ston-paper.md > > - there are a couple of more examples in the new version of Â the paper > > - Symbols in STON are not artificially limited, there are two variants > > Â Â Â Â #foo > Â Â Â Â #key-value > Â Â Â Â #FOO/1 > > Â Â Â Â #'foo$bar!' > Â Â Â Â #''\u00E9l\u00E8ve en Fran\u00E7ais' > > - yes, the other primitives are intentionally kept equal to JSON > > - STON is already ported and being ported to other Smalltalks > > - STON is now backwards compatible with JSON (both nil and null, as well as singe and double quotes work) > > - you skipped some of the predefined representations that make life so much easier in STON > > Â Â Â Â Time['10:32:10'] > Â Â Â Â Date['2012-05-08'] > Â Â Â Â DateAndTime['2012-05-08T10:33:05.134+02:00'] > Â Â Â Â ByteArray['F87800FF12'] > Â Â Â Â Point[10,-10] > > - but the key point is indeed the class tag (hence the definition, STON is a lightweight, text-based, human-readable data interchange format for class-based object-oriented languages), your small example > > Â Â Â Â IntegerArray [1, 2, 3] > > Â Â Â Â vs > > Â Â Â Â {"type": "IntegerArray", "data": [1, 2, 3]} > > (Your ByteArray example would be ByteArray['010203'] in STON, BTW). > > gives the impression that this is a small thing that is easily overcome, but I strongly disagree, and that is the main reason why I want to see how far STON can go. The things is, some people will call the field "type", others might call it "class" or "_class" or whatever, the value might be "Rectangle" or "java.lang.Rectangle" or "geometry$rectangle". This will never be interoperable and falls out of the JSON spec. > > JSON on itself is *not* self-describing: you either have to use and agree on annotations like the above, or both parties have to agree on types externally. JSON is *not* a serialization format. Despite all that JSON *is* successful, which is great. > > The annotation approach completely breaks down, IMHO, in terms of lightweight & human readable, when the example becomes even slightly more complicated: > > Â Â Â Â Rectangle { #origin : Point [ -40, -15 ], #corner : Point [ 60, 35 ] } > > Â Â Â Â vs > > Â Â Â Â { "type" : "Rectangle", "data" : { > Â Â Â Â Â Â Â Â "origin" : { "type" : "Point", "data" : { "x" : -40, "y" : -15 } }, > Â Â Â Â Â Â Â Â "corner" : { "type" : "Point", "data" : { "x" : 60, "y" : 35 } } } It's worse than that in two ways: given some type Foo understood by the two ends of the connection, unless you have frozen your wire contract (the shape of things), you need to add versioning. Your types essentially become something like "Foo(a)1.1" meaning " a version 1.1 Foo". That implies some convention on handling types of differing version. This issue's not limited to JSON: it'll occur in any serialisation mechanism. [1] But I guess the point of []s is to indicate "this is a well-known class whose shape WILL NOT change because its meaning is as per STON, not your crazy dialect where Rectangle has a special unique shape". The second way is one you already know about: JSON is tree-like, not DAG-like, so you can either use a convention for references, or break DAGs into trees by cloning nodes. In the latter case, you then need a way of reconstructing the DAG, for instance by giving the nodes in your graph an identity (like a "_node" : <an integer> field). frank [1] This links back to a topic I've mentioned before: in CLOS you have UPDATE-INSTANCE-FOR-REDEFINED-CLASS (http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/stagenfun…) but I'll not pursue that issue any further; it's pretty off-topic for the thread. > Granted, Point is treated special in STON, without that special treatment, it would be > > Â Â Â Â Rectangle { #origin : Point { #x : -40, #y : -15 ], #corner : Point { #x : 60, #y : 35 } } > > But let me be absolutely clear: if I want to publish a REST API to talk to the outside world, I would most certainly use JSON (with externally agreed types). For me, STON, is for use between Smalltalk programs (client-server, inter-server, preference, property and configuration files, messaging, meta-info, â¦). It could work with Java, C#, Objective-C, and others. > > Regards, > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > >

May 8, 2012

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

by GÃ¶ran Krampe

Hey! On 05/08/2012 10:05 AM, Janko MivÅ¡ek wrote: > Hi GÃ¶ran, > > One quick note: STON has more chance to be adopted than Tirade simply > because of the name. STON is closer to JSON in people's mind, while > Tirade, what that means? Do note that IMHO Tirade does not really compete with STON/JSON. As I think I wrote in the article I tend to think JSON trumphs STON but that Tirade may be more powerful and interesting in some Smalltalk specific cases. > For me it sounds something tyran-like , pretty > non-attractive therefore. And because most of us don't have time to go > to details, such outside things like name matters. We are also more and > more choosing things based on their perception and not reality. More on > their outside form than on their real value. Hmmm, I don't think I agree that the name is all that important for this kind of highly *technical* packages. STON is closer to JSON which is good since it basically is a true superset and tries to fill the exact same niche. But I agree, for "high profile" packages naming is important - like I convinced Nicolas to rename JTalk to something nicer. Tirade was just a funny name based on the "cascade" nature of the format: "a long angry speech or scolding. Synonyms: diatribe, harangue, rant" I mean, don't people have a sense of humor? :) > So, to have bigger adoption rate we need to take care about naming > things as well. Hehe, well... I am sorry Janko, I don't think Tirade is such a bad name and I don't think it would be worth renaming either. Any other more technical thoughts/comments? regards, GÃ¶ran

May 8, 2012

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

by Sven Van Caekenberghe

On 08 May 2012, at 09:55, GÃ¶ran Krampe wrote: > Sven - sorry for beating down a bit on STON in that article, nothing personal and I love all the stuff you have done, I just have a hard time placing STON in my toolbox. If you can give me good arguments why I am dead wrong - please do! ;) No problem, GÃ¶ran, discussion are good. No offense taken. I will try to come back with some more feedback on your post and about Tirade once I have more time to read and think about it. But I have little time this month. Here are some quick reactions and factual corrections: - <disclaimer> I don't want to push STON on anybody, I don't want to go on a crusade promoting it.</disclaimer> - please read the, much extended, paper https://github.com/svenvc/ston/blob/master/ston-paper.md - there are a couple of more examples in the new version of the paper - Symbols in STON are not artificially limited, there are two variants #foo #key-value #FOO/1 #'foo$bar!' #''\u00E9l\u00E8ve en Fran\u00E7ais' - yes, the other primitives are intentionally kept equal to JSON - STON is already ported and being ported to other Smalltalks - STON is now backwards compatible with JSON (both nil and null, as well as singe and double quotes work) - you skipped some of the predefined representations that make life so much easier in STON Time['10:32:10'] Date['2012-05-08'] DateAndTime['2012-05-08T10:33:05.134+02:00'] ByteArray['F87800FF12'] Point[10,-10] - but the key point is indeed the class tag (hence the definition, STON is a lightweight, text-based, human-readable data interchange format for class-based object-oriented languages), your small example IntegerArray [1, 2, 3] vs {"type": "IntegerArray", "data": [1, 2, 3]} (Your ByteArray example would be ByteArray['010203'] in STON, BTW). gives the impression that this is a small thing that is easily overcome, but I strongly disagree, and that is the main reason why I want to see how far STON can go. The things is, some people will call the field "type", others might call it "class" or "_class" or whatever, the value might be "Rectangle" or "java.lang.Rectangle" or "geometry$rectangle". This will never be interoperable and falls out of the JSON spec. JSON on itself is *not* self-describing: you either have to use and agree on annotations like the above, or both parties have to agree on types externally. JSON is *not* a serialization format. Despite all that JSON *is* successful, which is great. The annotation approach completely breaks down, IMHO, in terms of lightweight & human readable, when the example becomes even slightly more complicated: Rectangle { #origin : Point [ -40, -15 ], #corner : Point [ 60, 35 ] } vs { "type" : "Rectangle", "data" : { "origin" : { "type" : "Point", "data" : { "x" : -40, "y" : -15 } }, "corner" : { "type" : "Point", "data" : { "x" : 60, "y" : 35 } } } Granted, Point is treated special in STON, without that special treatment, it would be Rectangle { #origin : Point { #x : -40, #y : -15 ], #corner : Point { #x : 60, #y : 35 } } But let me be absolutely clear: if I want to publish a REST API to talk to the outside world, I would most certainly use JSON (with externally agreed types). For me, STON, is for use between Smalltalk programs (client-server, inter-server, preference, property and configuration files, messaging, meta-info, â¦). It could work with Java, C#, Objective-C, and others. Regards, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 8, 2012

[Pharo-project] Unicode/Latin1 handling in Pharo 1.3

by Holger Hans Peter Freyther

Hi, I am trying to read a file from disk that is in latin1 encoding and then try to compare the string with a string provided as literal and it fails. My test case can be seen below. I am using Pharo 1.3 on a Linux machine with a UTF-8 locale. Is there something obvious that I am doing wrong? | stream text | stream := (FileStream fileNamed: 'pharo_example_latin1.txt') converter: ISO885915TextConverter new; yourself. text := stream contents. text = 'TeilrÃ¼ckzahlung'

May 8, 2012

Re: [Pharo-project] Primitives

by Mariano Martinez Peck

On Tue, May 8, 2012 at 10:37 AM, Francisco Garau <francisco.garau(a)gmail.com>wrote: > Where is the Interpreter class now? > > I presume it is in a separate package -- if yes, how do I load it into > Pharo 2.0? > > We have lots of interpreters now. If you use cog, you will have for example StackInterpreter, CoInterpreter, etc. They are in a specific branch of the VMMaker package. You can use ConfigurationOfCog to load them in Pharo. For more details read: http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-us… or http://marianopeck.wordpress.com/2011/04/05/first-stop-vms-scm-and-related-… Cheers Thanks, > Francisco > > > On 8 May 2012 08:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On May 8, 2012, at 5:00 AM, Santiago Bragagnolo wrote: >> >> > Hi all, yes. me again. >> > >> > I'm searching for a primitive-definition, something like >> > code : what.it.do : relatedType if apply. >> > >> > Is there something like that? >> > >> >> No, sadly not. >> >> We need a table that has infos on input, side-effects, if the primitive >> is there >> just for speed (fall back code implements it, too)... things like that. >> >> And, of course, we should really clean up primitives and remove the ones >> not needed. (same for Plugins). >> >> Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> > -- Mariano http://marianopeck.wordpress.com

May 8, 2012

Re: [Pharo-project] Improved version of StartupPreferences

by Mariano Martinez Peck

On Tue, May 8, 2012 at 9:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > mariano > how can you override a general behavior without redoing it? > > What I mean by override is exactly redoing. So if in /Users/mariano/.config/pharo/general you have a script that does: UITheme currentSettings fastDragging: true. and then in /Users/mariano/.config/pharo/2.0 (or in startup.st in the image directory) I have a script that does UITheme currentSettings fastDragging: false. then it will be false the value, beacuse the order of execution is from the most general to the most specific. Cheers > Stef > > On May 7, 2012, at 10:21 PM, 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 3). > 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... > > > > 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 > > > > Cheers, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

May 8, 2012

[Pharo-project] [code review needed] Issue 3639: Remove ServerDirectory

by Marcus Denker

http://code.google.com/p/pharo/issues/detail?id=3639 remove FtpUrl, ServerDirectory, ServerFile and RemoteFileStream -- Marcus Denker -- http://marcusdenker.de

May 8, 2012

[Pharo-project] [code review needed] first iteration on moving fileIn users to new codeImporter

by Marcus Denker

http://code.google.com/p/pharo/issues/detail?id=5819 - some cleanings to fileIn usages - some fileIn users moved to use CodeImporter - some fixes to the CodeImporter that raised when testing the two points of above. -- Marcus Denker -- http://marcusdenker.de

May 8, 2012

Re: [Pharo-project] Primitives

by Francisco Garau

Where is the Interpreter class now? I presume it is in a separate package -- if yes, how do I load it into Pharo 2.0? Thanks, Francisco On 8 May 2012 08:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 8, 2012, at 5:00 AM, Santiago Bragagnolo wrote: > > > Hi all, yes. me again. > > > > I'm searching for a primitive-definition, something like > > code : what.it.do : relatedType if apply. > > > > Is there something like that? > > > > No, sadly not. > > We need a table that has infos on input, side-effects, if the primitive is > there > just for speed (fall back code implements it, too)... things like that. > > And, of course, we should really clean up primitives and remove the ones > not needed. (same for Plugins). > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > >

May 8, 2012