March 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] HMAC-SHA512

by Pierce Ng

On Sun, Mar 04, 2018 at 04:00:23PM -0300, Esteban A. Maringolo wrote: > Thank you Pierce, I managed to make play the SHA classes of your > OpenSSL wrapper with the PBKDF2 from Udo's plus HMAC from the > Cryptography package. > I sent you a pull-request > <https://github.com/PierceNg/OpenSSL-Pharo/pull/1> that includes > missing accessors that I needed to achieve the above interplay. Thanks Esteban. Pull request merged. > The end result is this: https://github.com/eMaringolo/pharo-bip39mnemonic Cool! > What I'm missing is a better PRNG to generate random numbers from 128 > to 256 bits. OpenSSL has RAND_* functions waiting to be wrapped. :-) Or, if your code is running on a modern Unix-like system, read directly from /dev/random or /dev/urandom. Pierce

March 6, 2018

does pharo 5 work in mac high sierra?

by PAUL DEBRUICKER

I assume it works fine but I'm thinking about upgrading and just want to be sure. Thanks Paul

March 6, 2018

Re: [Pharo-users] casting to subclass

by Siemen Baader

On Fri, Mar 2, 2018 at 9:19 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi Siemen > > IIRC this was known as "wide classes", there is some paper about it. > Thanks for the pointer! I found http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.4708 but no Pharo implementation. Was it available in Pharo at some point? cheers Siemen Cheers, > > HernÃ¡n > > 2018-03-02 15:45 GMT-03:00 Siemen Baader <siemenbaader(a)gmail.com>: > > Hi all, > > > > it seems like we cannot cast the class of object to its subclass if that > > subclass has had new instance variables added to it: > > > > http://forum.world.st/changing-the-class-of-an-existing- > object-to-a-subclass-td4239041.html > > > > But I (think) I need it - I'm transforming a DOM tree from > XMLHTMLParser's > > XMLElement s to a subclass of Iliad's ILHTMLBuilderElement s, and for > single > > occurences I would like to use the more specific subclasses, like > > ILCheckboxElement. I can make the cast manually, I know when it is safe > to > > do. > > > > What else could I do, apart from removing the element from its tree, > > creating a new (subclass) instance and then putting this element in > place of > > the old one? Some #perform or `super` magic..? > > > > hm.. > > > > thanks for any pointers! > > > > -- Siemen > >

March 6, 2018

Re: [Pharo-users] casting to subclass

by Siemen Baader

On Fri, Mar 2, 2018 at 9:21 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > "Castings" are aliens in the Smalltalk world, although there is a > #become*: method family, I would discourage you from using it as an > alternative unless you really need to do it. > Ok, thanks. I think this use case is specific enough for casting to be useful, but I see your point. > > If your use case is that concrete, I'd do something like: > > `ILHTMLBuilderElement fromXMLElement: anXMLElement` > Yes.. :) -- Siemen > > Then all subclasses of `ILHTMLBuilderElement` will know what to look > and what to omit from the `XMLElement` parameter. > > Regards! > > Esteban A. Maringolo > > > 2018-03-02 17:08 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > > Siemen Baader <siemenbaader(a)gmail.com> wrote: > >> > >> What else could I do, apart from removing the element from its tree, > >> creating a new (subclass) instance and then putting this element in > place > >> of the old one? Some #perform or `super` magic..? > > > > Use composition? Generate accessing code where necessary. > > Is this very performance critical code? > > > > Stephan > > > > > > > >

March 6, 2018

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

by Henrik Sperre Johansen

Esteban A. Maringolo wrote > Hi Richard, > > Certainly a BitStream is beyond what I initially thought. > > But it could be of some use to play with it, is it available somewhere > with a friendly open source license? > > I might give it a try using it for my generator (tests are already > passing). Your example is almost complete, but if I understand it > you're adding the size of the checksum instead of the checksum itself. > Nonetheless I think its readability is superior, and I guess that it > is better perfomance and memorywise. > > Also it could be useful for Base58Encoder I'm expermenting with. > Encoding is "simple" but requires the use of a really large integer, > I'm stuck at the decoding part now. > After that there is a Base32 encoder (to implement a Bech32 encoder as > well). > > So I might use it in my road of experimentation with these matters. > Unless I diverge from this and abandon it as it normally happens. :/ BaseX encode/decode can be simple enough to fit in a small workspace: base := 58. base58Lookup := '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'. myNumber := 12345678901234567890. decode := [ :string | |decodedNumber| decodedNumber := 0. string do: [ :char | decodedNumber := decodedNumber * base +(base58Lookup indexOf: char) - 1 ]. decodedNumber ]. encode := [ :number | |encodedString numDigits toEncode| numDigits := (number numberOfDigitsInBase: base). toEncode := number. encodedString := String new: numDigits. 0 to: numDigits - 1 do: [ :i | |lutIndex| encodedString at: numDigits - i put: (base58Lookup at: toEncode \\ base + 1). toEncode := toEncode // base. ]. encodedString ]. myString := encode value: myNumber. (decode value: myString) = myNumber. The appeal of Base64 is it transforms the // and \\ operations into simple shifts / masks. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 6, 2018

