October 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Ron Teitelbaum

> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of > Robert Withers > Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] > RandomGenerator class>>unpredictableStringsDo: > > Ron, > > I checked that email and there is no mention of who it was sent to now this > SFLC advisors. Ok that must be the Software Freedom Law Center. I just > reached out to them on this. [Ron Teitelbaum] It was set to Dan Ravicher but not sure if he is still there. http://lists.squeakfoundation.org/pipermail/cryptography/2005-November/0000… > > Thank you, > Robert > > On 10/19/2015 06:25 PM, Ron Teitelbaum wrote: > > Hi Robert, > > > > I went back and reviewed and this is what I sent to BIS. > > > > http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/ > > 000117.html > > > > Not much to it but we got a lot of advice from SFLC first. > > > > >From our research OS projects are allowed to host cryptographic code > > >and make available for anyone to download. BUT that does not exclude > > >users of the code from being restrained from exporting that code to > > >any USA identified restricted entities. For example: > > >http://www.state.gov/j/ct/list/c14151.htm > > > > I would recommend at the very least to register the repo with the BIS for > Pharo, but I would also contact the SFLC to verify nothing has changed. > > > > All the best, > > > > Ron > > > >> -----Original Message----- > >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf > >> Of Robert Withers > >> Sent: Monday, October 19, 2015 5:28 PM > >> To: The general-purpose Squeak developers list; 'Chris Muller' > >> Cc: 'Pharo Development List' > >> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] > >> RandomGenerator class>>unpredictableStringsDo: > >> > >> (resending with Pharo list) > >> > >> Ron, would it be an easy process to add a second URL to the exception > >> paperwork. Pharo does have new ideas about code storage and > >> distribution that we would want to take advantage of. This would help a > lot! > >> > >> Then again, screw their paperwork requirements of us. Put my name as > >> responsible on the Pharo code and I'll take a trip to Cuba, if they > >> need a scape goat for their 20th century thinking. Crypto is already > >> out of the bag and everyone uses it freely. Just do it and ask permission > later. > >> > >> In thinking about consolidating crypto code between squeak and pharo, > >> I would guess there would be a thin capatibility layer for each > >> system, then the Crypto code in the main. My goal is to have > >> compatibility, crypto and plugins on both virtual platforms. > >> > >> Thanks so much ^^ > >> > >> Robert > >> > >> On 10/19/2015 05:17 PM, Ron Teitelbaum wrote: > >>> Hi Chris, > >>> > >>> The exemption is not for the location of the server but the URL > >>> where it is > >> hosted. I'm happy to help in any way I can but I don't have access > >> to the Pharo Repos. I have no issue with having Pharo packages on > >> SqueakSource if that is what everyone agrees too. We have multiple > packages hosted there. > >> It's ok with me if we host some pharo code there too. > >>> All the best, > >>> > >>> Ron > >>> > >>>> -----Original Message----- > >>>> From: Chris Muller [mailto:ma.chris.m@gmail.com] > >>>> Sent: Monday, October 19, 2015 3:59 PM > >>>> To: Ron Teitelbaum > >>>> Cc: Pharo Development List; The general-purpose Squeak developers > >>>> list > >>>> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] > >>>> RandomGenerator class>>unpredictableStringsDo: > >>>> > >>>> Heh, well, since then SqueakSource itself was moved to a different > >>>> server in a different country. I guess there was also a mirror of > >>>> SqueakSource hosted in Chile under a different URL for many years. > >>>> > >>>> I'm doubtful any of it matters, but we wouldn't want anyone to end > >>>> up in Gitmo over it. If you're uncomfortable about hosting a copy > >>>> elsewhere, then please at least namespace-prefix the Pharo-specific > >>>> packages, to at least help keep it from becoming a tangled mess. > >>>> > >>>> On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum > <ron(a)usmedrec.com> > >>>> wrote: > >>>>> Hi All, > >>>>> > >>>>> Unless someone filed the proper paperwork I would suggest NOT > >>>>> moving > >>>> the cryptography code anywhere except for SqueakSource. When we > >>>> started the project we spent time ensuring that we had a proper > >>>> exemption from the U.S. regulations on exporting cryptographic code. > >>>> If someone copied and forked the code that exemption may not still > >>>> apply to that new repository. > >>>>> I'm not personally involved with the code on Pharo, not sure who > >>>>> is doing > >>>> crypto there. > >>>>> All the best, > >>>>> > >>>>> Ron > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On > >>>>>> Behalf Of Chris Muller > >>>>>> Sent: Monday, October 19, 2015 2:47 PM > >>>>>> To: The general-purpose Squeak developers list > >>>>>> Cc: Pharo Development List > >>>>>> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to > >>>>>> Pharo] RandomGenerator class>>unpredictableStringsDo: > >>>>>> > >>>>>> Yes, if a common package for both Squeak and Pharo is possible, > >>>>>> that'd be great. Otherwise, the Squeak and Pharo versions should > >>>>>> reside in separate repositories. Squeak users are still using > >>>>>> squeaksource.com, Pharo moved to smalltalkhub and beyond.. > >>>>>> > >>>>>> On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers > >>>>>> <robert.w.withers(a)gmail.com> wrote: > >>>>>>> hey Ron, > >>>>>>> > >>>>>>> It was actually the Pharo Cryptography team I was thinking of. > >>>>>>> Perhaps we can get the same package to work in both squeak and > >>>>>>> Pharo, with use of installable entropy sources or the like. In > >>>>>>> order to get SqueakElib running in Pharo I need crypto and we > >>>>>>> may as > >>>> well do it right. > >>>>>>> Cheers, > >>>>>>> Robert > >>>>>>> > >>>>>>> > >>>>>>> On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: > >>>>>>>> Hi Robert, > >>>>>>>> > >>>>>>>> You are already on the Cryptograph repo on SqueakSource.com as > >>>>>>>> an > >>>>>> admin. > >>>>>>>> Please feel free to reorg if you like. > >>>>>>>> > >>>>>>>> Let me know if you have trouble resurrecting your account. > >>>>>>>> > >>>>>>>> All the best, > >>>>>>>> > >>>>>>>> Ron > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: squeak-dev-bounces(a)lists.squeakfoundation.org > >>>>>>>>> [mailto:squeak-dev- bounces(a)lists.squeakfoundation.org] On > >>>>>>>>> Behalf Of Robert Withers > >>>>>>>>> Sent: Monday, October 19, 2015 1:53 PM > >>>>>>>>> To: squeak-dev(a)lists.squeakfoundation.org > >>>>>>>>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to > >>>>>>>>> Pharo] RandomGenerator class>>unpredictableStringsDo: > >>>>>>>>> > >>>>>>>>> This is great guys. Is there a way to get this from the image? > >>>>>>>>> Good to get > >>>>>>>> it > >>>>>>>>> with an FFI/OSProcess call or something. > >>>>>>>>> > >>>>>>>>> Thank you, > >>>>>>>>> Robert > >>>>>>>>> > >>>>>>>>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: > >>>>>>>>>> Hi Guys, > >>>>>>>>>> > >>>>>>>>>> How about getting the CPU temperature. I think most CPUs > >>>>>>>>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I > >>>>>>>>>> think it is seven bits. The real range should be less than > >>>>>>>>>> that but it may be enough to help add some entropy. > >>>>>>>>>> > >>>>>>>>>> Lou > >>>>>>>>>> > >>>>>>>>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers > >>>>>>>>>> <robert.w.withers(a)gmail.com> wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi Ron , nice to see you too! It has been a number of years, > >>>>>>>>>>> hasn't > >>>> it? > >>>>>>>>>>> Crypto is timestamped back in 2010, so there is is. I hope > >>>>>>>>>>> these have been kind years to you, as they have for me. > >>>>>>>>>>> > >>>>>>>>>>> I love the idea of optional sources of entropy, depending on > >>>>>>>>>>> the deployed capabilities. So there are our mouse points and > >>>>>>>>>>> such, because they ought to be optional. > >>>>>>>>>>> > >>>>>>>>>>> What are some reliably present sources in the most minimal > >>>>>> situation? > >>>>>>>>>>> If we could define minimal as an image with no image level > >>>>>>>>>>> I/O beyond file I/O, I would think we'd have: Kernel, > >>>>>>>>>>> System, Collections, Compiler and FFI. Some intransitives in > >>>>>>>>>>> that scope for entropy would be > >>>>>>>>> grand. > >>>>>>>>>>> > >>>>>>>>>>> I was thinking to take 5 millisecondClockValues, separated > >>>>>>>>>>> by > >>>>>>>>>>> 4 non-secure random intervals: take the low order byte of > >>>>>>>>>>> the > >>>>>>>>>>> 4 intervals and reverse & concat them, as a entropic source. > >>>>>>>>>>> > >>>>>>>>>>> I can coordinate these changes. Ron, could you add me to the > >>>>>>>>>>> Cryptography team so I can upload the Pharo Cryptography > >>>>>>>>> #bleedingEdge? > >>>>>>>>>>> > >>>>>>>>>>> Thanks and I look forward to more, :) > >>>>>>>>>>> > >>>>>>>>>>> Robert > >>>>>>>>>>> > >>>>>>>>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: > >>>>>>>>>>>> Hi Robert, > >>>>>>>>>>>> > >>>>>>>>>>>> Nice to see you! > >>>>>>>>>>>> > >>>>>>>>>>>> Looks interesting I know that Chris did something gathering > >>>>>>>>>>>> sources of > >>>>>>>>> entropy. Seems like the more the better. Could you just make > >>>>>>>>> the entropy sources optional such that if they exist we use them? > >>>>>>>>> I would have to go back and see what Chris did but he was > >>>>>>>>> following suggestions from Schneider in his secureRandom. > >>>>>>>>>>>> > >>>>>>>>>>>> All the best, > >>>>>>>>>>>> > >>>>>>>>>>>> Ron Teitelbaum > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: Pharo-dev [mailto:pharo-dev- > bounces(a)lists.pharo.org] > >>>>>>>>>>>>> On Behalf Of Robert Withers > >>>>>>>>>>>>> Sent: Sunday, October 18, 2015 5:00 AM > >>>>>>>>>>>>> To: The general-purpose Squeak developers list; Pharo > >>>>>>>>>>>>> Development List > >>>>>>>>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] > >>>>>>>>>>>>> RandomGenerator > >>>>>>>>>>>>> class>>unpredictableStringsDo: > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'm sorry, I forgot the code. I list the existing method, > >>>>>>>>>>>>> followed by my modified Pharo method below. I welcome > any > >>>>>> feedback. > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> Robert > >>>>>>>>>>>>> > >>>>>>>>>>>>> --- > >>>>>>>>>>>>> Existing: > >>>>>>>>>>>>> unpredictableStringsDo: aBlock > >>>>>>>>>>>>> "Enumerate sources of information from my > >>>>>>>>>>>>> environment that > >>>>>>>>> should > >>>>>>>>>>>>> be generally hard to guess." > >>>>>>>>>>>>> | time | > >>>>>>>>>>>>> time := Time millisecondsToRun: > >>>>>>>>>>>>> [ aBlock > >>>>>>>>>>>>> value: World imageForm bits > >>>>>>>>>>>>> compressToByteArray ; > >>>>>>>>>>>>> value: Sensor mousePoint x asString ; > >>>>>>>>>>>>> value: Sensor mousePoint y asString ; > >>>>>>>>>>>>> value: Time > >>>>>>>>>>>>> millisecondClockValue asByteArray ; > >>>>>>>>>>>>> value: Date today asString ; > >>>>>>>>>>>>> value: Time now asString ; > >>>>>>>>>>>>> value: Display extent asString. > >>>>>>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. > >>>>>>>>>>>>> #(vmVersion platformName primVmPath > >>>>>>>>>>>>> imageName > >>>>>>>>> platformSubtype > >>>>>>>>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString > >>>>>>>>>>>>> imageName) > >>>>>>>>>>>>> collect: > >>>>>>>>>>>>> [ : each | > >>>>>>>>>>>>> aBlock value: (SmalltalkImage > >>>>>>>>>>>>> current > >>>>>>>>>>>>> perform: each) > >>>>>>>>> asByteArray > >>>>>>>>>>>>> ] ]. > >>>>>>>>>>>>> aBlock > >>>>>>>>>>>>> value: time asByteArray; > >>>>>>>>>>>>> "maybe the pointer has moved, hit it again." > >>>>>>>>>>>>> value: Sensor mousePoint asString ; > >>>>>>>>>>>>> value: Time millisecondClockValue > >>>>>>>>>>>>> asByteArray > >>>>>>>>>>>>> > >>>>>>>>>>>>> --- > >>>>>>>>>>>>> Pharo port: > >>>>>>>>>>>>> unpredictableStringsDo: aBlock > >>>>>>>>>>>>> "Enumerate sources of information from my > >>>>>>>>>>>>> environment that > >>>>>>>>> should > >>>>>>>>>>>>> be generally hard to guess." > >>>>>>>>>>>>> > >>>>>>>>>>>>> | time | > >>>>>>>>>>>>> time := Time millisecondsToRun: > >>>>>>>>>>>>> [ aBlock > >>>>>>>>>>>>> value: Time > >>>>>>>>>>>>> millisecondClockValue asByteArray ; > >>>>>>>>>>>>> value: Date today asString ; > >>>>>>>>>>>>> value: Time now asString. > >>>>>>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. > >>>>>>>>>>>>> #(version primImagePath imagePath > >>>>>>>>>>>>> datedVersion > >>>>>>>>>>>>> lastQuitLogPosition) > >>>>>>>>>>>>> collect: > >>>>>>>>>>>>> [ : each | > >>>>>>>>>>>>> aBlock value: (SmalltalkImage > >>>>>>>>>>>>> current > >>>>>>>>>>>>> perform: each) > >>>>>>>>> asByteArray > >>>>>>>>>>>>> ] ]. > >>>>>>>>>>>>> aBlock > >>>>>>>>>>>>> value: time asByteArray; > >>>>>>>>>>>>> value: Time millisecondClockValue > >>>>>>>>>>>>> asByteArray > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: > >>>>>>>>>>>>>> This is a message intended for anyone who was on the > >>>>>>>>>>>>>> Cryptography > >>>>>>>>> team. > >>>>>>>>>>>>>> I recently ported it to Pharo and had to make changes to > >>>>>>>>>>>>> RandomGenerator > >>>>>>>>>>>>>> class>>unpredictableStringsDo:. This certainly removed > >>>>>>>>>>>>>> class>>some uncertainty > >>>>>>>>>>>>>> from the results of this message. My question is what > >>>>>>>>>>>>>> should I do about that? This method seems to require > >>>>>>>>>>>>>> non-headless, as it is checking the mouse point and such. > >>>>>>>>>>>>>> This being a crypto cornerstone, what the best answer > here. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thank you, > >>>>>>>>>>>>>> Robert > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> ----------------------------------------------------------- > >>>>>>>>>> Louis LaBrunda > >>>>>>>>>> Keystone Software Corp. > >>>>>>>>>> SkypeMe callto://PhotonDemon > >>>>>>>>>> mailto:Lou@Keystone-Software.com http://www.Keystone- > >>>>>> Software.com > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> > >>> > > > > >

Oct. 21, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Robert Withers

Ron, I checked that email and there is no mention of who it was sent to now this SFLC advisors. Ok that must be the Software Freedom Law Center. I just reached out to them on this. Thank you, Robert On 10/19/2015 06:25 PM, Ron Teitelbaum wrote: > Hi Robert, > > I went back and reviewed and this is what I sent to BIS. > > http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/00011… > > Not much to it but we got a lot of advice from SFLC first. > > >From our research OS projects are allowed to host cryptographic code and make available for anyone to download. BUT that does not exclude users of the code from being restrained from exporting that code to any USA identified restricted entities. For example: http://www.state.gov/j/ct/list/c14151.htm > > I would recommend at the very least to register the repo with the BIS for Pharo, but I would also contact the SFLC to verify nothing has changed. > > All the best, > > Ron > >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Robert Withers >> Sent: Monday, October 19, 2015 5:28 PM >> To: The general-purpose Squeak developers list; 'Chris Muller' >> Cc: 'Pharo Development List' >> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] >> RandomGenerator class>>unpredictableStringsDo: >> >> (resending with Pharo list) >> >> Ron, would it be an easy process to add a second URL to the exception >> paperwork. Pharo does have new ideas about code storage and distribution >> that we would want to take advantage of. This would help a lot! >> >> Then again, screw their paperwork requirements of us. Put my name as >> responsible on the Pharo code and I'll take a trip to Cuba, if they need a >> scape goat for their 20th century thinking. Crypto is already out of the bag >> and everyone uses it freely. Just do it and ask permission later. >> >> In thinking about consolidating crypto code between squeak and pharo, I >> would guess there would be a thin capatibility layer for each system, then >> the Crypto code in the main. My goal is to have compatibility, crypto and >> plugins on both virtual platforms. >> >> Thanks so much ^^ >> >> Robert >> >> On 10/19/2015 05:17 PM, Ron Teitelbaum wrote: >>> Hi Chris, >>> >>> The exemption is not for the location of the server but the URL where it is >> hosted. I'm happy to help in any way I can but I don't have access to the >> Pharo Repos. I have no issue with having Pharo packages on SqueakSource if >> that is what everyone agrees too. We have multiple packages hosted there. >> It's ok with me if we host some pharo code there too. >>> All the best, >>> >>> Ron >>> >>>> -----Original Message----- >>>> From: Chris Muller [mailto:ma.chris.m@gmail.com] >>>> Sent: Monday, October 19, 2015 3:59 PM >>>> To: Ron Teitelbaum >>>> Cc: Pharo Development List; The general-purpose Squeak developers >>>> list >>>> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] >>>> RandomGenerator class>>unpredictableStringsDo: >>>> >>>> Heh, well, since then SqueakSource itself was moved to a different >>>> server in a different country. I guess there was also a mirror of >>>> SqueakSource hosted in Chile under a different URL for many years. >>>> >>>> I'm doubtful any of it matters, but we wouldn't want anyone to end up >>>> in Gitmo over it. If you're uncomfortable about hosting a copy >>>> elsewhere, then please at least namespace-prefix the Pharo-specific >>>> packages, to at least help keep it from becoming a tangled mess. >>>> >>>> On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum <ron(a)usmedrec.com> >>>> wrote: >>>>> Hi All, >>>>> >>>>> Unless someone filed the proper paperwork I would suggest NOT moving >>>> the cryptography code anywhere except for SqueakSource. When we >>>> started the project we spent time ensuring that we had a proper >>>> exemption from the U.S. regulations on exporting cryptographic code. >>>> If someone copied and forked the code that exemption may not still >>>> apply to that new repository. >>>>> I'm not personally involved with the code on Pharo, not sure who is >>>>> doing >>>> crypto there. >>>>> All the best, >>>>> >>>>> Ron >>>>> >>>>>> -----Original Message----- >>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >>>>>> Behalf Of Chris Muller >>>>>> Sent: Monday, October 19, 2015 2:47 PM >>>>>> To: The general-purpose Squeak developers list >>>>>> Cc: Pharo Development List >>>>>> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] >>>>>> RandomGenerator class>>unpredictableStringsDo: >>>>>> >>>>>> Yes, if a common package for both Squeak and Pharo is possible, >>>>>> that'd be great. Otherwise, the Squeak and Pharo versions should >>>>>> reside in separate repositories. Squeak users are still using >>>>>> squeaksource.com, Pharo moved to smalltalkhub and beyond.. >>>>>> >>>>>> On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers >>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>> hey Ron, >>>>>>> >>>>>>> It was actually the Pharo Cryptography team I was thinking of. >>>>>>> Perhaps we can get the same package to work in both squeak and >>>>>>> Pharo, with use of installable entropy sources or the like. In >>>>>>> order to get SqueakElib running in Pharo I need crypto and we may >>>>>>> as >>>> well do it right. >>>>>>> Cheers, >>>>>>> Robert >>>>>>> >>>>>>> >>>>>>> On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: >>>>>>>> Hi Robert, >>>>>>>> >>>>>>>> You are already on the Cryptograph repo on SqueakSource.com as an >>>>>> admin. >>>>>>>> Please feel free to reorg if you like. >>>>>>>> >>>>>>>> Let me know if you have trouble resurrecting your account. >>>>>>>> >>>>>>>> All the best, >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: squeak-dev-bounces(a)lists.squeakfoundation.org >>>>>>>>> [mailto:squeak-dev- bounces(a)lists.squeakfoundation.org] On >>>>>>>>> Behalf Of Robert Withers >>>>>>>>> Sent: Monday, October 19, 2015 1:53 PM >>>>>>>>> To: squeak-dev(a)lists.squeakfoundation.org >>>>>>>>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to >>>>>>>>> Pharo] RandomGenerator class>>unpredictableStringsDo: >>>>>>>>> >>>>>>>>> This is great guys. Is there a way to get this from the image? >>>>>>>>> Good to get >>>>>>>> it >>>>>>>>> with an FFI/OSProcess call or something. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>>>>>>>>> Hi Guys, >>>>>>>>>> >>>>>>>>>> How about getting the CPU temperature. I think most CPUs >>>>>>>>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I >>>>>>>>>> think it is seven bits. The real range should be less than >>>>>>>>>> that but it may be enough to help add some entropy. >>>>>>>>>> >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>>>>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Ron , nice to see you too! It has been a number of years, >>>>>>>>>>> hasn't >>>> it? >>>>>>>>>>> Crypto is timestamped back in 2010, so there is is. I hope >>>>>>>>>>> these have been kind years to you, as they have for me. >>>>>>>>>>> >>>>>>>>>>> I love the idea of optional sources of entropy, depending on >>>>>>>>>>> the deployed capabilities. So there are our mouse points and >>>>>>>>>>> such, because they ought to be optional. >>>>>>>>>>> >>>>>>>>>>> What are some reliably present sources in the most minimal >>>>>> situation? >>>>>>>>>>> If we could define minimal as an image with no image level I/O >>>>>>>>>>> beyond file I/O, I would think we'd have: Kernel, System, >>>>>>>>>>> Collections, Compiler and FFI. Some intransitives in that >>>>>>>>>>> scope for entropy would be >>>>>>>>> grand. >>>>>>>>>>> >>>>>>>>>>> I was thinking to take 5 millisecondClockValues, separated by >>>>>>>>>>> 4 non-secure random intervals: take the low order byte of the >>>>>>>>>>> 4 intervals and reverse & concat them, as a entropic source. >>>>>>>>>>> >>>>>>>>>>> I can coordinate these changes. Ron, could you add me to the >>>>>>>>>>> Cryptography team so I can upload the Pharo Cryptography >>>>>>>>> #bleedingEdge? >>>>>>>>>>> >>>>>>>>>>> Thanks and I look forward to more, :) >>>>>>>>>>> >>>>>>>>>>> Robert >>>>>>>>>>> >>>>>>>>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>>>>>>>>> Hi Robert, >>>>>>>>>>>> >>>>>>>>>>>> Nice to see you! >>>>>>>>>>>> >>>>>>>>>>>> Looks interesting I know that Chris did something gathering >>>>>>>>>>>> sources of >>>>>>>>> entropy. Seems like the more the better. Could you just make >>>>>>>>> the entropy sources optional such that if they exist we use them? >>>>>>>>> I would have to go back and see what Chris did but he was >>>>>>>>> following suggestions from Schneider in his secureRandom. >>>>>>>>>>>> >>>>>>>>>>>> All the best, >>>>>>>>>>>> >>>>>>>>>>>> Ron Teitelbaum >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] >>>>>>>>>>>>> On Behalf Of Robert Withers >>>>>>>>>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>>>>>>>>> To: The general-purpose Squeak developers list; Pharo >>>>>>>>>>>>> Development List >>>>>>>>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>>>>>>>>> RandomGenerator >>>>>>>>>>>>> class>>unpredictableStringsDo: >>>>>>>>>>>>> >>>>>>>>>>>>> I'm sorry, I forgot the code. I list the existing method, >>>>>>>>>>>>> followed by my modified Pharo method below. I welcome any >>>>>> feedback. >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> Existing: >>>>>>>>>>>>> unpredictableStringsDo: aBlock >>>>>>>>>>>>> "Enumerate sources of information from my >>>>>>>>>>>>> environment that >>>>>>>>> should >>>>>>>>>>>>> be generally hard to guess." >>>>>>>>>>>>> | time | >>>>>>>>>>>>> time := Time millisecondsToRun: >>>>>>>>>>>>> [ aBlock >>>>>>>>>>>>> value: World imageForm bits >>>>>>>>>>>>> compressToByteArray ; >>>>>>>>>>>>> value: Sensor mousePoint x asString ; >>>>>>>>>>>>> value: Sensor mousePoint y asString ; >>>>>>>>>>>>> value: Time millisecondClockValue >>>>>>>>>>>>> asByteArray ; >>>>>>>>>>>>> value: Date today asString ; >>>>>>>>>>>>> value: Time now asString ; >>>>>>>>>>>>> value: Display extent asString. >>>>>>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>>>>>>>> #(vmVersion platformName primVmPath >>>>>>>>>>>>> imageName >>>>>>>>> platformSubtype >>>>>>>>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>>>>>>>>> imageName) >>>>>>>>>>>>> collect: >>>>>>>>>>>>> [ : each | >>>>>>>>>>>>> aBlock value: (SmalltalkImage >>>>>>>>>>>>> current >>>>>>>>>>>>> perform: each) >>>>>>>>> asByteArray >>>>>>>>>>>>> ] ]. >>>>>>>>>>>>> aBlock >>>>>>>>>>>>> value: time asByteArray; >>>>>>>>>>>>> "maybe the pointer has moved, hit it again." >>>>>>>>>>>>> value: Sensor mousePoint asString ; >>>>>>>>>>>>> value: Time millisecondClockValue >>>>>>>>>>>>> asByteArray >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> Pharo port: >>>>>>>>>>>>> unpredictableStringsDo: aBlock >>>>>>>>>>>>> "Enumerate sources of information from my >>>>>>>>>>>>> environment that >>>>>>>>> should >>>>>>>>>>>>> be generally hard to guess." >>>>>>>>>>>>> >>>>>>>>>>>>> | time | >>>>>>>>>>>>> time := Time millisecondsToRun: >>>>>>>>>>>>> [ aBlock >>>>>>>>>>>>> value: Time millisecondClockValue >>>>>>>>>>>>> asByteArray ; >>>>>>>>>>>>> value: Date today asString ; >>>>>>>>>>>>> value: Time now asString. >>>>>>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>>>>>>>> #(version primImagePath imagePath >>>>>>>>>>>>> datedVersion >>>>>>>>>>>>> lastQuitLogPosition) >>>>>>>>>>>>> collect: >>>>>>>>>>>>> [ : each | >>>>>>>>>>>>> aBlock value: (SmalltalkImage >>>>>>>>>>>>> current >>>>>>>>>>>>> perform: each) >>>>>>>>> asByteArray >>>>>>>>>>>>> ] ]. >>>>>>>>>>>>> aBlock >>>>>>>>>>>>> value: time asByteArray; >>>>>>>>>>>>> value: Time millisecondClockValue >>>>>>>>>>>>> asByteArray >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>>>>>>>>> This is a message intended for anyone who was on the >>>>>>>>>>>>>> Cryptography >>>>>>>>> team. >>>>>>>>>>>>>> I recently ported it to Pharo and had to make changes to >>>>>>>>>>>>> RandomGenerator >>>>>>>>>>>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>>>>>>>>>>> class>>uncertainty >>>>>>>>>>>>>> from the results of this message. My question is what >>>>>>>>>>>>>> should I do about that? This method seems to require >>>>>>>>>>>>>> non-headless, as it is checking the mouse point and such. >>>>>>>>>>>>>> This being a crypto cornerstone, what the best answer here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> ----------------------------------------------------------- >>>>>>>>>> Louis LaBrunda >>>>>>>>>> Keystone Software Corp. >>>>>>>>>> SkypeMe callto://PhotonDemon >>>>>>>>>> mailto:Lou@Keystone-Software.com http://www.Keystone- >>>>>> Software.com >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>> > >

