December 2016 - Pharo-users

Re: [Pharo-users] FFI on MacOS 10.12 using Pharo 5

by Pierce Ng

On Tue, Dec 20, 2016 at 05:23:37PM -0800, Jay Hardesty wrote: > realizing I had a 64 vs 32 bit problem.. works now. I built a 32/64-bit combo SQLite dylib and it didn't work with Pharo on El Capitan. A pure 32-bit dylib worked. Pierce

Dec. 21, 2016

Re: [Pharo-users] [Moose-dev] Design Challenge: metrics missing value...

by Tudor Girba

Hi Alex, Following the design proposed by Stef, in your case you would use a different collection. Cheers, Doru > On Dec 21, 2016, at 8:13 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi Stef, > > You are raising an interesting point to discuss. This MissingValue is indeed better than having -1 > Something to keep in mind: it may be that one would like to focus on the missing value and not really the value. > > Consider: > >> testCollect >> >> | uarray collected | >> uarray := UniformOrderedCollection new. >> uarray add: 10. >> uarray add: 20. >> uarray add: (MissingValue discarding). >> collected := uarray collect: [ :each | each ]. >> self assert: collected size equals: 2. > > It could well be that I would like to be able to query over the MissingValue. > Can something like possible: uarray collect: #isMissing > ? > > Cheers, > Alexandre > > >> On Dec 20, 2016, at 10:15 PM, stepharong <stepharong(a)free.fr> wrote: >> >> Hi dear great OO designers >> >> Here is a little challenges for your brainy souls :) >> >> In Moose when we compute metrics it may happen than a tool (often external to pharo) does not compute a metrics >> and when we request it in moose we check and often we return a not so good -1. >> >> I'm trying to brainstorm on a solution >> >> - first may be the simplest way is to not invoke a metrics when it is not computed. But it means that we should know it and that we should have a registration mechanism. After all this is probably the best solution. >> >> - Second we were thinking to use exception but when we have multiple entities missing one metrics.... I have serious doubts. >> >> - Second I was thinking about having the following behavior >> >> testCollect >> >> | uarray collected | >> uarray := UniformOrderedCollection new. >> uarray add: 10. >> uarray add: 20. >> uarray add: (MissingValue discarding). >> collected := uarray collect: [ :each | each ]. >> self assert: collected size equals: 2. >> >> testDo >> >> | res uarray | >> uarray := UniformOrderedCollection new. >> uarray add: 10. >> uarray add: 20. >> uarray add: (MissingValue discarding). >> uarray add: 40. >> res := 0. >> uarray do: [ :each | res := res + each ]. >> self assert: res equals: 70. >> >> >> testCollectDefaulting >> >> | uarray collected | >> uarray := UniformOrderedCollection new. >> uarray add: 10. >> uarray add: 20. >> uarray add: (MissingValue default: 33). >> collected := uarray collect: [ :each | each ]. >> self assert: collected size equals: 3. >> self assert: collected third equals: 33 >> >> >> I basically started to implement >> >> >> do: aBlock >> "Refer to the comment in Collection|do:." >> 1 to: self size do: >> [:index | (self at: index) toDo: aBlock on: self] >> >> >> >> collect: aBlock >> "Evaluate aBlock with each of the receiver's elements as the argument. >> Collect the resulting values into a collection like the receiver. Answer >> the new collection." >> >> | newCollection | >> newCollection := self species new. >> self >> do: [ :each | each toCollect: aBlock on: newCollection ]. >> ^ newCollection >> >> >> and >> >> DiscardingValue >> toCollect: aBlock on: aCollection >> "discard computation" >> ^ self >> >> >> Object >> toCollect: aBlock on: aCollection >> >> ^ aCollection add: (aBlock value: self) >> >> >> So I imagine that you see the design and I wanted to get your point of view. >> >> -- >> Using Opera a kind of bad mail client but far better than thunderbird >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Dec. 21, 2016

Re: [Pharo-users] [Moose-dev] Design Challenge: metrics missing value...

by Alexandre Bergel

