November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Tuning Opal Optimizations

by Igor Stasenko

On 21 November 2013 19:59, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > I fail to see what atomic means in this context, it's too broad idea. > To me atomic would be: compile all in a certain sequence, then install all > at once atomically. > And in this case, there is still a problem, because it would resolve > installation order, not compilation order... > > The idea of compiling class side first sounds good to me. > It's not atomic, but might just work. > > right, i also don't see how atomic installation helps in that regard. besides that such mechanism implies that it is not atomic, because first you have to compile and install #compilerClass method, and only then compile and install rest. because if it will be done in one atomic step, it either won't work or work incorrectly. > > 2013/11/21 Marcus Denker <marcus.denker(a)inria.fr> > >> >> On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> >> On 21 November 2013 12:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> > >>> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> >>> >>> >>> Yes, you can do it per class-hierarchyâ¦ you can implement on the >>> class side a method to parametrize the compiler: >>> >>> >>> >>> compiler >>> >>> ^super compiler options: #(- optionInlineTimesRepeat) >>> >> >>> >> Thanks, Marcus, that works just great. >>> > >>> > Marcus, >>> > >>> > Are we sure this option mechanism works when loading code through >>> Monticello ? >>> > >>> >>> Noâ¦ we should make sure that MC loads the method first. I think it does >>> that for #compilerClass >>> already (but not sure). >>> >>> >> which is still doesn't eliminates problem completely, because nothing >> prevents me from having: >> >> compilerClass >> ^ self otherMethod >> >> and now in order to work, MC have to know somehow that #otherMethod >> should also be loaded first. >> But i think some prioritization guarantees would be really useful. >> At least i think we can easily prioritize class-side compilation over >> instance side. >> Like that, when you compiling any of instance-side method, you know that >> class side is already there (and can be used >> as such in different kinds of hooks). >> >> >> >> >> yes, we need atomic code loading. >> >> Marcus >> > > -- Best regards, Igor Stasenko.

Nov. 22, 2013

Re: [Pharo-dev] NativeBoost: Documentation Suggestion and Question

by Igor Stasenko

On 21 November 2013 19:10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > mm.. well, i prefer that fairly common would be to pass meaningful data > back and forth rather than > > dummy values. > I don't understand... when I say "fairly common", I mean that in the C > world, it seems common to use null-passing for optional arguments. I'm not > saying that it's a good idea, but we don't have control over that, so... > > if it would be just C world :) Another reason for not making this default, because checking for nil is one extra check for every piece of generated code which expects pointer, and i hope you agree that while null-value is fairly common, non-null is much more common. > > For that best solution, IMO, would be to use 2 methods which call same > function, > > but one uses 'nil' in function signature (and therefore method doesn't > takes extra argument), > > while other takes extra argument but doesn't accepts nils, for sure. > Yuck ;) but this is quite common in smalltalk isn't? Look at Canvas - good example of overusing it i.e.: drawThis: withThis: andThat: drawThis: withThis: andThat: andAlsoThis: drawThis: withThis: andThat: andAlsoThis: andAlsoThat: :) yes, sometimes it looks like unnecessary protocol bloating, but i think for our case it is well justified. > Cheers, > Sean > > ------------------------------ > View this message in context: Re: NativeBoost: Documentation Suggestion > and Question<http://forum.world.st/NativeBoost-Documentation-Suggestion-and-Question-tp4…> > > Sent from the Pharo Smalltalk Developers mailing list archive<http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>at Nabble.com. > -- Best regards, Igor Stasenko.

Nov. 21, 2013

Re: [Pharo-dev] How to encrypt a password?

by Sebastian Sastre

+1 you should definitively NOT encrypt Cupid Media hacked, 42 million passwords was stolen: http://www.facepunch.com/showthread.php?t=1327069 You're Probably Storing Passwords Incorrectly: http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-i… And now you mentioned it, Monticello actually sucks on this one On Nov 21, 2013, at 7:06 PM, Davide Varvello <varvello(a)yahoo.com> wrote: > Hi Mariano, > > Hash functions are one way > (http://en.wikipedia.org/wiki/Cryptographic_hash_function) that's because > usually you don't want someone can decrypt password. > > Cheers > Davide > > > Mariano Martinez Peck wrote >> Hi Paul, and just to be sure I understand...none of them could work as a >> two-way encryption, right? >> The only one is your Pharo's version of Blowfish but that only works with >> 8 >> chars long. Is it like this? Or is there any other two-way encryption? >> >> Thanks! > > > > > > -- > View this message in context: http://forum.world.st/How-to-encrypt-a-password-tp3933585p4724097.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 21, 2013