Re: [Pharo-users] casting to subclass

by Siemen Baader

On Fri, Mar 2, 2018 at 9:08 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Siemen Baader <siemenbaader(a)gmail.com> wrote: > > > > What else could I do, apart from removing the element from its tree, > > creating a new (subclass) instance and then putting this element in place > > of the old one? Some #perform or `super` magic..? > > Use composition? Generate accessing code where necessary. > Hm yes.. This is probably what I'll end up doing eventually. I was trying to save a lot of typing work. XMLElement and ILHTMLBuilder both have useful interfaces, and some of it is called from behind the scenes by their respective frameworks. > Is this very performance critical code? I don't think so. But it is the HTML construction code of a web app, so it *might* become a bottleneck. I don't treat it like this ATM. Siemen > > Stephan > > > >

March 6, 2018

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

by Richard Sargent

+100. Strings are "dead bits", lacking behaviour specific to what they represent. Your date example is an excellent portrayal of that. They should never be used for holding structured data. Think of strings (dead bits) in much the same way we think of paper (dead trees). On Mar 6, 2018 05:46, "Richard O'Keefe" <raoknz(a)gmail.com> wrote: > Re "Strings are wrong", the influences on my thinking went like this. > > (1) As an undergraduate, I did exercises with the Euler compiler > (written in Burroughs Algol) and the XPL compiler (written in XPL). > XPL had immutable strings, rather like AWK or Java, and a PL/I-ish > set of operations on them. Burroughs Algol didn't have strings, > but did have pointers, that you could use to stream through arrays. > It turned out to be notably easier to do tokenising in Algol than > in XPL. > > (2) A friend of mine, while a masters student, made some pocket money > by writing a "batch editor" (same application domain as sed, but > different command set) for IBM mainframes under MVS, which he did > using PL/I. PL/I fans used to point to its string operations as > a good collection, but he had to fight PL/I every step of the way > to get the string operations he needed. When I met UNIX V7 on a > PDP-11, it took me 15 pages of C to accomplish what he needed > more than 50 pages of PL/I to do. And my editor had undo... > The trick was being able to make just the right text abstractions > that I needed. > > (3) A company I worked at had a program that generated assembly code > for several different machines from a common specification. The > original version manipulated instructions as *trees*. A new hire > was asked to write a new generator because the old one was > getting harder to maintain and we wanted it faster. His program > represented instructions as *strings*. It turned out to be > slower and harder to maintain than the original. > > (4) I encountered Eugene Myers' AVL DAG data structure (which quite > efficiently lets you maintain many versions of a large text) and > the Rope data structure (basically a lazy concatenation tree) > that accompanies the Boehm garbage collector. Both of them get > a lot of efficiency out of NOT doing concatenations. > > (5) Learning Java, I found that Java had taken a bullet to the head > which Smalltalk had dodged, and which had been very clearly > explained in the coloured books. Consider the selectors > #printOn: and #printString. There are two ways to implement > them: the smart (Smalltalk) and the spectacularly stupid (Java). > Smart way: #printOn: is basic, #printString is derived. > Stupid way: #printString is basic and #printOn: is derived. > Why is this smart? If you are generating several MB of text > *in order to write it to an external sink*, then #printOn: > does the job very efficiently. But #printString not only > turns over large amounts of memory, giving the GC more work > than it really needs, it is fatally easy to fall into > quadratic time behaviour. > > (5) There's the insufficiently famous epigram by Alan Perlis: > "The string is a stark data structure, > and everywhere it is passed there is much duplication of process. > It is a perfect vehicle for hiding information." > One way to understand this is that it's quite easy to put > information *into* a string, but it can be quite hard to get > it out again. I have even run into examples where the > getting-it-out-reliably part was accidentally impossible. > What the heck, let's take Dates as an example (not of impossibility). > What does '180612' mean? What does dateString copyFrom: 3 to: 4 > give you? But aData monthNumber is hard to misunderstand. > > (6) Then there's the whole scripting attack (Little Bobby Tables) > thing. > > The rule of thumb that I use is that if you are just accepting a > datum, maybe stashing it somewhere, and eventually giving it back, > then a string is fine. For example, considering the huge variety > in the way people's names may be structured, strings are pretty > much the ideal way to represent them. You *shouldn't* be extracting > "the middle initial" because some people don't *have* one and some > people have more than one. (I am sick of my name being rejected as > invalid by American-designed programs that insist that a surname > cannot have an apostrophe or two capital letters. No Irish need > apply.) But if you want to process structured information, you > want to get the data out of string form and into some kind of tree > as soon as you can. In fact, you don't want a string form in the > first place. I have seen people manipulating XML with string > operations, and it's not a pretty sight. > > And when we're talking about something like (REAL) object-oriented > programming in a language like Pharo, we really should be thinking > in terms of objects other than strings. For example, if we take > VMS as an example, [.FOO]BAR.TXT;1 and <.FOO>BAR.TXT.1 are the > same *filename* while they are different *strings*, and resolving > the filename relative to DSK:[ICK.ACK] isn't terribly similar to > string concatenation. (Alphabetic case? Let's not go there.) > This is precisely why there are classes like FileLocator and Path. > > > > On 6 March 2018 at 16:33, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > >> Hi Richard, >> >> Certainly a BitStream is beyond what I initially thought. >> >> But it could be of some use to play with it, is it available somewhere >> with a friendly open source license? >> >> I might give it a try using it for my generator (tests are already >> passing). Your example is almost complete, but if I understand it >> you're adding the size of the checksum instead of the checksum itself. >> Nonetheless I think its readability is superior, and I guess that it >> is better perfomance and memorywise. >> >> Also it could be useful for Base58Encoder I'm expermenting with. >> Encoding is "simple" but requires the use of a really large integer, >> I'm stuck at the decoding part now. >> After that there is a Base32 encoder (to implement a Bech32 encoder as >> well). >> >> So I might use it in my road of experimentation with these matters. >> Unless I diverge from this and abandon it as it normally happens. :/ >> >> Regarding this part: >> > This reminds me of a lesson I learned many years >> > ago: STRINGS ARE WRONG. (Thank you, designers of >> > Burroughs Extended Algol!) When trees aren't the >> > answer, streams often are. >> >> Can you provide more context to this? I wouldn't mind if it is in a >> separate thread or a blog post of your own. >> >> Thanks in advance. >> >> Esteban A. Maringolo >> >> 2018-03-05 21:55 GMT-03:00 Richard O'Keefe <raoknz(a)gmail.com>: >> > I note that the specification in question does not >> > deal with arbitrary bit strings but with "entropies" >> > that are 128 to 256 bits long and a multiple of 32 bits. >> > 4 to 8 bits are copied from the front to the end. >> > (So selecting *this* bit field can be done by taking >> > the first byte of a ByteArray.) This makes the sequence >> > 132 to 264 bits. This is then chopped into 11 bit >> > subsequences. These are not arbitrary subsequences and >> > they are not taken in arbitrary order. They are a stream. >> > >> > My own Smalltalk library include BitInputStream and >> > BitOutputStream, wrapping byte streams. So we could >> > do something like >> > >> > ent := aByteArray size * 8. "BIP-39 ENT" >> > cs := ent // 32. "BIP-39 CS" >> > foo := ByteArray new: (ent + cs) // 8. >> > o := BitOutputStream on: foo writeStream. >> > i := BitInputStream on: aByteArray readStream. >> > 1 to: ent do: [:x | o nextPut: i next]. >> > i reset. >> > o nextUnsigned: cs put: (i nextUnsigned: cs). >> > i close. >> > o close. >> > i := BitInputStream on: foo readStream. >> > ans := (1 to: (ent + cs) // 11) collect: [:x | >> > WordList at: 1 + (i nextUnsigned: 11)]. >> > >> > Stare at this for a bit, and you realise that you don't >> > actually need the working byte array foo. >> > ByteArray >> > methods for: 'bitcoin' >> > mnemonic >> > |ent csn i t| >> > (ent between: 128 and: 256) >> > ifFalse: [self error: 'wrong size for BIP-39']. >> > cs := ent // 32. >> > n := (ent + cs) // 11. >> > i := BitInputStream on: (ReadStream on: self). >> > t := i nextUnsigned: cs. >> > i reset. >> > ^(1 to: n) collect: [:index | >> > WordList at: 1 + (index = n >> > ifTrue: [((i nextUnsigned: 11 - cs) bitShift: cs) bitOr: t] >> > ifFalse: [i nextUnsigned: 11])] >> > >> > My BitInputStream and BitOutputStream classes are, >> > um, not really mature. They aren't *completely* >> > naive, but they could be a lot better, and in >> > particular, BitInputStream>>nextUnsigned: and >> > BitOutputStream>>nextUnsigned:put: are definitely >> > suboptimal. I put this out there just to suggest >> > that there is a completely different way of thinking >> > about the problem. (Actually, this isn't *entirely* >> > unlike using Erlang bit syntax.) >> > >> > Bit*Streams are useful enough to justify primitive >> > support. (Which my classes don't have yet. I did >> > say they are not mature...) >> > >> > This reminds me of a lesson I learned many years >> > ago: STRINGS ARE WRONG. (Thank you, designers of >> > Burroughs Extended Algol!) When trees aren't the >> > answer, streams often are. >> > >> > >> > >> > >> > On 6 March 2018 at 07:21, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >> >> >> >> 2018-03-05 14:02 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> > On Sun, Mar 4, 2018 at 9:43 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". >> >> > >> >> > naive question: why? >> >> >> >> Because it says so. >> >> "A checksum is generated by taking the first ENT / 32 bits of its >> >> SHA256 hash. This checksum is appended to the end of the initial >> >> entropy. >> >> Next, these concatenated bits are split into groups of 11 bits, each >> >> encoding a number from 0-2047, serving as an index into a wordlist. >> >> Finally, we convert these numbers into words and use the joined words >> >> as a mnemonic sentence." [1]. >> >> >> >> > To me it looks like a lousy specification. >> >> >> >> It might be, I can't really tell. >> >> >> >> But such manipulation could be useful if you are knitting different >> >> parts of a binary packet whose boundaries are not at byte level, but >> >> bit instead. So you can take "these 5 bits, concatenate with this >> >> other 7, add 13 zero bits, then 1 followed by the payload". I'm >> >> assuming a non real case here though, my use case was fulfilled >> >> already. >> >> >> >> Regards! >> >> >> >> -- >> >> Esteban A. Maringolo >> >> >> >> [1] >> >> https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi >> ki#generating-the-mnemonic >> >> >> > >> >> >