Oct. 21, 2015

Re: [Pharo-dev] Settings: where are they stored?

by stepharo

I want to create a package and set up the font automatically but I found another way. Le 20/10/15 19:39, Juraj Kubelka a Ã©crit : > SystemSettingsPersistence defaultPreferenceFileReference

Oct. 20, 2015

Stream instead of string concatenation

by Jan Vrany

Hi there,Â it's a little less than a year ago the above issue has been raisedÂ by Uko [1]. I run some benchmarks (a little less than year ago :-) With the integration of QA this issue may deserve some attention again. Besides, Uko asked for a feedback.Â The rule seems to be wrong - it barks on code which is (seems to be)Â perfectly fine performance-wise, For example:Â shutUp Class allInstances do:[:cls | Transcript show: 'barking at' , cls name ] See *some* of the benchmark results:Â http://bit.ly/1GnZ3K0 My interpretation of the result is the following: For small number of concatenations, i.e., up to 5, with no accumulator and with reasonably small strings, i.e., shorter than 50 bytes,Â it's actually faster to use string concatenation.Â Using streams is slower, unless one preallocates stream backingÂ string to exactly the size needed. In that case, it's roughly the same as string concatenation using #, You may find full benchmark data at:Â https://swing.fit.cvut.cz/calipel/archive/943.json https://swing.fit.cvut.cz/calipel/archive/944.json Benchmark source:Â https://bitbucket.org/janvrany/jv-calipel/src/tip/s/benchmarks/micro/Be nchmarkMicroStringConcat.st?fileviewer=file-view-default https://bitbucket.org/janvrany/jv-calipel/src/tip/s/benchmarks/micro/Be nchmarkMicroStringConcatN.st?fileviewer=file-view-default Indeed, I could have messed up things - we all know about lies, damn lies and benchmarks. HTH, Jan [1]:Â http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-No vember/103162.html

Oct. 20, 2015

Re: [Pharo-dev] ConfigurationOf and Git

by Dale Henrichs

Here's the documentation for the Metacello github:// repository description[1]. ... In recent versions of Metacello I have made it possible for you to use pattern matching in the <version identifier> to provide for symbolic-version-like facility for github references. Instead of stableForPharo4 you would associate a semantic version with the code that is "stableForPharo4" for example `4.0.0` and use the tag `v4.0.0` to mark the commit that is "stableForPharo4". Similarly you'd use the tag `v5.0.0` to mark the commit that is "stableForPharo5". Then you'd use the following in your baseline: method (not in a symbolicVersion method). spec for: #'pharo4.0.x' do: [spec baseline: 'Project' with: [ spec repository: 'github://username/Project:v4.?/']]. spec for: #'pharo5.0.x' do: [spec baseline: 'Project' with: [ spec repository: 'github://username/Project:v5.?/']]. If you end up with a new commit that patches a Pharo4 problem, you'd tag that commit as `v4.0.1` and so on .... The above `v4.?` pattern will match `v4.0.1` and you'll pick up that tag the next time you refresh your build (i.e., do a `get` on the Project baseline ... which causes a new download from Github) ... HTH, Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScr… [2] https://github.com/dalehenrich/metacello-work/issues/277#issuecomment-58970… On 10/19/2015 08:05 PM, Gabriel Cotelli wrote: > I was wondering if something like this can work: > > Given a ConfigurationOfProject (a subclass of ConfigurationOf) defining: > > stable: spec <symbolicVersion: #stable> spec for: #'pharo4.0.x' do: > [spec baseline: 'Project' with: [ spec repository: > 'github://username/Project:stableForPharo4/']]. spec for: > #'pharo5.0.x' do: [spec baseline: 'Project'with: [ spec repository: > 'github://username/Project:stableForPharo5/']]. > > > where stableForPharo4 and stableForPharo5 are tags in the git repo > (and assuming the BaselineOfProject is defined in this commits). Is > this supposed to work : > Metacello new > configuration: 'Project'; > repository: 'github://username/Project:master'; > version: #stable; > load.?? > I've tried using a non-symbolic version and it works but I can't make > it work for #stable. I'd like to use this configuration for the > Configuration Browser/Catalog Browser. > Any help is appreciated.

Oct. 20, 2015

VM background reading "porting squeak"

by Ben Coman

Just sharing that I found the following chapter from Mark Guzdial's "Squeak: Open Personal Computing and Multimedia" an interesting background read on the VM. Cross posting since some others not on [vm-dev] might similarly find it interesting. http://sdmeta.gforge.inria.fr/FreeBooks/CollectiveNBlueBook/porting-subfina… cheers -ben

Oct. 20, 2015

Re: [Pharo-dev] Settings: where are they stored?

by Juraj Kubelka

Hi, > On Oct 20, 2015, at 13:54, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > I took latest image set up some fonts. > Then pressed saved. > > "Information > Settings has been stored on the disk." > would be good to know where. I have no clue. > SystemSettingsPersistence defaultPreferenceFileReference > Then I tried load > > I got: no idea what it is. > > Information > Cannot update #Nautilus#emptyCommentWarning. Exception: MessageNotUnderstood: Nautilus class>>emptyCommentWarning: You got this message because Nautilus settings in #nautilusSettingsOn: called #emptyCommentWarning do not have a setting method that should be defined on Nautilus class>>#emptyCommentWarning: This is a Nautilus's bug. I can write a test case that will detect problematic settings. Setting Browser will only inform a user about a issue. It does not raise error (debugger). > > I want to set automatically and programmatically settings and I thought that I could use Ston saved settings but I looks like a not > so good idea. > I do not understand this. You can programmatically save a setting using SystemSettingsPersistence>>#storeIdentifier: Cheers, Juraj > > Stef >

Oct. 20, 2015

Re: [Pharo-dev] Settings: where are they stored?

by Henrik Nergaard

SystemSettingsPersistence defaultPreferenceFileReference parent ^^ evaluate that and it should give the result, if not there was some changes in 50393 (https://pharo.fogbugz.com/f/cases/16816) Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo Sent: Tuesday, October 20, 2015 6:55 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] Settings: where are they stored? Hi guys I took latest image set up some fonts. Then pressed saved. "Information Settings has been stored on the disk." would be good to know where. I have no clue. Then I tried load I got: no idea what it is. Information Cannot update #Nautilus#emptyCommentWarning. Exception: MessageNotUnderstood: Nautilus class>>emptyCommentWarning: I want to set automatically and programmatically settings and I thought that I could use Ston saved settings but I looks like a not so good idea. Stef

Oct. 20, 2015

Settings: where are they stored?

by stepharo

Hi guys I took latest image set up some fonts. Then pressed saved. "Information Settings has been stored on the disk." would be good to know where. I have no clue. Then I tried load I got: no idea what it is. Information Cannot update #Nautilus#emptyCommentWarning. Exception: MessageNotUnderstood: Nautilus class>>emptyCommentWarning: I want to set automatically and programmatically settings and I thought that I could use Ston saved settings but I looks like a not so good idea. Stef

Oct. 20, 2015

Re: [Pharo-dev] FastTable question

by Ferlicot D. Cyril

Le 20/10/2015 18:42, stepharo a Ã©crit : > for the mooc videos I must use larger fonts. > So I ended up hacking and changing the hardcoded number in default > > defaultRowHeight > ^ 24 > > rowHeight > "This is the row height your rows will have. Cells answered in > dataSource will be forced to have > this height number... We force it instead allowing lists to have > any height because the logic to > calculate rows becomes complicated. Possible, but complicated :)" > > ^ rowHeight ifNil: [ self class defaultRowHeight ] > > > Esteban two questions: > > - when I read the code of FTmorph I was thinking that a lot of it has > not much to do with UI but looks like a model :). > > - if I were about to manage the height of a row based on its actual > contents where should I put it. > FTTableContainerMorph is containing what is visible but I wonder why it > was asking this to the FastTable and to the elements displayed? > > Why the ContainerMorph does not ask the FTTableRowMorph for its height > and it could be computed based on the font. > I still did not get where the strings built. > > > may be here > > updateExposedRows > > ... > > | cell | > cell := (self owner dataSource > cellColumn: (columns at: columnIndex) > row: rowIndex). > cell width: (columnWidths at: columnIndex). > > We should add more comments to methods. > > > Stef > > > > drawOn: canvas > | x y cellWidth cellHeight rowsToDisplay rowSubviews > highligtedRowIndexes primarySelectionIndex | > > self bounds ifNil: [ ^ self ]. "Nothing to show yet" > self owner ifNil: [ ^ self ]. > > x := self left + self class rowLeftMargin. > y := self top. > cellWidth := self width - self class rowLeftMargin. > cellHeight := self owner rowHeight. > ^^^^^^^^^^^^^^^^^^^^^^^ > > highligtedRowIndexes := > self owner selectedRowIndexes, > self owner highlightedRowIndexes. > primarySelectionIndex := self owner selectedRowIndex. > > "For some superweird reason, calling #calculateExposedRows here > instead in #changed (where > it should be called) is 10x faster. Since the whole purpose of this > component is speed, for > now I'm calling it here and adding the #setNeedRecalculateRows > mechanism. > History, please forgive me." > self updateAllRows. > > rowsToDisplay := self exposedRows. > rowSubviews := OrderedCollection new: rowsToDisplay size + 1. > headerRow ifNotNil: [ > headerRow bounds: (x@y extent: cellWidth@cellHeight). > y := y + cellHeight + self owner intercellSpacing. > rowSubviews add: headerRow ]. > > rowsToDisplay keysAndValuesDo: [ :rowIndex :row | | visibleHeight | > visibleHeight := cellHeight min: (self bottom - y). > row bounds: (x@y extent: cellWidth@visibleHeight). > y := y + visibleHeight + self owner intercellSpacing. > rowSubviews add: ((highligtedRowIndexes includes: rowIndex) > ifTrue: [ > "IMPORTANT: I need to set owner to nil because otherwise > it will trigger an > invalidation of the owner when adding morph to > selectionMorph, causing an > infinite loop" > self > toSelectionRow: (row privateOwner: nil) > primary: primarySelectionIndex = rowIndex ] > ifFalse: [ row ]) ]. > > submorphs := rowSubviews asArray. > super drawOn: canvas. > needsRefreshExposedRows := false > If you load the development version of FT it will be fine normally :) Maybe not perfect for now but usable with large fonts. (You have to close and reopen the existing FT if you change font size because the change is hard coded and not announce). I adapted also the FTFastTableComposer so that it manage the font size. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 20, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by stepharo

We have one single rule. Any package belonging to the core of Pharo should be hosted under Pharo on SmalltalkHub. After that people can use any services/server they want. Stef Le 20/10/15 18:41, David T. Lewis a Ã©crit : >> Hi Chris, >> >> The exemption is not for the location of the server but the URL where it >> is hosted. I'm happy to help in any way I can but I don't have access to >> the Pharo Repos. I have no issue with having Pharo packages on >> SqueakSource if that is what everyone agrees too. We have multiple >> packages hosted there. It's ok with me if we host some pharo code there >> too. >> >> All the best, >> >> Ron >> > The squeaksource.com service is open to everyone. Many people in the Pharo > community make use of it, and should feel welcome to do so. > > Dave > > >

Oct. 20, 2015

FastTable question

by stepharo

for the mooc videos I must use larger fonts. So I ended up hacking and changing the hardcoded number in default defaultRowHeight ^ 24 rowHeight "This is the row height your rows will have. Cells answered in dataSource will be forced to have this height number... We force it instead allowing lists to have any height because the logic to calculate rows becomes complicated. Possible, but complicated :)" ^ rowHeight ifNil: [ self class defaultRowHeight ] Esteban two questions: - when I read the code of FTmorph I was thinking that a lot of it has not much to do with UI but looks like a model :). - if I were about to manage the height of a row based on its actual contents where should I put it. FTTableContainerMorph is containing what is visible but I wonder why it was asking this to the FastTable and to the elements displayed? Why the ContainerMorph does not ask the FTTableRowMorph for its height and it could be computed based on the font. I still did not get where the strings built. may be here updateExposedRows ... | cell | cell := (self owner dataSource cellColumn: (columns at: columnIndex) row: rowIndex). cell width: (columnWidths at: columnIndex). We should add more comments to methods. Stef drawOn: canvas | x y cellWidth cellHeight rowsToDisplay rowSubviews highligtedRowIndexes primarySelectionIndex | self bounds ifNil: [ ^ self ]. "Nothing to show yet" self owner ifNil: [ ^ self ]. x := self left + self class rowLeftMargin. y := self top. cellWidth := self width - self class rowLeftMargin. cellHeight := self owner rowHeight. ^^^^^^^^^^^^^^^^^^^^^^^ highligtedRowIndexes := self owner selectedRowIndexes, self owner highlightedRowIndexes. primarySelectionIndex := self owner selectedRowIndex. "For some superweird reason, calling #calculateExposedRows here instead in #changed (where it should be called) is 10x faster. Since the whole purpose of this component is speed, for now I'm calling it here and adding the #setNeedRecalculateRows mechanism. History, please forgive me." self updateAllRows. rowsToDisplay := self exposedRows. rowSubviews := OrderedCollection new: rowsToDisplay size + 1. headerRow ifNotNil: [ headerRow bounds: (x@y extent: cellWidth@cellHeight). y := y + cellHeight + self owner intercellSpacing. rowSubviews add: headerRow ]. rowsToDisplay keysAndValuesDo: [ :rowIndex :row | | visibleHeight | visibleHeight := cellHeight min: (self bottom - y). row bounds: (x@y extent: cellWidth@visibleHeight). y := y + visibleHeight + self owner intercellSpacing. rowSubviews add: ((highligtedRowIndexes includes: rowIndex) ifTrue: [ "IMPORTANT: I need to set owner to nil because otherwise it will trigger an invalidation of the owner when adding morph to selectionMorph, causing an infinite loop" self toSelectionRow: (row privateOwner: nil) primary: primarySelectionIndex = rowIndex ] ifFalse: [ row ]) ]. submorphs := rowSubviews asArray. super drawOn: canvas. needsRefreshExposedRows := false

Oct. 20, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by David T. Lewis

> Hi Chris, > > The exemption is not for the location of the server but the URL where it > is hosted. I'm happy to help in any way I can but I don't have access to > the Pharo Repos. I have no issue with having Pharo packages on > SqueakSource if that is what everyone agrees too. We have multiple > packages hosted there. It's ok with me if we host some pharo code there > too. > > All the best, > > Ron > The squeaksource.com service is open to everyone. Many people in the Pharo community make use of it, and should feel welcome to do so. Dave

Oct. 20, 2015

Re: [Pharo-dev] Smalltalkhub instable

by stepharo

superb! Le 20/10/15 14:13, Marcus Denker a Ã©crit : >> On 10 Oct 2015, at 09:48, stepharo <stepharo(a)free.fr> wrote: >> >> do we have a document to show how to do such reboot? >> > I have updated https://pharo.fogbugz.com/default.asp?W66 > > Marcus > > >

Oct. 20, 2015

Re: [Pharo-dev] Is storing a setting supposed to work in latest version?

by stepharo

Tx I'm sick with fever and all the stuff around... getting slowly out of this. I will try. I'm building an image for the mooc screening. Stef Le 19/10/15 20:34, Juraj Kubelka a Ã©crit : > It is already integrated. Thanks Marcus! > > Cheers, > Juraj > >> On Oct 19, 2015, at 12:33, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >> >> There is a bug: https://pharo.fogbugz.com/f/cases/16816/Storing-System-Settings-produces-er… >> >> Slice included. >> Cheers, >> Juraj >> >>> On Oct 19, 2015, at 12:21, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi guys >>> >>> When I press Store Setting in the Settings Browser, I get a DNU. >>> How can I save a setting now? >>> >>> Stef >>> > >

Oct. 20, 2015

Re: [Pharo-dev] ConfigurationOf and Git

by Dimitris Chloupis

you diffirent versions can also be branches of the same repo , so you have one branch for pharo 4 and one for pharo 5 , baseline can load code from specific branches. On Tue, Oct 20, 2015 at 4:14 PM Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > I've tried something like this with a BaselineOf and it works, but I want > to define the #stable version for a ConfigurationOf because as far as I > know the ConfigurationBrowser/CatalogBrowser uses only configurations and > tries to load the stable symbolic version. > > On Tue, Oct 20, 2015 at 4:06 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> Hi Gabriel, >> >> Looks ok to me. >> >> Take a look at >> https://github.com/theseion/LibGit/blob/master/BaselineOfLibGit.package/Bas…. >> I think youâll find all your use cases in that baseline. >> >> As for loading: >> >> Metacello new >> baseline: #LibGit; >> repository: 'github://theseion/LibGit:master'; >> load. >> >> Metacello new >> baseline: #LibGit; >> repository: 'github://theseion/LibGit:master'; >> load: 'developmentâ. >> >> HTH, >> Max >> >> >> On 20 Oct 2015, at 05:05, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> >> I was wondering if something like this can work: >> >> Given a ConfigurationOfProject (a subclass of ConfigurationOf) defining: >> >> stable: spec <symbolicVersion: #stable> spec for: #'pharo4.0.x' do: >> [spec baseline: 'Project' with: [ spec repository: 'github://username/Project:stableForPharo4/']]. >> spec for: #'pharo5.0.x' do: [spec baseline: 'Project' with: [ spec >> repository: 'github://username/Project:stableForPharo5/']]. >> >> where stableForPharo4 and stableForPharo5 are tags in the git repo (and >> assuming the BaselineOfProject is defined in this commits). Is this >> supposed to work : >> >> Metacello new >> configuration: 'Project'; >> repository: 'github://username/Project:master'; >> version: #stable; >> load. ?? >> >> I've tried using a non-symbolic version and it works but I can't make it >> work for #stable. I'd like to use this configuration for the Configuration >> Browser/Catalog Browser. >> >> Any help is appreciated. >> >> >> >

Oct. 20, 2015

Re: [Pharo-dev] ConfigurationOf and Git

by Gabriel Cotelli