Hi Stef, You are raising an interesting point to discuss. This MissingValue is indeed better than having -1 Something to keep in mind: it may be that one would like to focus on the missing value and not really the value. Consider: > testCollect > > | uarray collected | > uarray := UniformOrderedCollection new. > uarray add: 10. > uarray add: 20. > uarray add: (MissingValue discarding). > collected := uarray collect: [ :each | each ]. > self assert: collected size equals: 2. It could well be that I would like to be able to query over the MissingValue. Can something like possible: uarray collect: #isMissing ? Cheers, Alexandre > On Dec 20, 2016, at 10:15 PM, stepharong <stepharong(a)free.fr> wrote: > > Hi dear great OO designers > > Here is a little challenges for your brainy souls :) > > In Moose when we compute metrics it may happen than a tool (often external to pharo) does not compute a metrics > and when we request it in moose we check and often we return a not so good -1. > > I'm trying to brainstorm on a solution > > - first may be the simplest way is to not invoke a metrics when it is not computed. But it means that we should know it and that we should have a registration mechanism. After all this is probably the best solution. > > - Second we were thinking to use exception but when we have multiple entities missing one metrics.... I have serious doubts. > > - Second I was thinking about having the following behavior > > testCollect > > | uarray collected | > uarray := UniformOrderedCollection new. > uarray add: 10. > uarray add: 20. > uarray add: (MissingValue discarding). > collected := uarray collect: [ :each | each ]. > self assert: collected size equals: 2. > > testDo > > | res uarray | > uarray := UniformOrderedCollection new. > uarray add: 10. > uarray add: 20. > uarray add: (MissingValue discarding). > uarray add: 40. > res := 0. > uarray do: [ :each | res := res + each ]. > self assert: res equals: 70. > > > testCollectDefaulting > > | uarray collected | > uarray := UniformOrderedCollection new. > uarray add: 10. > uarray add: 20. > uarray add: (MissingValue default: 33). > collected := uarray collect: [ :each | each ]. > self assert: collected size equals: 3. > self assert: collected third equals: 33 > > > I basically started to implement > > > do: aBlock > "Refer to the comment in Collection|do:." > 1 to: self size do: > [:index | (self at: index) toDo: aBlock on: self] > > > > collect: aBlock > "Evaluate aBlock with each of the receiver's elements as the argument. > Collect the resulting values into a collection like the receiver. Answer > the new collection." > > | newCollection | > newCollection := self species new. > self > do: [ :each | each toCollect: aBlock on: newCollection ]. > ^ newCollection > > > and > > DiscardingValue >> toCollect: aBlock on: aCollection > "discard computation" > ^ self > > > Object >> toCollect: aBlock on: aCollection > > ^ aCollection add: (aBlock value: self) > > > So I imagine that you see the design and I wanted to get your point of view. > > -- > Using Opera a kind of bad mail client but far better than thunderbird > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 21, 2016

Re: [Pharo-users] [Moose-dev] Design Challenge: metrics missing value...

by Tudor Girba

Hi, MissingValue (or NoValue) is definitely the way to go. The UniformOrderedCollection is an interesting idea, too. We had a NoValue like solution a long time ago but we discarded because we missed the idea around collections. It would be really cool to have this working. Cheers, Doru > On Dec 20, 2016, at 10:15 PM, stepharong <stepharong(a)free.fr> wrote: > > Hi dear great OO designers > > Here is a little challenges for your brainy souls :) > > In Moose when we compute metrics it may happen than a tool (often external to pharo) does not compute a metrics > and when we request it in moose we check and often we return a not so good -1. > > I'm trying to brainstorm on a solution > > - first may be the simplest way is to not invoke a metrics when it is not computed. But it means that we should know it and that we should have a registration mechanism. After all this is probably the best solution. > > - Second we were thinking to use exception but when we have multiple entities missing one metrics.... I have serious doubts. > > - Second I was thinking about having the following behavior > > testCollect > > | uarray collected | > uarray := UniformOrderedCollection new. > uarray add: 10. > uarray add: 20. > uarray add: (MissingValue discarding). > collected := uarray collect: [ :each | each ]. > self assert: collected size equals: 2. > > testDo > > | res uarray | > uarray := UniformOrderedCollection new. > uarray add: 10. > uarray add: 20. > uarray add: (MissingValue discarding). > uarray add: 40. > res := 0. > uarray do: [ :each | res := res + each ]. > self assert: res equals: 70. > > > testCollectDefaulting > > | uarray collected | > uarray := UniformOrderedCollection new. > uarray add: 10. > uarray add: 20. > uarray add: (MissingValue default: 33). > collected := uarray collect: [ :each | each ]. > self assert: collected size equals: 3. > self assert: collected third equals: 33 > > > I basically started to implement > > > do: aBlock > "Refer to the comment in Collection|do:." > 1 to: self size do: > [:index | (self at: index) toDo: aBlock on: self] > > > > collect: aBlock > "Evaluate aBlock with each of the receiver's elements as the argument. > Collect the resulting values into a collection like the receiver. Answer > the new collection." > > | newCollection | > newCollection := self species new. > self > do: [ :each | each toCollect: aBlock on: newCollection ]. > ^ newCollection > > > and > > DiscardingValue >> toCollect: aBlock on: aCollection > "discard computation" > ^ self > > > Object >> toCollect: aBlock on: aCollection > > ^ aCollection add: (aBlock value: self) > > > So I imagine that you see the design and I wanted to get your point of view. > > -- > Using Opera a kind of bad mail client but far better than thunderbird > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."

