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

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

by Damien Cassou

Hi Carla, On Tue, May 8, 2012 at 11:37 AM, Carla F. Griggio <carla.griggio(a)gmail.com> wrote: > There's still a lot of work to be done, but I've just got this working and I > wanted to show it to you :) what about some screenshots to help us get a feeling of what you did? -- 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] Unicode/Latin1 handling in Pharo 1.3

by Sven Van Caekenberghe

Hi Holger, -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 08 May 2012, at 10:57, Holger Hans Peter Freyther wrote: > 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' > > <pharo_example_latin1.txt> This should work: | stream text | stream := (FileStream fileNamed: '/Users/sven/Desktop/pharo_example_latin1.txt') converter: Latin1TextConverter new; yourself. text := stream contents. text = 'TeilrÃ¼ckzahlung'. or this (latest Zn code): | stream text | stream := (FileStream fileNamed: '/Users/sven/Desktop/pharo_example_latin1.txt') binary; yourself. text := (ZnCharacterEncoder newForEncoding: 'iso-8859-15') decodeBytes: stream contents. text = 'TeilrÃ¼ckzahlung'. there seems to be an issue with ISO885915TextConverter, check the umlaut encoding: it adds something called the leadingChar which I don't think is needed (I don't know why it even exists). HTH, Sven

May 8, 2012

[Pharo-project] smallUML news: towards autogenerated diagrams

by Carla F. Griggio

Hi everyone! I've been doing some experiments to get Class Diagrams generated from the evaluation of a block. There's still a lot of work to be done, but I've just got this working and I wanted to show it to you :) Gofer new squeaksource: 'smallUML'; package: 'ConfigurationOfSmallUML'; load. ((Smalltalk at: #ConfigurationOfSmallUML) project version:'1.1.6') load. After downloading the project, try this example: [|jack william blackPearl questMission| jack := Pirate new alcoholLevel: 0.7; items:#(#compass #islandMap #rum #moreRum #goldMedallion). questMission := TreasureQuest new. blackPearl := Ship new. blackPearl mission: questMission. blackPearl acceptIntoTripulation: jack. ] asClassDiagram openQuickView A messy and 'overlapped' diagram will come up, because there's still no autimatic positioning of the diagram nodes :( but you can drag the class boxes around to place them anywhere you want. 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? 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 :) Cheers! Carla.

May 8, 2012

Re: [Pharo-project] Improved version of StartupPreferences

by Marcus Denker

On May 8, 2012, at 11:34 AM, Damien Cassou wrote: > 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? > It is enabled now for all platform but windows. Marcus -- Marcus Denker -- http://marcusdenker.de

May 8, 2012

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