- Pharo-users - lists.pharo.org

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾

Thank you, Esteban! You may believe me or not, but I dream about going to every ESUG conference every time. It's not framework this time, it's just small and simple package. And it makes life much, MUCH easier when developing business applications. 2016-12-18 15:39 GMT+03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi Yuri, > > Long time not seeing you ! welcome back :) > Nice framework ! > > Esteban > > On 18 Dec 2016, at 11:45, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > > Imagine, you have some object with amount and price variables. > And you want to calculate total, put this totals to collection and > calculate grand total. > > Naive implementation will be something like > total := amount * price for the first task > and something like > grandTotal := totals sum for the latter one. > > But what if amount or price are nil's? > You can add nil checks, of course: total := (amount ifNil:[0]) * (price > ifNil: [0]). > And then what if totals will be empty? *More checks*. > Is it really wise to have total to be zero if amount is nil? *More > ifTrue:ifFalse: code*. > And then you want to add amount := total / price calculation, and you > realize that both total and price may be nil, and price may be zero. > *More and more and more checks.* > > *Protego* (http://www.smalltalkhub.com/#!/~assargadon/Protego) adds > "protected" versions of common operators and methods. > > So, you just put > total := amount *@ price > and > grandTotal := totals sum_protected > into your code - and everything *just works*. > > total will be nil if any of the operands are nil. grandTotal will be > calculated normally, even for empty totals collection (will return nil > for empty collection). > Collection can hold nil's and it will work anyway. If all elements of the > collection is nil, result will be nil. > > Protected version of addition and subtraction will treat nil's as zeros > until both operands are nil - then it will return nil. > There are protected versions of comparisions, too. > > It's quite simple idea, which is still very useful, and it makes code much > more readable, clean and self-commenting. > > That's why I have extracted this part of SmallPOS framework, and have > published it as separate package to use it in other, non-SmallPOS > applications. > > >

Dec. 18, 2016

Re: [Pharo-users] Hash collision

by stepharong

Hi andres I did not follow the discussion. My remark is just that a good discussion without code for integration does not improve Pharo and we will have people facing again the problem. Stef On Sun, 18 Dec 2016 11:29:11 +0100, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > The primitive and the primitive failure code should behave the same? > > On 12/18/16 2:13 , stepharong wrote: >> Sorry but how can we improve the situation concretely >> >> >> Stef >> >> On Wed, 14 Dec 2016 00:22:47 +0100, Andres Valloud >> <avalloud(a)smalltalk.comcastbiz.net> wrote: >> >>> Oh, ok... then the failure code isn't doing what was intended :). >>> >>> On 12/13/16 15:16 , Martin McClure wrote: >>>> On 12/13/2016 08:39 AM, Andres Valloud wrote: >>>>> I would have expected the floats to be a byte object of size 8. Why >>>>> is >>>>> this conversion needed? Is somehow the primitive thinking the float >>>>> has >>>>> size 2? Or is the primitive hashing 32 bits at a time? The prim >>>>> used >>>>> to be a C version of the byte oriented 1644525 multiplicative hash, >>>>> did >>>>> this change? >>>> >>>> The float is not a byte object of size 8, it's a word object of size >>>> 2. >>>> >>>> When you feed it to #hashBytes:startingWith: the primitive fails. (I >>>> didn't look at why -- maybe because it isn't a byte object?) >>>> >>>> The alternative Smalltalk code treats it like it was a byte object, >>>> even >>>> though it's not. So it iterates through the two words, multiplying >>>> each >>>> by 1664525, then keeping only the low-order 28 bits of the result. But >>>> since each word is a full 32 bits, the high-order four bits of each >>>> word, which include the sign bit, can never affect the hash. >>>> >>>> Regards, >>>> >>>> -Martin >>>> >>> >> >> > -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 18, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by stepharong

thanks for sharing it with us. Now in Moose we have metrics and when a metrics value is not available giving 0 is not the solution. We should probably have Value that wraps the real value for normal case and Unvalued for the case where there is no value. Stef On Sun, 18 Dec 2016 11:45:30 +0100, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > Imagine, you have some object with amount and price variables. > And you want to calculate total, put this totals to collection and > calculate grand total. > > Naive implementation will be something like > total := amount * price for the first task > and something like > grandTotal := totals sum for the latter one. > > But what if amount or price are nil's? > You can add nil checks, of course: total := (amount ifNil:[0]) * (price > ifNil: [0]). > And then what if totals will be empty? More checks. > Is it really wise to have total to be zero if amount is nil? More > ifTrue:ifFalse: code. > And then you want to add amount := total / price calculation, and you > realize that both total and price may be nil, and price may be zero. > More and more and more checks. > > Protego (http://www.smalltalkhub.com/#!/~assargadon/Protego) adds > "protected" versions of common operators and methods. > > So, you just put > total := amount *@ price > and > grandTotal := totals sum_protected > into your code - and everything just works. > > total will be nil if any of the operands are nil. grandTotal will be > calculated normally, even for empty totals collection (will return nil > for empty collection). > Collection can hold nil's and it will work anyway. If all elements of > the collection is nil, result will be nil. > > Protected version of addition and subtraction will treat nil's as zeros > until both operands are nil - then it will return nil. > There are protected versions of comparisions, too. > > It's quite simple idea, which is still very useful, and it makes code > much more readable, clean and self-commenting. > > That's why I have extracted this part of SmallPOS framework, and have > published it as separate package to use it in other, non-SmallPOS > applications. -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 18, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by Ben Coman

