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

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

by Norbert Hartl

Am 08.05.2012 um 11:41 schrieb 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). > Yes, characters are mapped to characters with a leadingChar. Furthermore in Character the leadingChar value alters the output of asInteger, asciiValue, codePoint... because they all use the value of the character that includes leadingChar.But Latin1TextConverter doesn't do it so you get false for (ISO885915TextConverter new byteToUnicode: $Ã¼) = (Latin1TextConverter new byteToUnicode: $Ã¼) Because Character>>#= aCharacter "Primitive. Answer true if the receiver and the argument are the same object (have the same object pointer) and false otherwise. Optional. See Object documentation whatIsAPrimitive." ^ self == aCharacter or:[ aCharacter isCharacter and: [self asciiValue = aCharacter asciiValue]] is using asciiValue containing in one case 252 and in the other 71303420 (252 + leadingChar) So leadingChar can be considered harmful. It surely was useful in the 8bit days (that followed the 7bit days). But I personally cannot see why the encoding of character should persist if a character has been created. The approach with leadingChar is keeping the 128 >= asciiValue >= 255 and add the leadingChar for the encoding (comparable to code pages). Another approach would be to have a homogenous encoding inside the image. So a value of a character is always unicode (The 8bit trouble is solved because 8bit now is latin1). There would be only be unicode characters without encoding. And encoders that produce individual encodings. The "westeners first" approach then leads to a situation that everyone not living in the latin1 zone (or good ol' 7bit US) has to live with wide strings. This should be changed but I can see that's no easy task because the leadingChar is used throughout the system trying to help in collation things. It would be a bigger effort to clean this up. Norbert

May 8, 2012

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

by GÃ¶ran Krampe

Hey Sven! On 05/08/2012 11:07 AM, Sven Van Caekenberghe wrote: > 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 Ok, perhaps you have updated it? I thought I read it. I wrote most of the article more than a week ago :) > - Symbols in STON are not artificially limited, there are two variants > > #foo > #key-value > #FOO/1 > > #'foo$bar!' > #''\u00E9l\u00E8ve en Fran\u00E7ais' Ok, perhaps I misunderstood then. I read the BNF etc, and did find some cases which seemed to be limited but now I don't recall. > - yes, the other primitives are intentionally kept equal to JSON > > - STON is already ported and being ported to other Smalltalks Right, I wrote "probably" because I didn't know :) > - STON is now backwards compatible with JSON (both nil and null, as well as singe and double quotes work) That is indeed a nice approach and makes it much more attractive as an alternative. :) > - 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] Skipped? Oh, ok, yeah. I skipped tons of stuff about Tirade too ;). But I agree, its nice with "out of the box" utilities like the above. > - 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, Mmm, in fact, I don't really *advocate* the above - I merely wrote that to show that we *can* do it like that. Personally I tend to think that the reader in 99% of the cases would need to "know" what the hell it is parsing anyway and then also knows what classes to map to. > 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. I agree in full, however contradictory that may sound. ;) > 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 } } } Yeah, but just let me note that my view is that: - If you really, really want to name classes for instantiation you *can* do it within JSON. Ugly, sure. But you can. - In general I believe in 99% of the cases the parsing system has to know what it is parsing, how the JSON looks and how it should be mapped onto objects. Making the JSON parser itsy bitsy smarter with type annotations doesn't help me there, I still need to know that I want to instantiate a PDFPage and put this Rectangle into it - but oh, perhaps not as a Rectangle, but perhaps as two points sent into a class side instantiation message or something. My point being that the type annotations doesn't "buy me" enough. regards, GÃ¶ran

May 8, 2012

Re: [Pharo-project] Primitives

by Guillermo Polito

Santi, On Tue, May 8, 2012 at 1:00 PM, Santiago Bragagnolo < santiagobragagnolo(a)gmail.com> wrote: > I want to know if we've missing primitives in our typeinference > 'primitive-map'. Several primitives allow us to decide the return type of > the method that returns just the primitive. > Actually, the defined primitives in the typeinference 'primitive-map' are > the related with squeak 2.8... it's been a while :P. > Download the VM code as said in Mariano's Blog and have a look at implementations of #initializePrimitiveTable. There you will find stuff like: (0 primitiveFail) (1 primitiveAdd) (2 primitiveSubtract) (3 primitiveLessThan) where the left item is the primitive number, the right one is where to fond the primitive code. Search implementors of the item in the second column and you are in the primitive code :). voilÃ¡. Guille > > 2012/5/8 Frank Shearar <frank.shearar(a)gmail.com> > >> Hi Santiago, >> >> On 8 May 2012 03:59, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> >> 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? >> >> Are you looking to type a primitive call? >> >> frank >> >> > Thanks in advance. >> > >> > Santiago. >> >> >

May 8, 2012

Re: [Pharo-project] Primitives

by Guillermo Polito

On Tue, May 8, 2012 at 10:56 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > 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-… > Yes, but most the primitives are shared and the same :). > > 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] Primitives

by Santiago Bragagnolo

