June 2014 - Pharo-dev - lists.pharo.org

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

by Chris Cunningham

A stretch for rational behind cull: We are 'culling' the excess variables passed to the block (roughly equivalent to killing animals when there are too many of them). On Thu, Jun 19, 2014 at 7:31 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > http://www.wordreference.com/es/translation.asp?tranword=cull > > yet, it does not looks like having anything to do with executing a block > with optional parameters :) > > > On 19 Jun 2014, at 11:24, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > 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] vm over android

by Jean Baptiste Arnaud

> Can you share what is the intended use of the android vm that you're building? -_^ ? Run StackVM on an android is not enough from intellectual point of view ? I am not sure to understand the question. Why I do that, "Because I can :-)" I am based on the StackVM unix, my main objective is to change less sources as possible to keep that easy to maintain. I used a fork of PharoVM because the process is simpler for merging and reviewing my changes. And because I using the Pharo-contribution (jenkins) infrastructure to generate VM as I do for RaspberryPi. The first objective is to have something usable on Android, which can be easily update if for whatever reason I decide to stop or if someone want to do it own android App. First step: -Having that running, with graphic based on unix source (with some change but less possible). Next step: - have fun with it and wrap it with a nice android app. - a lot of cool idea that people can do because everything will be public. If it isn't precise enough, be more direct :-). On 18 Jun 2014, at 18:44, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Hi Jean-Baptiste, > > Dmitry wrote some hook to call the Android Virtual keyboard from the > image, and may be some other I forget about. I get the source of CogDroid from him. :-) Most of the java code and the hook that he did is conserved they are extract from the platform android source. And I create a External plugin display for android. > Hilaire > > Le 18/06/2014 14:56, Jean Baptiste Arnaud a Ã©crit : >> >> CogDroid, project is not maintain since 3 or 4 years. >> But still seems work (just have a completely separated source). >> Peoples give me all the key to revive it. >> I take the source of Cogdroid for understand what they do and redo it >> changing less thing possible in unix source. >> > > -- > Dr. Geo http://drgeo.eu > iStoa - https://launchpad.net/istoa > > Best Regards Dr Arnaud jbaptiste.arnaud(a)gmail.com

June 19, 2014

Re: [Pharo-dev] Azure Storage Library

by FranÃ§ois Stephany

Got it. It's super stupid. The key they give to feed the HMAC-SHA256 is actually a base64 string that needs to be decoded. It's not mentionned in the docs and I missed the constructor of the Signer in Ruby: # Public: Initialize the Signer. # # access_key - The access_key encoded in Base64. Defaults to the one # in the global configuration. def initialize(access_key=Azure.config.storage_access_key) @access_key = Base64.strict_decode64(access_key) end Tests are passing now :) Thanks for your patience Sven! On Thu, Jun 19, 2014 at 4:01 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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

Re: [Pharo-dev] Where is the postcard with syntax?

by Dennis Schetinin

Simple ~= Easy. Smalltalk is simple (simpler then most of other PLs), but it's not easy (to understand and master, especially after other PLs). -- Best regards, Dennis Schetinin 2014-06-17 11:59 GMT+04:00 kilon alios <kilon.alios(a)gmail.com>: > personally I don't like this postcard , it looks too much like "snake oil > marketing" to me. > > It creates the illusion that Pharo is much simpler than other programming > languages as a programming language while nothing can be further from the > truth. The idea here is to prove to the viewer that Pharo is based on a > very simple recipe and that is of course true. But if we have to be honest > is should come with a disclaimer for the potential users that Pharo is no > blue pill and there tons of things outside this postcard you need to learn > if you want to create the simplest Pharo application. I will be frank , as > a language I dont find Pharo any simpler than let's say python , which I am > more familiar with. And the fact that there is this simple recipe gave me > zero benefits to me so far. Its a cool trick that may come handy down the > line if I want to shape the language more to my needs, but I dont see doing > this to a day by day basis. > > Now a "living coding postcard" stating the workflow of Pharo and > demonstrating the power of the debugger is much more honest and frankly > better marketing for Pharo. You show something to a person that will > benefit his workflow on a day by day basis. > > > On Tue, Jun 17, 2014 at 10:32 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> Now, who is creative enough to add âdynamic arrayâ (one with curly >> braces) and temporaries in a block to the original thing: >> >> exampleWithNumber: x >> | y | >> true & false not & (nil isNil) ifFalse: [self halt]. >> y := self size + super size. >> #($a #a "a" 1 1.0) >> do: [ :each | >> Transcript show: (each class name); >> show: ' ']. >> ^x < y >> >> >> >> Uko >> >> On 16 Jun 2014, at 15:35, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> >> wrote: >> >> >> I got it from Stef, who always said it came originally from Ralph Johnson. >> >> http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard >> >> Googling around finds various copies of this, but no original source. >> >> Oscar >> >> On 16 Jun 2014, at 10:58 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> I guess itâs here: http://files.pharo.org/media/flyer-cheat-sheet.pdf >> >> I think that it would be interesting to put the syntax on a postcard. It >> can work as a proof of concept, some addition cheat-sheet for newcomers and >> also as some king of souvenir. >> >> Uko >> >> On 16 Jun 2014, at 10:36, stepharo <stepharo(a)free.fr> wrote: >> >> you have the flyer of Damien (no idea where it is) but no real postcard. >> >> Stef >> >> On 16/6/14 09:35, Yuriy Tymchuk wrote: >> >> Hi guys, >> >> we all are talking about the syntax fitting in a postcard, but was there >> any real postcard with Pharo syntax prototype? This would be really >> interesting. >> >> Uko >> >> >> >> >> >> >> >> >> >> >

June 19, 2014

Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo

by Esteban Lorenzano

On 19 Jun 2014, at 11:33, Stephan Eggermont <stephan(a)stack.nl> wrote: > Esteban wrote: >> no idea. >> as I said before, the tiger demo works for me out of the box (10.9). >> now I do not have a 10.7 but since nothing of the build process changed (specially the cairo build), I do not understand what can be going bad > > Does anyone have a 10.7.5 there to see if it is a problem with my machine only? > Or was the build box upgraded? 'newer libc style problem?â it was updated like a lot of time ago (more than 6 months). It shouldnât be a problem if older version workedâ¦ but who knows :S > >> what about an âIT Crowdâ answer: did you try downloading the vm again? :P > > Tried again with the latest 352. Same problem. but then is a problem in the build of cairo libraryâ¦ and yes, probably a problem of SDK versions. I do not have the time to check now (also, Iâm supposed to be on holidaysâ¦ the weirdest holidays everâ¦ but holidays after all :P). I will check it as soon as Iâm close to the infrastructure. Esteban > > Stephan

June 19, 2014

Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo

by Stephan Eggermont

Esteban wrote: >no idea. >as I said before, the tiger demo works for me out of the box (10.9). >now I do not have a 10.7 but since nothing of the build process changed (specially the cairo build), I do not understand what can be going bad Does anyone have a 10.7.5 there to see if it is a problem with my machine only? Or was the build box upgraded? 'newer libc style problem?' >what about an âIT Crowdâ answer: did you try downloading the vm again? :P Tried again with the latest 352. Same problem. Stephan

June 19, 2014

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

by Esteban Lorenzano

http://www.wordreference.com/es/translation.asp?tranword=cull yet, it does not looks like having anything to do with executing a block with optional parameters :) On 19 Jun 2014, at 11:24, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 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 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