I've tried something like this with a BaselineOf and it works, but I want to define the #stable version for a ConfigurationOf because as far as I know the ConfigurationBrowser/CatalogBrowser uses only configurations and tries to load the stable symbolic version. On Tue, Oct 20, 2015 at 4:06 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi Gabriel, > > Looks ok to me. > > Take a look at > https://github.com/theseion/LibGit/blob/master/BaselineOfLibGit.package/Bas…. > I think youâll find all your use cases in that baseline. > > As for loading: > > Metacello new > baseline: #LibGit; > repository: 'github://theseion/LibGit:master'; > load. > > Metacello new > baseline: #LibGit; > repository: 'github://theseion/LibGit:master'; > load: 'developmentâ. > > HTH, > Max > > > On 20 Oct 2015, at 05:05, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > I was wondering if something like this can work: > > Given a ConfigurationOfProject (a subclass of ConfigurationOf) defining: > > stable: spec <symbolicVersion: #stable> spec for: #'pharo4.0.x' do: [spec > baseline: 'Project' with: [ spec repository: 'github://username/Project:stableForPharo4/']]. > spec for: #'pharo5.0.x' do: [spec baseline: 'Project' with: [ spec > repository: 'github://username/Project:stableForPharo5/']]. > > where stableForPharo4 and stableForPharo5 are tags in the git repo (and > assuming the BaselineOfProject is defined in this commits). Is this > supposed to work : > > Metacello new > configuration: 'Project'; > repository: 'github://username/Project:master'; > version: #stable; > load. ?? > > I've tried using a non-symbolic version and it works but I can't make it > work for #stable. I'd like to use this configuration for the Configuration > Browser/Catalog Browser. > > Any help is appreciated. > > >

Oct. 20, 2015

Re: [Pharo-dev] Smalltalkhub instable

by Marcus Denker

> On 10 Oct 2015, at 09:48, stepharo <stepharo(a)free.fr> wrote: > > do we have a document to show how to do such reboot? > I have updated https://pharo.fogbugz.com/default.asp?W66 Marcus

Oct. 20, 2015

Re: [Pharo-dev] tests should be green

by Marcus Denker

Hello, yes, this looks like a solution to me. Can you open an issue? Marcus > On 15 Oct 2015, at 13:01, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-10-15 9:36 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > Yes, > > -> there is a bug somewhere that flattens traits in some cases > > Any idea how to fix this? > > I already provided a fix for the package fileout: > ( 10808 Bad behavior on FileOut/FileIn tool when using traits) > > But for Monticello packages, this works differently. A quick look at MCPackage>>#snapshot shows: > .... > rPackageSet methods > do: [:ea | definitions add: ea asMCMethodDefinition] > displayingProgress: [ :ea| 'Snapshotting methods...' ]. > > rPackageSet overriddenMethods > do: [:ea | definitions add: > (rPackageSet changeRecordForOverriddenMethod: ea) asMCMethodDefinition] > displayingProgress: [ :ea| 'Searching for overrides in ', ea asString ]. > > ... > > here, rPackageSet methods > and rPackageSet overrriddenMethods > create RGMethodDefinition for all, trait and non trait methods. > > We could try to solve this by adding a #reject: > > rPackageSet methods reject:#isFromTrait ..... > > > > > > -> we need to write a script to delete all the wrong methods. > > > On 14 Oct 2015, at 17:16, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: > > > > Please, someone can look at the Collections-Tests > > The ReleaseTest complains about > > > > testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits > > (These are all Test-subclasses that use traits, but all(!) trait method are > > compiled in the class instead, this happened after someone moved the Test > > packages (for bootstrap?) > > > > OrderedCollectionTest > > FloatArrayTest > > ArrayTest > > DateTest > > HeapTest > > MorphicTextAdapter > > LinkedListTest > > DatePrintFormatTester > > StackTest > > CheckboxButtonMorph > > IntervalTest > > DateAndTimeTest > > SimpleButtonMorph > > MethodDictionaryTest > > SetTest > > DictionaryTest > > BagTest > > SymbolTest > > StringTest > > CollectionRootTest > > SortedCollectionTest > > > >

Oct. 20, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50394 Home: https://github.com/pharo-project/pharo-core

Oct. 20, 2015

[pharo-project/pharo-core] 6d00af: 50394

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 6d00affb20b225096b2fda3cb3359575de3bc8d6 https://github.com/pharo-project/pharo-core/commit/6d00affb20b225096b2fda3c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-20 (Tue, 20 Oct 2015) Changed paths: A AST-Core.package/RBLiteralNode.class/instance/initialization/initialize.st M BlueInk-Core.package/BIConfigurableFormatter.class/instance/visiting/visitCascadeNode_.st R Morphic-Widgets-Taskbar.package/extension/SystemWindow/instance/taskbarIcon.st M Morphic-Widgets-Windows.package/AbstractResizerMorph.class/definition.st M Morphic-Widgets-Windows.package/BottomLeftGripMorph.class/definition.st M Morphic-Widgets-Windows.package/BottomRightGripMorph.class/definition.st M Morphic-Widgets-Windows.package/CornerGripMorph.class/definition.st M Morphic-Widgets-Windows.package/EdgeGripMorph.class/definition.st M Morphic-Widgets-Windows.package/ProportionalSplitterMorph.class/definition.st M Morphic-Widgets-Windows.package/StandardWindow.class/instance/operations/flash.st A Morphic-Widgets-Windows.package/SystemWindow.class/instance/activation/activate.st A Morphic-Widgets-Windows.package/SystemWindow.class/instance/activation/activatedModalChild.st A Morphic-Widgets-Windows.package/SystemWindow.class/instance/activation/addPaneSplittersIfNeeded.st A Morphic-Widgets-Windows.package/SystemWindow.class/instance/activation/basicActivate.st A Morphic-Widgets-Windows.package/SystemWindow.class/instance/activation/navigateFocus.st A Morphic-Widgets-Windows.package/SystemWindow.class/instance/activation/positionModalOwner.st R Morphic-Widgets-Windows.package/SystemWindow.class/instance/dropping%2Fgrabbing/aboutToBeGrabbedBy_.st A Morphic-Widgets-Windows.package/SystemWindow.class/instance/events/grabSelfOrTopRenderer_.st M Morphic-Widgets-Windows.package/SystemWindow.class/instance/events/mouseDown_.st A Morphic-Widgets-Windows.package/SystemWindow.class/instance/events/mouseMove_.st M Morphic-Widgets-Windows.package/SystemWindow.class/instance/events/paneTransition_.st M Morphic-Widgets-Windows.package/SystemWindow.class/instance/events/secondaryPaneTransition_divider_.st M Morphic-Widgets-Windows.package/SystemWindow.class/instance/geometry/paneMorphs.st M Morphic-Widgets-Windows.package/TopLeftGripMorph.class/definition.st M Morphic-Widgets-Windows.package/TopRightGripMorph.class/definition.st A Morphic-Widgets-Windows.package/WindowDeActivated.class/README.md A Morphic-Widgets-Windows.package/WindowDeActivated.class/definition.st M Morphic-Widgets-Windows.package/WindowEdgeGripMorph.class/definition.st A Polymorph-TaskbarIcons.package/extension/SystemWindow/instance/taskbarIcon.st R Polymorph-Widgets.package/extension/SystemWindow/instance/activate.st R Polymorph-Widgets.package/extension/SystemWindow/instance/basicActivate.st M Polymorph-Widgets.package/extension/SystemWindow/instance/configureForUnembedding.st M Polymorph-Widgets.package/extension/SystemWindow/instance/modalLockTo_.st R Polymorph-Widgets.package/extension/SystemWindow/instance/mouseMove_.st A Refactoring-Environment.package/RBBrowserEnvironmentWrapper.class/instance/private/packageNames.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50393.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50394.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50393.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50394.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-FileList.package/FileDialogWindow.class/instance/accessing/cache_.st A Tool-FileList.package/FileDialogWindow.class/instance/private/dirEntriesOrEmptyListFor_.st Log Message: ----------- 50394 16786 Code formatter moves comments to wrong place https://pharo.fogbugz.com/f/cases/16786 16815 DNU RBAndEnvironment>>packageNames while producing html report bootstrap architecture rule https://pharo.fogbugz.com/f/cases/16815 16817 like 16798 #sourceInterval should work for every RBNode - RBLiteralNode too https://pharo.fogbugz.com/f/cases/16817 16711 FileDialogWindow should fail silently on DirectoryDoesNotExist: when clicking on Junctions (Windows) https://pharo.fogbugz.com/f/cases/16711 16807 SystemWindow refactoring (Events, activation ++) https://pharo.fogbugz.com/f/cases/16807 http://files.pharo.org/image/50/50394.zip

Oct. 20, 2015

Re: [Pharo-dev] ConfigurationOf and Git

by Max Leske

Hi Gabriel, Looks ok to me. Take a look at https://github.com/theseion/LibGit/blob/master/BaselineOfLibGit.package/Bas…. I think youâll find all your use cases in that baseline. As for loading: Metacello new baseline: #LibGit; repository: 'github://theseion/LibGit:master'; load. Metacello new baseline: #LibGit; repository: 'github://theseion/LibGit:master'; load: 'developmentâ. HTH, Max > On 20 Oct 2015, at 05:05, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > I was wondering if something like this can work: > > Given a ConfigurationOfProject (a subclass of ConfigurationOf) defining: > > stable: spec > <symbolicVersion: #stable> > spec for: #'pharo4.0.x' > do: [spec > baseline: 'Project' > with: [ spec repository: 'github://username/Project:stableForPharo4/']]. > spec for: #'pharo5.0.x' > do: [spec > baseline: 'Project' > with: [ spec repository: 'github://username/Project:stableForPharo5/']]. > > > > where stableForPharo4 and stableForPharo5 are tags in the git repo (and assuming the BaselineOfProject is defined in this commits). Is this supposed to work : > > Metacello new > configuration: 'Project'; > repository: 'github://username/Project:master'; > version: #stable; > load. ?? > > I've tried using a non-symbolic version and it works but I can't make it work for #stable. I'd like to use this configuration for the Configuration Browser/Catalog Browser. > > Any help is appreciated.

Oct. 20, 2015

ConfigurationOf and Git

by Gabriel Cotelli

I was wondering if something like this can work: Given a ConfigurationOfProject (a subclass of ConfigurationOf) defining: stable: spec <symbolicVersion: #stable> spec for: #'pharo4.0.x' do: [spec baseline: 'Project' with: [ spec repository: 'github://username/Project:stableForPharo4/']]. spec for: #'pharo5.0.x' do: [spec baseline: 'Project' with: [ spec repository: 'github://username/Project:stableForPharo5/']]. where stableForPharo4 and stableForPharo5 are tags in the git repo (and assuming the BaselineOfProject is defined in this commits). Is this supposed to work : Metacello new configuration: 'Project'; repository: 'github://username/Project:master'; version: #stable; load. ?? I've tried using a non-symbolic version and it works but I can't make it work for #stable. I'd like to use this configuration for the Configuration Browser/Catalog Browser. Any help is appreciated.

Oct. 20, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Robert Withers

Thank you Ron, I'll look into it. Regards, ... ^^ robert On 10/19/2015 06:25 PM, Ron Teitelbaum wrote: > Hi Robert, > > I went back and reviewed and this is what I sent to BIS. > > http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/00011… > > Not much to it but we got a lot of advice from SFLC first. > >>From our research OS projects are allowed to host cryptographic code and make available for anyone to download. BUT that does not exclude users of the code from being restrained from exporting that code to any USA identified restricted entities. For example: http://www.state.gov/j/ct/list/c14151.htm > > I would recommend at the very least to register the repo with the BIS for Pharo, but I would also contact the SFLC to verify nothing has changed. > > All the best, > > Ron > >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Robert Withers >> Sent: Monday, October 19, 2015 5:28 PM >> To: The general-purpose Squeak developers list; 'Chris Muller' >> Cc: 'Pharo Development List' >> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] >> RandomGenerator class>>unpredictableStringsDo: >> >> (resending with Pharo list) >> >> Ron, would it be an easy process to add a second URL to the exception >> paperwork. Pharo does have new ideas about code storage and distribution >> that we would want to take advantage of. This would help a lot! >> >> Then again, screw their paperwork requirements of us. Put my name as >> responsible on the Pharo code and I'll take a trip to Cuba, if they need a >> scape goat for their 20th century thinking. Crypto is already out of the bag >> and everyone uses it freely. Just do it and ask permission later. >> >> In thinking about consolidating crypto code between squeak and pharo, I >> would guess there would be a thin capatibility layer for each system, then >> the Crypto code in the main. My goal is to have compatibility, crypto and >> plugins on both virtual platforms. >> >> Thanks so much ^^ >> >> Robert >> >> On 10/19/2015 05:17 PM, Ron Teitelbaum wrote: >>> Hi Chris, >>> >>> The exemption is not for the location of the server but the URL where it is >> hosted. I'm happy to help in any way I can but I don't have access to the >> Pharo Repos. I have no issue with having Pharo packages on SqueakSource if >> that is what everyone agrees too. We have multiple packages hosted there. >> It's ok with me if we host some pharo code there too. >>> >>> All the best, >>> >>> Ron >>> >>>> -----Original Message----- >>>> From: Chris Muller [mailto:ma.chris.m@gmail.com] >>>> Sent: Monday, October 19, 2015 3:59 PM >>>> To: Ron Teitelbaum >>>> Cc: Pharo Development List; The general-purpose Squeak developers >>>> list >>>> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] >>>> RandomGenerator class>>unpredictableStringsDo: >>>> >>>> Heh, well, since then SqueakSource itself was moved to a different >>>> server in a different country. I guess there was also a mirror of >>>> SqueakSource hosted in Chile under a different URL for many years. >>>> >>>> I'm doubtful any of it matters, but we wouldn't want anyone to end up >>>> in Gitmo over it. If you're uncomfortable about hosting a copy >>>> elsewhere, then please at least namespace-prefix the Pharo-specific >>>> packages, to at least help keep it from becoming a tangled mess. >>>> >>>> On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum <ron(a)usmedrec.com> >>>> wrote: >>>>> Hi All, >>>>> >>>>> Unless someone filed the proper paperwork I would suggest NOT moving >>>> the cryptography code anywhere except for SqueakSource. When we >>>> started the project we spent time ensuring that we had a proper >>>> exemption from the U.S. regulations on exporting cryptographic code. >>>> If someone copied and forked the code that exemption may not still >>>> apply to that new repository. >>>>> >>>>> I'm not personally involved with the code on Pharo, not sure who is >>>>> doing >>>> crypto there. >>>>> >>>>> All the best, >>>>> >>>>> Ron >>>>> >>>>>> -----Original Message----- >>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >>>>>> Behalf Of Chris Muller >>>>>> Sent: Monday, October 19, 2015 2:47 PM >>>>>> To: The general-purpose Squeak developers list >>>>>> Cc: Pharo Development List >>>>>> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] >>>>>> RandomGenerator class>>unpredictableStringsDo: >>>>>> >>>>>> Yes, if a common package for both Squeak and Pharo is possible, >>>>>> that'd be great. Otherwise, the Squeak and Pharo versions should >>>>>> reside in separate repositories. Squeak users are still using >>>>>> squeaksource.com, Pharo moved to smalltalkhub and beyond.. >>>>>> >>>>>> On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers >>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>> hey Ron, >>>>>>> >>>>>>> It was actually the Pharo Cryptography team I was thinking of. >>>>>>> Perhaps we can get the same package to work in both squeak and >>>>>>> Pharo, with use of installable entropy sources or the like. In >>>>>>> order to get SqueakElib running in Pharo I need crypto and we may >>>>>>> as >>>> well do it right. >>>>>>> >>>>>>> Cheers, >>>>>>> Robert >>>>>>> >>>>>>> >>>>>>> On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: >>>>>>>> >>>>>>>> Hi Robert, >>>>>>>> >>>>>>>> You are already on the Cryptograph repo on SqueakSource.com as an >>>>>> admin. >>>>>>>> Please feel free to reorg if you like. >>>>>>>> >>>>>>>> Let me know if you have trouble resurrecting your account. >>>>>>>> >>>>>>>> All the best, >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: squeak-dev-bounces(a)lists.squeakfoundation.org >>>>>>>>> [mailto:squeak-dev- bounces(a)lists.squeakfoundation.org] On >>>>>>>>> Behalf Of Robert Withers >>>>>>>>> Sent: Monday, October 19, 2015 1:53 PM >>>>>>>>> To: squeak-dev(a)lists.squeakfoundation.org >>>>>>>>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to >>>>>>>>> Pharo] RandomGenerator class>>unpredictableStringsDo: >>>>>>>>> >>>>>>>>> This is great guys. Is there a way to get this from the image? >>>>>>>>> Good to get >>>>>>>> >>>>>>>> it >>>>>>>>> >>>>>>>>> with an FFI/OSProcess call or something. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>>>>>>>>> >>>>>>>>>> Hi Guys, >>>>>>>>>> >>>>>>>>>> How about getting the CPU temperature. I think most CPUs >>>>>>>>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I >>>>>>>>>> think it is seven bits. The real range should be less than >>>>>>>>>> that but it may be enough to help add some entropy. >>>>>>>>>> >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>>>>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Ron , nice to see you too! It has been a number of years, >>>>>>>>>>> hasn't >>>> it? >>>>>>>>>>> Crypto is timestamped back in 2010, so there is is. I hope >>>>>>>>>>> these have been kind years to you, as they have for me. >>>>>>>>>>> >>>>>>>>>>> I love the idea of optional sources of entropy, depending on >>>>>>>>>>> the deployed capabilities. So there are our mouse points and >>>>>>>>>>> such, because they ought to be optional. >>>>>>>>>>> >>>>>>>>>>> What are some reliably present sources in the most minimal >>>>>> situation? >>>>>>>>>>> If we could define minimal as an image with no image level I/O >>>>>>>>>>> beyond file I/O, I would think we'd have: Kernel, System, >>>>>>>>>>> Collections, Compiler and FFI. Some intransitives in that >>>>>>>>>>> scope for entropy would be >>>>>>>>> >>>>>>>>> grand. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I was thinking to take 5 millisecondClockValues, separated by >>>>>>>>>>> 4 non-secure random intervals: take the low order byte of the >>>>>>>>>>> 4 intervals and reverse & concat them, as a entropic source. >>>>>>>>>>> >>>>>>>>>>> I can coordinate these changes. Ron, could you add me to the >>>>>>>>>>> Cryptography team so I can upload the Pharo Cryptography >>>>>>>>> >>>>>>>>> #bleedingEdge? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks and I look forward to more, :) >>>>>>>>>>> >>>>>>>>>>> Robert >>>>>>>>>>> >>>>>>>>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Robert, >>>>>>>>>>>> >>>>>>>>>>>> Nice to see you! >>>>>>>>>>>> >>>>>>>>>>>> Looks interesting I know that Chris did something gathering >>>>>>>>>>>> sources of >>>>>>>>> >>>>>>>>> entropy. Seems like the more the better. Could you just make >>>>>>>>> the entropy sources optional such that if they exist we use them? >>>>>>>>> I would have to go back and see what Chris did but he was >>>>>>>>> following suggestions from Schneider in his secureRandom. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> All the best, >>>>>>>>>>>> >>>>>>>>>>>> Ron Teitelbaum >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] >>>>>>>>>>>>> On Behalf Of Robert Withers >>>>>>>>>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>>>>>>>>> To: The general-purpose Squeak developers list; Pharo >>>>>>>>>>>>> Development List >>>>>>>>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>>>>>>>>> RandomGenerator >>>>>>>>>>>>> class>>unpredictableStringsDo: >>>>>>>>>>>>> >>>>>>>>>>>>> I'm sorry, I forgot the code. I list the existing method, >>>>>>>>>>>>> followed by my modified Pharo method below. I welcome any >>>>>> feedback. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> Existing: >>>>>>>>>>>>> unpredictableStringsDo: aBlock >>>>>>>>>>>>> "Enumerate sources of information from my >>>>>>>>>>>>> environment that >>>>>>>>> >>>>>>>>> should >>>>>>>>>>>>> >>>>>>>>>>>>> be generally hard to guess." >>>>>>>>>>>>> | time | >>>>>>>>>>>>> time := Time millisecondsToRun: >>>>>>>>>>>>> [ aBlock >>>>>>>>>>>>> value: World imageForm bits >>>>>>>>>>>>> compressToByteArray ; >>>>>>>>>>>>> value: Sensor mousePoint x asString ; >>>>>>>>>>>>> value: Sensor mousePoint y asString ; >>>>>>>>>>>>> value: Time millisecondClockValue >>>>>>>>>>>>> asByteArray ; >>>>>>>>>>>>> value: Date today asString ; >>>>>>>>>>>>> value: Time now asString ; >>>>>>>>>>>>> value: Display extent asString. >>>>>>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>>>>>>>> #(vmVersion platformName primVmPath >>>>>>>>>>>>> imageName >>>>>>>>> >>>>>>>>> platformSubtype >>>>>>>>>>>>> >>>>>>>>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>>>>>>>>> imageName) >>>>>>>>>>>>> collect: >>>>>>>>>>>>> [ : each | >>>>>>>>>>>>> aBlock value: (SmalltalkImage >>>>>>>>>>>>> current >>>>>>>>>>>>> perform: each) >>>>>>>>> >>>>>>>>> asByteArray >>>>>>>>>>>>> >>>>>>>>>>>>> ] ]. >>>>>>>>>>>>> aBlock >>>>>>>>>>>>> value: time asByteArray; >>>>>>>>>>>>> "maybe the pointer has moved, hit it again." >>>>>>>>>>>>> value: Sensor mousePoint asString ; >>>>>>>>>>>>> value: Time millisecondClockValue >>>>>>>>>>>>> asByteArray >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> Pharo port: >>>>>>>>>>>>> unpredictableStringsDo: aBlock >>>>>>>>>>>>> "Enumerate sources of information from my >>>>>>>>>>>>> environment that >>>>>>>>> >>>>>>>>> should >>>>>>>>>>>>> >>>>>>>>>>>>> be generally hard to guess." >>>>>>>>>>>>> >>>>>>>>>>>>> | time | >>>>>>>>>>>>> time := Time millisecondsToRun: >>>>>>>>>>>>> [ aBlock >>>>>>>>>>>>> value: Time millisecondClockValue >>>>>>>>>>>>> asByteArray ; >>>>>>>>>>>>> value: Date today asString ; >>>>>>>>>>>>> value: Time now asString. >>>>>>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>>>>>>>> #(version primImagePath imagePath >>>>>>>>>>>>> datedVersion >>>>>>>>>>>>> lastQuitLogPosition) >>>>>>>>>>>>> collect: >>>>>>>>>>>>> [ : each | >>>>>>>>>>>>> aBlock value: (SmalltalkImage >>>>>>>>>>>>> current >>>>>>>>>>>>> perform: each) >>>>>>>>> >>>>>>>>> asByteArray >>>>>>>>>>>>> >>>>>>>>>>>>> ] ]. >>>>>>>>>>>>> aBlock >>>>>>>>>>>>> value: time asByteArray; >>>>>>>>>>>>> value: Time millisecondClockValue >>>>>>>>>>>>> asByteArray >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a message intended for anyone who was on the >>>>>>>>>>>>>> Cryptography >>>>>>>>> >>>>>>>>> team. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I recently ported it to Pharo and had to make changes to >>>>>>>>>>>>> >>>>>>>>>>>>> RandomGenerator >>>>>>>>>>>>>> >>>>>>>>>>>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>>>>>>>>>>> class>>uncertainty >>>>>>>>>>>>>> from the results of this message. My question is what >>>>>>>>>>>>>> should I do about that? This method seems to require >>>>>>>>>>>>>> non-headless, as it is checking the mouse point and such. >>>>>>>>>>>>>> This being a crypto cornerstone, what the best answer here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> ----------------------------------------------------------- >>>>>>>>>> Louis LaBrunda >>>>>>>>>> Keystone Software Corp. >>>>>>>>>> SkypeMe callto://PhotonDemon >>>>>>>>>> mailto:Lou@Keystone-Software.com http://www.Keystone- >>>>>> Software.com >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > >

Oct. 20, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Robert Withers

Hi Ben, ... ^^ robert On 10/19/2015 11:06 AM, Ben Coman wrote: > > On Mon, Oct 19, 2015 at 7:55 PM, Robert Withers > <robert.w.withers(a)gmail.com> wrote: >> >> Thank you for your response, Ben. I'm here to help where I may be helpful, >> so let me know where. I have interest in the Pi and the ARM simulator was >> expressed as an area needing more resources. 64-bit is the strategic effort, >> so if I can help. > > You may find these interesting... > * http://forum.world.st/ARM-Cog-progress-td4827195.html > * http://markmail.org/message/tfqa4lgriw6xchh3 > * http://www.slideshare.net/esug/pharo-arm-status Thank you, their in my vm list of reading. > >> I'd hope we could agree that whether is goes 64-bit then MT (which is what's >> up) or MT then 64-bit (as I was so rashly suggesting) there will be an >> integration cost. > > Agreed, but I guess the former shares that cost amongst more people. Yes, good point. I am happy with having the MY discussion, only at this time, and helping the broader effort as you point out so that cost is less. > >> As 64-bit is a Spur ObjectMemory effort and MT is a >> process/stack oriented facet, are they not orthogonal and fairly >> non-interfering, aside from a few touch points. If there is integration >> cost, why not proceed in parallel? > > Naturally you'll get more support working in an area where the vm devs > *need* more help, but I can't judge this. I'm not familiar with what > the interference points might be. > Maybe this helps... > http://lists.squeakfoundation.org/pipermail/vm-dev/2014-October/016781.html Thank you again, for later consumption. > >> Certainly the discussion about what exactly MT is seems alright. > > Sure. MT has several meanings. Its good to scope a common understanding. Yes, it's good. > >> I'm guessing the answer to that you have mentioned: resources. We need a >> bunch of hardcore CompSci students to catch the fire. >> >> Please let me know where I can help best. Rapport is key to team, this I >> have experienced. > > I learn a lot listening in on [vm-dev], but I've still only dabbled > around the fringe of the vm. The best reference is Eliot overall and > Esteban from a Pharo perspective. > btw, have you seen... > * http://www.mirandabanda.org/cogblog/cog-projects/ I had seen those. Sista sounds interesting as does an event vm. Isn't the event vm solved by the MTVM? Cheers, Robert > > cheers -ben > > >> Regards, >> Robert >> >> >> On 10/18/2015 11:56 AM, Ben Coman wrote: >>> >>> >>> On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers >>> <robert.w.withers(a)gmail.com> wrote: >>>> >>>> Yes, exactly. I do realize I was consciously changing that effort >>>> synchronization order. >>> >>> >>> I see 64-bit being higher priority than multi-threaded for the wider >>> community. Dealing with larger in-Image data opens the door to more >>> corporate project/funding opportunities. Also simplifying the install >>> on modern Linux platforms without requiring additional 386 libraries >>> will help acceptance there. >>> >>>> It is my humble opinion, without really knowing, that 64-bit would have >>>> to be redone after the MTVM completes. >>> >>> >>> I would assume it was the other way around. Presuming that Eliot has >>> sponsors influencing his priorities, it seems given that 64-bits will >>> happen first. I would guess any MTVM development on the old vm would >>> then need to be reworked. >>> >>>> I was doing so with the idea in mind that I and others >>>> might dig into working on the VM, for threading support, while Eliot >>>> maintains focus on 64-bits...a tall order, I know. >>> >>> >>> The usual downside of splitting resources applies. There are not that >>> many "others" and maybe they would be drawn away from helping with the >>> 64-bit vm. If the 64-bit vm goes slower for lack of resources then >>> your footing for MTVM will shifting for a longer time. You may >>> ultimately get where you want to go faster by helping with the 64-bit >>> vm. The rapport built with other vm devs from working on 64-bit might >>> could then be applied to MTVM. (Of course, its your free time, so you >>> should pursue what interests you.) >>> >>>> I was barely familiar with the VM, slang, interpreter, it years ago... >>>> I'm totally unfamiliar with cog. >>> >>> >>> The experience you gain from working beside Esteban and Eliot on >>> 64-bit Cog/Spur could then be applied to a MTVM. >>> >>> btw, you may find these threads interesting... >>> * >>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/10864… >>> * >>> http://forum.world.st/Copy-on-write-for-a-multithreaded-VM-td4837905.html >>> >>> cheers -ben >>> >>>> I believe another item on that list ought to be modernizing slang. So >>>> many big items! >>>> >>>> Robert >>>> >>>> On 10/16/2015 12:48 PM, Stephan Eggermont wrote: >>>>> >>>>> On 16-10-15 14:05, Robert Withers wrote: >>>>>> >>>>>> >>>>>> Because of that assumption I've made and without the responsibilities >>>>>> you have, Esteban, but recognizing modernizing NB to FFI, my desired >>>>>> list is: >>>>> >>>>> I would expect the least total effort to be needed by keeping the work >>>>> of Esteban and Eliot as much as possible aligned. That is what Esteban's >>>>> list achieves. >>>>> >>>>> Stephan

Oct. 19, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Robert Withers

Hi Eliot, ... ^^ robert On 10/19/2015 10:10 AM, Eliot Miranda wrote: > > Hi Robert, > > _,,,^..^,,,_ (phone) > > On Oct 19, 2015, at 5:03 AM, Robert Withers <robert.w.withers(a)gmail.com > <mailto:robert.w.withers@gmail.com>> wrote: > >> Could you please help me by talking further about the different models >> and scopes of what is meant by MT? >> >> a) MT-FFI I believe gives the developer a way to call and be invoked >> on callback, asynchronously. Is it so? > > It's a bit more than that. It is the sharing of the VM between > different threads, but only allowing one thread to own the VM at any one > time, changing ownership in call out or Smalltalk process switch time. > This approach provides interleaved concurrency but not parallelism in > your Smalltalk code and it means the Smalltalk class library doesn't > have to be made thread-safe, which as Esteban said is a huge task. > > See > http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/038943.ht… > > and google "eliot Miranda Simmons own thread" to find more messages. > > >> b) General MTVM means other system services are threaded, like I/O >> events and scheduling and heartbeat. > > No; at least not in my opinion. In the standard single-threaded VM the > heartbeat is ideally a thread (it can be an interval timer, but that's > problematic; system calls get interrupted), and maybe an incremental > global GC could be in its own thread. > > So I'm defining the MTVM to be the sharing of the VM between threads, I apologize if I am off the rails again, Eliot. I must watch that. Let's see if I can express it right. I think, not entirely sure mind you, that I am talking about single threading the image and not sharing the VM between different threads. I need to read the links you provided and hopefully you'd welcome discussion about alternatives, long as it doesn't consume your needed time; that's your discretion, I acknowledge. Why change owners of the vm process and deal with thread contention edge cases? If you put a Elib-style vat in the core of the vm and run a single-osthread instance image, you get hydra, soft virtual semaphores, threaded FFI and real virtualization, as all external vat communication must go through the vats' queue. All plugins would have to be changed to talk through the scheduling queue as pointers to function calls, sort of thing - continuations queue? Perhaps outbound calls as well so no thread-safing the plugins... > and /not/ just the use of threads to implement non-Smalltalk sub tasks I suppose I'm thinking of it more as this, yet it seems your goal is to not have to thread safe the plugins, which is safe & reliable. This I understand. Perhaps both are possible, by placing a queue in front of every thread, preparatory or sensory worker threads or main image thread. This is where I'm at with my thinking. I'd welcome your thoughts. > of the VM, and /not/ a full-blown multithreaded Smalltalk VM providing I see this as an escalation of your idea, surely too much and violating encapsulation of decentralization. I think shared memory is bad and copyOnWrite sort of thing is much better. Yet perhaps in some cases. Do all store bytecodes lock the page they access? > concurrent execution of Smalltalk processes in parallel. Hydra is with separate threads for separate images, isn't it? A new Hydra, with an elib vm automatically gets this if we enforce all inter-vat communications go through each vat's queue. Does the question come down to complexity, then? May be too much. > >> I think that the right model (my stack/priQueue/pool intuition?) will >> change a Herculean task into a fairly straightfoward task and >> achievable. Change the problem, to get better answers. > > This has been well thought through and discussed. The definition above > is very useful. It provides a system that can inter operate with > concurrent code without having to implement a system that provides > parallelism. It is used in David Simmons' VMs for S# etc and a similar > (but less performant) scheme is available in Python VMs. I would love to learn more about it. > > Please, let's get this scheme working first. I'm not at all happy > (read, extremely unhappy) that there is not much focus on working > together to get our current VM to an excellent state and instead lots of > work on other VMs that is speculative and a long way away from being > production ready. Thank you for discussing and defining multi-threading; I welcome it. Thanks as well for the task specification... I put this together, with a few details from some of the other emails, mostly sub-tasks. However, I did not see ARM or Pharo modernization on the list, so I added those. You'll find a Word doc and pdf attached, thank you! This is most beneficial to have a bird's eye view. So I added the "Current items in play" ... We have a huge amount of work to do on Cog: > > - event-driven VM (that hence costs 0% processor time at idle) > - 64-bits (x64 and ARM and...?) > - Sista adaptive optimizer > - FFI via dynamic generation of marshaling code, as required for > efficient and correct call outs on x64 > - MTVM as defined above > - an incremental global mark-sweep GC for Spur > - running on Xen/Unikernels/containers > - providing a JavaScript plugin to proved rendering and events so we can > run an efficient VM in a web browser > - a port of the Interpreter/Context VM to Spur > > IMO, things that can /and should/ wait are > - throwing away Slang and providing a true written-in-pure-Smalltalk VM > that is self-bootstrapped a la Gerardo Richarte and Xavier Burroni > - a truly parallel multi/threaded VM > > and things we shouldn't go anywhere near are > - using libffi > - targeting JavaScript, Java or any other dynamic language de jour that > happens to run in a web browser but either provides abysmal performance > or doesn't support full Smalltalk semantics > - implementing the VM in other VM frameworks such as PyPy which simply > strengthens that community and weakens our own > > Right now there are only a handful of people who make commits to the VM > and three who are "full time", and we're all overloaded. But the VM is > the base of the pillar and if we want to provide high-quality solutions > that people will pay money to use we have to have a high-quality VM. In > Spur we have a VM that is significantly faster that VW, and very > reliable. In Sista we will have a system that is much faster and can be > improved upon for years to come and a system that can migrate to future > VMs (because it is mostly Smalltalk), and useful support for a high > quality FFI. People like have stepped up and made significant > contributions to give us what is a respectable VM that is on an arc to > providing a really high-quality production Smalltalk VM written in > Smalltalk produced by a very small community. But it is now 2015 and > Cog started 7 years ago. All the work on other VMs, deployment platforms > etc, IMO dilutes and delays in delivering to our community a truly > world-class VM that we can compete with against Java HotSpot, node.js > v8, lua luajit, factor, swift et al. Please get on board. We'd love the > help and we can guarantee you'll have fun and you can guarantee you'll > have an impact. What else can man want in life that the opportunity to take up challenges when life so graciously lays these obstacles in one's path. It stuns me what you all have done. Truly amazing the targets and varieties you offer. A smÃ¶rgÃ¥sbord of multiple generated VMs. Amazing. Unless you feel otherwise, I think I will focus on 2, 4 & 5 of the current items: - 64-bit vm support - MTVM discussions - Pharo support and modernization I love Pharo and what they have done and are doing - it's fantastic and I want to make an impact there as well. They really need FileDirectory, though, if only a wrapper, as compatibility code for VMMaker.oscog. :) > >> >> I appreciate you and this MT discussion. Thank you , Robert >> >> >>> Said that: >>> >>> - What is in plans is MT-FFI, and that will be available eventually. >>> - There is an approach I want to re-work, that would allow us profit >>> of multicores without going multithread: the âhydraâ experiment made >>> some years ago by Igor creates a good basis to this. But is also a >>> lot of of work (but a lot less than a complete MT), and not a real >>> priority for nowâ¦ I hope to resume work on that area some dayâ¦ just >>> not anytime soon. >> >> Yes, please. I recall those discussions. Hydra is cosmological. >> >> Regards, >> Robert >> >>> >>> Esteban >>> >>>> On 18 Oct 2015, at 17:56, Ben Coman <btc(a)openInWorld.com >>>> <mailto:btc@openinworld.com>> wrote: >>>> >>>> >>>> On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers >>>> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: >>>>> Yes, exactly. I do realize I was consciously changing that effort >>>>> synchronization order. >>>> >>>> I see 64-bit being higher priority than multi-threaded for the wider >>>> community. Dealing with larger in-Image data opens the door to more >>>> corporate project/funding opportunities. Also simplifying the install >>>> on modern Linux platforms without requiring additional 386 libraries >>>> will help acceptance there. >>>> >>>>> It is my humble opinion, without really knowing, that 64-bit would >>>>> have to be redone after the MTVM completes. >>>> >>>> I would assume it was the other way around. Presuming that Eliot has >>>> sponsors influencing his priorities, it seems given that 64-bits will >>>> happen first. I would guess any MTVM development on the old vm would >>>> then need to be reworked. >>>> >>>>> I was doing so with the idea in mind that I and others >>>>> might dig into working on the VM, for threading support, while Eliot >>>>> maintains focus on 64-bits...a tall order, I know. >>>> >>>> The usual downside of splitting resources applies. There are not that >>>> many "others" and maybe they would be drawn away from helping with the >>>> 64-bit vm. If the 64-bit vm goes slower for lack of resources then >>>> your footing for MTVM will shifting for a longer time. You may >>>> ultimately get where you want to go faster by helping with the 64-bit >>>> vm. The rapport built with other vm devs from working on 64-bit might >>>> could then be applied to MTVM. (Of course, its your free time, so you >>>> should pursue what interests you.) >>>> >>>>> I was barely familiar with the VM, slang, interpreter, it years ago... >>>>> I'm totally unfamiliar with cog. >>>> >>>> The experience you gain from working beside Esteban and Eliot on >>>> 64-bit Cog/Spur could then be applied to a MTVM. >>>> >>>> btw, you may find these threads interesting... >>>> * >>>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/10864… >>>> * >>>> http://forum.world.st/Copy-on-write-for-a-multithreaded-VM-td4837905.html >>>> >>>> cheers -ben >>>> >>>>> I believe another item on that list ought to be modernizing slang. So >>>>> many big items! >>>>> >>>>> Robert >>>>> >>>>> >>>>> >>>>> On 10/16/2015 12:48 PM, Stephan Eggermont wrote: >>>>>> >>>>>> >>>>>> On 16-10-15 14:05, Robert Withers wrote: >>>>>>> >>>>>>> Because of that assumption I've made and without the responsibilities >>>>>>> you have, Esteban, but recognizing modernizing NB to FFI, my desired >>>>>>> list is: >>>>>> >>>>>> >>>>>> I would expect the least total effort to be needed by keeping the work >>>>>> of Esteban and Eliot as much as possible aligned. That is what >>>>>> Esteban's >>>>>> list achieves. >>>>>> >>>>>> Stephan >>>>>> >>>>>> >>>>> >>>

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Ron Teitelbaum

Hi Robert, I went back and reviewed and this is what I sent to BIS. http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/00011… Not much to it but we got a lot of advice from SFLC first. >From our research OS projects are allowed to host cryptographic code and make available for anyone to download. BUT that does not exclude users of the code from being restrained from exporting that code to any USA identified restricted entities. For example: http://www.state.gov/j/ct/list/c14151.htm I would recommend at the very least to register the repo with the BIS for Pharo, but I would also contact the SFLC to verify nothing has changed. All the best, Ron > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of > Robert Withers > Sent: Monday, October 19, 2015 5:28 PM > To: The general-purpose Squeak developers list; 'Chris Muller' > Cc: 'Pharo Development List' > Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] > RandomGenerator class>>unpredictableStringsDo: > > (resending with Pharo list) > > Ron, would it be an easy process to add a second URL to the exception > paperwork. Pharo does have new ideas about code storage and distribution > that we would want to take advantage of. This would help a lot! > > Then again, screw their paperwork requirements of us. Put my name as > responsible on the Pharo code and I'll take a trip to Cuba, if they need a > scape goat for their 20th century thinking. Crypto is already out of the bag > and everyone uses it freely. Just do it and ask permission later. > > In thinking about consolidating crypto code between squeak and pharo, I > would guess there would be a thin capatibility layer for each system, then > the Crypto code in the main. My goal is to have compatibility, crypto and > plugins on both virtual platforms. > > Thanks so much ^^ > > Robert > > On 10/19/2015 05:17 PM, Ron Teitelbaum wrote: > > Hi Chris, > > > > The exemption is not for the location of the server but the URL where it is > hosted. I'm happy to help in any way I can but I don't have access to the > Pharo Repos. I have no issue with having Pharo packages on SqueakSource if > that is what everyone agrees too. We have multiple packages hosted there. > It's ok with me if we host some pharo code there too. > > > > All the best, > > > > Ron > > > >> -----Original Message----- > >> From: Chris Muller [mailto:ma.chris.m@gmail.com] > >> Sent: Monday, October 19, 2015 3:59 PM > >> To: Ron Teitelbaum > >> Cc: Pharo Development List; The general-purpose Squeak developers > >> list > >> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] > >> RandomGenerator class>>unpredictableStringsDo: > >> > >> Heh, well, since then SqueakSource itself was moved to a different > >> server in a different country. I guess there was also a mirror of > >> SqueakSource hosted in Chile under a different URL for many years. > >> > >> I'm doubtful any of it matters, but we wouldn't want anyone to end up > >> in Gitmo over it. If you're uncomfortable about hosting a copy > >> elsewhere, then please at least namespace-prefix the Pharo-specific > >> packages, to at least help keep it from becoming a tangled mess. > >> > >> On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum <ron(a)usmedrec.com> > >> wrote: > >>> Hi All, > >>> > >>> Unless someone filed the proper paperwork I would suggest NOT moving > >> the cryptography code anywhere except for SqueakSource. When we > >> started the project we spent time ensuring that we had a proper > >> exemption from the U.S. regulations on exporting cryptographic code. > >> If someone copied and forked the code that exemption may not still > >> apply to that new repository. > >>> > >>> I'm not personally involved with the code on Pharo, not sure who is > >>> doing > >> crypto there. > >>> > >>> All the best, > >>> > >>> Ron > >>> > >>>> -----Original Message----- > >>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On > >>>> Behalf Of Chris Muller > >>>> Sent: Monday, October 19, 2015 2:47 PM > >>>> To: The general-purpose Squeak developers list > >>>> Cc: Pharo Development List > >>>> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] > >>>> RandomGenerator class>>unpredictableStringsDo: > >>>> > >>>> Yes, if a common package for both Squeak and Pharo is possible, > >>>> that'd be great. Otherwise, the Squeak and Pharo versions should > >>>> reside in separate repositories. Squeak users are still using > >>>> squeaksource.com, Pharo moved to smalltalkhub and beyond.. > >>>> > >>>> On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers > >>>> <robert.w.withers(a)gmail.com> wrote: > >>>>> hey Ron, > >>>>> > >>>>> It was actually the Pharo Cryptography team I was thinking of. > >>>>> Perhaps we can get the same package to work in both squeak and > >>>>> Pharo, with use of installable entropy sources or the like. In > >>>>> order to get SqueakElib running in Pharo I need crypto and we may > >>>>> as > >> well do it right. > >>>>> > >>>>> Cheers, > >>>>> Robert > >>>>> > >>>>> > >>>>> On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: > >>>>>> > >>>>>> Hi Robert, > >>>>>> > >>>>>> You are already on the Cryptograph repo on SqueakSource.com as an > >>>> admin. > >>>>>> Please feel free to reorg if you like. > >>>>>> > >>>>>> Let me know if you have trouble resurrecting your account. > >>>>>> > >>>>>> All the best, > >>>>>> > >>>>>> Ron > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: squeak-dev-bounces(a)lists.squeakfoundation.org > >>>>>>> [mailto:squeak-dev- bounces(a)lists.squeakfoundation.org] On > >>>>>>> Behalf Of Robert Withers > >>>>>>> Sent: Monday, October 19, 2015 1:53 PM > >>>>>>> To: squeak-dev(a)lists.squeakfoundation.org > >>>>>>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to > >>>>>>> Pharo] RandomGenerator class>>unpredictableStringsDo: > >>>>>>> > >>>>>>> This is great guys. Is there a way to get this from the image? > >>>>>>> Good to get > >>>>>> > >>>>>> it > >>>>>>> > >>>>>>> with an FFI/OSProcess call or something. > >>>>>>> > >>>>>>> Thank you, > >>>>>>> Robert > >>>>>>> > >>>>>>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: > >>>>>>>> > >>>>>>>> Hi Guys, > >>>>>>>> > >>>>>>>> How about getting the CPU temperature. I think most CPUs > >>>>>>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I > >>>>>>>> think it is seven bits. The real range should be less than > >>>>>>>> that but it may be enough to help add some entropy. > >>>>>>>> > >>>>>>>> Lou > >>>>>>>> > >>>>>>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers > >>>>>>>> <robert.w.withers(a)gmail.com> wrote: > >>>>>>>> > >>>>>>>>> Hi Ron , nice to see you too! It has been a number of years, > >>>>>>>>> hasn't > >> it? > >>>>>>>>> Crypto is timestamped back in 2010, so there is is. I hope > >>>>>>>>> these have been kind years to you, as they have for me. > >>>>>>>>> > >>>>>>>>> I love the idea of optional sources of entropy, depending on > >>>>>>>>> the deployed capabilities. So there are our mouse points and > >>>>>>>>> such, because they ought to be optional. > >>>>>>>>> > >>>>>>>>> What are some reliably present sources in the most minimal > >>>> situation? > >>>>>>>>> If we could define minimal as an image with no image level I/O > >>>>>>>>> beyond file I/O, I would think we'd have: Kernel, System, > >>>>>>>>> Collections, Compiler and FFI. Some intransitives in that > >>>>>>>>> scope for entropy would be > >>>>>>> > >>>>>>> grand. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I was thinking to take 5 millisecondClockValues, separated by > >>>>>>>>> 4 non-secure random intervals: take the low order byte of the > >>>>>>>>> 4 intervals and reverse & concat them, as a entropic source. > >>>>>>>>> > >>>>>>>>> I can coordinate these changes. Ron, could you add me to the > >>>>>>>>> Cryptography team so I can upload the Pharo Cryptography > >>>>>>> > >>>>>>> #bleedingEdge? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks and I look forward to more, :) > >>>>>>>>> > >>>>>>>>> Robert > >>>>>>>>> > >>>>>>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: > >>>>>>>>>> > >>>>>>>>>> Hi Robert, > >>>>>>>>>> > >>>>>>>>>> Nice to see you! > >>>>>>>>>> > >>>>>>>>>> Looks interesting I know that Chris did something gathering > >>>>>>>>>> sources of > >>>>>>> > >>>>>>> entropy. Seems like the more the better. Could you just make > >>>>>>> the entropy sources optional such that if they exist we use them? > >>>>>>> I would have to go back and see what Chris did but he was > >>>>>>> following suggestions from Schneider in his secureRandom. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> All the best, > >>>>>>>>>> > >>>>>>>>>> Ron Teitelbaum > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] > >>>>>>>>>>> On Behalf Of Robert Withers > >>>>>>>>>>> Sent: Sunday, October 18, 2015 5:00 AM > >>>>>>>>>>> To: The general-purpose Squeak developers list; Pharo > >>>>>>>>>>> Development List > >>>>>>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] > >>>>>>>>>>> RandomGenerator > >>>>>>>>>>> class>>unpredictableStringsDo: > >>>>>>>>>>> > >>>>>>>>>>> I'm sorry, I forgot the code. I list the existing method, > >>>>>>>>>>> followed by my modified Pharo method below. I welcome any > >>>> feedback. > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Robert > >>>>>>>>>>> > >>>>>>>>>>> --- > >>>>>>>>>>> Existing: > >>>>>>>>>>> unpredictableStringsDo: aBlock > >>>>>>>>>>> "Enumerate sources of information from my > >>>>>>>>>>> environment that > >>>>>>> > >>>>>>> should > >>>>>>>>>>> > >>>>>>>>>>> be generally hard to guess." > >>>>>>>>>>> | time | > >>>>>>>>>>> time := Time millisecondsToRun: > >>>>>>>>>>> [ aBlock > >>>>>>>>>>> value: World imageForm bits > >>>>>>>>>>> compressToByteArray ; > >>>>>>>>>>> value: Sensor mousePoint x asString ; > >>>>>>>>>>> value: Sensor mousePoint y asString ; > >>>>>>>>>>> value: Time millisecondClockValue > >>>>>>>>>>> asByteArray ; > >>>>>>>>>>> value: Date today asString ; > >>>>>>>>>>> value: Time now asString ; > >>>>>>>>>>> value: Display extent asString. > >>>>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. > >>>>>>>>>>> #(vmVersion platformName primVmPath > >>>>>>>>>>> imageName > >>>>>>> > >>>>>>> platformSubtype > >>>>>>>>>>> > >>>>>>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString > >>>>>>>>>>> imageName) > >>>>>>>>>>> collect: > >>>>>>>>>>> [ : each | > >>>>>>>>>>> aBlock value: (SmalltalkImage > >>>>>>>>>>> current > >>>>>>>>>>> perform: each) > >>>>>>> > >>>>>>> asByteArray > >>>>>>>>>>> > >>>>>>>>>>> ] ]. > >>>>>>>>>>> aBlock > >>>>>>>>>>> value: time asByteArray; > >>>>>>>>>>> "maybe the pointer has moved, hit it again." > >>>>>>>>>>> value: Sensor mousePoint asString ; > >>>>>>>>>>> value: Time millisecondClockValue > >>>>>>>>>>> asByteArray > >>>>>>>>>>> > >>>>>>>>>>> --- > >>>>>>>>>>> Pharo port: > >>>>>>>>>>> unpredictableStringsDo: aBlock > >>>>>>>>>>> "Enumerate sources of information from my > >>>>>>>>>>> environment that > >>>>>>> > >>>>>>> should > >>>>>>>>>>> > >>>>>>>>>>> be generally hard to guess." > >>>>>>>>>>> > >>>>>>>>>>> | time | > >>>>>>>>>>> time := Time millisecondsToRun: > >>>>>>>>>>> [ aBlock > >>>>>>>>>>> value: Time millisecondClockValue > >>>>>>>>>>> asByteArray ; > >>>>>>>>>>> value: Date today asString ; > >>>>>>>>>>> value: Time now asString. > >>>>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. > >>>>>>>>>>> #(version primImagePath imagePath > >>>>>>>>>>> datedVersion > >>>>>>>>>>> lastQuitLogPosition) > >>>>>>>>>>> collect: > >>>>>>>>>>> [ : each | > >>>>>>>>>>> aBlock value: (SmalltalkImage > >>>>>>>>>>> current > >>>>>>>>>>> perform: each) > >>>>>>> > >>>>>>> asByteArray > >>>>>>>>>>> > >>>>>>>>>>> ] ]. > >>>>>>>>>>> aBlock > >>>>>>>>>>> value: time asByteArray; > >>>>>>>>>>> value: Time millisecondClockValue > >>>>>>>>>>> asByteArray > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> This is a message intended for anyone who was on the > >>>>>>>>>>>> Cryptography > >>>>>>> > >>>>>>> team. > >>>>>>>>>>>> > >>>>>>>>>>>> I recently ported it to Pharo and had to make changes to > >>>>>>>>>>> > >>>>>>>>>>> RandomGenerator > >>>>>>>>>>>> > >>>>>>>>>>>> class>>unpredictableStringsDo:. This certainly removed some > >>>>>>>>>>>> class>>uncertainty > >>>>>>>>>>>> from the results of this message. My question is what > >>>>>>>>>>>> should I do about that? This method seems to require > >>>>>>>>>>>> non-headless, as it is checking the mouse point and such. > >>>>>>>>>>>> This being a crypto cornerstone, what the best answer here. > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you, > >>>>>>>>>>>> Robert > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> ----------------------------------------------------------- > >>>>>>>> Louis LaBrunda > >>>>>>>> Keystone Software Corp. > >>>>>>>> SkypeMe callto://PhotonDemon > >>>>>>>> mailto:Lou@Keystone-Software.com http://www.Keystone- > >>>> Software.com > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>> > >>> > > > >

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Robert Withers

(resending with Pharo list) Ron, would it be an easy process to add a second URL to the exception paperwork. Pharo does have new ideas about code storage and distribution that we would want to take advantage of. This would help a lot! Then again, screw their paperwork requirements of us. Put my name as responsible on the Pharo code and I'll take a trip to Cuba, if they need a scape goat for their 20th century thinking. Crypto is already out of the bag and everyone uses it freely. Just do it and ask permission later. In thinking about consolidating crypto code between squeak and pharo, I would guess there would be a thin capatibility layer for each system, then the Crypto code in the main. My goal is to have compatibility, crypto and plugins on both virtual platforms. Thanks so much ^^ Robert On 10/19/2015 05:17 PM, Ron Teitelbaum wrote: > Hi Chris, > > The exemption is not for the location of the server but the URL where it is hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple packages hosted there. It's ok with me if we host some pharo code there too. > > All the best, > > Ron > >> -----Original Message----- >> From: Chris Muller [mailto:ma.chris.m@gmail.com] >> Sent: Monday, October 19, 2015 3:59 PM >> To: Ron Teitelbaum >> Cc: Pharo Development List; The general-purpose Squeak developers list >> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] >> RandomGenerator class>>unpredictableStringsDo: >> >> Heh, well, since then SqueakSource itself was moved to a different server in >> a different country. I guess there was also a mirror of SqueakSource hosted >> in Chile under a different URL for many years. >> >> I'm doubtful any of it matters, but we wouldn't want anyone to end up in >> Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then >> please at least namespace-prefix the Pharo-specific packages, to at least help >> keep it from becoming a tangled mess. >> >> On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum <ron(a)usmedrec.com> >> wrote: >>> Hi All, >>> >>> Unless someone filed the proper paperwork I would suggest NOT moving >> the cryptography code anywhere except for SqueakSource. When we started >> the project we spent time ensuring that we had a proper exemption from >> the U.S. regulations on exporting cryptographic code. If someone copied >> and forked the code that exemption may not still apply to that new >> repository. >>> >>> I'm not personally involved with the code on Pharo, not sure who is doing >> crypto there. >>> >>> All the best, >>> >>> Ron >>> >>>> -----Original Message----- >>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf >>>> Of Chris Muller >>>> Sent: Monday, October 19, 2015 2:47 PM >>>> To: The general-purpose Squeak developers list >>>> Cc: Pharo Development List >>>> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] >>>> RandomGenerator class>>unpredictableStringsDo: >>>> >>>> Yes, if a common package for both Squeak and Pharo is possible, >>>> that'd be great. Otherwise, the Squeak and Pharo versions should >>>> reside in separate repositories. Squeak users are still using >>>> squeaksource.com, Pharo moved to smalltalkhub and beyond.. >>>> >>>> On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers >>>> <robert.w.withers(a)gmail.com> wrote: >>>>> hey Ron, >>>>> >>>>> It was actually the Pharo Cryptography team I was thinking of. >>>>> Perhaps we can get the same package to work in both squeak and >>>>> Pharo, with use of installable entropy sources or the like. In >>>>> order to get SqueakElib running in Pharo I need crypto and we may as >> well do it right. >>>>> >>>>> Cheers, >>>>> Robert >>>>> >>>>> >>>>> On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: >>>>>> >>>>>> Hi Robert, >>>>>> >>>>>> You are already on the Cryptograph repo on SqueakSource.com as an >>>> admin. >>>>>> Please feel free to reorg if you like. >>>>>> >>>>>> Let me know if you have trouble resurrecting your account. >>>>>> >>>>>> All the best, >>>>>> >>>>>> Ron >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: squeak-dev-bounces(a)lists.squeakfoundation.org >>>>>>> [mailto:squeak-dev- bounces(a)lists.squeakfoundation.org] On Behalf >>>>>>> Of Robert Withers >>>>>>> Sent: Monday, October 19, 2015 1:53 PM >>>>>>> To: squeak-dev(a)lists.squeakfoundation.org >>>>>>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to >>>>>>> Pharo] RandomGenerator class>>unpredictableStringsDo: >>>>>>> >>>>>>> This is great guys. Is there a way to get this from the image? >>>>>>> Good to get >>>>>> >>>>>> it >>>>>>> >>>>>>> with an FFI/OSProcess call or something. >>>>>>> >>>>>>> Thank you, >>>>>>> Robert >>>>>>> >>>>>>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>>>>>>> >>>>>>>> Hi Guys, >>>>>>>> >>>>>>>> How about getting the CPU temperature. I think most CPUs >>>>>>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I >>>>>>>> think it is seven bits. The real range should be less than that >>>>>>>> but it may be enough to help add some entropy. >>>>>>>> >>>>>>>> Lou >>>>>>>> >>>>>>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Ron , nice to see you too! It has been a number of years, hasn't >> it? >>>>>>>>> Crypto is timestamped back in 2010, so there is is. I hope >>>>>>>>> these have been kind years to you, as they have for me. >>>>>>>>> >>>>>>>>> I love the idea of optional sources of entropy, depending on >>>>>>>>> the deployed capabilities. So there are our mouse points and >>>>>>>>> such, because they ought to be optional. >>>>>>>>> >>>>>>>>> What are some reliably present sources in the most minimal >>>> situation? >>>>>>>>> If we could define minimal as an image with no image level I/O >>>>>>>>> beyond file I/O, I would think we'd have: Kernel, System, >>>>>>>>> Collections, Compiler and FFI. Some intransitives in that scope >>>>>>>>> for entropy would be >>>>>>> >>>>>>> grand. >>>>>>>>> >>>>>>>>> >>>>>>>>> I was thinking to take 5 millisecondClockValues, separated by 4 >>>>>>>>> non-secure random intervals: take the low order byte of the 4 >>>>>>>>> intervals and reverse & concat them, as a entropic source. >>>>>>>>> >>>>>>>>> I can coordinate these changes. Ron, could you add me to the >>>>>>>>> Cryptography team so I can upload the Pharo Cryptography >>>>>>> >>>>>>> #bleedingEdge? >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks and I look forward to more, :) >>>>>>>>> >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>>>>>>> >>>>>>>>>> Hi Robert, >>>>>>>>>> >>>>>>>>>> Nice to see you! >>>>>>>>>> >>>>>>>>>> Looks interesting I know that Chris did something gathering >>>>>>>>>> sources of >>>>>>> >>>>>>> entropy. Seems like the more the better. Could you just make >>>>>>> the entropy sources optional such that if they exist we use them? >>>>>>> I would have to go back and see what Chris did but he was >>>>>>> following suggestions from Schneider in his secureRandom. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> All the best, >>>>>>>>>> >>>>>>>>>> Ron Teitelbaum >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >>>>>>>>>>> Behalf Of Robert Withers >>>>>>>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>>>>>>> To: The general-purpose Squeak developers list; Pharo >>>>>>>>>>> Development List >>>>>>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>>>>>>> RandomGenerator >>>>>>>>>>> class>>unpredictableStringsDo: >>>>>>>>>>> >>>>>>>>>>> I'm sorry, I forgot the code. I list the existing method, >>>>>>>>>>> followed by my modified Pharo method below. I welcome any >>>> feedback. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Robert >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> Existing: >>>>>>>>>>> unpredictableStringsDo: aBlock >>>>>>>>>>> "Enumerate sources of information from my environment >>>>>>>>>>> that >>>>>>> >>>>>>> should >>>>>>>>>>> >>>>>>>>>>> be generally hard to guess." >>>>>>>>>>> | time | >>>>>>>>>>> time := Time millisecondsToRun: >>>>>>>>>>> [ aBlock >>>>>>>>>>> value: World imageForm bits >>>>>>>>>>> compressToByteArray ; >>>>>>>>>>> value: Sensor mousePoint x asString ; >>>>>>>>>>> value: Sensor mousePoint y asString ; >>>>>>>>>>> value: Time millisecondClockValue >>>>>>>>>>> asByteArray ; >>>>>>>>>>> value: Date today asString ; >>>>>>>>>>> value: Time now asString ; >>>>>>>>>>> value: Display extent asString. >>>>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>>>>>> #(vmVersion platformName primVmPath imageName >>>>>>> >>>>>>> platformSubtype >>>>>>>>>>> >>>>>>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>>>>>>> imageName) >>>>>>>>>>> collect: >>>>>>>>>>> [ : each | >>>>>>>>>>> aBlock value: (SmalltalkImage current >>>>>>>>>>> perform: each) >>>>>>> >>>>>>> asByteArray >>>>>>>>>>> >>>>>>>>>>> ] ]. >>>>>>>>>>> aBlock >>>>>>>>>>> value: time asByteArray; >>>>>>>>>>> "maybe the pointer has moved, hit it again." >>>>>>>>>>> value: Sensor mousePoint asString ; >>>>>>>>>>> value: Time millisecondClockValue asByteArray >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> Pharo port: >>>>>>>>>>> unpredictableStringsDo: aBlock >>>>>>>>>>> "Enumerate sources of information from my environment >>>>>>>>>>> that >>>>>>> >>>>>>> should >>>>>>>>>>> >>>>>>>>>>> be generally hard to guess." >>>>>>>>>>> >>>>>>>>>>> | time | >>>>>>>>>>> time := Time millisecondsToRun: >>>>>>>>>>> [ aBlock >>>>>>>>>>> value: Time millisecondClockValue >>>>>>>>>>> asByteArray ; >>>>>>>>>>> value: Date today asString ; >>>>>>>>>>> value: Time now asString. >>>>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>>>>>> #(version primImagePath imagePath >>>>>>>>>>> datedVersion >>>>>>>>>>> lastQuitLogPosition) >>>>>>>>>>> collect: >>>>>>>>>>> [ : each | >>>>>>>>>>> aBlock value: (SmalltalkImage current >>>>>>>>>>> perform: each) >>>>>>> >>>>>>> asByteArray >>>>>>>>>>> >>>>>>>>>>> ] ]. >>>>>>>>>>> aBlock >>>>>>>>>>> value: time asByteArray; >>>>>>>>>>> value: Time millisecondClockValue asByteArray >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>>>>>>> >>>>>>>>>>>> This is a message intended for anyone who was on the >>>>>>>>>>>> Cryptography >>>>>>> >>>>>>> team. >>>>>>>>>>>> >>>>>>>>>>>> I recently ported it to Pharo and had to make changes to >>>>>>>>>>> >>>>>>>>>>> RandomGenerator >>>>>>>>>>>> >>>>>>>>>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>>>>>>>>> class>>uncertainty >>>>>>>>>>>> from the results of this message. My question is what should >>>>>>>>>>>> I do about that? This method seems to require non-headless, >>>>>>>>>>>> as it is checking the mouse point and such. This being a >>>>>>>>>>>> crypto cornerstone, what the best answer here. >>>>>>>>>>>> >>>>>>>>>>>> Thank you, >>>>>>>>>>>> Robert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> ----------------------------------------------------------- >>>>>>>> Louis LaBrunda >>>>>>>> Keystone Software Corp. >>>>>>>> SkypeMe callto://PhotonDemon >>>>>>>> mailto:Lou@Keystone-Software.com http://www.Keystone- >>>> Software.com >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>> >>> > >

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Ron Teitelbaum

