- Pharo-users - lists.pharo.org

[ANN] SpecUIAddOns

by HernÃ¡n Morales Durand

Hi, SpecUIAddOns is a set of widgets for Spec. The aim of SpecUIAddOns is to provide additional widgets missing in the current distribution of Spec. Please be aware this is still an experimental package. Tested in Pharo 6.1 and Windows. Installation, sceenshots and usage instructions can be found in the github page: https://github.com/hernanmd/SpecUIAddOns Cheers, HernÃ¡n

March 5, 2018

Pharo for MacOs 10.6.8?

by stefano franchi

I am trying to find a version of Pharo that would run on an old Mac Powerbook that cannot be upgraded past 10.6.8, but I 'm having no luck. Any suggestions on what I should download? Cheers, Stefano -- __________________________________________________ Stefano Franchi stefano.franchi(a)gmail.com <stefano(a)tamu.edu> http://stefano.cleinias.org

March 5, 2018

Re: [Pharo-users] Bitwise operations in ByteArray (slicing, etc.)

by Benoit St-Jean

Just put that in Integer. ----------------------------bitsSliceFrom: start to: end Â Â Â " Â Â Â Extract bits 4 to 6, i.e. 111 which equals to 7 Â Â Â 2r10000111000 bitsSliceFrom: 4 to: 6 Â Â Â " Â Â Â | num maskÂ | Â Â Â self < 0 ifTrue: [self error: 'This operation is not allowed for negative numbers!']. Â Â Â num := self >> (start - 1). Â Â Â mask := (1 << ((end - start) + 1)) -Â 1. Â Â Â ^num bitAnd: mask.-----------------------------bitsSliceInPlaceFrom: start to: end Â Â Â " Â Â Â Extract bits 4 to 6, IN PLACE, i.e. 111 which equals to 2r00000111000 = 56 Â Â Â 2r10000111000 bitsSliceInPlaceFrom: 4 to: 6 Â Â Â " Â Â Â |Â | Â Â Â ^(self bitsSliceFrom: start to: end) << (start - 1)---------------------------- This should do the job!Â hth ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) On Sunday, March 4, 2018, 2:59:16 PM EST, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: I do bitshifts and masks on Integer. What if you want to take the bits from the 3rd to the 7th? You have to do a some arithmetic to get the slice you want. I'm simply asking for something more dev-friendlier that adds a "layer" on top of that, but that internally does regular bitwise. What I don't like about Integers is that you "lose" information about the zero bits to the left, and with a ByteArray you don't, because the array is fixed size. E.g. (1 << 16) printStringBase: 16. "'10000'" #[1 0 0] hex "'010000'" Maybe I'm too lazy asking when I could have done it myself :) Regards, Esteban A. Maringolo 2018-03-04 16:40 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Take a 24-bit number and you want to isolate the first 5 (these are actually the last, higher order) bits. > > n := 2r101010001111000011110000. > n >> (16+3). > > If necessary, you can apply a mask (assume there are bits earlier/later still). > > (n >> (16+3)) bitAnd: 2r11111 > > Large integers behave as bit strings, see the 'bit manipulation' protocol, and are efficient at it. > >> On 4 Mar 2018, at 20:29, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> Is there any package/library that makes bitwise operations as simple >> as with an Integer, but for larger numbers (as in a ByteArray). >> >> Something that allows me to "slice" a sequence of bits, or extract >> some using the same protocol as with a String of ones and zeros. >> >> Now when I need to work with sequence of bits, I convert an Integer to >> a zero padded version of it up a known size, and then do #copyFrom:to: >> to extract what I need and read back the number from it. >> >> I could use a bytearray for it, but as its name implies, it is >> oriented towards bytes rather than bits (as in the case of Integer). >> >> Now I do stuff like the following to to extract the first 5 bits of a >> fixed length 256 bit array (an Integer). >> >> Integer >>Â readFrom: >>Â Â (((SHA256 hashMessage: message)) asInteger >>Â Â Â printStringBase: 2 length: 256 padded: true) >>Â Â Â copyFrom: 1 to: 5) >>Â base: 2 >> >> I understand bitwise operations, but I couldn't find something that >> does the above in a conciser way. >> >> Performance in my case isn't critical, but working with strings is >> probably two orders of magnitude slower than manipulating bits in >> integers or ByteArrays >> >> Regards, >> >> Esteban A. Maringolo >> > >