March 6, 2018

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

by Richard O'Keefe

Re "Strings are wrong", the influences on my thinking went like this. (1) As an undergraduate, I did exercises with the Euler compiler (written in Burroughs Algol) and the XPL compiler (written in XPL). XPL had immutable strings, rather like AWK or Java, and a PL/I-ish set of operations on them. Burroughs Algol didn't have strings, but did have pointers, that you could use to stream through arrays. It turned out to be notably easier to do tokenising in Algol than in XPL. (2) A friend of mine, while a masters student, made some pocket money by writing a "batch editor" (same application domain as sed, but different command set) for IBM mainframes under MVS, which he did using PL/I. PL/I fans used to point to its string operations as a good collection, but he had to fight PL/I every step of the way to get the string operations he needed. When I met UNIX V7 on a PDP-11, it took me 15 pages of C to accomplish what he needed more than 50 pages of PL/I to do. And my editor had undo... The trick was being able to make just the right text abstractions that I needed. (3) A company I worked at had a program that generated assembly code for several different machines from a common specification. The original version manipulated instructions as *trees*. A new hire was asked to write a new generator because the old one was getting harder to maintain and we wanted it faster. His program represented instructions as *strings*. It turned out to be slower and harder to maintain than the original. (4) I encountered Eugene Myers' AVL DAG data structure (which quite efficiently lets you maintain many versions of a large text) and the Rope data structure (basically a lazy concatenation tree) that accompanies the Boehm garbage collector. Both of them get a lot of efficiency out of NOT doing concatenations. (5) Learning Java, I found that Java had taken a bullet to the head which Smalltalk had dodged, and which had been very clearly explained in the coloured books. Consider the selectors #printOn: and #printString. There are two ways to implement them: the smart (Smalltalk) and the spectacularly stupid (Java). Smart way: #printOn: is basic, #printString is derived. Stupid way: #printString is basic and #printOn: is derived. Why is this smart? If you are generating several MB of text *in order to write it to an external sink*, then #printOn: does the job very efficiently. But #printString not only turns over large amounts of memory, giving the GC more work than it really needs, it is fatally easy to fall into quadratic time behaviour. (5) There's the insufficiently famous epigram by Alan Perlis: "The string is a stark data structure, and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information." One way to understand this is that it's quite easy to put information *into* a string, but it can be quite hard to get it out again. I have even run into examples where the getting-it-out-reliably part was accidentally impossible. What the heck, let's take Dates as an example (not of impossibility). What does '180612' mean? What does dateString copyFrom: 3 to: 4 give you? But aData monthNumber is hard to misunderstand. (6) Then there's the whole scripting attack (Little Bobby Tables) thing. The rule of thumb that I use is that if you are just accepting a datum, maybe stashing it somewhere, and eventually giving it back, then a string is fine. For example, considering the huge variety in the way people's names may be structured, strings are pretty much the ideal way to represent them. You *shouldn't* be extracting "the middle initial" because some people don't *have* one and some people have more than one. (I am sick of my name being rejected as invalid by American-designed programs that insist that a surname cannot have an apostrophe or two capital letters. No Irish need apply.) But if you want to process structured information, you want to get the data out of string form and into some kind of tree as soon as you can. In fact, you don't want a string form in the first place. I have seen people manipulating XML with string operations, and it's not a pretty sight. And when we're talking about something like (REAL) object-oriented programming in a language like Pharo, we really should be thinking in terms of objects other than strings. For example, if we take VMS as an example, [.FOO]BAR.TXT;1 and <.FOO>BAR.TXT.1 are the same *filename* while they are different *strings*, and resolving the filename relative to DSK:[ICK.ACK] isn't terribly similar to string concatenation. (Alphabetic case? Let's not go there.) This is precisely why there are classes like FileLocator and Path. On 6 March 2018 at 16:33, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi Richard, > > Certainly a BitStream is beyond what I initially thought. > > But it could be of some use to play with it, is it available somewhere > with a friendly open source license? > > I might give it a try using it for my generator (tests are already > passing). Your example is almost complete, but if I understand it > you're adding the size of the checksum instead of the checksum itself. > Nonetheless I think its readability is superior, and I guess that it > is better perfomance and memorywise. > > Also it could be useful for Base58Encoder I'm expermenting with. > Encoding is "simple" but requires the use of a really large integer, > I'm stuck at the decoding part now. > After that there is a Base32 encoder (to implement a Bech32 encoder as > well). > > So I might use it in my road of experimentation with these matters. > Unless I diverge from this and abandon it as it normally happens. :/ > > Regarding this part: > > This reminds me of a lesson I learned many years > > ago: STRINGS ARE WRONG. (Thank you, designers of > > Burroughs Extended Algol!) When trees aren't the > > answer, streams often are. > > Can you provide more context to this? I wouldn't mind if it is in a > separate thread or a blog post of your own. > > Thanks in advance. > > Esteban A. Maringolo > > 2018-03-05 21:55 GMT-03:00 Richard O'Keefe <raoknz(a)gmail.com>: > > I note that the specification in question does not > > deal with arbitrary bit strings but with "entropies" > > that are 128 to 256 bits long and a multiple of 32 bits. > > 4 to 8 bits are copied from the front to the end. > > (So selecting *this* bit field can be done by taking > > the first byte of a ByteArray.) This makes the sequence > > 132 to 264 bits. This is then chopped into 11 bit > > subsequences. These are not arbitrary subsequences and > > they are not taken in arbitrary order. They are a stream. > > > > My own Smalltalk library include BitInputStream and > > BitOutputStream, wrapping byte streams. So we could > > do something like > > > > ent := aByteArray size * 8. "BIP-39 ENT" > > cs := ent // 32. "BIP-39 CS" > > foo := ByteArray new: (ent + cs) // 8. > > o := BitOutputStream on: foo writeStream. > > i := BitInputStream on: aByteArray readStream. > > 1 to: ent do: [:x | o nextPut: i next]. > > i reset. > > o nextUnsigned: cs put: (i nextUnsigned: cs). > > i close. > > o close. > > i := BitInputStream on: foo readStream. > > ans := (1 to: (ent + cs) // 11) collect: [:x | > > WordList at: 1 + (i nextUnsigned: 11)]. > > > > Stare at this for a bit, and you realise that you don't > > actually need the working byte array foo. > > ByteArray > > methods for: 'bitcoin' > > mnemonic > > |ent csn i t| > > (ent between: 128 and: 256) > > ifFalse: [self error: 'wrong size for BIP-39']. > > cs := ent // 32. > > n := (ent + cs) // 11. > > i := BitInputStream on: (ReadStream on: self). > > t := i nextUnsigned: cs. > > i reset. > > ^(1 to: n) collect: [:index | > > WordList at: 1 + (index = n > > ifTrue: [((i nextUnsigned: 11 - cs) bitShift: cs) bitOr: t] > > ifFalse: [i nextUnsigned: 11])] > > > > My BitInputStream and BitOutputStream classes are, > > um, not really mature. They aren't *completely* > > naive, but they could be a lot better, and in > > particular, BitInputStream>>nextUnsigned: and > > BitOutputStream>>nextUnsigned:put: are definitely > > suboptimal. I put this out there just to suggest > > that there is a completely different way of thinking > > about the problem. (Actually, this isn't *entirely* > > unlike using Erlang bit syntax.) > > > > Bit*Streams are useful enough to justify primitive > > support. (Which my classes don't have yet. I did > > say they are not mature...) > > > > This reminds me of a lesson I learned many years > > ago: STRINGS ARE WRONG. (Thank you, designers of > > Burroughs Extended Algol!) When trees aren't the > > answer, streams often are. > > > > > > > > > > On 6 March 2018 at 07:21, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > >> > >> 2018-03-05 14:02 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> > On Sun, Mar 4, 2018 at 9:43 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". > >> > > >> > naive question: why? > >> > >> Because it says so. > >> "A checksum is generated by taking the first ENT / 32 bits of its > >> SHA256 hash. This checksum is appended to the end of the initial > >> entropy. > >> Next, these concatenated bits are split into groups of 11 bits, each > >> encoding a number from 0-2047, serving as an index into a wordlist. > >> Finally, we convert these numbers into words and use the joined words > >> as a mnemonic sentence." [1]. > >> > >> > To me it looks like a lousy specification. > >> > >> It might be, I can't really tell. > >> > >> But such manipulation could be useful if you are knitting different > >> parts of a binary packet whose boundaries are not at byte level, but > >> bit instead. So you can take "these 5 bits, concatenate with this > >> other 7, add 13 zero bits, then 1 followed by the payload". I'm > >> assuming a non real case here though, my use case was fulfilled > >> already. > >> > >> Regards! > >> > >> -- > >> Esteban A. Maringolo > >> > >> [1] > >> https://github.com/bitcoin/bips/blob/master/bip-0039. > mediawiki#generating-the-mnemonic > >> > > > >