Re: [Pharo-dev] How to encrypt a password?

by Paul DeBruicker

Davide Varvello wrote > Paul, > > I've already tried to load PasswordHashingFFI-PaulDeBruicker.16.mcz, but a > warning shows: > > This package depends on the following classes: > ExternalStructure > You must resolve these dependencies before you will be able to load these > definitions: > BCryptLinuxFFI > bcrypt: > bcrypt:with: > Have you loaded FFI into your image prior to loading the PasswordHashinFFI package? I've only used/tested these things on Pharo 1.1 - 2 and Squeak 4.3 & 4.4. What platform are you using? -- View this message in context: http://forum.world.st/How-to-encrypt-a-password-tp3933585p4724123.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 21, 2013

Re: [Pharo-dev] How to encrypt a password?

by Davide Varvello

Hi Mariano, Hash functions are one way (http://en.wikipedia.org/wiki/Cryptographic_hash_function) that's because usually you don't want someone can decrypt password. Cheers Davide Mariano Martinez Peck wrote > Hi Paul, and just to be sure I understand...none of them could work as a > two-way encryption, right? > The only one is your Pharo's version of Blowfish but that only works with > 8 > chars long. Is it like this? Or is there any other two-way encryption? > > Thanks! -- View this message in context: http://forum.world.st/How-to-encrypt-a-password-tp3933585p4724097.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 21, 2013

Re: [Pharo-dev] How to encrypt a password?

by Davide Varvello

Paul, I've already tried to load PasswordHashingFFI-PaulDeBruicker.16.mcz, but a warning shows: This package depends on the following classes: ExternalStructure You must resolve these dependencies before you will be able to load these definitions: BCryptLinuxFFI bcrypt: bcrypt:with: bcrypt:with:for: bcrypt:withSalt: checkPassword:against: defaultRounds ffiCrypt:with: generateBCryptIterations: generateBCryptSalt: generateRandomSalt iterationString: randomBCryptSaltData saltDataLength saltOutputLength CryptLinuxFFI checkPassword:against: des: des:with: ffiCrypt:with: md5: md5:with: prepareSalt: randomSalt randomSalt: saltDataLength sha256: sha256:with: sha512: sha512:with: Select Proceed to continue, or close this window to cancel the operation. Cheers Davide Paul DeBruicker wrote > Hi Davide, > > > You need to be on Linux and > > On pharo or squeak > - have a 32bit version of libxcrypt installed. > - use this mcz > > http://www.squeaksource.com/Cryptography/PasswordHashingFFI-PaulDeBruicker.… > or > > http://www.smalltalkhub.com/mc/Cryptography/Cryptography/main/PasswordHashi… > (they're the same file) > > On GemStone > - have a 64bit version of libxcrypt installed > - use this mcz > http://seaside.gemtalksystems.com/ss/Cryptography/PasswordHashingFFI-PaulDe… > > > The Blowfish stuff is an implementation of the cipher > (https://en.wikipedia.org/wiki/Blowfish_%28cipher%29) BCrypt uses > blowfish as its encryption mechanisim, calling it tens to hundreds of > thousands of times. > > > The PasswordHashingFFI package also includes support for accessing the > crypt(3) library so you can use SHA512 password hashing too if you like > (or other mechanisms it supports like DES, MD5, etc) > > > Hope this helps > > Paul -- View this message in context: http://forum.world.st/How-to-encrypt-a-password-tp3933585p4724096.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 21, 2013

Re: [Pharo-dev] petit parser longest match

by Chris Cunningham