March 5, 2018

Re: [Pharo-users] Bitwise operations in ByteArray (slicing, etc.)

by Benoit St-Jean

Hi Esteban, When you say "extract", what exactly do you mean? Let's suppose you have 86, i.e. 2r1010110 Which case do you want? a) 2r1010110 "2 to 5 = 2r10[1011]0 = 2r1011 = 11" or b) 2r1010110 "2 to 5 = 2r10[1011]0 = 2r00[1011]0 =Â 2r0010110 =Â 22" Both cases can be dealt with bit shifting and a bitAnd with optimal performance. ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) On Sunday, March 4, 2018, 2:31:21 PM EST, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: Is there any package/library that makes bitwise operations as simple as with an Integer, but for larger numbers (as in a ByteArray). Something that allows me to "slice" a sequence of bits, or extract some using the same protocol as with a String of ones and zeros. Now when I need to work with sequence of bits, I convert an Integer to a zero padded version of it up a known size, and then do #copyFrom:to: to extract what I need and read back the number from it. I could use a bytearray for it, but as its name implies, it is oriented towards bytes rather than bits (as in the case of Integer). Now I do stuff like the following to to extract the first 5 bits of a fixed length 256 bit array (an Integer). Integer Â readFrom: Â Â (((SHA256 hashMessage: message)) asInteger Â Â Â printStringBase: 2 length: 256 padded: true) Â Â Â copyFrom: 1 to: 5) Â base: 2 I understand bitwise operations, but I couldn't find something that does the above in a conciser way. Performance in my case isn't critical, but working with strings is probably two orders of magnitude slower than manipulating bits in integers or ByteArrays Regards, Esteban A. Maringolo

March 5, 2018

Re: [Pharo-users] Bitwise operations in ByteArray (slicing, etc.)

by Richard Sargent

Please, if you do implement something, start with a Collection class and call it something like BitArray. It might be appropriate to subclass under ByteArray, but perhaps not. On Mar 4, 2018 12:45 PM, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > 2018-03-04 17:15 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Bits are actually numbered from right to left (seen from how they are > printed). > > I understand bit operations, used it extensively with IP address eons ago. > > But if a spec says: "Take the first n bits from the hash", it means > the first significant bits. > so in 2r100101111 the first 3 bits are "100" and not "111". > > > But in a fixed amount of bits you could indeed number them the other way > around. > > It does not matter that you write the leading zeros or not, everything > to the left is zero anyway. When shifting, the right thing happens. > > If it were a packet, with a fixed size, and the header started with 0, > then the leading zeros matter. > > So in my use case it isn't the same "00000000000000000000000000000000" > than "000000000000000000000000000000000000000000000000" (both in hex > notation). > See [1] > > > Adding something like Integer>>#bitSliceFrom:to:size: based on your > reverse numbering would be wrong, IMHO. > > Yes, it would be wrong. Unless you have to option to specify the > endianess you want to use. > > > I guess you could write it like > > > > n := 2r11110000101010001111000011110000. > > from := 8. > > to := 13. > > size := 32. > > (n >> (size - 13)) bitAnd: ((1 << ( to - from + 1)) - 1). > > > > But the size feels out of place. > > How so? > > Thanks in advance, this is super low priority, I just wanted to check > whether something like that already existed. > > Regards! > > > [1] https://github.com/eMaringolo/pharo-bip39mnemonic/blob/ > master/src/BIP39Mnemonic-Core.package/BIP39MnemonicTest.class/instance/ > jsonTestVectors.st > > > Esteban A. Maringolo > >

