July 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] UTF converter fails to read tildes and Ã±

by Sven Van Caekenberghe

On 04 Jul 2011, at 20:44, Guillermo Polito wrote: > Actually, this testcase may be wrong, but reproduces the problem when doing a fileout with tildes and Ã±'s in packages or authors... > > BTW, it does not fail on the assert, it raises an exception when sending the #nextFromStream: :S Well, this is a correct test case: | converter string | converter := UTF8TextConverter new. string := String streamContents: [ :stream | converter nextPut: $a toStream: stream ]. $a = (converter nextFromStream: string readStream). | converter string character | converter := UTF8TextConverter new. character := Character value: 241. "lowercase n with diacritical tilde, in HTML ñ" string := String streamContents: [ :stream | converter nextPut: character toStream: stream ]. character = (converter nextFromStream: string readStream). The silly/stupid thing with the TextConverter hierarchy is that it encodes characters onto a character stream that it treats as a binary stream (i.e. a byte with value 200 decimal is stored as a Character with value 200). To decode, its needs a character stream but treats it as if it contained bytes! If you replace the String with ByteArray in the above it completely fails to act as expected. Look into the code and you'll be surprised. On the other hand, the ZnCharacterEncoder hierachy acts as a real (and simpler) encoder/decoder from characters to bytes and vice versa: | converter bytes character | converter := ZnUTF8Encoder new. character := Character value: 241. "lowercase n with diacritical tilde, in HTML ñ" bytes := ByteArray streamContents: [ :stream | converter nextPut: character toStream: stream ]. character = (converter nextFromStream: bytes readStream). BTW, the main reason for introducing the ZnCharacterEncoder hierachy was because I needed a way to compute how many bytes of encoding a string needed before encoding it (see #encodedByteCountFor:), a non trivial operation for a variable length encoding like UTF8, but the messed up API was another one. Sven PS: I have *not* said that there is an encoding fault in UTF8TextConverter, just that the APi is freaky.

July 5, 2011

[Pharo-project] [update 1.4] #14026

by Marcus Denker

14026 ----- Issue 4496: Package Graphics-Support is empty http://code.google.com/p/pharo/issues/detail?id=4496 Issue 4497: package System-SourceAndChangeFile is empty http://code.google.com/p/pharo/issues/detail?id=4497 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 5, 2011

Re: [Pharo-project] how can I get bit representation of numbers

by bb

Am 05.07.2011 00:26, schrieb Nicolas Cellier: > 2011/7/5 Douglas McPherson <djm1329(a)san.rr.com>: >> Two's complement is a platform representation of integers not (necessarily) a smalltalk one. The concept of negative numbers has nothing to do with the radix a number is expressed in. >> >> There are convenient extensions to the ByteArray protocol added by FFI which allow easy conversion though. I don't have time this second to list them, but will do so in a few hours. >> >> > That's true, but the internal implementation leaks out the bitAnd: > bitOr: and other bit operations... > > Nicolas > >> On Jul 4, 2011, at 15:14 , StÃ©phane Ducasse wrote: >> >>> Sven do your code work with Smalltalk smallInteger? >>> Because I think that in that case you should have 31 bits? >>> >>> >>>>> I would like to see the two complement representation of numbers. >>>> This is what I do, for reading/writing unsigned or two complement signed integer from/to byte streams. >>>> >>>> Note that two complement is only defined for a specific number size, 8, 16, 32 bits. >>>> >>>> unsignedToSigned: integer size: size >>>> ^ integer < (2 raisedTo: size - 1) >>>> ifTrue: [ integer ] >>>> ifFalse: [ (self twoComplement: integer size: size) negated ] >>>> >>>> signedToUnsigned: integer size: size >>>> ^ integer negative >>>> ifTrue: [ self twoComplement: integer size: size ] >>>> ifFalse: [ integer ] >>>> >>>> twoComplement: integer size: size >>>> | mask | >>>> mask := (2 raisedTo: size) - 1. >>>> ^ mask bitAnd: ((integer abs bitXor: mask) + 1) >>>> >>>> These are also very handy in this context (I believe I once submitted that as an issue): >>>> >>>> integerFromByteArray: bytes >>>> | integer | >>>> integer := 0. >>>> bytes withIndexDo: [ :each :index | >>>> integer := integer + (each bitShift: (bytes size - index) * 8) ]. >>>> ^ integer >>>> >>>> and Integer>>#asByteArrayOfSize: >>>> >>>> Once you have a byte representation, you can render it as bits as well. >>>> >>>> Sven >>>> >>>> >>>> >>> >> >> Sorry for breaking into the thread. A very good hint to get the picture of Integer representation in the twos complement is the "Zahlenkreis". I always use the "Zahlenkreis" if I have to explain someone the twos complement representation of fixed point numbers. See for instance ti.uni-due.de/vs/de/education/Dv1/vorlesung2006/Folie-Zahlenkreis.pdf for a transparency. (That given link is not a special choice for any reason and I will not be paied for - you find many links with the search topic "Zahlenkreis".) I found a french translation: reprÃ©sentation circulaire. I think it is called fixed-point circle in english: http://www.mathworks.com/products/fixed/demos.html?file=/products/demos/shi… The Large Integers obviously are represented symmetric with a leading sign bit. (SmallInteger maxVal +1) printStringBase: 2 '1000000000000000000000000000000' It is astonisching that the smallest LargePositiveInteger has 30 0`s? (SmallInteger maxVal +2) printStringBase: 2 '1000000000000000000000000000001' (SmallInteger maxVal +1) negated printStringBase: 2 '-1000000000000000000000000000000' (SmallInteger maxVal +2) negated printStringBase: 2 '1000000000000000000000000000001' (SmallInteger maxVal raisedTo: 10) printStringBase: 2 '111111111111111111111111110110000000000000000000000000101100111111111111111111111110001000000000000000000000000011010001111111111111111111111100000100000000000000000000000011010001111111111111111111111110001000000000000000000000000000101100111111111111111111111111110110000000000000000000000000000001' (SmallInteger maxVal raisedTo: 10) negated printStringBase: 2 '-111111111111111111111111110110000000000000000000000000101100111111111111111111111110001000000000000000000000000011010001111111111111111111111100000100000000000000000000000011010001111111111111111111111110001000000000000000000000000000101100111111111111111111111111110110000000000000000000000000000001' An interesting topic! Regards BB

July 5, 2011

Re: [Pharo-project] About locating home

by Marcus Denker

On Jul 5, 2011, at 10:53 AM, Igor Stasenko wrote: > > i'm not sure if there are any prims which allowing you to access > environment vars. > I remember i made an example for FFI how to read them.. but that means > it will work only using FFI. I personally think we should (mid-term) get one *really* good and fast FFI and than move as many things as possible from the VM to the image... Security (what people in the past used as an excuse to not do this) we should deal with on another level. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 5, 2011

Re: [Pharo-project] "I arranged all my public packages with metacello."

by Igor Stasenko

Nice excersise.. So, we have one more person with metacello expertise :) On 5 July 2011 02:52, HwaJong Oh <daliot.oh(a)gmail.com> wrote: > Hi, > > I arranged all my public packages with metacello. > http://www.squeaksource.com/DaliotsPlayground.html > > What i did was: > step 0. learned metacello with ProStef (ProStef rocks!) > step 1. create a new repository www.squeaksource.com/DaliotsPlayground. > step 2. upload all public packages to it. (Gofer push rocks!) > step 3. With clean image, test each packages installable stand-aone. > step 4. Write small ConfigurationOfXXX package for each package that does > not install alone. > step 5. realize all those small ConfigurationOfXXX have many redundancy. > step 6. create ConfigurationOfDaliotsPlayground and copied baselines and > versions into it. > step 7. removed all ConfigurationOfXXX except > ConfigurationOfDaliotsPlayground. > > ** through this process, tested each packages and ConfigurationOfXXXs by > installing them in clearn image. > > problems: > 1. package testing was uneffiicient consuming a lot of time. > 2. download counts and activity indicator soared unintentionally. > 3. testing doubles since Squeak compatibility is not checked. > > Best Regards > > -- > View this message in context: http://forum.world.st/I-arranged-all-my-public-packages-with-metacello-tp36… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