Hi Chris, The exemption is not for the location of the server but the URL where it is hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple packages hosted there. It's ok with me if we host some pharo code there too. All the best, Ron > -----Original Message----- > From: Chris Muller [mailto:ma.chris.m@gmail.com] > Sent: Monday, October 19, 2015 3:59 PM > To: Ron Teitelbaum > Cc: Pharo Development List; The general-purpose Squeak developers list > Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] > RandomGenerator class>>unpredictableStringsDo: > > Heh, well, since then SqueakSource itself was moved to a different server in > a different country. I guess there was also a mirror of SqueakSource hosted > in Chile under a different URL for many years. > > I'm doubtful any of it matters, but we wouldn't want anyone to end up in > Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then > please at least namespace-prefix the Pharo-specific packages, to at least help > keep it from becoming a tangled mess. > > On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum <ron(a)usmedrec.com> > wrote: > > Hi All, > > > > Unless someone filed the proper paperwork I would suggest NOT moving > the cryptography code anywhere except for SqueakSource. When we started > the project we spent time ensuring that we had a proper exemption from > the U.S. regulations on exporting cryptographic code. If someone copied > and forked the code that exemption may not still apply to that new > repository. > > > > I'm not personally involved with the code on Pharo, not sure who is doing > crypto there. > > > > All the best, > > > > Ron > > > >> -----Original Message----- > >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf > >> Of Chris Muller > >> Sent: Monday, October 19, 2015 2:47 PM > >> To: The general-purpose Squeak developers list > >> Cc: Pharo Development List > >> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] > >> RandomGenerator class>>unpredictableStringsDo: > >> > >> Yes, if a common package for both Squeak and Pharo is possible, > >> that'd be great. Otherwise, the Squeak and Pharo versions should > >> reside in separate repositories. Squeak users are still using > >> squeaksource.com, Pharo moved to smalltalkhub and beyond.. > >> > >> On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers > >> <robert.w.withers(a)gmail.com> wrote: > >> > hey Ron, > >> > > >> > It was actually the Pharo Cryptography team I was thinking of. > >> > Perhaps we can get the same package to work in both squeak and > >> > Pharo, with use of installable entropy sources or the like. In > >> > order to get SqueakElib running in Pharo I need crypto and we may as > well do it right. > >> > > >> > Cheers, > >> > Robert > >> > > >> > > >> > On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: > >> >> > >> >> Hi Robert, > >> >> > >> >> You are already on the Cryptograph repo on SqueakSource.com as an > >> admin. > >> >> Please feel free to reorg if you like. > >> >> > >> >> Let me know if you have trouble resurrecting your account. > >> >> > >> >> All the best, > >> >> > >> >> Ron > >> >> > >> >>> -----Original Message----- > >> >>> From: squeak-dev-bounces(a)lists.squeakfoundation.org > >> >>> [mailto:squeak-dev- bounces(a)lists.squeakfoundation.org] On Behalf > >> >>> Of Robert Withers > >> >>> Sent: Monday, October 19, 2015 1:53 PM > >> >>> To: squeak-dev(a)lists.squeakfoundation.org > >> >>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to > >> >>> Pharo] RandomGenerator class>>unpredictableStringsDo: > >> >>> > >> >>> This is great guys. Is there a way to get this from the image? > >> >>> Good to get > >> >> > >> >> it > >> >>> > >> >>> with an FFI/OSProcess call or something. > >> >>> > >> >>> Thank you, > >> >>> Robert > >> >>> > >> >>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: > >> >>>> > >> >>>> Hi Guys, > >> >>>> > >> >>>> How about getting the CPU temperature. I think most CPUs > >> >>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I > >> >>>> think it is seven bits. The real range should be less than that > >> >>>> but it may be enough to help add some entropy. > >> >>>> > >> >>>> Lou > >> >>>> > >> >>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers > >> >>>> <robert.w.withers(a)gmail.com> wrote: > >> >>>> > >> >>>>> Hi Ron , nice to see you too! It has been a number of years, hasn't > it? > >> >>>>> Crypto is timestamped back in 2010, so there is is. I hope > >> >>>>> these have been kind years to you, as they have for me. > >> >>>>> > >> >>>>> I love the idea of optional sources of entropy, depending on > >> >>>>> the deployed capabilities. So there are our mouse points and > >> >>>>> such, because they ought to be optional. > >> >>>>> > >> >>>>> What are some reliably present sources in the most minimal > >> situation? > >> >>>>> If we could define minimal as an image with no image level I/O > >> >>>>> beyond file I/O, I would think we'd have: Kernel, System, > >> >>>>> Collections, Compiler and FFI. Some intransitives in that scope > >> >>>>> for entropy would be > >> >>> > >> >>> grand. > >> >>>>> > >> >>>>> > >> >>>>> I was thinking to take 5 millisecondClockValues, separated by 4 > >> >>>>> non-secure random intervals: take the low order byte of the 4 > >> >>>>> intervals and reverse & concat them, as a entropic source. > >> >>>>> > >> >>>>> I can coordinate these changes. Ron, could you add me to the > >> >>>>> Cryptography team so I can upload the Pharo Cryptography > >> >>> > >> >>> #bleedingEdge? > >> >>>>> > >> >>>>> > >> >>>>> Thanks and I look forward to more, :) > >> >>>>> > >> >>>>> Robert > >> >>>>> > >> >>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: > >> >>>>>> > >> >>>>>> Hi Robert, > >> >>>>>> > >> >>>>>> Nice to see you! > >> >>>>>> > >> >>>>>> Looks interesting I know that Chris did something gathering > >> >>>>>> sources of > >> >>> > >> >>> entropy. Seems like the more the better. Could you just make > >> >>> the entropy sources optional such that if they exist we use them? > >> >>> I would have to go back and see what Chris did but he was > >> >>> following suggestions from Schneider in his secureRandom. > >> >>>>>> > >> >>>>>> > >> >>>>>> All the best, > >> >>>>>> > >> >>>>>> Ron Teitelbaum > >> >>>>>> > >> >>>>>>> -----Original Message----- > >> >>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On > >> >>>>>>> Behalf Of Robert Withers > >> >>>>>>> Sent: Sunday, October 18, 2015 5:00 AM > >> >>>>>>> To: The general-purpose Squeak developers list; Pharo > >> >>>>>>> Development List > >> >>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] > >> >>>>>>> RandomGenerator > >> >>>>>>> class>>unpredictableStringsDo: > >> >>>>>>> > >> >>>>>>> I'm sorry, I forgot the code. I list the existing method, > >> >>>>>>> followed by my modified Pharo method below. I welcome any > >> feedback. > >> >>>>>>> > >> >>>>>>> Regards, > >> >>>>>>> Robert > >> >>>>>>> > >> >>>>>>> --- > >> >>>>>>> Existing: > >> >>>>>>> unpredictableStringsDo: aBlock > >> >>>>>>> "Enumerate sources of information from my environment > >> >>>>>>> that > >> >>> > >> >>> should > >> >>>>>>> > >> >>>>>>> be generally hard to guess." > >> >>>>>>> | time | > >> >>>>>>> time := Time millisecondsToRun: > >> >>>>>>> [ aBlock > >> >>>>>>> value: World imageForm bits > >> >>>>>>> compressToByteArray ; > >> >>>>>>> value: Sensor mousePoint x asString ; > >> >>>>>>> value: Sensor mousePoint y asString ; > >> >>>>>>> value: Time millisecondClockValue > >> >>>>>>> asByteArray ; > >> >>>>>>> value: Date today asString ; > >> >>>>>>> value: Time now asString ; > >> >>>>>>> value: Display extent asString. > >> >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. > >> >>>>>>> #(vmVersion platformName primVmPath imageName > >> >>> > >> >>> platformSubtype > >> >>>>>>> > >> >>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString > >> >>>>>>> imageName) > >> >>>>>>> collect: > >> >>>>>>> [ : each | > >> >>>>>>> aBlock value: (SmalltalkImage current > >> >>>>>>> perform: each) > >> >>> > >> >>> asByteArray > >> >>>>>>> > >> >>>>>>> ] ]. > >> >>>>>>> aBlock > >> >>>>>>> value: time asByteArray; > >> >>>>>>> "maybe the pointer has moved, hit it again." > >> >>>>>>> value: Sensor mousePoint asString ; > >> >>>>>>> value: Time millisecondClockValue asByteArray > >> >>>>>>> > >> >>>>>>> --- > >> >>>>>>> Pharo port: > >> >>>>>>> unpredictableStringsDo: aBlock > >> >>>>>>> "Enumerate sources of information from my environment > >> >>>>>>> that > >> >>> > >> >>> should > >> >>>>>>> > >> >>>>>>> be generally hard to guess." > >> >>>>>>> > >> >>>>>>> | time | > >> >>>>>>> time := Time millisecondsToRun: > >> >>>>>>> [ aBlock > >> >>>>>>> value: Time millisecondClockValue > >> >>>>>>> asByteArray ; > >> >>>>>>> value: Date today asString ; > >> >>>>>>> value: Time now asString. > >> >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. > >> >>>>>>> #(version primImagePath imagePath > >> >>>>>>> datedVersion > >> >>>>>>> lastQuitLogPosition) > >> >>>>>>> collect: > >> >>>>>>> [ : each | > >> >>>>>>> aBlock value: (SmalltalkImage current > >> >>>>>>> perform: each) > >> >>> > >> >>> asByteArray > >> >>>>>>> > >> >>>>>>> ] ]. > >> >>>>>>> aBlock > >> >>>>>>> value: time asByteArray; > >> >>>>>>> value: Time millisecondClockValue asByteArray > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: > >> >>>>>>>> > >> >>>>>>>> This is a message intended for anyone who was on the > >> >>>>>>>> Cryptography > >> >>> > >> >>> team. > >> >>>>>>>> > >> >>>>>>>> I recently ported it to Pharo and had to make changes to > >> >>>>>>> > >> >>>>>>> RandomGenerator > >> >>>>>>>> > >> >>>>>>>> class>>unpredictableStringsDo:. This certainly removed some > >> >>>>>>>> class>>uncertainty > >> >>>>>>>> from the results of this message. My question is what should > >> >>>>>>>> I do about that? This method seems to require non-headless, > >> >>>>>>>> as it is checking the mouse point and such. This being a > >> >>>>>>>> crypto cornerstone, what the best answer here. > >> >>>>>>>> > >> >>>>>>>> Thank you, > >> >>>>>>>> Robert > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>>> ----------------------------------------------------------- > >> >>>> Louis LaBrunda > >> >>>> Keystone Software Corp. > >> >>>> SkypeMe callto://PhotonDemon > >> >>>> mailto:Lou@Keystone-Software.com http://www.Keystone- > >> Software.com > >> >>>> > >> >>>> > >> >> > >> >> > >> >> > >> > > > > >

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Chris Muller

Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years. I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess. On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum <ron(a)usmedrec.com> wrote: > Hi All, > > Unless someone filed the proper paperwork I would suggest NOT moving the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository. > > I'm not personally involved with the code on Pharo, not sure who is doing crypto there. > > All the best, > > Ron > >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Chris Muller >> Sent: Monday, October 19, 2015 2:47 PM >> To: The general-purpose Squeak developers list >> Cc: Pharo Development List >> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] >> RandomGenerator class>>unpredictableStringsDo: >> >> Yes, if a common package for both Squeak and Pharo is possible, that'd be >> great. Otherwise, the Squeak and Pharo versions should reside in separate >> repositories. Squeak users are still using squeaksource.com, Pharo moved to >> smalltalkhub and beyond.. >> >> On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers >> <robert.w.withers(a)gmail.com> wrote: >> > hey Ron, >> > >> > It was actually the Pharo Cryptography team I was thinking of. Perhaps >> > we can get the same package to work in both squeak and Pharo, with use >> > of installable entropy sources or the like. In order to get SqueakElib >> > running in Pharo I need crypto and we may as well do it right. >> > >> > Cheers, >> > Robert >> > >> > >> > On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: >> >> >> >> Hi Robert, >> >> >> >> You are already on the Cryptograph repo on SqueakSource.com as an >> admin. >> >> Please feel free to reorg if you like. >> >> >> >> Let me know if you have trouble resurrecting your account. >> >> >> >> All the best, >> >> >> >> Ron >> >> >> >>> -----Original Message----- >> >>> From: squeak-dev-bounces(a)lists.squeakfoundation.org >> >>> [mailto:squeak-dev- bounces(a)lists.squeakfoundation.org] On Behalf Of >> >>> Robert Withers >> >>> Sent: Monday, October 19, 2015 1:53 PM >> >>> To: squeak-dev(a)lists.squeakfoundation.org >> >>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to Pharo] >> >>> RandomGenerator class>>unpredictableStringsDo: >> >>> >> >>> This is great guys. Is there a way to get this from the image? Good >> >>> to get >> >> >> >> it >> >>> >> >>> with an FFI/OSProcess call or something. >> >>> >> >>> Thank you, >> >>> Robert >> >>> >> >>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >> >>>> >> >>>> Hi Guys, >> >>>> >> >>>> How about getting the CPU temperature. I think most CPUs support >> >>>> "Digital Thermal Sensor" (I'm not sure about ARM). I think it is >> >>>> seven bits. The real range should be less than that but it may be >> >>>> enough to help add some entropy. >> >>>> >> >>>> Lou >> >>>> >> >>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >> >>>> <robert.w.withers(a)gmail.com> wrote: >> >>>> >> >>>>> Hi Ron , nice to see you too! It has been a number of years, hasn't it? >> >>>>> Crypto is timestamped back in 2010, so there is is. I hope these >> >>>>> have been kind years to you, as they have for me. >> >>>>> >> >>>>> I love the idea of optional sources of entropy, depending on the >> >>>>> deployed capabilities. So there are our mouse points and such, >> >>>>> because they ought to be optional. >> >>>>> >> >>>>> What are some reliably present sources in the most minimal >> situation? >> >>>>> If we could define minimal as an image with no image level I/O >> >>>>> beyond file I/O, I would think we'd have: Kernel, System, >> >>>>> Collections, Compiler and FFI. Some intransitives in that scope >> >>>>> for entropy would be >> >>> >> >>> grand. >> >>>>> >> >>>>> >> >>>>> I was thinking to take 5 millisecondClockValues, separated by 4 >> >>>>> non-secure random intervals: take the low order byte of the 4 >> >>>>> intervals and reverse & concat them, as a entropic source. >> >>>>> >> >>>>> I can coordinate these changes. Ron, could you add me to the >> >>>>> Cryptography team so I can upload the Pharo Cryptography >> >>> >> >>> #bleedingEdge? >> >>>>> >> >>>>> >> >>>>> Thanks and I look forward to more, :) >> >>>>> >> >>>>> Robert >> >>>>> >> >>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >> >>>>>> >> >>>>>> Hi Robert, >> >>>>>> >> >>>>>> Nice to see you! >> >>>>>> >> >>>>>> Looks interesting I know that Chris did something gathering >> >>>>>> sources of >> >>> >> >>> entropy. Seems like the more the better. Could you just make the >> >>> entropy sources optional such that if they exist we use them? I >> >>> would have to go back and see what Chris did but he was following >> >>> suggestions from Schneider in his secureRandom. >> >>>>>> >> >>>>>> >> >>>>>> All the best, >> >>>>>> >> >>>>>> Ron Teitelbaum >> >>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >> >>>>>>> Behalf Of Robert Withers >> >>>>>>> Sent: Sunday, October 18, 2015 5:00 AM >> >>>>>>> To: The general-purpose Squeak developers list; Pharo >> >>>>>>> Development List >> >>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >> >>>>>>> RandomGenerator >> >>>>>>> class>>unpredictableStringsDo: >> >>>>>>> >> >>>>>>> I'm sorry, I forgot the code. I list the existing method, >> >>>>>>> followed by my modified Pharo method below. I welcome any >> feedback. >> >>>>>>> >> >>>>>>> Regards, >> >>>>>>> Robert >> >>>>>>> >> >>>>>>> --- >> >>>>>>> Existing: >> >>>>>>> unpredictableStringsDo: aBlock >> >>>>>>> "Enumerate sources of information from my environment >> >>>>>>> that >> >>> >> >>> should >> >>>>>>> >> >>>>>>> be generally hard to guess." >> >>>>>>> | time | >> >>>>>>> time := Time millisecondsToRun: >> >>>>>>> [ aBlock >> >>>>>>> value: World imageForm bits >> >>>>>>> compressToByteArray ; >> >>>>>>> value: Sensor mousePoint x asString ; >> >>>>>>> value: Sensor mousePoint y asString ; >> >>>>>>> value: Time millisecondClockValue >> >>>>>>> asByteArray ; >> >>>>>>> value: Date today asString ; >> >>>>>>> value: Time now asString ; >> >>>>>>> value: Display extent asString. >> >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >> >>>>>>> #(vmVersion platformName primVmPath imageName >> >>> >> >>> platformSubtype >> >>>>>>> >> >>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >> >>>>>>> imageName) >> >>>>>>> collect: >> >>>>>>> [ : each | >> >>>>>>> aBlock value: (SmalltalkImage current >> >>>>>>> perform: each) >> >>> >> >>> asByteArray >> >>>>>>> >> >>>>>>> ] ]. >> >>>>>>> aBlock >> >>>>>>> value: time asByteArray; >> >>>>>>> "maybe the pointer has moved, hit it again." >> >>>>>>> value: Sensor mousePoint asString ; >> >>>>>>> value: Time millisecondClockValue asByteArray >> >>>>>>> >> >>>>>>> --- >> >>>>>>> Pharo port: >> >>>>>>> unpredictableStringsDo: aBlock >> >>>>>>> "Enumerate sources of information from my environment >> >>>>>>> that >> >>> >> >>> should >> >>>>>>> >> >>>>>>> be generally hard to guess." >> >>>>>>> >> >>>>>>> | time | >> >>>>>>> time := Time millisecondsToRun: >> >>>>>>> [ aBlock >> >>>>>>> value: Time millisecondClockValue >> >>>>>>> asByteArray ; >> >>>>>>> value: Date today asString ; >> >>>>>>> value: Time now asString. >> >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >> >>>>>>> #(version primImagePath imagePath datedVersion >> >>>>>>> lastQuitLogPosition) >> >>>>>>> collect: >> >>>>>>> [ : each | >> >>>>>>> aBlock value: (SmalltalkImage current >> >>>>>>> perform: each) >> >>> >> >>> asByteArray >> >>>>>>> >> >>>>>>> ] ]. >> >>>>>>> aBlock >> >>>>>>> value: time asByteArray; >> >>>>>>> value: Time millisecondClockValue asByteArray >> >>>>>>> >> >>>>>>> >> >>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >> >>>>>>>> >> >>>>>>>> This is a message intended for anyone who was on the >> >>>>>>>> Cryptography >> >>> >> >>> team. >> >>>>>>>> >> >>>>>>>> I recently ported it to Pharo and had to make changes to >> >>>>>>> >> >>>>>>> RandomGenerator >> >>>>>>>> >> >>>>>>>> class>>unpredictableStringsDo:. This certainly removed some >> >>>>>>>> class>>uncertainty >> >>>>>>>> from the results of this message. My question is what should I >> >>>>>>>> do about that? This method seems to require non-headless, as it >> >>>>>>>> is checking the mouse point and such. This being a crypto >> >>>>>>>> cornerstone, what the best answer here. >> >>>>>>>> >> >>>>>>>> Thank you, >> >>>>>>>> Robert >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>> ----------------------------------------------------------- >> >>>> Louis LaBrunda >> >>>> Keystone Software Corp. >> >>>> SkypeMe callto://PhotonDemon >> >>>> mailto:Lou@Keystone-Software.com http://www.Keystone- >> Software.com >> >>>> >> >>>> >> >> >> >> >> >> >> > > >

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Ron Teitelbaum

Hi All, Unless someone filed the proper paperwork I would suggest NOT moving the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository. I'm not personally involved with the code on Pharo, not sure who is doing crypto there. All the best, Ron > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of > Chris Muller > Sent: Monday, October 19, 2015 2:47 PM > To: The general-purpose Squeak developers list > Cc: Pharo Development List > Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] > RandomGenerator class>>unpredictableStringsDo: > > Yes, if a common package for both Squeak and Pharo is possible, that'd be > great. Otherwise, the Squeak and Pharo versions should reside in separate > repositories. Squeak users are still using squeaksource.com, Pharo moved to > smalltalkhub and beyond.. > > On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers > <robert.w.withers(a)gmail.com> wrote: > > hey Ron, > > > > It was actually the Pharo Cryptography team I was thinking of. Perhaps > > we can get the same package to work in both squeak and Pharo, with use > > of installable entropy sources or the like. In order to get SqueakElib > > running in Pharo I need crypto and we may as well do it right. > > > > Cheers, > > Robert > > > > > > On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: > >> > >> Hi Robert, > >> > >> You are already on the Cryptograph repo on SqueakSource.com as an > admin. > >> Please feel free to reorg if you like. > >> > >> Let me know if you have trouble resurrecting your account. > >> > >> All the best, > >> > >> Ron > >> > >>> -----Original Message----- > >>> From: squeak-dev-bounces(a)lists.squeakfoundation.org > >>> [mailto:squeak-dev- bounces(a)lists.squeakfoundation.org] On Behalf Of > >>> Robert Withers > >>> Sent: Monday, October 19, 2015 1:53 PM > >>> To: squeak-dev(a)lists.squeakfoundation.org > >>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to Pharo] > >>> RandomGenerator class>>unpredictableStringsDo: > >>> > >>> This is great guys. Is there a way to get this from the image? Good > >>> to get > >> > >> it > >>> > >>> with an FFI/OSProcess call or something. > >>> > >>> Thank you, > >>> Robert > >>> > >>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: > >>>> > >>>> Hi Guys, > >>>> > >>>> How about getting the CPU temperature. I think most CPUs support > >>>> "Digital Thermal Sensor" (I'm not sure about ARM). I think it is > >>>> seven bits. The real range should be less than that but it may be > >>>> enough to help add some entropy. > >>>> > >>>> Lou > >>>> > >>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers > >>>> <robert.w.withers(a)gmail.com> wrote: > >>>> > >>>>> Hi Ron , nice to see you too! It has been a number of years, hasn't it? > >>>>> Crypto is timestamped back in 2010, so there is is. I hope these > >>>>> have been kind years to you, as they have for me. > >>>>> > >>>>> I love the idea of optional sources of entropy, depending on the > >>>>> deployed capabilities. So there are our mouse points and such, > >>>>> because they ought to be optional. > >>>>> > >>>>> What are some reliably present sources in the most minimal > situation? > >>>>> If we could define minimal as an image with no image level I/O > >>>>> beyond file I/O, I would think we'd have: Kernel, System, > >>>>> Collections, Compiler and FFI. Some intransitives in that scope > >>>>> for entropy would be > >>> > >>> grand. > >>>>> > >>>>> > >>>>> I was thinking to take 5 millisecondClockValues, separated by 4 > >>>>> non-secure random intervals: take the low order byte of the 4 > >>>>> intervals and reverse & concat them, as a entropic source. > >>>>> > >>>>> I can coordinate these changes. Ron, could you add me to the > >>>>> Cryptography team so I can upload the Pharo Cryptography > >>> > >>> #bleedingEdge? > >>>>> > >>>>> > >>>>> Thanks and I look forward to more, :) > >>>>> > >>>>> Robert > >>>>> > >>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: > >>>>>> > >>>>>> Hi Robert, > >>>>>> > >>>>>> Nice to see you! > >>>>>> > >>>>>> Looks interesting I know that Chris did something gathering > >>>>>> sources of > >>> > >>> entropy. Seems like the more the better. Could you just make the > >>> entropy sources optional such that if they exist we use them? I > >>> would have to go back and see what Chris did but he was following > >>> suggestions from Schneider in his secureRandom. > >>>>>> > >>>>>> > >>>>>> All the best, > >>>>>> > >>>>>> Ron Teitelbaum > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On > >>>>>>> Behalf Of Robert Withers > >>>>>>> Sent: Sunday, October 18, 2015 5:00 AM > >>>>>>> To: The general-purpose Squeak developers list; Pharo > >>>>>>> Development List > >>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] > >>>>>>> RandomGenerator > >>>>>>> class>>unpredictableStringsDo: > >>>>>>> > >>>>>>> I'm sorry, I forgot the code. I list the existing method, > >>>>>>> followed by my modified Pharo method below. I welcome any > feedback. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Robert > >>>>>>> > >>>>>>> --- > >>>>>>> Existing: > >>>>>>> unpredictableStringsDo: aBlock > >>>>>>> "Enumerate sources of information from my environment > >>>>>>> that > >>> > >>> should > >>>>>>> > >>>>>>> be generally hard to guess." > >>>>>>> | time | > >>>>>>> time := Time millisecondsToRun: > >>>>>>> [ aBlock > >>>>>>> value: World imageForm bits > >>>>>>> compressToByteArray ; > >>>>>>> value: Sensor mousePoint x asString ; > >>>>>>> value: Sensor mousePoint y asString ; > >>>>>>> value: Time millisecondClockValue > >>>>>>> asByteArray ; > >>>>>>> value: Date today asString ; > >>>>>>> value: Time now asString ; > >>>>>>> value: Display extent asString. > >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. > >>>>>>> #(vmVersion platformName primVmPath imageName > >>> > >>> platformSubtype > >>>>>>> > >>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString > >>>>>>> imageName) > >>>>>>> collect: > >>>>>>> [ : each | > >>>>>>> aBlock value: (SmalltalkImage current > >>>>>>> perform: each) > >>> > >>> asByteArray > >>>>>>> > >>>>>>> ] ]. > >>>>>>> aBlock > >>>>>>> value: time asByteArray; > >>>>>>> "maybe the pointer has moved, hit it again." > >>>>>>> value: Sensor mousePoint asString ; > >>>>>>> value: Time millisecondClockValue asByteArray > >>>>>>> > >>>>>>> --- > >>>>>>> Pharo port: > >>>>>>> unpredictableStringsDo: aBlock > >>>>>>> "Enumerate sources of information from my environment > >>>>>>> that > >>> > >>> should > >>>>>>> > >>>>>>> be generally hard to guess." > >>>>>>> > >>>>>>> | time | > >>>>>>> time := Time millisecondsToRun: > >>>>>>> [ aBlock > >>>>>>> value: Time millisecondClockValue > >>>>>>> asByteArray ; > >>>>>>> value: Date today asString ; > >>>>>>> value: Time now asString. > >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. > >>>>>>> #(version primImagePath imagePath datedVersion > >>>>>>> lastQuitLogPosition) > >>>>>>> collect: > >>>>>>> [ : each | > >>>>>>> aBlock value: (SmalltalkImage current > >>>>>>> perform: each) > >>> > >>> asByteArray > >>>>>>> > >>>>>>> ] ]. > >>>>>>> aBlock > >>>>>>> value: time asByteArray; > >>>>>>> value: Time millisecondClockValue asByteArray > >>>>>>> > >>>>>>> > >>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: > >>>>>>>> > >>>>>>>> This is a message intended for anyone who was on the > >>>>>>>> Cryptography > >>> > >>> team. > >>>>>>>> > >>>>>>>> I recently ported it to Pharo and had to make changes to > >>>>>>> > >>>>>>> RandomGenerator > >>>>>>>> > >>>>>>>> class>>unpredictableStringsDo:. This certainly removed some > >>>>>>>> class>>uncertainty > >>>>>>>> from the results of this message. My question is what should I > >>>>>>>> do about that? This method seems to require non-headless, as it > >>>>>>>> is checking the mouse point and such. This being a crypto > >>>>>>>> cornerstone, what the best answer here. > >>>>>>>> > >>>>>>>> Thank you, > >>>>>>>> Robert > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> ----------------------------------------------------------- > >>>> Louis LaBrunda > >>>> Keystone Software Corp. > >>>> SkypeMe callto://PhotonDemon > >>>> mailto:Lou@Keystone-Software.com http://www.Keystone- > Software.com > >>>> > >>>> > >> > >> > >> > >

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Chris Muller

Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond.. On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > hey Ron, > > It was actually the Pharo Cryptography team I was thinking of. Perhaps we > can get the same package to work in both squeak and Pharo, with use of > installable entropy sources or the like. In order to get SqueakElib running > in Pharo I need crypto and we may as well do it right. > > Cheers, > Robert > > > On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: >> >> Hi Robert, >> >> You are already on the Cryptograph repo on SqueakSource.com as an admin. >> Please feel free to reorg if you like. >> >> Let me know if you have trouble resurrecting your account. >> >> All the best, >> >> Ron >> >>> -----Original Message----- >>> From: squeak-dev-bounces(a)lists.squeakfoundation.org [mailto:squeak-dev- >>> bounces(a)lists.squeakfoundation.org] On Behalf Of Robert Withers >>> Sent: Monday, October 19, 2015 1:53 PM >>> To: squeak-dev(a)lists.squeakfoundation.org >>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to Pharo] >>> RandomGenerator class>>unpredictableStringsDo: >>> >>> This is great guys. Is there a way to get this from the image? Good to >>> get >> >> it >>> >>> with an FFI/OSProcess call or something. >>> >>> Thank you, >>> Robert >>> >>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>>> >>>> Hi Guys, >>>> >>>> How about getting the CPU temperature. I think most CPUs support >>>> "Digital Thermal Sensor" (I'm not sure about ARM). I think it is >>>> seven bits. The real range should be less than that but it may be >>>> enough to help add some entropy. >>>> >>>> Lou >>>> >>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>>> <robert.w.withers(a)gmail.com> wrote: >>>> >>>>> Hi Ron , nice to see you too! It has been a number of years, hasn't it? >>>>> Crypto is timestamped back in 2010, so there is is. I hope these have >>>>> been kind years to you, as they have for me. >>>>> >>>>> I love the idea of optional sources of entropy, depending on the >>>>> deployed capabilities. So there are our mouse points and such, >>>>> because they ought to be optional. >>>>> >>>>> What are some reliably present sources in the most minimal situation? >>>>> If we could define minimal as an image with no image level I/O beyond >>>>> file I/O, I would think we'd have: Kernel, System, Collections, >>>>> Compiler and FFI. Some intransitives in that scope for entropy would be >>> >>> grand. >>>>> >>>>> >>>>> I was thinking to take 5 millisecondClockValues, separated by 4 >>>>> non-secure random intervals: take the low order byte of the 4 >>>>> intervals and reverse & concat them, as a entropic source. >>>>> >>>>> I can coordinate these changes. Ron, could you add me to the >>>>> Cryptography team so I can upload the Pharo Cryptography >>> >>> #bleedingEdge? >>>>> >>>>> >>>>> Thanks and I look forward to more, :) >>>>> >>>>> Robert >>>>> >>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>>> >>>>>> Hi Robert, >>>>>> >>>>>> Nice to see you! >>>>>> >>>>>> Looks interesting I know that Chris did something gathering sources of >>> >>> entropy. Seems like the more the better. Could you just make the >>> entropy >>> sources optional such that if they exist we use them? I would have to go >>> back and see what Chris did but he was following suggestions from >>> Schneider in his secureRandom. >>>>>> >>>>>> >>>>>> All the best, >>>>>> >>>>>> Ron Teitelbaum >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >>>>>>> Behalf Of Robert Withers >>>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>>> To: The general-purpose Squeak developers list; Pharo Development >>>>>>> List >>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>>> RandomGenerator >>>>>>> class>>unpredictableStringsDo: >>>>>>> >>>>>>> I'm sorry, I forgot the code. I list the existing method, followed >>>>>>> by my modified Pharo method below. I welcome any feedback. >>>>>>> >>>>>>> Regards, >>>>>>> Robert >>>>>>> >>>>>>> --- >>>>>>> Existing: >>>>>>> unpredictableStringsDo: aBlock >>>>>>> "Enumerate sources of information from my environment that >>> >>> should >>>>>>> >>>>>>> be generally hard to guess." >>>>>>> | time | >>>>>>> time := Time millisecondsToRun: >>>>>>> [ aBlock >>>>>>> value: World imageForm bits >>>>>>> compressToByteArray ; >>>>>>> value: Sensor mousePoint x asString ; >>>>>>> value: Sensor mousePoint y asString ; >>>>>>> value: Time millisecondClockValue asByteArray >>>>>>> ; >>>>>>> value: Date today asString ; >>>>>>> value: Time now asString ; >>>>>>> value: Display extent asString. >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>> #(vmVersion platformName primVmPath imageName >>> >>> platformSubtype >>>>>>> >>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>>> imageName) >>>>>>> collect: >>>>>>> [ : each | >>>>>>> aBlock value: (SmalltalkImage current >>>>>>> perform: each) >>> >>> asByteArray >>>>>>> >>>>>>> ] ]. >>>>>>> aBlock >>>>>>> value: time asByteArray; >>>>>>> "maybe the pointer has moved, hit it again." >>>>>>> value: Sensor mousePoint asString ; >>>>>>> value: Time millisecondClockValue asByteArray >>>>>>> >>>>>>> --- >>>>>>> Pharo port: >>>>>>> unpredictableStringsDo: aBlock >>>>>>> "Enumerate sources of information from my environment that >>> >>> should >>>>>>> >>>>>>> be generally hard to guess." >>>>>>> >>>>>>> | time | >>>>>>> time := Time millisecondsToRun: >>>>>>> [ aBlock >>>>>>> value: Time millisecondClockValue asByteArray >>>>>>> ; >>>>>>> value: Date today asString ; >>>>>>> value: Time now asString. >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>> #(version primImagePath imagePath datedVersion >>>>>>> lastQuitLogPosition) >>>>>>> collect: >>>>>>> [ : each | >>>>>>> aBlock value: (SmalltalkImage current >>>>>>> perform: each) >>> >>> asByteArray >>>>>>> >>>>>>> ] ]. >>>>>>> aBlock >>>>>>> value: time asByteArray; >>>>>>> value: Time millisecondClockValue asByteArray >>>>>>> >>>>>>> >>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>>> >>>>>>>> This is a message intended for anyone who was on the Cryptography >>> >>> team. >>>>>>>> >>>>>>>> I recently ported it to Pharo and had to make changes to >>>>>>> >>>>>>> RandomGenerator >>>>>>>> >>>>>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>>>>> class>>uncertainty >>>>>>>> from the results of this message. My question is what should I do >>>>>>>> about that? This method seems to require non-headless, as it is >>>>>>>> checking the mouse point and such. This being a crypto >>>>>>>> cornerstone, what the best answer here. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Robert >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> ----------------------------------------------------------- >>>> Louis LaBrunda >>>> Keystone Software Corp. >>>> SkypeMe callto://PhotonDemon >>>> mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com >>>> >>>> >> >> >> >

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Robert Withers

hey Ron, It was actually the Pharo Cryptography team I was thinking of. Perhaps we can get the same package to work in both squeak and Pharo, with use of installable entropy sources or the like. In order to get SqueakElib running in Pharo I need crypto and we may as well do it right. Cheers, Robert On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: > Hi Robert, > > You are already on the Cryptograph repo on SqueakSource.com as an admin. > Please feel free to reorg if you like. > > Let me know if you have trouble resurrecting your account. > > All the best, > > Ron > >> -----Original Message----- >> From: squeak-dev-bounces(a)lists.squeakfoundation.org [mailto:squeak-dev- >> bounces(a)lists.squeakfoundation.org] On Behalf Of Robert Withers >> Sent: Monday, October 19, 2015 1:53 PM >> To: squeak-dev(a)lists.squeakfoundation.org >> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to Pharo] >> RandomGenerator class>>unpredictableStringsDo: >> >> This is great guys. Is there a way to get this from the image? Good to get > it >> with an FFI/OSProcess call or something. >> >> Thank you, >> Robert >> >> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>> Hi Guys, >>> >>> How about getting the CPU temperature. I think most CPUs support >>> "Digital Thermal Sensor" (I'm not sure about ARM). I think it is >>> seven bits. The real range should be less than that but it may be >>> enough to help add some entropy. >>> >>> Lou >>> >>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>> <robert.w.withers(a)gmail.com> wrote: >>> >>>> Hi Ron , nice to see you too! It has been a number of years, hasn't it? >>>> Crypto is timestamped back in 2010, so there is is. I hope these have >>>> been kind years to you, as they have for me. >>>> >>>> I love the idea of optional sources of entropy, depending on the >>>> deployed capabilities. So there are our mouse points and such, >>>> because they ought to be optional. >>>> >>>> What are some reliably present sources in the most minimal situation? >>>> If we could define minimal as an image with no image level I/O beyond >>>> file I/O, I would think we'd have: Kernel, System, Collections, >>>> Compiler and FFI. Some intransitives in that scope for entropy would be >> grand. >>>> >>>> I was thinking to take 5 millisecondClockValues, separated by 4 >>>> non-secure random intervals: take the low order byte of the 4 >>>> intervals and reverse & concat them, as a entropic source. >>>> >>>> I can coordinate these changes. Ron, could you add me to the >>>> Cryptography team so I can upload the Pharo Cryptography >> #bleedingEdge? >>>> >>>> Thanks and I look forward to more, :) >>>> >>>> Robert >>>> >>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>> Hi Robert, >>>>> >>>>> Nice to see you! >>>>> >>>>> Looks interesting I know that Chris did something gathering sources of >> entropy. Seems like the more the better. Could you just make the entropy >> sources optional such that if they exist we use them? I would have to go >> back and see what Chris did but he was following suggestions from >> Schneider in his secureRandom. >>>>> >>>>> All the best, >>>>> >>>>> Ron Teitelbaum >>>>> >>>>>> -----Original Message----- >>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >>>>>> Behalf Of Robert Withers >>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>> To: The general-purpose Squeak developers list; Pharo Development >>>>>> List >>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>> RandomGenerator >>>>>> class>>unpredictableStringsDo: >>>>>> >>>>>> I'm sorry, I forgot the code. I list the existing method, followed >>>>>> by my modified Pharo method below. I welcome any feedback. >>>>>> >>>>>> Regards, >>>>>> Robert >>>>>> >>>>>> --- >>>>>> Existing: >>>>>> unpredictableStringsDo: aBlock >>>>>> "Enumerate sources of information from my environment that >> should >>>>>> be generally hard to guess." >>>>>> | time | >>>>>> time := Time millisecondsToRun: >>>>>> [ aBlock >>>>>> value: World imageForm bits compressToByteArray ; >>>>>> value: Sensor mousePoint x asString ; >>>>>> value: Sensor mousePoint y asString ; >>>>>> value: Time millisecondClockValue asByteArray ; >>>>>> value: Date today asString ; >>>>>> value: Time now asString ; >>>>>> value: Display extent asString. >>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>> #(vmVersion platformName primVmPath imageName >> platformSubtype >>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>> imageName) >>>>>> collect: >>>>>> [ : each | >>>>>> aBlock value: (SmalltalkImage current perform: each) >> asByteArray >>>>>> ] ]. >>>>>> aBlock >>>>>> value: time asByteArray; >>>>>> "maybe the pointer has moved, hit it again." >>>>>> value: Sensor mousePoint asString ; >>>>>> value: Time millisecondClockValue asByteArray >>>>>> >>>>>> --- >>>>>> Pharo port: >>>>>> unpredictableStringsDo: aBlock >>>>>> "Enumerate sources of information from my environment that >> should >>>>>> be generally hard to guess." >>>>>> >>>>>> | time | >>>>>> time := Time millisecondsToRun: >>>>>> [ aBlock >>>>>> value: Time millisecondClockValue asByteArray ; >>>>>> value: Date today asString ; >>>>>> value: Time now asString. >>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>> #(version primImagePath imagePath datedVersion >>>>>> lastQuitLogPosition) >>>>>> collect: >>>>>> [ : each | >>>>>> aBlock value: (SmalltalkImage current perform: each) >> asByteArray >>>>>> ] ]. >>>>>> aBlock >>>>>> value: time asByteArray; >>>>>> value: Time millisecondClockValue asByteArray >>>>>> >>>>>> >>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>> This is a message intended for anyone who was on the Cryptography >> team. >>>>>>> I recently ported it to Pharo and had to make changes to >>>>>> RandomGenerator >>>>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>>>> class>>uncertainty >>>>>>> from the results of this message. My question is what should I do >>>>>>> about that? This method seems to require non-headless, as it is >>>>>>> checking the mouse point and such. This being a crypto >>>>>>> cornerstone, what the best answer here. >>>>>>> >>>>>>> Thank you, >>>>>>> Robert >>>>> >>>>> >>>>> >>>> >>> ----------------------------------------------------------- >>> Louis LaBrunda >>> Keystone Software Corp. >>> SkypeMe callto://PhotonDemon >>> mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com >>> >>> > > >

Oct. 19, 2015

Re: [Pharo-dev] Is storing a setting supposed to work in latest version?

by Juraj Kubelka

It is already integrated. Thanks Marcus! Cheers, Juraj > On Oct 19, 2015, at 12:33, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > > There is a bug: https://pharo.fogbugz.com/f/cases/16816/Storing-System-Settings-produces-er… > > Slice included. > Cheers, > Juraj > >> On Oct 19, 2015, at 12:21, stepharo <stepharo(a)free.fr> wrote: >> >> Hi guys >> >> When I press Store Setting in the Settings Browser, I get a DNU. >> How can I save a setting now? >> >> Stef >> >

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] The Trunk: System-mt.771.mcz

by Chris Muller

> I quite like being able to make several changes within the same minute because I can tell that they were related > changes. With second granularity I have no chance. Just truncate the timeStamps to whatever granularity you want to group by.. DateAndTime now asDuration truncateTo: 1 minute > Do you have a programmatic reason for wanting second granularity? I thought his case sounds compelling. Is there any harm to have finer granularity? > What to others think? Are there workflow implications to the granularity of time stamps?

Oct. 19, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50393 Home: https://github.com/pharo-project/pharo-core

Oct. 19, 2015

[pharo-project/pharo-core] d375b5: 50393

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d375b50bd1a89ed16808aece1f0525a4058a488f https://github.com/pharo-project/pharo-core/commit/d375b50bd1a89ed16808aece… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-19 (Mon, 19 Oct 2015) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/buildVariableMenuFor_variablesFrom_menuItemBy_.st M Nautilus.package/PackageTreeNodeModel.class/instance/event handling/openFloatingEditorToRenameFromNodeMorph_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50392.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50393.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50392.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50393.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Settings-Tests.package/AbstractStoredSettingTest.class/README.md A System-Settings-Tests.package/AbstractStoredSettingTest.class/definition.st A System-Settings-Tests.package/AbstractStoredSettingTest.class/instance/tests/testEqual.st A System-Settings-Tests.package/AbstractStoredSettingTest.class/instance/tests/testHash.st A System-Settings-Tests.package/AbstractStoredSettingTest.class/instance/tests/testPrintOn.st A System-Settings-Tests.package/AbstractStoredSettingTest.class/instance/tests/testPrintOn2.st A System-Settings-Tests.package/SettingBrowserTest.class/README.md A System-Settings-Tests.package/SettingBrowserTest.class/definition.st A System-Settings-Tests.package/SettingBrowserTest.class/instance/tests/testOpening.st M System-Settings-Tests.package/SystemSettingsPersistenceTest.class/instance/running/setUp.st M System-Settings-Tests.package/SystemSettingsPersistenceTest.class/instance/tests/testAllStoredSettings.st A System-Settings-Tests.package/SystemSettingsPersistenceTest.class/instance/tests/testWriteStream.st A System-Settings.package/AbstractStoredSetting.class/instance/comparing/=.st A System-Settings.package/AbstractStoredSetting.class/instance/comparing/hash.st A System-Settings.package/AbstractStoredSetting.class/instance/printing/printOn_.st R System-Settings.package/StoredSetting.class/instance/comparing/=.st R System-Settings.package/StoredSetting.class/instance/comparing/hash.st A System-Settings.package/SystemSettingsPersistence.class/instance/accessing/ensureFileReference.st M System-Settings.package/SystemSettingsPersistence.class/instance/streams/writeStream.st R System-Settings.package/SystemSettingsPersistence.class/instance/tests/testOpening.st Log Message: ----------- 50393 16816 Storing System Settings produces error when preference directory does not exist https://pharo.fogbugz.com/f/cases/16816 16809 Sort the variables from each class in the variables-menu alphabetically https://pharo.fogbugz.com/f/cases/16809 16810 Floating editor size too large for Nautilus package pane https://pharo.fogbugz.com/f/cases/16810 http://files.pharo.org/image/50/50393.zip

Oct. 19, 2015

Re: [Pharo-dev] Is storing a setting supposed to work in latest version?

by Juraj Kubelka

There is a bug: https://pharo.fogbugz.com/f/cases/16816/Storing-System-Settings-produces-er… Slice included. Cheers, Juraj > On Oct 19, 2015, at 12:21, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > When I press Store Setting in the Settings Browser, I get a DNU. > How can I save a setting now? > > Stef >

Oct. 19, 2015

Re: [Pharo-dev] Storing System Settings using STON

by Juraj Kubelka

Here it is: ClassStoredSetting ThemeIconsStoredSetting LogicalFontStoredSetting StrikeFontSetStoredSetting StrikeFontStoredSetting FileLocatorStoredSetting AbsolutePathStoredSetting RelativePathStoredSetting Cheers, Juraj > On Oct 18, 2015, at 06:20, stepharo <stepharo(a)free.fr> wrote: > > Can you past the full tree so that I understand? > > > >

Oct. 19, 2015

Re: [Pharo-dev] Storing System Settings using STON

by Juraj Kubelka

Hi, thank you for the report. Fix in the inbox: https://pharo.fogbugz.com/f/cases/16816/Storing-System-Settings-produces-er… Cheers, Juraj > On Oct 19, 2015, at 07:09, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > Le 12/10/2015 19:45, Juraj Kubelka a Ã©crit : >> Hi, >> >> we have a slice that introduce new storage solution for System Settings. >> See: https://pharo.fogbugz.com/f/cases/16681/Storing-System-Settings-using-STON >> >> You can load it using: >> >> Gofer it >> smalltalkhubUser: 'Pharo' project: 'Pharo50Inbox'; >> package: 'SLICE-Issue-16681-Storing-System-Settings-using-STON'; >> load. >> >> When you open the Setting Browser, you can see that every setting has >> new items in context menu: >> >> >> Thanks for reviewing it. >> Cheers, >> Juraj > > Hi, > > Thank you for that. > When I make store settings for the first time I have an exception on the > write stream because the file doesn't exist. I had to create the folder > 5.0 and an empty file to get it right. > In Pharo 50392 on Linux. > > I join the stack: > > FileHandle>>streamError > FileHandle>>writeStream > FileSystem>>writeStreamOn: > FileReference>>writeStream > SystemSettingsPersistence>>writeStream > SystemSettingsPersistence>>storeExactStoredSettings: > SystemSettingsPersistence>>storeStoredSettings: > SystemSettingsPersistence>>storeSettingNodes: > SystemSettingsPersistence>>storeSettingNodes > SettingTree>>storeSettingNodes > SettingBrowser>>storeSettings > PluggableButtonMorph>>performAction: > [ :m | > (m containsPoint: evt cursorPoint) > ifTrue: [ m enabled > ifTrue: [ m performAction: evt ] ] ] in > PluggableButtonMorph>>mouseUp: in Block: [ :m | ... > Array(SequenceableCollection)>>do: > PluggableButtonMorph>>mouseUp: > PluggableButtonMorph(Morph)>>handleMouseUp: > MouseButtonEvent>>sentTo: > PluggableButtonMorph(Morph)>>handleEvent: > PluggableButtonMorph(Morph)>>handleFocusEvent: > [ ActiveHand := self. > ActiveEvent := anEvent. > result := focusHolder > handleFocusEvent: > (anEvent transformedBy: (focusHolder transformedFrom: self)) ] in > HandMorph>>sendFocusEvent:to:clear: in Block: [ ActiveHand := self.... > BlockClosure>>on:do: > WorldMorph(PasteUpMorph)>>becomeActiveDuring: > HandMorph>>sendFocusEvent:to:clear: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendMouseEvent: > HandMorph>>handleEvent: > HandMorph>>processEvents > [ :h | > ActiveHand := h. > h processEvents. > ActiveHand := nil ] in WorldState>>doOneCycleNowFor: in Block: [ :h | ... > Array(SequenceableCollection)>>do: > WorldState>>handsDo: > > > -- > > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France >

Oct. 19, 2015

Is storing a setting supposed to work in latest version?

by stepharo

Hi guys When I press Store Setting in the Settings Browser, I get a DNU. How can I save a setting now? Stef

Oct. 19, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Ben Coman

On Mon, Oct 19, 2015 at 7:55 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > Thank you for your response, Ben. I'm here to help where I may be helpful, > so let me know where. I have interest in the Pi and the ARM simulator was > expressed as an area needing more resources. 64-bit is the strategic effort, > so if I can help. You may find these interesting... * http://forum.world.st/ARM-Cog-progress-td4827195.html * http://markmail.org/message/tfqa4lgriw6xchh3 * http://www.slideshare.net/esug/pharo-arm-status > I'd hope we could agree that whether is goes 64-bit then MT (which is what's > up) or MT then 64-bit (as I was so rashly suggesting) there will be an > integration cost. Agreed, but I guess the former shares that cost amongst more people. > As 64-bit is a Spur ObjectMemory effort and MT is a > process/stack oriented facet, are they not orthogonal and fairly > non-interfering, aside from a few touch points. If there is integration > cost, why not proceed in parallel? Naturally you'll get more support working in an area where the vm devs *need* more help, but I can't judge this. I'm not familiar with what the interference points might be. Maybe this helps... http://lists.squeakfoundation.org/pipermail/vm-dev/2014-October/016781.html > Certainly the discussion about what exactly MT is seems alright. Sure. MT has several meanings. Its good to scope a common understanding. > I'm guessing the answer to that you have mentioned: resources. We need a > bunch of hardcore CompSci students to catch the fire. > > Please let me know where I can help best. Rapport is key to team, this I > have experienced. I learn a lot listening in on [vm-dev], but I've still only dabbled around the fringe of the vm. The best reference is Eliot overall and Esteban from a Pharo perspective. btw, have you seen... * http://www.mirandabanda.org/cogblog/cog-projects/ cheers -ben > Regards, > Robert > > > On 10/18/2015 11:56 AM, Ben Coman wrote: >> >> >> On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers >> <robert.w.withers(a)gmail.com> wrote: >>> >>> Yes, exactly. I do realize I was consciously changing that effort >>> synchronization order. >> >> >> I see 64-bit being higher priority than multi-threaded for the wider >> community. Dealing with larger in-Image data opens the door to more >> corporate project/funding opportunities. Also simplifying the install >> on modern Linux platforms without requiring additional 386 libraries >> will help acceptance there. >> >>> It is my humble opinion, without really knowing, that 64-bit would have >>> to be redone after the MTVM completes. >> >> >> I would assume it was the other way around. Presuming that Eliot has >> sponsors influencing his priorities, it seems given that 64-bits will >> happen first. I would guess any MTVM development on the old vm would >> then need to be reworked. >> >>> I was doing so with the idea in mind that I and others >>> might dig into working on the VM, for threading support, while Eliot >>> maintains focus on 64-bits...a tall order, I know. >> >> >> The usual downside of splitting resources applies. There are not that >> many "others" and maybe they would be drawn away from helping with the >> 64-bit vm. If the 64-bit vm goes slower for lack of resources then >> your footing for MTVM will shifting for a longer time. You may >> ultimately get where you want to go faster by helping with the 64-bit >> vm. The rapport built with other vm devs from working on 64-bit might >> could then be applied to MTVM. (Of course, its your free time, so you >> should pursue what interests you.) >> >>> I was barely familiar with the VM, slang, interpreter, it years ago... >>> I'm totally unfamiliar with cog. >> >> >> The experience you gain from working beside Esteban and Eliot on >> 64-bit Cog/Spur could then be applied to a MTVM. >> >> btw, you may find these threads interesting... >> * >> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/10864… >> * >> http://forum.world.st/Copy-on-write-for-a-multithreaded-VM-td4837905.html >> >> cheers -ben >> >>> I believe another item on that list ought to be modernizing slang. So >>> many big items! >>> >>> Robert >>> >>> On 10/16/2015 12:48 PM, Stephan Eggermont wrote: >>>> >>>> On 16-10-15 14:05, Robert Withers wrote: >>>>> >>>>> >>>>> Because of that assumption I've made and without the responsibilities >>>>> you have, Esteban, but recognizing modernizing NB to FFI, my desired >>>>> list is: >>>> >>>> I would expect the least total effort to be needed by keeping the work >>>> of Esteban and Eliot as much as possible aligned. That is what Esteban's >>>> list achieves. >>>> >>>> Stephan

Oct. 19, 2015

Re: [Pharo-dev] Smalltalkhub projects not indexed?

by Levente Uzonyi

This is because for some unknown reason the creators of Smalltalkhub decided to use hashbang urls at a time when it was already considered bad practice to do so[1]. Crawlers can't crawl such pages, unless there are non-hashbang versions provided as well[2], but I strongly doubt Smalltalkhub has anything like that. Levente [1] http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs [2] https://developers.google.com/webmasters/ajax-crawling/docs/learn-more On Mon, 19 Oct 2015, Jan KurÅ¡ wrote: > Hi, > > I noticed that my projects on Smalltalkhub cannotÂ be googled :( I have project set up as a public, I actively develop and update the overview > page for several months, but even the query: smalltalkhub <myname> <nameOfMyProject> does not find anything. > > Is there a way to help this? > > Cheers, > Jan > >

Oct. 19, 2015

Smalltalkhub projects not indexed?

by Jan KurÅ¡

Hi, I noticed that my projects on Smalltalkhub cannot be googled :( I have project set up as a public, I actively develop and update the overview page for several months, but even the query: smalltalkhub <myname> <nameOfMyProject> does not find anything. Is there a way to help this? Cheers, Jan

Oct. 19, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Eliot Miranda

Hi Robert, _,,,^..^,,,_ (phone) > On Oct 19, 2015, at 5:03 AM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > Hi Esteban, > > >> On 10/19/2015 05:10 AM, Esteban Lorenzano wrote: >> >> Hi, >> >> just to be clear. >> When we talk about MTVM, we talk about a MT-FFI, *not* a MTVM in general. >> In general, a âcommonâ approach to MT cannot be applied in Pharo (or Smalltalk in general) and to get a VM *and* an image working properly is an effort that makes what I called massive some mails above like a small stone compared to a mountain. > > Could you please help me by talking further about the different models and scopes of what is meant by MT? > > a) MT-FFI I believe gives the developer a way to call and be invoked on callback, asynchronously. Is it so? It's a bit more than that. It is the sharing of the VM between different threads, but only allowing one thread to own the VM at any one time, changing ownership in call out or Smalltalk process switch time. This approach provides interleaved concurrency but not parallelism in your Smalltalk code and it means the Smalltalk class library doesn't have to be made thread-safe, which as Esteban said is a huge task. See http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/038943.ht… and google "eliot Miranda Simmons own thread" to find more messages. > b) General MTVM means other system services are threaded, like I/O events and scheduling and heartbeat. No; at least not in my opinion. In the standard single-threaded VM the heartbeat is ideally a thread (it can be an interval timer, but that's problematic; system calls get interrupted), and maybe an incremental global GC could be in its own thread. So I'm defining the MTVM to be the sharing of the VM between threads, and /not/ just the use of threads to implement non-Smalltalk sub tasks of the VM, and /not/ a full-blown multithreaded Smalltalk VM providing concurrent execution of Smalltalk processes in parallel. > I think that the right model (my stack/priQueue/pool intuition?) will change a Herculean task into a fairly straightfoward task and achievable. Change the problem, to get better answers. This has been well thought through and discussed. The definition above is very useful. It provides a system that can inter operate with concurrent code without having to implement a system that provides parallelism. It is used in David Simmons' VMs for S# etc and a similar (but less performant) scheme is available in Python VMs. Please, let's get this scheme working first. I'm not at all happy (read, extremely unhappy) that there is not much focus on working together to get our current VM to an excellent state and instead lots of work on other VMs that is speculative and a long way away from being production ready. We have a huge amount of work to do on Cog: - event-driven VM (that hence costs 0% processor time at idle) - 64-bits (x64 and ARM and...?) - Sista adaptive optimizer - FFI via dynamic generation of marshaling code, as required for efficient and correct call outs on x64 - MTVM as defined above - an incremental global mark-sweep GC for Spur - running on Xen/Unikernels/containers - providing a JavaScript plugin to proved rendering and events so we can run an efficient VM in a web browser - a port of the Interpreter/Context VM to Spur IMO, things that can /and should/ wait are - throwing away Slang and providing a true written-in-pure-Smalltalk VM that is self-bootstrapped a la Gerardo Richarte and Xavier Burroni - a truly parallel multi/threaded VM and things we shouldn't go anywhere near are - using libffi - targeting JavaScript, Java or any other dynamic language de jour that happens to run in a web browser but either provides abysmal performance or doesn't support full Smalltalk semantics - implementing the VM in other VM frameworks such as PyPy which simply strengthens that community and weakens our own Right now there are only a handful of people who make commits to the VM and three who are "full time", and we're all overloaded. But the VM is the base of the pillar and if we want to provide high-quality solutions that people will pay money to use we have to have a high-quality VM. In Spur we have a VM that is significantly faster that VW, and very reliable. In Sista we will have a system that is much faster and can be improved upon for years to come and a system that can migrate to future VMs (because it is mostly Smalltalk), and useful support for a high quality FFI. People like have stepped up and made significant contributions to give us what is a respectable VM that is on an arc to providing a really high-quality production Smalltalk VM written in Smalltalk produced by a very small community. But it is now 2015 and Cog started 7 years ago. All the work on other VMs, deployment platforms etc, IMO dilutes and delays in delivering to our community a truly world-class VM that we can compete with against Java HotSpot, node.js v8, lua luajit, factor, swift et al. Please get on board. We'd love the help and we can guarantee you'll have fun and you can guarantee you'll have an impact. > > I appreciate you and this MT discussion. > > >> Said that: >> >> - What is in plans is MT-FFI, and that will be available eventually. >> - There is an approach I want to re-work, that would allow us profit of multicores without going multithread: the âhydraâ experiment made some years ago by Igor creates a good basis to this. But is also a lot of of work (but a lot less than a complete MT), and not a real priority for nowâ¦ I hope to resume work on that area some dayâ¦ just not anytime soon. > > Yes, please. I recall those discussions. Hydra is cosmological. > > Regards, > Robert > >> >> Esteban >> >>> On 18 Oct 2015, at 17:56, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> >>> On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers >>> <robert.w.withers(a)gmail.com> wrote: >>>> Yes, exactly. I do realize I was consciously changing that effort >>>> synchronization order. >>> >>> I see 64-bit being higher priority than multi-threaded for the wider >>> community. Dealing with larger in-Image data opens the door to more >>> corporate project/funding opportunities. Also simplifying the install >>> on modern Linux platforms without requiring additional 386 libraries >>> will help acceptance there. >>> >>>> It is my humble opinion, without really knowing, that 64-bit would have to be redone after the MTVM completes. >>> >>> I would assume it was the other way around. Presuming that Eliot has >>> sponsors influencing his priorities, it seems given that 64-bits will >>> happen first. I would guess any MTVM development on the old vm would >>> then need to be reworked. >>> >>>> I was doing so with the idea in mind that I and others >>>> might dig into working on the VM, for threading support, while Eliot >>>> maintains focus on 64-bits...a tall order, I know. >>> >>> The usual downside of splitting resources applies. There are not that >>> many "others" and maybe they would be drawn away from helping with the >>> 64-bit vm. If the 64-bit vm goes slower for lack of resources then >>> your footing for MTVM will shifting for a longer time. You may >>> ultimately get where you want to go faster by helping with the 64-bit >>> vm. The rapport built with other vm devs from working on 64-bit might >>> could then be applied to MTVM. (Of course, its your free time, so you >>> should pursue what interests you.) >>> >>>> I was barely familiar with the VM, slang, interpreter, it years ago... >>>> I'm totally unfamiliar with cog. >>> >>> The experience you gain from working beside Esteban and Eliot on >>> 64-bit Cog/Spur could then be applied to a MTVM. >>> >>> btw, you may find these threads interesting... >>> * http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/10864… >>> * http://forum.world.st/Copy-on-write-for-a-multithreaded-VM-td4837905.html >>> >>> cheers -ben >>> >>>> I believe another item on that list ought to be modernizing slang. So >>>> many big items! >>>> >>>> Robert >>>> >>>> >>>> >>>>> On 10/16/2015 12:48 PM, Stephan Eggermont wrote: >>>>> >>>>> >>>>>> On 16-10-15 14:05, Robert Withers wrote: >>>>>> >>>>>> Because of that assumption I've made and without the responsibilities >>>>>> you have, Esteban, but recognizing modernizing NB to FFI, my desired >>>>>> list is: >>>>> >>>>> >>>>> I would expect the least total effort to be needed by keeping the work >>>>> of Esteban and Eliot as much as possible aligned. That is what Esteban's >>>>> list achieves. >>>>> >>>>> Stephan >>

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] The Trunk: System-mt.771.mcz

by Eliot Miranda

Hi Marcel, > On Oct 17, 2015, at 10:47 AM, commits(a)source.squeak.org wrote: > > Marcel Taeumel uploaded a new version of System to project The Trunk: > http://source.squeak.org/trunk/System-mt.771.mcz > > ==================== Summary ==================== > > Name: System-mt.771 > Author: mt > Time: 17 October 2015, 6:38:55.72 pm > UUID: 4aee8d76-cfcf-ad48-ae3e-6d971ce6fea9 > Ancestors: System-cmm.770 > > Log change stamps at the granularity of seconds not only minutes. > > Why? A minute is quite long and it is likely to have two method (versions) with the same timestamp. I think we should discuss this a bit further. This is all a soft touchy freely gut kind of thing for me: I don't like this change. I think the granularity for time stamps needs to differentiate versions in different package commits. Within an image versions can be distinguished by their order in the changes file (the previous source position, can't remember what that's called and I'm on my phone). So there's no real need for fine granularity. One could also say that a second is a long time if one is auto generating methods. I quite like being able to make several changes within the same minute because I can tell that they were related changes. With second granularity I have no chance. Do you have a programmatic reason for wanting second granularity? What to others think? Are there workflow implications to the granularity of time stamps? This is all very anal but, well, the changes file is all very anal anyway :-) I _,,,^..^,,,_ (phone)

Oct. 19, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Robert Withers

Hi Esteban, On 10/19/2015 05:10 AM, Esteban Lorenzano wrote: > > Hi, > > just to be clear. > When we talk about MTVM, we talk about a MT-FFI, *not* a MTVM in general. > In general, a âcommonâ approach to MT cannot be applied in Pharo (or Smalltalk in general) and to get a VM *and* an image working properly is an effort that makes what I called massive some mails above like a small stone compared to a mountain. Could you please help me by talking further about the different models and scopes of what is meant by MT? a) MT-FFI I believe gives the developer a way to call and be invoked on callback, asynchronously. Is it so? b) General MTVM means other system services are threaded, like I/O events and scheduling and heartbeat. I think that the right model (my stack/priQueue/pool intuition?) will change a Herculean task into a fairly straightfoward task and achievable. Change the problem, to get better answers. I appreciate you and this MT discussion. > Said that: > > - What is in plans is MT-FFI, and that will be available eventually. > - There is an approach I want to re-work, that would allow us profit of multicores without going multithread: the âhydraâ experiment made some years ago by Igor creates a good basis to this. But is also a lot of of work (but a lot less than a complete MT), and not a real priority for nowâ¦ I hope to resume work on that area some dayâ¦ just not anytime soon. Yes, please. I recall those discussions. Hydra is cosmological. Regards, Robert > > Esteban > >> On 18 Oct 2015, at 17:56, Ben Coman <btc(a)openInWorld.com> wrote: >> >> >> On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers >> <robert.w.withers(a)gmail.com> wrote: >>> Yes, exactly. I do realize I was consciously changing that effort >>> synchronization order. >> >> I see 64-bit being higher priority than multi-threaded for the wider >> community. Dealing with larger in-Image data opens the door to more >> corporate project/funding opportunities. Also simplifying the install >> on modern Linux platforms without requiring additional 386 libraries >> will help acceptance there. >> >>> It is my humble opinion, without really knowing, that 64-bit would have to be redone after the MTVM completes. >> >> I would assume it was the other way around. Presuming that Eliot has >> sponsors influencing his priorities, it seems given that 64-bits will >> happen first. I would guess any MTVM development on the old vm would >> then need to be reworked. >> >>> I was doing so with the idea in mind that I and others >>> might dig into working on the VM, for threading support, while Eliot >>> maintains focus on 64-bits...a tall order, I know. >> >> The usual downside of splitting resources applies. There are not that >> many "others" and maybe they would be drawn away from helping with the >> 64-bit vm. If the 64-bit vm goes slower for lack of resources then >> your footing for MTVM will shifting for a longer time. You may >> ultimately get where you want to go faster by helping with the 64-bit >> vm. The rapport built with other vm devs from working on 64-bit might >> could then be applied to MTVM. (Of course, its your free time, so you >> should pursue what interests you.) >> >>> I was barely familiar with the VM, slang, interpreter, it years ago... >>> I'm totally unfamiliar with cog. >> >> The experience you gain from working beside Esteban and Eliot on >> 64-bit Cog/Spur could then be applied to a MTVM. >> >> btw, you may find these threads interesting... >> * http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/10864… >> * http://forum.world.st/Copy-on-write-for-a-multithreaded-VM-td4837905.html >> >> cheers -ben >> >>> I believe another item on that list ought to be modernizing slang. So >>> many big items! >>> >>> Robert >>> >>> >>> >>> On 10/16/2015 12:48 PM, Stephan Eggermont wrote: >>>> >>>> >>>> On 16-10-15 14:05, Robert Withers wrote: >>>>> >>>>> Because of that assumption I've made and without the responsibilities >>>>> you have, Esteban, but recognizing modernizing NB to FFI, my desired >>>>> list is: >>>> >>>> >>>> I would expect the least total effort to be needed by keeping the work >>>> of Esteban and Eliot as much as possible aligned. That is what Esteban's >>>> list achieves. >>>> >>>> Stephan >>>> >>>> >>> >

Oct. 19, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Robert Withers

Thank you for your response, Ben. I'm here to help where I may be helpful, so let me know where. I have interest in the Pi and the ARM simulator was expressed as an area needing more resources. 64-bit is the strategic effort, so if I can help. I'd hope we could agree that whether is goes 64-bit then MT (which is what's up) or MT then 64-bit (as I was so rashly suggesting) there will be an integration cost. As 64-bit is a Spur ObjectMemory effort and MT is a process/stack oriented facet, are they not orthogonal and fairly non-interfering, aside from a few touch points. If there is integration cost, why not proceed in parallel? Certainly the discussion about what exactly MT is seems alright. I'm guessing the answer to that you have mentioned: resources. We need a bunch of hardcore CompSci students to catch the fire. Please let me know where I can help best. Rapport is key to team, this I have experienced. As well, thanks so much for those links! Those are gold and will be reread recursively. Regards, Robert On 10/18/2015 11:56 AM, Ben Coman wrote: > > On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers > <robert.w.withers(a)gmail.com> wrote: >> Yes, exactly. I do realize I was consciously changing that effort >> synchronization order. > > I see 64-bit being higher priority than multi-threaded for the wider > community. Dealing with larger in-Image data opens the door to more > corporate project/funding opportunities. Also simplifying the install > on modern Linux platforms without requiring additional 386 libraries > will help acceptance there. > >> It is my humble opinion, without really knowing, that 64-bit would have to be redone after the MTVM completes. > > I would assume it was the other way around. Presuming that Eliot has > sponsors influencing his priorities, it seems given that 64-bits will > happen first. I would guess any MTVM development on the old vm would > then need to be reworked. > >> I was doing so with the idea in mind that I and others >> might dig into working on the VM, for threading support, while Eliot >> maintains focus on 64-bits...a tall order, I know. > > The usual downside of splitting resources applies. There are not that > many "others" and maybe they would be drawn away from helping with the > 64-bit vm. If the 64-bit vm goes slower for lack of resources then > your footing for MTVM will shifting for a longer time. You may > ultimately get where you want to go faster by helping with the 64-bit > vm. The rapport built with other vm devs from working on 64-bit might > could then be applied to MTVM. (Of course, its your free time, so you > should pursue what interests you.) > >> I was barely familiar with the VM, slang, interpreter, it years ago... >> I'm totally unfamiliar with cog. > > The experience you gain from working beside Esteban and Eliot on > 64-bit Cog/Spur could then be applied to a MTVM. > > btw, you may find these threads interesting... > * http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/10864… > * http://forum.world.st/Copy-on-write-for-a-multithreaded-VM-td4837905.html > > cheers -ben > >> I believe another item on that list ought to be modernizing slang. So >> many big items! >> >> Robert >> >> >> >> On 10/16/2015 12:48 PM, Stephan Eggermont wrote: >>> >>> >>> On 16-10-15 14:05, Robert Withers wrote: >>>> >>>> Because of that assumption I've made and without the responsibilities >>>> you have, Esteban, but recognizing modernizing NB to FFI, my desired >>>> list is: >>> >>> >>> I would expect the least total effort to be needed by keeping the work >>> of Esteban and Eliot as much as possible aligned. That is what Esteban's >>> list achieves. >>> >>> Stephan >>> >>> >>

Oct. 19, 2015

Re: [Pharo-dev] [squeak-dev] RE: [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:

by Robert Withers

Hi Ron , nice to see you too! It has been a number of years, hasn't it? Crypto is timestamped back in 2010, so there is is. I hope these have been kind years to you, as they have for me. I love the idea of optional sources of entropy, depending on the deployed capabilities. So there are our mouse points and such, because they ought to be optional. What are some reliably present sources in the most minimal situation? If we could define minimal as an image with no image level I/O beyond file I/O, I would think we'd have: Kernel, System, Collections, Compiler and FFI. Some intransitives in that scope for entropy would be grand. I was thinking to take 5 millisecondClockValues, separated by 4 non-secure random intervals: take the low order byte of the 4 intervals and reverse & concat them, as a entropic source. I can coordinate these changes. Ron, could you add me to the Cryptography team so I can upload the Pharo Cryptography #bleedingEdge? Thanks and I look forward to more, :) Robert On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: > Hi Robert, > > Nice to see you! > > Looks interesting I know that Chris did something gathering sources of entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom. > > All the best, > > Ron Teitelbaum > >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Robert Withers >> Sent: Sunday, October 18, 2015 5:00 AM >> To: The general-purpose Squeak developers list; Pharo Development List >> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] RandomGenerator >> class>>unpredictableStringsDo: >> >> I'm sorry, I forgot the code. I list the existing method, followed by my >> modified Pharo method below. I welcome any feedback. >> >> Regards, >> Robert >> >> --- >> Existing: >> unpredictableStringsDo: aBlock >> "Enumerate sources of information from my environment that >> should be generally hard to guess." >> | time | >> time := Time millisecondsToRun: >> [ aBlock >> value: World imageForm bits compressToByteArray ; >> value: Sensor mousePoint x asString ; >> value: Sensor mousePoint y asString ; >> value: Time millisecondClockValue asByteArray ; >> value: Date today asString ; >> value: Time now asString ; >> value: Display extent asString. >> 100 timesRepeat: [ aBlock value: UUID new ]. >> #(vmVersion platformName primVmPath imageName >> platformSubtype datedVersion lastQuitLogPosition vmStatisticsReportString >> imageName) >> collect: >> [ : each | >> aBlock value: (SmalltalkImage current perform: each) >> asByteArray ] ]. >> aBlock >> value: time asByteArray; >> "maybe the pointer has moved, hit it again." >> value: Sensor mousePoint asString ; >> value: Time millisecondClockValue asByteArray >> >> --- >> Pharo port: >> unpredictableStringsDo: aBlock >> "Enumerate sources of information from my environment that >> should be generally hard to guess." >> >> | time | >> time := Time millisecondsToRun: >> [ aBlock >> value: Time millisecondClockValue asByteArray ; >> value: Date today asString ; >> value: Time now asString. >> 100 timesRepeat: [ aBlock value: UUID new ]. >> #(version primImagePath imagePath datedVersion >> lastQuitLogPosition) >> collect: >> [ : each | >> aBlock value: (SmalltalkImage current perform: each) >> asByteArray ] ]. >> aBlock >> value: time asByteArray; >> value: Time millisecondClockValue asByteArray >> >> >> On 10/18/2015 04:23 AM, Robert Withers wrote: >>> This is a message intended for anyone who was on the Cryptography team. >>> I recently ported it to Pharo and had to make changes to >> RandomGenerator >>> class>>unpredictableStringsDo:. This certainly removed some uncertainty >>> from the results of this message. My question is what should I do about >>> that? This method seems to require non-headless, as it is checking the >>> mouse point and such. This being a crypto cornerstone, what the best >>> answer here. >>> >>> Thank you, >>> Robert > > >

Oct. 19, 2015

Re: [Pharo-dev] Storing System Settings using STON

by Ferlicot D. Cyril

Le 12/10/2015 19:45, Juraj Kubelka a Ã©crit : > Hi, > > we have a slice that introduce new storage solution for System Settings. > See: https://pharo.fogbugz.com/f/cases/16681/Storing-System-Settings-using-STON > > You can load it using: > > Gofer it > smalltalkhubUser: 'Pharo' project: 'Pharo50Inbox'; > package: 'SLICE-Issue-16681-Storing-System-Settings-using-STON'; > load. > > When you open the Setting Browser, you can see that every setting has > new items in context menu: > > > Thanks for reviewing it. > Cheers, > Juraj Hi, Thank you for that. When I make store settings for the first time I have an exception on the write stream because the file doesn't exist. I had to create the folder 5.0 and an empty file to get it right. In Pharo 50392 on Linux. I join the stack: FileHandle>>streamError FileHandle>>writeStream FileSystem>>writeStreamOn: FileReference>>writeStream SystemSettingsPersistence>>writeStream SystemSettingsPersistence>>storeExactStoredSettings: SystemSettingsPersistence>>storeStoredSettings: SystemSettingsPersistence>>storeSettingNodes: SystemSettingsPersistence>>storeSettingNodes SettingTree>>storeSettingNodes SettingBrowser>>storeSettings PluggableButtonMorph>>performAction: [ :m | (m containsPoint: evt cursorPoint) ifTrue: [ m enabled ifTrue: [ m performAction: evt ] ] ] in PluggableButtonMorph>>mouseUp: in Block: [ :m | ... Array(SequenceableCollection)>>do: PluggableButtonMorph>>mouseUp: PluggableButtonMorph(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorph(Morph)>>handleEvent: PluggableButtonMorph(Morph)>>handleFocusEvent: [ ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: in Block: [ ActiveHand := self.... BlockClosure>>on:do: WorldMorph(PasteUpMorph)>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [ :h | ActiveHand := h. h processEvents. ActiveHand := nil ] in WorldState>>doOneCycleNowFor: in Block: [ :h | ... Array(SequenceableCollection)>>do: WorldState>>handsDo: -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 19, 2015