March 4, 2018

Re: [Pharo-users] [Pharo-dev] Looking for names for the booklet collection

by Esteban A. Maringolo

2018-03-04 13:49 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> Pharo Tools & Technologies >> Pharo Language & Environment > > +1 ... simple, obvious, to the point I adhere to this. I add one more option: "Pharo Tools & Libraries" Regards, Esteban A. Maringolo

March 4, 2018

Re: [Pharo-users] Bitwise operations in ByteArray (slicing, etc.)

by Esteban A. Maringolo

2018-03-04 17:15 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Bits are actually numbered from right to left (seen from how they are printed). I understand bit operations, used it extensively with IP address eons ago. But if a spec says: "Take the first n bits from the hash", it means the first significant bits. so in 2r100101111 the first 3 bits are "100" and not "111". > But in a fixed amount of bits you could indeed number them the other way around. > It does not matter that you write the leading zeros or not, everything to the left is zero anyway. When shifting, the right thing happens. If it were a packet, with a fixed size, and the header started with 0, then the leading zeros matter. So in my use case it isn't the same "00000000000000000000000000000000" than "000000000000000000000000000000000000000000000000" (both in hex notation). See [1] > Adding something like Integer>>#bitSliceFrom:to:size: based on your reverse numbering would be wrong, IMHO. Yes, it would be wrong. Unless you have to option to specify the endianess you want to use. > I guess you could write it like > > n := 2r11110000101010001111000011110000. > from := 8. > to := 13. > size := 32. > (n >> (size - 13)) bitAnd: ((1 << ( to - from + 1)) - 1). > > But the size feels out of place. How so? Thanks in advance, this is super low priority, I just wanted to check whether something like that already existed. Regards! [1] https://github.com/eMaringolo/pharo-bip39mnemonic/blob/master/src/BIP39Mnem… Esteban A. Maringolo

March 4, 2018

Re: [Pharo-users] [Pharo-dev] Looking for names for the booklet collection

by Offray Vladimir Luna CÃ¡rdenas

On 04/03/18 11:49, Peter UhnÃ¡k wrote: > > Pharo Tools & Technologies > > Pharo Language & Environment > > +1 ... simple, obvious, to the point > > please no cryptic/"clever" names > +1. I can see Grafoscopio booklets in the first one, for example. Cheers, Offray

March 4, 2018

Re: [Pharo-users] Bitwise operations in ByteArray (slicing, etc.)

by Sven Van Caekenberghe

