- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Implementing cull:cull: in symbol

by Esteban A. Maringolo

Can somebody please tell me the semantic difference between #cull: and #value: ? 'Cull' is not a word I ever used in any english based conversation :) Regards, -- Esteban. ps: I'm a big fan of having a "valuable" protocol, implemented by both Symbol and BlockClosure (and MessageSend), and I miss this behavior in Pharo. Esteban A. Maringolo 2014-06-19 11:14 GMT-03:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > On 19 Jun 2014, at 15:47, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > In other engines where we want scripting to be used, we use a cull: or > value: with a prefix. In the case of Spec, this could be specCull:cull:. > This could be used as an extension of Symbol without spawning religious wars > :). > > > Yes, also I can use a block with 1 param. The thing is that as far as I > understand cull:cull: means: > > if possible: âvalue:value:â > else if possible: âvalue:â > else âvalueâ > > So this can work for block. But maybe cull: has different philosophy > > Uko > > > The funny thing is that in all these engines that do define special value: > like methods, the implementation looks exactly the same. Perhaps this should > tell us that it would be worth having it by default. > > Doru > > > On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> The thing is that cull:cull: can be used on block with 1 parameter. If you >> consider symbol as a block with one parameter then it will work in the same >> style. >> >> In other words: methods that use value:value: want to ensure that they are >> working with 2 param block. Methods that use cull:cull: donât care what is >> there, but allow you to customise the result with up to 2 parameters. With >> symbol you can customise it with 1 parameter. >> >> Uko >> >> On 19 Jun 2014, at 14:08, Henrik Johansen <henrik.s.johansen(a)veloxit.no> >> wrote: >> >> > >> > On 19 Jun 2014, at 1:42 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> >> Hi, >> >> >> >> maybe we should implement #cull:cull: in symbol so that it will call >> >> #cull:? Because this looks correct, if block has 1 parameter, then >> >> #cull:cull: boils down to #value:, but when we have a symbol instead, we >> >> have an exception. >> >> >> >> I can open an issue and implement that stuff, but I want a feedback >> >> from the conceptual point of view. >> >> >> >> Uko >> >> >> > >> > #cull: is supposed to be the equivalent to the #value: protocol, where >> > the parameter is optional. >> > >> > Symbol has no #value:value: message, hence it should have no #cull:cull: >> > either. >> > >> > You could argue it should implement both, with value:value: polymorphic >> > to the block >> > [:a :b | a perform: theSymbol with: b ]. >> > >> > but cull:cull: would then mean equivalence to: >> > for #+ [:a :b | a + b] >> > for #squared [:a | a self] >> > >> > And I donât see how thatâd be intuitive/useful enough to warrant >> > inclusion >> > >> > Considering the sole reason cull: on Symbol exists, is to allow select: >> > etc. to be written using cull so the block arg is optional, but still do >> > aCollection collect: #mySymbol, the closest equivalent would be . >> > aCollection sort: #> / aCollection inject: 0 into: #+ >> > which, while might be nice, both have no use for cull:cull: in the same >> > manner: >> > aCollection inject: 0 into: #squared -> [:sub :next | sub squared] ??? >> > >> > The whole "who is the receiver, whatâs going onÂ»-factor of cull:cull: on >> > symbol is non-intuitive enough that at least I feel itâs better to write out >> > the block explicitly. >> > >> > Cheers, >> > Henry >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > >

June 19, 2014

Re: [Pharo-dev] Implementing cull:cull: in symbol

by Yuriy Tymchuk

On 19 Jun 2014, at 15:47, Tudor Girba <tudor(a)tudorgirba.com> wrote: > In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). Yes, also I can use a block with 1 param. The thing is that as far as I understand cull:cull: means: if possible: âvalue:value:â else if possible: âvalue:â else âvalueâ So this can work for block. But maybe cull: has different philosophy Uko > > The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. > > Doru > > > On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. > > In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: donât care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. > > Uko > > On 19 Jun 2014, at 14:08, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > > > On 19 Jun 2014, at 1:42 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > >> Hi, > >> > >> maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. > >> > >> I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. > >> > >> Uko > >> > > > > #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. > > > > Symbol has no #value:value: message, hence it should have no #cull:cull: either. > > > > You could argue it should implement both, with value:value: polymorphic to the block > > [:a :b | a perform: theSymbol with: b ]. > > > > but cull:cull: would then mean equivalence to: > > for #+ [:a :b | a + b] > > for #squared [:a | a self] > > > > And I donât see how thatâd be intuitive/useful enough to warrant inclusion > > > > Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . > > aCollection sort: #> / aCollection inject: 0 into: #+ > > which, while might be nice, both have no use for cull:cull: in the same manner: > > aCollection inject: 0 into: #squared -> [:sub :next | sub squared] ??? > > > > The whole "who is the receiver, whatâs going onÂ»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel itâs better to write out the block explicitly. > > > > Cheers, > > Henry > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

