- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo page is not working

by Marcus Denker

it works for meâ¦ > On 21 Oct 2015, at 04:52, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > It's giving: > Error: Duplicate key: 'index-header'

Oct. 21, 2015

Pharo page is not working

by Gabriel Cotelli

It's giving: Error: Duplicate key: 'index-header'

Oct. 21, 2015

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