Bits are actually numbered from right to left (seen from how they are printed). But in a fixed amount of bits you could indeed number them the other way around. It does not matter that you write the leading zeros or not, everything to the left is zero anyway. When shifting, the right thing happens. Adding something like Integer>>#bitSliceFrom:to:size: based on your reverse numbering would be wrong, IMHO. I guess you could write it like n := 2r11110000101010001111000011110000. from := 8. to := 13. size := 32. (n >> (size - 13)) bitAnd: ((1 << ( to - from + 1)) - 1). But the size feels out of place. > On 4 Mar 2018, at 20:57, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > I do bitshifts and masks on Integer. > > What if you want to take the bits from the 3rd to the 7th? You have to > do a some arithmetic to get the slice you want. > I'm simply asking for something more dev-friendlier that adds a > "layer" on top of that, but that internally does regular bitwise. > > What I don't like about Integers is that you "lose" information about > the zero bits to the left, and with a ByteArray you don't, because the > array is fixed size. > > E.g. > (1 << 16) printStringBase: 16. "'10000'" > #[1 0 0] hex "'010000'" > > Maybe I'm too lazy asking when I could have done it myself :) > > Regards, > > Esteban A. Maringolo > > > 2018-03-04 16:40 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> Take a 24-bit number and you want to isolate the first 5 (these are actually the last, higher order) bits. >> >> n := 2r101010001111000011110000. >> n >> (16+3). >> >> If necessary, you can apply a mask (assume there are bits earlier/later still). >> >> (n >> (16+3)) bitAnd: 2r11111 >> >> Large integers behave as bit strings, see the 'bit manipulation' protocol, and are efficient at it. >> >>> On 4 Mar 2018, at 20:29, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> Is there any package/library that makes bitwise operations as simple >>> as with an Integer, but for larger numbers (as in a ByteArray). >>> >>> Something that allows me to "slice" a sequence of bits, or extract >>> some using the same protocol as with a String of ones and zeros. >>> >>> Now when I need to work with sequence of bits, I convert an Integer to >>> a zero padded version of it up a known size, and then do #copyFrom:to: >>> to extract what I need and read back the number from it. >>> >>> I could use a bytearray for it, but as its name implies, it is >>> oriented towards bytes rather than bits (as in the case of Integer). >>> >>> Now I do stuff like the following to to extract the first 5 bits of a >>> fixed length 256 bit array (an Integer). >>> >>> Integer >>> readFrom: >>> (((SHA256 hashMessage: message)) asInteger >>> printStringBase: 2 length: 256 padded: true) >>> copyFrom: 1 to: 5) >>> base: 2 >>> >>> I understand bitwise operations, but I couldn't find something that >>> does the above in a conciser way. >>> >>> Performance in my case isn't critical, but working with strings is >>> probably two orders of magnitude slower than manipulating bits in >>> integers or ByteArrays >>> >>> Regards, >>> >>> Esteban A. Maringolo >>> >> >> >

March 4, 2018

Re: [Pharo-users] Bitwise operations in ByteArray (slicing, etc.)

by Esteban A. Maringolo

I do bitshifts and masks on Integer. What if you want to take the bits from the 3rd to the 7th? You have to do a some arithmetic to get the slice you want. I'm simply asking for something more dev-friendlier that adds a "layer" on top of that, but that internally does regular bitwise. What I don't like about Integers is that you "lose" information about the zero bits to the left, and with a ByteArray you don't, because the array is fixed size. E.g. (1 << 16) printStringBase: 16. "'10000'" #[1 0 0] hex "'010000'" Maybe I'm too lazy asking when I could have done it myself :) Regards, Esteban A. Maringolo 2018-03-04 16:40 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Take a 24-bit number and you want to isolate the first 5 (these are actually the last, higher order) bits. > > n := 2r101010001111000011110000. > n >> (16+3). > > If necessary, you can apply a mask (assume there are bits earlier/later still). > > (n >> (16+3)) bitAnd: 2r11111 > > Large integers behave as bit strings, see the 'bit manipulation' protocol, and are efficient at it. > >> On 4 Mar 2018, at 20:29, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> Is there any package/library that makes bitwise operations as simple >> as with an Integer, but for larger numbers (as in a ByteArray). >> >> Something that allows me to "slice" a sequence of bits, or extract >> some using the same protocol as with a String of ones and zeros. >> >> Now when I need to work with sequence of bits, I convert an Integer to >> a zero padded version of it up a known size, and then do #copyFrom:to: >> to extract what I need and read back the number from it. >> >> I could use a bytearray for it, but as its name implies, it is >> oriented towards bytes rather than bits (as in the case of Integer). >> >> Now I do stuff like the following to to extract the first 5 bits of a >> fixed length 256 bit array (an Integer). >> >> Integer >> readFrom: >> (((SHA256 hashMessage: message)) asInteger >> printStringBase: 2 length: 256 padded: true) >> copyFrom: 1 to: 5) >> base: 2 >> >> I understand bitwise operations, but I couldn't find something that >> does the above in a conciser way. >> >> Performance in my case isn't critical, but working with strings is >> probably two orders of magnitude slower than manipulating bits in >> integers or ByteArrays >> >> Regards, >> >> Esteban A. Maringolo >> > >

March 4, 2018