Dec. 21, 2016

Re: [Pharo-users] [Moose-dev] Design Challenge: metrics missing value...

by Serge Stinckwich

So basically you are trying to deal with missing values in collections. People working with R or Python data analytics framework made some ways to work with specific data structures called dataframes where you can have some missing values. For example you may have a look here: http://pandas.pydata.org/pandas-docs/stable/missing_data.html On Wed, Dec 21, 2016 at 4:15 AM, stepharong <stepharong(a)free.fr> wrote: > Hi dear great OO designers > > Here is a little challenges for your brainy souls :) > > In Moose when we compute metrics it may happen than a tool (often external > to pharo) does not compute a metrics > and when we request it in moose we check and often we return a not so good > -1. > > I'm trying to brainstorm on a solution > > - first may be the simplest way is to not invoke a metrics when it is not > computed. But it means that we should know it and that we should have a > registration mechanism. After all this is probably the best solution. > > - Second we were thinking to use exception but when we have multiple > entities missing one metrics.... I have serious doubts. > > - Second I was thinking about having the following behavior > > testCollect > > | uarray collected | > uarray := UniformOrderedCollection new. > uarray add: 10. > uarray add: 20. > uarray add: (MissingValue discarding). > collected := uarray collect: [ :each | each ]. > self assert: collected size equals: 2. > > testDo > > | res uarray | > uarray := UniformOrderedCollection new. > uarray add: 10. > uarray add: 20. > uarray add: (MissingValue discarding). > uarray add: 40. > res := 0. > uarray do: [ :each | res := res + each ]. > self assert: res equals: 70. > > > testCollectDefaulting > > | uarray collected | > uarray := UniformOrderedCollection new. > uarray add: 10. > uarray add: 20. > uarray add: (MissingValue default: 33). > collected := uarray collect: [ :each | each ]. > self assert: collected size equals: 3. > self assert: collected third equals: 33 > > > I basically started to implement > > > do: aBlock > "Refer to the comment in Collection|do:." > 1 to: self size do: > [:index | (self at: index) toDo: aBlock on: self] > > > > collect: aBlock > "Evaluate aBlock with each of the receiver's elements as the > argument. > Collect the resulting values into a collection like the receiver. > Answer > the new collection." > > | newCollection | > newCollection := self species new. > self > do: [ :each | each toCollect: aBlock on: newCollection ]. > ^ newCollection > > > and > > DiscardingValue >> toCollect: aBlock on: aCollection > "discard computation" > ^ self > > > Object >> toCollect: aBlock on: aCollection > > ^ aCollection add: (aBlock value: self) > > > So I imagine that you see the design and I wanted to get your point of view. > > -- > Using Opera a kind of bad mail client but far better than thunderbird > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Dec. 21, 2016

Re: [Pharo-users] FFI on MacOS 10.12 using Pharo 5

by Jay Hardesty

Thanks - testing the new dylib (see response to Esteban) with a C app (command line tool) as you suggested saved me from wasting time before realizing I had a 64 vs 32 bit problem.. works now. Cheers, Jay -- View this message in context: http://forum.world.st/FFI-on-MacOS-10-12-using-Pharo-5-tp4927537p4927702.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 21, 2016

Re: [Pharo-users] FFI on MacOS 10.12 using Pharo 5

by Jay Hardesty

Thanks Esteban, was helpful to know I had (almost!) the right syntax.. With that I was able to concentrate on the library loading - apparently using a .dylib rather than .bundle made the difference. It now works - thanks again! Jay -- View this message in context: http://forum.world.st/FFI-on-MacOS-10-12-using-Pharo-5-tp4927537p4927700.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 21, 2016

Re: [Pharo-users] Password storage options

by Jan BlizniÄenko