I have a version I'm happier with, but it includes a fair amount of invasive changes. Latest .mcz in http://www.smalltalkhub.com/#!/~cbc/PetitParser It does change PPChoiceParser and has a significant change to PPFailure as well (from a previous enhancement). -cbc On Thu, Nov 21, 2013 at 8:10 AM, Chris Cunningham <cunningham.cb(a)gmail.com>wrote: > There are several things wrong with it, actually. > > First, in my example, I never did actually return the longest error - I > just set the location to the longest error location. Not right at all. > > Next, setting the stream to the position of the error on the choice is not > a good idea. The problem is when you have more than 1 choice depth. So, > the first choice goes down path 1, which calls another choice (eventually), > which fails and resets the location to some point further on in the stream. > The the rollback to the first choice seems to get fouled up and doesn't > work quite right. Probably. In any case, playing with how it is storing > and returning, I am getting wildly different points of where the track > fails. > > Finally, the array at each choice doesn't necessarily pick the furthest > failure. If you consider a 4 choice depth parser (which is roughly what > I'm working with - parsing Java source code), the 4th choice will fail on a > couple of paths, and then eventually work on one. This might then return > back to the 3rd choice successfully (so no error, so no returned error from > that choice) and then later fails. That particular path might be much > shorter (that it made it through) than the one that failed earlier (maybe a > much more complex but also more consuming path, for example). > > The question is what exactly are you (we) looking for. > * I think we want to know what was the parsing path the best describes the > source file we are parsing, and where is it failing to parse. > * I would also like to know what the path was that arrived at that point > (the context) so that I can decide how to either fix the parser (if it is > wrong) or fix the source. > > So, I'm still looking for a better answer than the two I tried to provide > earlier. > > -cbc > > On Wed, Nov 20, 2013 at 5:03 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I'm not sure what you are trying to improve. It works quite well :) >> >> Norbert >> >> Am 20.11.2013 um 22:59 schrieb Chris Cunningham <cunningham.cb(a)gmail.com >> >: >> >> ehh, ignore this for now. Neither is working well enough. If I get >> something working well, I'll post back. >> >> >> On Wed, Nov 20, 2013 at 1:45 PM, Chris Cunningham < >> cunningham.cb(a)gmail.com> wrote: >> >>> Actually, do this [the #( 0 nil ) meant it was shared with ALL choice >>> parsers forever - not a good choice]. >>> >>> parseOn: aStream >>> "This is optimized code that avoids unnecessary block activations, do >>> not change. When all choices fail, the last failure is answered." >>> >>> | element longest | >>> longest := Array with: 0 with: nil. >>> 1 to: parsers size do: [ :index | >>> element := (parsers at: index) >>> parseOn: aStream. >>> element isPetitFailure >>> ifTrue: [ aStream position > longest first ifTrue: [ longest at: 1 >>> put: aStream position; at: 2 put: element ] ] >>> ifFalse: [ ^ element ] ]. >>> aStream position: longest first. >>> ^ element >>> >>> >>> On Wed, Nov 20, 2013 at 1:35 PM, Chris Cunningham < >>> cunningham.cb(a)gmail.com> wrote: >>> >>>> Ho about this (replacement for yours, or just replace in PPChoiceParser >>>> - but it will result in different behavior for that method outside of your >>>> particular parser, so beware): >>>> >>>> parseOn: aStream >>>> "This is optimized code that avoids unnecessary block activations, do >>>> not change. When all choices fail, the last failure is answered." >>>> >>>> | element longest | >>>> longest := #( 0 nil ). >>>> 1 to: parsers size do: [ :index | >>>> element := (parsers at: index) >>>> parseOn: aStream. >>>> element isPetitFailure >>>> ifTrue: [ aStream position > longest first ifTrue: [ longest at: 1 >>>> put: aStream position; at: 2 put: element ] ] >>>> ifFalse: [ ^ element ] ]. >>>> aStream position: longest first. >>>> ^ element >>>> >>>> I had a need for it in the past (and, just now, in fact - so minimally >>>> tested just now). >>>> >>>> -cbc >>>> >>>> >>>> On Wed, Nov 20, 2013 at 2:15 AM, Norbert Hartl <norbert(a)hartl.name>wrote: >>>> >>>>> I talked to Lukas two years ago about parsing the longest match [1]. >>>>> He committed it to PetitBeta back then. Now I need it and I had a look at >>>>> the current parsers but didnât find one that can do the same. Is there a >>>>> parser that can do longest match? >>>>> >>>>> If not I would propose adding that to the default petit parser >>>>> package. Lukasâ proposal back then was >>>>> >>>>> LongestChoiceParser>>parseOn: aStream >>>>> | start element longestEnd longestElement | >>>>> start := aStream position. >>>>> 1 to: parsers size do: [ :index | >>>>> element := (parsers at: index) >>>>> parseOn: aStream. >>>>> (longestEnd isNil or: [ longestEnd < aStream position ]) ifTrue: [ >>>>> longestEnd := aStream position. >>>>> longestElement := element ]. >>>>> aStream position: start ]. >>>>> aStream position: longestEnd. >>>>> ^ longestElement >>>>> >>>>> >>>>> Norbert >>>>> >>>>> [1] http://www.iam.unibe.ch/pipermail/moose-dev/2011-July/009365.html >>>>> >>>> >>>> >>> >> >