June 19, 2014

Re: [Pharo-dev] Azure Storage Library

by Sven Van Caekenberghe

On 19 Jun 2014, at 15:52, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > > > > > You might want to have a look at the code in Zinc-AWS (group AWS in ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and ZnAWSS3RequestSignatureTool - it is using similar request signing but does HMAC-SHA1. > > > > Thanks! I wasn't aware of the existence of ZnAWS. > > Actually, i'm currently using the HMAC-SHA256 implementation of the CloudFork. > > Is that an all Smalltalk implementation ? > Because it would be really good to have SHA256 in the image. > > Yes it is. The class comment says: > > " > http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.… This class represnets the implementation of CFSHA256 as describied above. > Please direct questions or comments about this implementation to Ron Teitelbaum: Ron(a)USMedRec.com > This code was extensively coppied from SHA1 by Luciano Notarfrancesco lnotarfrancesco(a)yahoo.com > " > > It seems to work for AWS, I wonder what I'm doing wrong here... You have to be 100% sure that the SHA256, HMAC-SHA256 code works (as opposed to the SHA1, HMAC-SHA1 code) then you absolutely need examples: a known canonical string and keys with a Base64 signature output. Start by making sure you can replicate this in your reference implementation (Ruby, Java, C#) and then start to go to Pharo. Look *very* carefully at each element of the canonical string, one letter difference, one header, punctuation, whitespace, case, date or time format difference will break the whole thing - that is the point of being a signature.

June 19, 2014

[ANN] LaTeX to Pillar converter

by Damien Cassou

I'm happy to announce that I wrote a LaTeX to Pillar converter. This converter should not be considered perfect and proof reading is required. Still, the converter could automatically convert from: https://github.com/SquareBracketAssociates/PharoByExample-english/blob/mast… to: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/maste… This Pillar file is then exported to either html: https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/lastSucces… or pdf: https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/lastSucces… -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 19, 2014

Re: [Pharo-dev] Azure Storage Library

by FranÃ§ois Stephany

> > > > You might want to have a look at the code in Zinc-AWS (group AWS in > ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and > ZnAWSS3RequestSignatureTool - it is using similar request signing but does > HMAC-SHA1. > > > > Thanks! I wasn't aware of the existence of ZnAWS. > > Actually, i'm currently using the HMAC-SHA256 implementation of the > CloudFork. > > Is that an all Smalltalk implementation ? > Because it would be really good to have SHA256 in the image. > Yes it is. The class comment says: " http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.… This class represnets the implementation of CFSHA256 as describied above. Please direct questions or comments about this implementation to Ron Teitelbaum: Ron(a)USMedRec.com This code was extensively coppied from SHA1 by Luciano Notarfrancesco lnotarfrancesco(a)yahoo.com " It seems to work for AWS, I wonder what I'm doing wrong here...

June 19, 2014

Re: [Pharo-dev] Improving Pharo By Example

by Damien Cassou

On Thu, Jun 19, 2014 at 3:39 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > ok I leave it to your capable hands and I will try to position images at > the start of the page , though that is easier said than done :D > no! Don't do anything like that. LaTeX is capable of doing it by itself. You don't know where the page boundaries will be so it is hopeless for you :-). What you must ensure though, is that all figures are properly referenced in the text. This is a good example: ... bla... bla... see Figure *fig:myfig*. This is a bad example: ... bla... bla... see figure below: This is bad because you can't be sure the figure will be below (it can also be above, LaTeX decides). > In any case chapters need proof reading so what I commit should never > consider "the final version". But I always try to produce as much quality > as I can. > No problem. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 19, 2014

Re: [Pharo-dev] Implementing cull:cull: in symbol

by Tudor Girba

In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > The thing is that cull:cull: can be used on block with 1 parameter. If you > consider symbol as a block with one parameter then it will work in the same > style. > > In other words: methods that use value:value: want to ensure that they are > working with 2 param block. Methods that use cull:cull: donât care what is > there, but allow you to customise the result with up to 2 parameters. With > symbol you can customise it with 1 parameter. > > Uko > > On 19 Jun 2014, at 14:08, Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > > > On 19 Jun 2014, at 1:42 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > >> Hi, > >> > >> maybe we should implement #cull:cull: in symbol so that it will call > #cull:? Because this looks correct, if block has 1 parameter, then > #cull:cull: boils down to #value:, but when we have a symbol instead, we > have an exception. > >> > >> I can open an issue and implement that stuff, but I want a feedback > from the conceptual point of view. > >> > >> Uko > >> > > > > #cull: is supposed to be the equivalent to the #value: protocol, where > the parameter is optional. > > > > Symbol has no #value:value: message, hence it should have no #cull:cull: > either. > > > > You could argue it should implement both, with value:value: polymorphic > to the block > > [:a :b | a perform: theSymbol with: b ]. > > > > but cull:cull: would then mean equivalence to: > > for #+ [:a :b | a + b] > > for #squared [:a | a self] > > > > And I donât see how thatâd be intuitive/useful enough to warrant > inclusion > > > > Considering the sole reason cull: on Symbol exists, is to allow select: > etc. to be written using cull so the block arg is optional, but still do > aCollection collect: #mySymbol, the closest equivalent would be . > > aCollection sort: #> / aCollection inject: 0 into: #+ > > which, while might be nice, both have no use for cull:cull: in the same > manner: > > aCollection inject: 0 into: #squared -> [:sub :next | sub squared] ??? > > > > The whole "who is the receiver, whatâs going onÂ»-factor of cull:cull: on > symbol is non-intuitive enough that at least I feel itâs better to write > out the block explicitly. > > > > Cheers, > > Henry > > > -- www.tudorgirba.com "Every thing has its own flow"

June 19, 2014

Re: [Pharo-dev] Improving Pharo By Example

by kilon alios

ok I leave it to your capable hands and I will try to position images at the start of the page , though that is easier said than done :D In any case chapters need proof reading so what I commit should never consider "the final version". But I always try to produce as much quality as I can. On Thu, Jun 19, 2014 at 12:18 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Thu, Jun 19, 2014 at 10:24 AM, kilon alios <kilon.alios(a)gmail.com> > wrote: > > So basically the image appears inside the code block even though the > image > > and the code block are a few paragraphs apart !!! > > > oh, this! Don't worry about that, LaTeX is doing its job its own way > :-). LaTeX try to put the figures at the top of the pages when > possible. > > Best > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

June 19, 2014

Re: [Pharo-dev] Azure Storage Library

by Sven Van Caekenberghe

On 19 Jun 2014, at 14:59, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > Hello Sven, > > > You might want to have a look at the code in Zinc-AWS (group AWS in ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and ZnAWSS3RequestSignatureTool - it is using similar request signing but does HMAC-SHA1. > > Thanks! I wasn't aware of the existence of ZnAWS. > Actually, i'm currently using the HMAC-SHA256 implementation of the CloudFork. Is that an all Smalltalk implementation ? Because it would be really good to have SHA256 in the image. > From a quick glance at the documentation, it seems you have to use Character lf (\r) else you'll get the wrong result. > > I'm using withUnixLineEndings to ensure the Character lf line ending. You meant \n instead of \r, right? Yes, of course, sorry. > Have you tried signing the examples (canonical strings) in the documentation and comparing with their result ? > > The problem is that they don't tell with which key they've signed the string. It makes it quite hard to decompose the problem and see where something breaks. How crazy is that ?? (I am trying to be polite here ;-) > The tests in the Ruby SDK are not really useful neither. I'll the other SDKs, maybe the tests are more revealing. Good luck. > If you really can't make it work, we can discuss further. > > I'll try a bit more and come back if needed! > > Thanks !

June 19, 2014

Re: [Pharo-dev] Azure Storage Library

by FranÃ§ois Stephany

Hello Sven, > You might want to have a look at the code in Zinc-AWS (group AWS in > ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and > ZnAWSS3RequestSignatureTool - it is using similar request signing but does > HMAC-SHA1. > Thanks! I wasn't aware of the existence of ZnAWS. Actually, i'm currently using the HMAC-SHA256 implementation of the CloudFork. > > From a quick glance at the documentation, it seems you have to use > Character lf (\r) else you'll get the wrong result. > I'm using withUnixLineEndings to ensure the Character lf line ending. You meant \n instead of \r, right? > Have you tried signing the examples (canonical strings) in the > documentation and comparing with their result ? > The problem is that they don't tell with which key they've signed the string. It makes it quite hard to decompose the problem and see where something breaks. The tests in the Ruby SDK are not really useful neither. I'll the other SDKs, maybe the tests are more revealing. > If you really can't make it work, we can discuss further. > I'll try a bit more and come back if needed! Thanks !

June 19, 2014