I'm currently trying it and it seems quite easy to load and use - just working fine. Of couse it seems kinda slow in comparison with native implementations (2000 iterations of SHA256 into 32 byte hash taking almost a second on my quite powerful PC), but that's expected and not that much of a problem. I'm also not capable to tell whether there are not any security flaws, but anything is better than something I would write myself without reading deep enough into the topic. Anyway, I think I will happily keep with it until there is somehow easy to use implementation or FFI for current Pharo for any more current algorithm. Thank you both. Jan Udo Schneider wrote > Hi Jan, > > I extracted a PBKDF2 implementation from some of my code some time ago. > Take a look here: > > http://readthesourceluke.blogspot.de/2014/07/pbkdf2-for-pharo.html > http://www.smalltalkhub.com/#!/~UdoSchneider/PBKDF2 > > CU, > > Udo > > On 19/12/16 18:09, Jan BlizniÄenko wrote: >> Hello >> >> I'm working on Pharo-based webserver and right now I got to the topic of >> storing user passwords. I found SHA256 integrated in Pharo, but hashing >> with >> SHA is far from enough. I also looked around the mailing list history to >> find few posts from 2011 about bcrypt using Linux libraries. I'd like to >> ask >> what is current status - what are my options under following conditions: >> >> I prefer Pharo 5 compatibility. I could downgrade to Pharo 4 or use beta >> Pharo 6, but latest stable relase is preferred. >> >> I require at least bcrypt or PDKBF2, but I much more prefer >> GPU-attack-resistant solutions like scrypt or Argon2. >> >> I require Linux compatibility, but platform independent solution would be >> kinda nice (we could use the same algorithm on our local machines with >> Mac >> and Win for development). >> >> Thank you >> Jan >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Password-storage-options-tp4927471.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> -- View this message in context: http://forum.world.st/Password-storage-options-tp4927480p4927698.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 20, 2016

Re: [Pharo-users] Password storage options

by Udo Schneider

Hi Jan, I extracted a PBKDF2 implementation from some of my code some time ago. Take a look here: http://readthesourceluke.blogspot.de/2014/07/pbkdf2-for-pharo.html http://www.smalltalkhub.com/#!/~UdoSchneider/PBKDF2 CU, Udo On 19/12/16 18:09, Jan BlizniÄenko wrote: > Hello > > I'm working on Pharo-based webserver and right now I got to the topic of > storing user passwords. I found SHA256 integrated in Pharo, but hashing with > SHA is far from enough. I also looked around the mailing list history to > find few posts from 2011 about bcrypt using Linux libraries. I'd like to ask > what is current status - what are my options under following conditions: > > I prefer Pharo 5 compatibility. I could downgrade to Pharo 4 or use beta > Pharo 6, but latest stable relase is preferred. > > I require at least bcrypt or PDKBF2, but I much more prefer > GPU-attack-resistant solutions like scrypt or Argon2. > > I require Linux compatibility, but platform independent solution would be > kinda nice (we could use the same algorithm on our local machines with Mac > and Win for development). > > Thank you > Jan > > > > -- > View this message in context: http://forum.world.st/Password-storage-options-tp4927471.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Dec. 20, 2016

Design Challenge: metrics missing value...

by stepharong

Hi dear great OO designers Here is a little challenges for your brainy souls :) In Moose when we compute metrics it may happen than a tool (often external to pharo) does not compute a metrics and when we request it in moose we check and often we return a not so good -1. I'm trying to brainstorm on a solution - first may be the simplest way is to not invoke a metrics when it is not computed. But it means that we should know it and that we should have a registration mechanism. After all this is probably the best solution. - Second we were thinking to use exception but when we have multiple entities missing one metrics.... I have serious doubts. - Second I was thinking about having the following behavior testCollect | uarray collected | uarray := UniformOrderedCollection new. uarray add: 10. uarray add: 20. uarray add: (MissingValue discarding). collected := uarray collect: [ :each | each ]. self assert: collected size equals: 2. testDo | res uarray | uarray := UniformOrderedCollection new. uarray add: 10. uarray add: 20. uarray add: (MissingValue discarding). uarray add: 40. res := 0. uarray do: [ :each | res := res + each ]. self assert: res equals: 70. testCollectDefaulting | uarray collected | uarray := UniformOrderedCollection new. uarray add: 10. uarray add: 20. uarray add: (MissingValue default: 33). collected := uarray collect: [ :each | each ]. self assert: collected size equals: 3. self assert: collected third equals: 33 I basically started to implement do: aBlock "Refer to the comment in Collection|do:." 1 to: self size do: [:index | (self at: index) toDo: aBlock on: self] collect: aBlock "Evaluate aBlock with each of the receiver's elements as the argument. Collect the resulting values into a collection like the receiver. Answer the new collection." | newCollection | newCollection := self species new. self do: [ :each | each toCollect: aBlock on: newCollection ]. ^ newCollection and DiscardingValue >> toCollect: aBlock on: aCollection "discard computation" ^ self Object >> toCollect: aBlock on: aCollection ^ aCollection add: (aBlock value: self) So I imagine that you see the design and I wanted to get your point of view. -- Using Opera a kind of bad mail client but far better than thunderbird

Dec. 20, 2016