March 6, 2018

Re: [Pharo-users] my mistake on Spec?

by Yuriy Babah

Yes, i'm undestand. Looks good now. 2018-03-05 23:10 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > You should initialize the instance variable > > #subjectTextInput > > I suggest to do your UI incrementally. > > Stef > > On Mon, Mar 5, 2018 at 9:08 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > defaultSpec2 > > <spec: #default> > > ^ SpecLayout composed > > newColumn: [ :col | > > col > > newRow: [ :row | > > row > > add: #plaintiffsTextInput; > > add: #addButtonPlaintiffs ]; > > newRow: [ :row | > > row > > add: #defendantsTextInput; > > add: #addButtonDefendants ]; > > newRow: [ :row | > > row > > add: #thirdPartiesTextInput; > > add: #addButtonThirdParties ]; > > newRow: [ :row | row add: #addButtonCourtCase ] ]; > > yourself > > > > is working > > > > > > > > > > > > > > On Mon, Mar 5, 2018 at 9:00 PM, Stephane Ducasse > > <stepharo.self(a)gmail.com> wrote: > >> I'm trying to understand. > >> I do not get a DNU with the following. You cannot put row out of > nowhere. > >> > >> defaultSpec > >> ^ SpecLayout composed > >> newColumn: [ :col | > >> col > >> newRow: [ :row | > >> row > >> add: #plaintiffsTextInput; > >> add: #addButtonPlaintiffs ]; > >> newRow: [ :row | > >> row > >> add: #defendantsTextInput; > >> add: #addButtonDefendants ]; > >> newRow: [ :row | > >> row > >> add: #thirdPartiesTextInput; > >> add: #addButtonThirdParties ] ]; > >> yourself > >> > >> Now I do not understand why when I add the next lines I get an error > >> > >> > >> > >> > >> > >> > >> > >> > >> On Mon, Mar 5, 2018 at 7:03 PM, Yuriy Babah <babah.yuriy06(a)gmail.com> > wrote: > >>> yesterday i did it, and got --> doesNotUndestand #layout > >>> > >>> 2018-03-05 20:28 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >>>> > >>>> First implement all the missing methods that you use in the spec class > >>>> method. > >>>> Then let us know. > >>>> > >>>> Stef > >>>> > >>>> > >>>> On Sun, Mar 4, 2018 at 2:56 PM, Yuriy Babah <babah.yuriy06(a)gmail.com> > >>>> wrote: > >>>> > Thanks for your help, Stef. > >>>> > Mistakes remain, but I will try to understand them > >>>> > > >>>> > 2018-03-04 16:35 GMT+03:00 Stephane Ducasse < > stepharo.self(a)gmail.com>: > >>>> >> > >>>> >> I'm doing a pass on your code > >>>> >> > >>>> >> OrderedCollection new is better to me than #() asOrderedCollection. > >>>> >> > >>>> >> GUI_ListCourtCase new openWithSpec > >>>> >> => DNU > >>>> >> So I added the first missing method, but you should define the > >>>> >> corresponding methods in the class. > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> On Sun, Mar 4, 2018 at 2:28 PM, Stephane Ducasse > >>>> >> <stepharo.self(a)gmail.com> wrote: > >>>> >> > Hi yuri > >>>> >> > > >>>> >> > some feedback before looking into spec. > >>>> >> > tab method bodies > >>>> >> > then do not use instance variables with uppercase. > >>>> >> > > >>>> >> > Stef > >>>> >> > > >>>> >> > > >>>> >> > On Sun, Mar 4, 2018 at 2:26 PM, Yuriy Babah < > babah.yuriy06(a)gmail.com> > >>>> >> > wrote: > >>>> >> >> changed > >>>> >> >> > >>>> >> >> 2018-03-04 16:20 GMT+03:00 Yuriy Babah <babah.yuriy06(a)gmail.com > >: > >>>> >> >>> > >>>> >> >>> Is it enough if I just attach it? > >>>> >> >>> > >>>> >> >>> I slightly changed the code, that leads to error: > "DoesNotUndestand > >>>> >> >>> #plaintiffsTextInput" . > >>>> >> >>> > >>>> >> >>> Now I'm studying Help on Spec in SystemBrowser . > >>>> >> >>> > >>>> >> >>> > >>>> >> >>> > >>>> >> >>> 2018-03-04 15:23 GMT+03:00 Stephane Ducasse > >>>> >> >>> <stepharo.self(a)gmail.com>: > >>>> >> >>>> > >>>> >> >>>> Hi Yuriy > >>>> >> >>>> > >>>> >> >>>> this is difficult to debug remotely. Do you have your code > >>>> >> >>>> somewhere? > >>>> >> >>>> > >>>> >> >>>> Stef > >>>> >> >>>> > >>>> >> >>>> On Sat, Mar 3, 2018 at 8:41 AM, Yuriy Babah > >>>> >> >>>> <babah.yuriy06(a)gmail.com> > >>>> >> >>>> wrote: > >>>> >> >>>> > Hi! > >>>> >> >>>> > I'm trying to write GUI element with Spec, Pharo6.1x64 on > Linux. > >>>> >> >>>> > Do according to the SpecBooklet. > >>>> >> >>>> > > >>>> >> >>>> > Finished the fragment, and try do: > >>>> >> >>>> > > >>>> >> >>>> > ui := GUI_ListCourtCase new openWithSpec . -> #value was > sent to > >>>> >> >>>> > nil. > >>>> >> >>>> > > >>>> >> >>>> > I look in a debugger and: > >>>> >> >>>> > > >>>> >> >>>> > openWithSpecLayout: aSpec > >>>> >> >>>> > "Build the widget using the spec name provided as > argument > >>>> >> >>>> > and > >>>> >> >>>> > display > >>>> >> >>>> > it into a window" > >>>> >> >>>> > > >>>> >> >>>> > (window value notNil and: [ self needRebuild not ]) > >>>> >> >>>> > ifTrue: [ "window != nil" > >>>> >> >>>> > window value rebuildWithSpecLayout: aSpec ] > >>>> >> >>>> > ifFalse: [ "If value = Nil --> send him a message > >>>> >> >>>> > ???" > >>>> >> >>>> > window value: (self defaultWindowModelClass new > >>>> >> >>>> > model: > >>>> >> >>>> > self). > >>>> >> >>>> > window value openWithSpecLayout: aSpec. > >>>> >> >>>> > self takeKeyboardFocus ]. > >>>> >> >>>> > > >>>> >> >>>> > ^ window value > >>>> >> >>>> > >>>> >> >>> > >>>> >> >> > >>>> > > >>>> > > >>>> > >>> > >

March 6, 2018

Re: [Pharo-users] Ever growing image

by Guillermo Polito

>From the 90's there is the work of Ole Agesen, using type inference to detect (not) dead code and build SELF images. http://dblp.uni-trier.de/pers/hd/a/Agesen:Ole In any case, I only wanted to say that it is unfair to say that Pharo is big when "you only load your packages". And I feel that's not true, if you're using the graphical environment, you need display, bitblt, morphic, widgets. As soon as you need to dynamically run scripts you need the compiler and parsing machinery. As soon as you write any program you mostly need many core libraries (just think about collections). How much space would take both in disk and in memory to build a similar environment in Java/Python? What I feel the most unfair is that we don't even take the time to measure to make a comparison. It's just a complaint... Now, I understand we could build images without development tools, but for that there is some work needed (not only from the pharo side but also from the developer's point of view). In the file server you can download latest minimal images both 32 and 64 bits (http://files.pharo.org/image/70/) - Pharo-metacello-7.0.0-alpha.build.654.sha.494bbfc.arch.32bit.zip <http://files.pharo.org/image/70/Pharo-metacello-7.0.0-alpha.build.654.sha.4…>2018-03-06 10:314.4 MB <http://files.pharo.org/image/70/Pharo-metacello-7.0.0-alpha.build.654.sha.4…> - Pharo-metacello-7.0.0-alpha.build.654.sha.494bbfc.arch.64bit.zip <http://files.pharo.org/image/70/Pharo-metacello-7.0.0-alpha.build.654.sha.4…>2018-03-06 10:314.5 MB <http://files.pharo.org/image/70/Pharo-metacello-7.0.0-alpha.build.654.sha.4…> Those are ~4.5M zip files containing 10MB images and 9MB changes files. Probably that is small enough for you. We can do better but each line of code we remove is indeed a lot of work. Those images have the following packages installed only: - Language Kernel + Traits + Class builder + Slots - RPackage - FFI Kernel - Opal Compiler + AST + Chunk files reader writers - Announcements - Collections - Colors - Files - Others (Hermes, Jobs, Transcript, System packages, UIManager...) - Zinc Character encoders and Buffered streams - Network - Monticello - Metacello + Filetree For a more detailed list, you can browse BaselineOfPharoBootstrap. If you want an image that requires packages that are not there (like morphic), you should install them on top and specify those as dependencies of your project. That is what we do with the Pharo IDE. Take a look at BaselineOfIDE. Again, this could be enhanced and we will greatfully accept any contribution, or discuss on skype about the details or help people to get into this. Guille On Tue, Mar 6, 2018 at 11:14 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Maybe this: > > https://rmod.inria.fr/web/publications/bib?query=Poli17c&display=abstract > > Guillermo Polito, Luc Fabresse, Noury Bouraqadi, and StÃ©phane Ducasse. > Run-Fail-Grow: Creating Tailored Object-Oriented Runtimes > > Producing a small deployment version of an application is a challenge > because static abstractions such as packages cannot anticipate the use of > their parts at runtime. Thus, an application often occupies more memory > than actually needed. Tailoring is one of the main solutions to this > problem i.e., extracting used code units such as classes and methods of an > application. However, existing tailoring techniques are mostly based on > static type annotations. These techniques cannot efficiently tailor > applications in all their extent (e.g., runtime object graphs and metadata) > nor be used in the context of dynamically-typed languages. We propose a > run-fail-grow technique to tailor applications using their runtime > execution. Run-fail-grow launches (a) a reference application containing > the original application to tailor and (b) a nurtured application > containing only a seed with a minimal set of code units the user wants to > ensure in the final application. The nurtured application is executed, > failing when it founds missing objects, classes or methods. On failure, the > necessary elements are installed into the nurtured application from the > reference one, and the execution resumes. The nurtured application is > executed until it finishes, or until the developer explicitly finishes it, > for example in the case of a web application. resulting in an object memory > (i.e., a heap) with only objects, classes and methods required to execute > the application. To validate our approach we implemented a tool based on > Virtual Machine modifications, namely Tornado. Tornado succeeds to create > very small memory footprint versions of applications e.g., a simple > object-oriented heap of 11kb. We show how tailoring works on application > code, base and third-party libraries even supporting human interaction with > user G. interfaces. These experiments show memory savings ranging from 95\% > to 99\%. > > > > > yes, Mariano Peck made a PhD on that (when we were exploring âhow to get > smaller imagesâ possibilities). > > We finally went for bootstrap, but we made an analysis on all > possibilities around. > > > > Mariano was doing swapping outâ¦ > > Mariano Martinez Peck, Noury Bouraqadi, Marcus Denker, StÃ©phane Ducasse, > and Luc Fabresse. Marea: An Efficient Application-Level Object Graph > Swapper. > > Abstract > Abstract During the execution of object-oriented applications, several > millions of objects are created, used and then collected if they are not > referenced. Problems appear when objects are unused but cannot be > garbage-collected because they are still referenced from other objects. > This is an issue because those objects waste primary memory and > applications use more primary memory than they actually need. We claim that > relying on the operating system's (OS) virtual memory is not always enough > since it cannot take into account the domain and structure of applications. > At the same time, applications have no easy way to parametrize nor > cooperate with memory management. In this paper, we present Marea, an > efficient application-level object graph swapper for object-oriented > programming languages. Its main goal is to offer the programmer a novel > solution to handle application-level memory. Developers can instruct our > system to release primary memory by swapping out unused yet referenced > objects to secondary memory. Our approach has been qualitatively and > quantitatively validated. Our experiments and benchmarks on real-world > applications show that Marea can reduce the memory footprint between 23\% > and 36\%. > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 6, 2018