- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] fuel configuration was broken

by Mariano Martinez Peck

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

July 5, 2011

Re: [Pharo-project] About HTTP

by Sven Van Caekenberghe

On 05 Jul 2011, at 00:05, StÃ©phane Ducasse wrote: > curl -i http://localhost:8080/DateOfTheDay|more ZnClient get: 'http://localhost:8080/DateOfTheDay' Sven

July 5, 2011

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

by StÃ©phane Ducasse

Salut nicolas :) > For positive integers, we have an infinite serie of 0 bits, but we > don't care, we just don't print them. > The problem with two complement is that you have an infinite serie of > leading 1 bits... Yes :) > Otherwise, you can access the bit at any rank with bitAt: > For example, you could use > bitRepresentation > ^(self digitLength * 8 + 1 to: 1 by: -1) collect: [:i | Character > value: $0 charCode + (self bitAt: i)] as: String Included in my question is the fact that small integer are encoded on 31 bits (may be I'm wrong) so printing 32 bits represent LargeINteger and so far I want small integetr so was my assumption correct? and what would be a good method to return bitString of a Small Integer.s 2 raisedTo: 29 returns 536870912 536870912 class returns SmallInteger 2 raisedTo: 30 returns 1073741824 1073741824 class returns LargePositiveInteger -1073741824 class returns SmallInteger 2 class maxVal returns 1073741823 -1 * (2 raisedTo: (31-1)) returns -1073741824 (2 raisedTo: 30) - 1 returns 1073741823 > > The first bit will aways be the sign with the + 1 trick. > > Nicolas > > 2011/7/4 Sven Van Caekenberghe <sven(a)beta9.be>: >> >> On 04 Jul 2011, at 20:16, StÃ©phane Ducasse wrote: >> >>> 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 >> >> >> >> >

July 5, 2011

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

by StÃ©phane Ducasse

On Jul 5, 2011, at 12:26 AM, Nicolas Cellier wrote: > 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... what do you mean by this sentence? That using bitAnd: we can get an idea of the implementation? exactly :) > > 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 >>>> >>>> >>>> >>> >>> >> >> >> >

July 5, 2011