July 5, 2011

Re: [Pharo-project] About locating home

by Igor Stasenko

Here what they returning (on macs) TTT class>>getSecuredir <primitive: 'primitiveGetSecureUserDirectory' module: 'SecurityPlugin'> self primitiveFailed. TTT getSecuredir '/foobar/tooBar/forSqueak/bogus/' TTT class>>primitiveGetUntrustedUserDirectory <primitive: 'primitiveGetUntrustedUserDirectory' module: 'SecurityPlugin'> self primitiveFailed. TTT primitiveGetUntrustedUserDirectory '/Users/sig/Library/Preferences/Croquet/Internet/Untrusted' as you can see none of them could be called 'home', which in my case should be /Users/sig On unix system(s), this is easy - one could just use HOME environment variable. On windows.. its different. i'm not sure if there are any prims which allowing you to access environment vars. I remember i made an example for FFI how to read them.. but that means it will work only using FFI. On 5 July 2011 10:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > There are two primitives defined in SecurityPlugin: > > primitiveGetSecureUserDirectory > primitiveGetUntrustedUserDirectory > > i'm not sure what they return, but this is all it has. > > On 4 July 2011 18:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> do yo have an idea of the primitive? >> >> Stef >> >>>> >>>> FS uses SecurityManager as a fix point to identify home. >>>> Now we do not have Security manager so I'm wondering if we should not remove home/document/desktop from FS, >>>> else any ideas how we can replace the entry point a securityManager? >>>> >>> I think you can place a primitives which providing these paths somewhere in FS. >>> >>>> Stef >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