Thanks for sharing. A similar thing might be useful for dealing with "quality" of Process Variable measurement in industrial situations - where instruments fail from time to time. I'm not sure of all the pros and cons, but btw an alternative to hanging special behaviour on a method, would be to hang special behaviour on a MissingValue class that you could #initialize any instance variable to. Object subclass: #MissingValue instanceVariableNames: '' classVariableNames: '' package: 'AAAA' MissingValue >> * dummyValue self inform: 'debug trace - got here'. ^self MissingValue >> adaptToNumber: rcvr andSend: selector ^self perform: selector with: rcvr Collection >> sumProtected ^ self inject: 0 into: [ :sum :each | sum + each value] Usage... c := {1.1 * MissingValue new. 1.2 * 10. MissingValue new * 1.3. 10 * 1.4}. "==> an Array(aMissingValue 12.0 aMissingValue 14.0)" c sumExcludeMissing "==> 26.0" cheers -ben On Sun, Dec 18, 2016 at 6:45 PM, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > Imagine, you have some object with amount and price variables. > And you want to calculate total, put this totals to collection and calculate > grand total. > > Naive implementation will be something like > total := amount * price for the first task > and something like > grandTotal := totals sum for the latter one. > > But what if amount or price are nil's? > You can add nil checks, of course: total := (amount ifNil:[0]) * (price > ifNil: [0]). > And then what if totals will be empty? More checks. > Is it really wise to have total to be zero if amount is nil? More > ifTrue:ifFalse: code. > And then you want to add amount := total / price calculation, and you > realize that both total and price may be nil, and price may be zero. > More and more and more checks. > > Protego (http://www.smalltalkhub.com/#!/~assargadon/Protego) adds > "protected" versions of common operators and methods. > > So, you just put > total := amount *@ price > and > grandTotal := totals sum_protected > into your code - and everything just works. > > total will be nil if any of the operands are nil. grandTotal will be > calculated normally, even for empty totals collection (will return nil for > empty collection). > Collection can hold nil's and it will work anyway. If all elements of the > collection is nil, result will be nil. > > Protected version of addition and subtraction will treat nil's as zeros > until both operands are nil - then it will return nil. > There are protected versions of comparisions, too. > > It's quite simple idea, which is still very useful, and it makes code much > more readable, clean and self-commenting. > > That's why I have extracted this part of SmallPOS framework, and have > published it as separate package to use it in other, non-SmallPOS > applications.

Dec. 18, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by Esteban Lorenzano

Hi Yuri, Long time not seeing you ! welcome back :) Nice framework ! Esteban > On 18 Dec 2016, at 11:45, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > > Imagine, you have some object with amount and price variables. > And you want to calculate total, put this totals to collection and calculate grand total. > > Naive implementation will be something like > total := amount * price for the first task > and something like > grandTotal := totals sum for the latter one. > > But what if amount or price are nil's? > You can add nil checks, of course: total := (amount ifNil:[0]) * (price ifNil: [0]). > And then what if totals will be empty? More checks. > Is it really wise to have total to be zero if amount is nil? More ifTrue:ifFalse: code. > And then you want to add amount := total / price calculation, and you realize that both total and price may be nil, and price may be zero. > More and more and more checks. > > Protego (http://www.smalltalkhub.com/#!/~assargadon/Protego <http://www.smalltalkhub.com/#!/~assargadon/Protego>) adds "protected" versions of common operators and methods. > > So, you just put > total := amount *@ price > and > grandTotal := totals sum_protected > into your code - and everything just works. > > total will be nil if any of the operands are nil. grandTotal will be calculated normally, even for empty totals collection (will return nil for empty collection). > Collection can hold nil's and it will work anyway. If all elements of the collection is nil, result will be nil. > > Protected version of addition and subtraction will treat nil's as zeros until both operands are nil - then it will return nil. > There are protected versions of comparisions, too. > > It's quite simple idea, which is still very useful, and it makes code much more readable, clean and self-commenting. > > That's why I have extracted this part of SmallPOS framework, and have published it as separate package to use it in other, non-SmallPOS applications.

Dec. 18, 2016

Protego - smart way to manage NIL's in business calculations

by Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾

Imagine, you have some object with amount and price variables. And you want to calculate total, put this totals to collection and calculate grand total. Naive implementation will be something like total := amount * price for the first task and something like grandTotal := totals sum for the latter one. But what if amount or price are nil's? You can add nil checks, of course: total := (amount ifNil:[0]) * (price ifNil: [0]). And then what if totals will be empty? *More checks*. Is it really wise to have total to be zero if amount is nil? *More ifTrue:ifFalse: code*. And then you want to add amount := total / price calculation, and you realize that both total and price may be nil, and price may be zero. *More and more and more checks.* *Protego* (http://www.smalltalkhub.com/#!/~assargadon/Protego) adds "protected" versions of common operators and methods. So, you just put total := amount *@ price and grandTotal := totals sum_protected into your code - and everything *just works*. total will be nil if any of the operands are nil. grandTotal will be calculated normally, even for empty totals collection (will return nil for empty collection). Collection can hold nil's and it will work anyway. If all elements of the collection is nil, result will be nil. Protected version of addition and subtraction will treat nil's as zeros until both operands are nil - then it will return nil. There are protected versions of comparisions, too. It's quite simple idea, which is still very useful, and it makes code much more readable, clean and self-commenting. That's why I have extracted this part of SmallPOS framework, and have published it as separate package to use it in other, non-SmallPOS applications.

Dec. 18, 2016

Re: [Pharo-users] Hash collision

by Andres Valloud

The primitive and the primitive failure code should behave the same? On 12/18/16 2:13 , stepharong wrote: > Sorry but how can we improve the situation concretely > > > Stef > > On Wed, 14 Dec 2016 00:22:47 +0100, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net> wrote: > >> Oh, ok... then the failure code isn't doing what was intended :). >> >> On 12/13/16 15:16 , Martin McClure wrote: >>> On 12/13/2016 08:39 AM, Andres Valloud wrote: >>>> I would have expected the floats to be a byte object of size 8. Why is >>>> this conversion needed? Is somehow the primitive thinking the float >>>> has >>>> size 2? Or is the primitive hashing 32 bits at a time? The prim used >>>> to be a C version of the byte oriented 1644525 multiplicative hash, did >>>> this change? >>> >>> The float is not a byte object of size 8, it's a word object of size 2. >>> >>> When you feed it to #hashBytes:startingWith: the primitive fails. (I >>> didn't look at why -- maybe because it isn't a byte object?) >>> >>> The alternative Smalltalk code treats it like it was a byte object, even >>> though it's not. So it iterates through the two words, multiplying each >>> by 1664525, then keeping only the low-order 28 bits of the result. But >>> since each word is a full 32 bits, the high-order four bits of each >>> word, which include the sign bit, can never affect the hash. >>> >>> Regards, >>> >>> -Martin >>> >> > >

Dec. 18, 2016

Re: [Pharo-users] Modeling a join table

by stepharong

Hi sergio Did you find a solution to your problem? Stef On Tue, 13 Dec 2016 21:59:09 +0100, sergio ruiz <sergio.rrd(a)gmail.com> wrote: > Hello, all. > > This question is not as much a question about smalltalk as one about > modeling in smalltalk. > > I am currently writing an API using Teapot that will be serving up data > about internet radio stations. I want to be able to let users tag the > stations with arbitrary tags. Using a >relational database, I would > create an object like "Tagging" with foreign keys pointing to the > "Stations" class and the "Tag" Class. It would have station_id and > tag_id. > > If this was going to be even a tiny bit more complex, I would probably > just make it a polymorphic association. > My question is, how would I approach this in smalltalk? Would I just > make methods on tag and station (and whatever else) that stored arrays > of each other? Would I create an >intermediary model like "Tagging" and > have that do the heavy lifting? > > Ideas? Thanks!; > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.Village-Buzz.com > http://www.ThoseOptimizeGuys.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 18, 2016

Re: [Pharo-users] Hash collision

by stepharong

Sorry but how can we improve the situation concretely Stef On Wed, 14 Dec 2016 00:22:47 +0100, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > Oh, ok... then the failure code isn't doing what was intended :). > > On 12/13/16 15:16 , Martin McClure wrote: >> On 12/13/2016 08:39 AM, Andres Valloud wrote: >>> I would have expected the floats to be a byte object of size 8. Why is >>> this conversion needed? Is somehow the primitive thinking the float >>> has >>> size 2? Or is the primitive hashing 32 bits at a time? The prim used >>> to be a C version of the byte oriented 1644525 multiplicative hash, did >>> this change? >> >> The float is not a byte object of size 8, it's a word object of size 2. >> >> When you feed it to #hashBytes:startingWith: the primitive fails. (I >> didn't look at why -- maybe because it isn't a byte object?) >> >> The alternative Smalltalk code treats it like it was a byte object, even >> though it's not. So it iterates through the two words, multiplying each >> by 1664525, then keeping only the low-order 28 bits of the result. But >> since each word is a full 32 bits, the high-order four bits of each >> word, which include the sign bit, can never affect the hash. >> >> Regards, >> >> -Martin >> > -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 18, 2016

whisper code push

by Robert Withers

I just pushed code and I think it is function complete. The encoders available are Bytes, Asn1Der and Json using http://www.squeaksource.com/JSON/ Cryptography-68 Whisper-122 performance numbers by encoder bytes: 123 Mbs json: 5 Mbs asn1der: 5 Mbs I'm off to Java land to integrate these changes.

Dec. 18, 2016