I want to know if we've missing primitives in our typeinference 'primitive-map'. Several primitives allow us to decide the return type of the method that returns just the primitive. Actually, the defined primitives in the typeinference 'primitive-map' are the related with squeak 2.8... it's been a while :P. 2012/5/8 Frank Shearar <frank.shearar(a)gmail.com> > Hi Santiago, > > On 8 May 2012 03:59, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> > 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? > > Are you looking to type a primitive call? > > frank > > > Thanks in advance. > > > > Santiago. > >

May 8, 2012

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

by Sven Van Caekenberghe

Hey Torsten, On 08 May 2012, at 12:10, Torsten Bergmann wrote: > | stream text | > stream := (FileStream fileNamed: 'c:\text.txt') > converter: ISO885915TextConverter new; > yourself. > text := stream contents. > text = 'TeilrÃ¼ckzahlung' > > returns with true for me on a german WindowsXP with the attached file. > > Maybe it is a file format DOS/Unix issue. > > Did you check the bytes/characters in the resulting strings in > an inspector to see the differences: > > ... > text := stream contents. > text inspect. > 'TeilrÃ¼ckzahlung' inspect. > > Bye > T. You're in a better position than me to comment, of course. On my Mac I get: | stream text | stream := (FileStream fileNamed: '/Users/sven/Desktop/pharo_example_latin1.txt') converter: ISO885915TextConverter new; yourself. (stream contents at: 6) codePoint 71303420 ('TeilrÃ¼ckzahlung' at: 6) codePoint 252 252 is lowercase umlaut in Unicode, no ? What ISO885915TextConverter does is in Smalltalk, not it the OS, right ? Sven

May 8, 2012

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

by Carla F. Griggio

Sure, here you are. This would be the diagram of the example I suggested. This is a "quick view" of the diagram, I still need to figure out a better way to save and organize diagrams of a project/category/package, etc On Tue, May 8, 2012 at 6:42 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > 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] Nested progress bars

by Martin Dias

I didn't mention that my question comes from trying and finding bugs in the method BlockClosure>>silentlyValue, in Pharo 2.0 (should be in 1.4 also): silentlyValue "evaluates the receiver but avoiding progress bar notifications to show up." ^[ self value ] on: ProgressInitiationException do: [ :ex | ex sendNotificationsTo: [ :min :max :curr | self traceCr: min printString,' ',max printString,' ',curr printString; cr ]. ]. ----> "; cr" has to be removed from code. After this easy fix, the other bug makes visible: #silentlyValue is not that silently with nested progress bars. Try: [ 'main task' displayProgressFrom: 0 to: 5 during: [ :bar | 0 to: 5 do: [:x | bar value: x. (Delay forMilliseconds: 200) wait. 'nested task ' , x printString displayProgressFrom: 5 to: 10 during: [ :bar2 | 5 to: 10 do: [:x2 | bar2 value: x2. (Delay forMilliseconds: 200) wait] ] ] ]. ] silentlyValue. Cheers. MartÃn On Tue, May 8, 2012 at 12:28 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi all. > > Given the next code, could you explain me why nested progress bars are > not handled by my #on:do:? > How can I achieve that? > > [ > 'main task' > Â Â Â Â displayProgressFrom: 0 to: 5 > Â Â Â Â during: [ :bar | > Â Â Â Â Â Â Â Â 0 to: 5 do: [:x | bar value: x. > Â Â Â Â Â Â Â Â (Delay forMilliseconds: 200) wait. > > Â Â Â Â Â Â Â Â 'nested task ' , x printString > Â Â Â Â Â Â Â Â Â Â Â Â displayProgressFrom: 5 to: 10 > Â Â Â Â Â Â Â Â Â Â Â Â during: [ :bar2 | > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 5 to: 10 do: [:x2 | bar2 value: x2. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (Delay forMilliseconds: 200) wait] ] ] ] > > ] Â Â Â on: ProgressInitiationException > Â Â Â Â do: [ :ex | > Â Â Â Â Â Â Â Â ex sendNotificationsTo: [ :min :max :curr | > Â Â Â Â Â Â Â Â Â Â Â Â self traceCr: curr ] ]. > > > Thanks in advance. > MartÃn

May 8, 2012

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

by Torsten Bergmann

| stream text | stream := (FileStream fileNamed: 'c:\text.txt') converter: ISO885915TextConverter new; yourself. text := stream contents. text = 'TeilrÃ¼ckzahlung' returns with true for me on a german WindowsXP with the attached file. Maybe it is a file format DOS/Unix issue. Did you check the bytes/characters in the resulting strings in an inspector to see the differences: ... text := stream contents. text inspect. 'TeilrÃ¼ckzahlung' inspect. Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

May 8, 2012

Re: [Pharo-project] Improved version of StartupPreferences

by Mariano Martinez Peck

On Tue, May 8, 2012 at 11:36 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > 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. > > Yes Damien, as Marcus said I put it back and only disabled it for Windows until it is fixed. I also solved a problem in which actions defined as "runOnce" were actually executed each time ;) I wrote a blog post about StartupLoader but I will publish it when the changes are integrated ;) otherwise it doesn't make sense. -- Mariano http://marianopeck.wordpress.com

May 8, 2012