Nov. 21, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Nicolas Cellier

Of course, if someone has stupid idea to define Object>>compiler, then it's not on class side, but should be compiled first :( 2013/11/21 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > I fail to see what atomic means in this context, it's too broad idea. > To me atomic would be: compile all in a certain sequence, then install all > at once atomically. > And in this case, there is still a problem, because it would resolve > installation order, not compilation order... > > The idea of compiling class side first sounds good to me. > It's not atomic, but might just work. > > > 2013/11/21 Marcus Denker <marcus.denker(a)inria.fr> > >> >> On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> >> On 21 November 2013 12:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> > >>> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> >>> >>> >>> Yes, you can do it per class-hierarchyâ¦ you can implement on the >>> class side a method to parametrize the compiler: >>> >>> >>> >>> compiler >>> >>> ^super compiler options: #(- optionInlineTimesRepeat) >>> >> >>> >> Thanks, Marcus, that works just great. >>> > >>> > Marcus, >>> > >>> > Are we sure this option mechanism works when loading code through >>> Monticello ? >>> > >>> >>> Noâ¦ we should make sure that MC loads the method first. I think it does >>> that for #compilerClass >>> already (but not sure). >>> >>> >> which is still doesn't eliminates problem completely, because nothing >> prevents me from having: >> >> compilerClass >> ^ self otherMethod >> >> and now in order to work, MC have to know somehow that #otherMethod >> should also be loaded first. >> But i think some prioritization guarantees would be really useful. >> At least i think we can easily prioritize class-side compilation over >> instance side. >> Like that, when you compiling any of instance-side method, you know that >> class side is already there (and can be used >> as such in different kinds of hooks). >> >> >> >> >> yes, we need atomic code loading. >> >> Marcus >> > >

Nov. 21, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Nicolas Cellier

I fail to see what atomic means in this context, it's too broad idea. To me atomic would be: compile all in a certain sequence, then install all at once atomically. And in this case, there is still a problem, because it would resolve installation order, not compilation order... The idea of compiling class side first sounds good to me. It's not atomic, but might just work. 2013/11/21 Marcus Denker <marcus.denker(a)inria.fr> > > On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > On 21 November 2013 12:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> > >> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> >>> >> >>> Yes, you can do it per class-hierarchyâ¦ you can implement on the >> class side a method to parametrize the compiler: >> >>> >> >>> compiler >> >>> ^super compiler options: #(- optionInlineTimesRepeat) >> >> >> >> Thanks, Marcus, that works just great. >> > >> > Marcus, >> > >> > Are we sure this option mechanism works when loading code through >> Monticello ? >> > >> >> Noâ¦ we should make sure that MC loads the method first. I think it does >> that for #compilerClass >> already (but not sure). >> >> > which is still doesn't eliminates problem completely, because nothing > prevents me from having: > > compilerClass > ^ self otherMethod > > and now in order to work, MC have to know somehow that #otherMethod > should also be loaded first. > But i think some prioritization guarantees would be really useful. > At least i think we can easily prioritize class-side compilation over > instance side. > Like that, when you compiling any of instance-side method, you know that > class side is already there (and can be used > as such in different kinds of hooks). > > > > > yes, we need atomic code loading. > > Marcus >

Nov. 21, 2013

Re: [Pharo-dev] How to encrypt a password?

by Paul DeBruicker

Mariano Martinez Peck wrote > Hi Paul, and just to be sure I understand...none of them could work as a > two-way encryption, right? > The only one is your Pharo's version of Blowfish but that only works with > 8 > chars long. Is it like this? Or is there any other two-way encryption? > > Thanks! > > -- > Mariano > http://marianopeck.wordpress.com Yes that's right. The PasswordHashingFFI stuff is all one way encryption. Blowfish is two way, and the current implementation only works for 8 byte chunks. I stopped working on it when the Smalltalk bcrypt implementation I wanted proved to be 5000x times slower than the FFI version. Someone needs to add the CBC part to Blowfish to encrypt longer strings. I do not know of another in image two way encryption scheme, but there may be something in the Cryptography repo. I'm not sure. -- View this message in context: http://forum.world.st/How-to-encrypt-a-password-tp3933585p4724078.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 21, 2013