July 5, 2011

Re: [Pharo-project] About locating home

by Igor Stasenko

There are two primitives defined in SecurityPlugin: primitiveGetSecureUserDirectory primitiveGetUntrustedUserDirectory i'm not sure what they return, but this is all it has. On 4 July 2011 18:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > do yo have an idea of the primitive? > > Stef > >>> >>> FS uses SecurityManager as a fix point to identify home. >>> Now we do not have Security manager so I'm wondering if we should not remove home/document/desktop from FS, >>> else any ideas how we can replace the entry point a securityManager? >>> >> I think you can place a primitives which providing these paths somewhere in FS. >> >>> Stef >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

July 5, 2011

Re: [Pharo-project] fuel configuration was broken

by Mariano Martinez Peck

On Tue, Jul 5, 2011 at 10:16 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > The issue is this. The first step Metacello does with a configuration is to > go through all versions and reify them. If this step fails, the loading > stops. > > So, even if you only want to load one specific version, Metacello will > still try to reify every version in the configuration. If there is any > error, the whole process fails. I am arguing that this is not a wanted > behavior :). > I didn't know that :) And do you/Dale know which other problem can appear while reifying versions? I mean...just to be aware of. Last question....I remember something about a new way to validate configurations, I think it was using the toolbox. Does someone know how can I validate a configuration and get the results? > > Did I explain it better now? > > yes :) > Cheers, > Doru > > > > On 5 Jul 2011, at 08:39, Mariano Martinez Peck wrote: > > > > > > > On Tue, Jul 5, 2011 at 12:03 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > Hi, > > > > The Moose build fails because the Fuel configuration is broken. In > particular, in baseline15: there was an error because > FuelWithProgressBarBenchmarks was not defined anymore, but it was required. > So, I simply removed the requirement. Martin, please take a look. > > > > > > Hi Tudor. Such new version was a new version 1.3 and new baseline 1.5. > Even if baseline15 was not correct, I don't understand how that can impact > in Moose because you are still using version 1.2. And if there is impact, > then it is not nice. > > > > > > Please pay attention when building a new version in a Metacello > configuration because Metacello tries to reify every version in the > Configuration, even if that version is not used. I keep on arguing that this > is not a good thing, but at the moment we have to pay more attention :). > > > > > > Sorry, I didn't understand this. > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." > > > -- Mariano http://marianopeck.wordpress.com

July 5, 2011

Re: [Pharo-project] fuel configuration was broken

by Marcus Denker

On Jul 5, 2011, at 10:17 AM, Tudor Girba wrote: > Hi, > > The issue is this. The first step Metacello does with a configuration is to go through all versions and reify them. If this step fails, the loading stops. > But if we now would have continued the Full image and made a new version for *every* trivial change, would this scale? Considering that it already takes 45 Minutes to build Pharo 1.3... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 5, 2011

Re: [Pharo-project] fuel configuration was broken

by Tudor Girba

Hi, The issue is this. The first step Metacello does with a configuration is to go through all versions and reify them. If this step fails, the loading stops. So, even if you only want to load one specific version, Metacello will still try to reify every version in the configuration. If there is any error, the whole process fails. I am arguing that this is not a wanted behavior :). Did I explain it better now? Cheers, Doru On 5 Jul 2011, at 08:39, Mariano Martinez Peck wrote: > > > On Tue, Jul 5, 2011 at 12:03 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > The Moose build fails because the Fuel configuration is broken. In particular, in baseline15: there was an error because FuelWithProgressBarBenchmarks was not defined anymore, but it was required. So, I simply removed the requirement. Martin, please take a look. > > > Hi Tudor. Such new version was a new version 1.3 and new baseline 1.5. Even if baseline15 was not correct, I don't understand how that can impact in Moose because you are still using version 1.2. And if there is impact, then it is not nice. > > > Please pay attention when building a new version in a Metacello configuration because Metacello tries to reify every version in the Configuration, even if that version is not used. I keep on arguing that this is not a good thing, but at the moment we have to pay more attention :). > > > Sorry, I didn't understand this. > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

July 5, 2011