- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ScriptManager config in 1.4

by HernÃ¡n Morales Durand

Thanks Torsten, very useful package. 2012/6/19 Torsten Bergmann <astares(a)gmx.de> > The ConfigurationOfScriptManager is now also > in the Pharo 1.4. repo and therefore directly > available for easy loading in "Tools" -> > "Configuration Browser" > > Bye > T. > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > >

June 20, 2012

Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch

by Eliot Miranda

On Tue, Jun 19, 2012 at 1:50 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > IMO epoch starting is completely orthogonal to timezone bug which > should simply fixed. > If you define epoch time as 1 jan 1970 (or any other date you prefer) > but still will mess up with timezones, it won't change anything isn't? > +1. In Cog the VM has a 64-bit microsecond clock which is available both as microseconds from 1901 UTC and in local time. This is a great basis as it eliminates millisecond clock rollover issues (every 49 days?), lasts for > 50,000 years, and needs only the one primitive to answerUTC in up to microsecond resolution, fully synchronised. VW has been using such a basis for about a decade. If we could add these time primtiievs to the Interpreter IMO we'd have a much better basis for time. > > On 19 June 2012 21:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I wrote some tests to show the broken behavior. I'm attaching them to the > > issue and > > http://forum.world.st/file/n4635557/DateAndTimeTest-test_-_epoch.st to > > Nabble . Comments inline below... > > > > > > Eliot Miranda-2 wrote > >> > >>> We recently agreed that the Squeak epoch was well-defined, i.e. the > >>> start of the 20th century in GMT. This is clear if you read the > >>> SMalltalk-80 V2 sources. The reason advanced for changing to Unix was > >>> that the Squeak epoch is not well-defined. That argument is incorrect. > >> > > > > My understanding of what we found was that ST-80 referenced GMT, but > Squeak > > was cloudy (IMO wrong) from the beginning [1]. However, the actual > constant > > SqueakEpoch is actually a number of julian days, so that *could* stay > > unchanged if we decide that way. > > > > [1] > > > http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-tp4630581… > > > > > > Eliot Miranda-2 wrote > >> > >>> Further, the Squeak epoch is embedded in the VMs, in their answering > both > >>> seconds and microseconds from the epoch. So there's work involved in > >>> getting rid of it. > >> > > This test indicates to me that the VM is using the same (wrong) logic as > the > > image: > > testSqueakEpochClock > > > > | secondsFromClock secondsSinceEpochUTC | > > self useTimeZone: 'EDT' during: [ > > secondsFromClock := Time primSecondsClock. > > secondsSinceEpochUTC := (DateAndTime now - > '1901-01-01T00:00:00+00:00' > > asDateAndTime) asSeconds. > > > > "Fails because the clock returns the number of seconds > since > > 1901-01-01T00:00:00+(localOffset)" > > self deny: secondsFromClock = (secondsSinceEpochUTC + > DateAndTime > > localOffset asSeconds). > > self assert: secondsFromClock equals: > secondsSinceEpochUTC ]. > > > > > > StÃ©phane Ducasse wrote > >> > >> Now Sean what was your problem? Because may be we can also improve > >> Squeak-epoch. > >> > > Any time a DateAndTime is converted to seconds, the result is "the > number of > > seconds since 1901-01-01T00:00:00+(localOffset)", which is indeterminate. > > For example (see #testSqueakEpochAcrossTimeZones): > > 1. aDateAndTime asSeconds. > > 2. quit the image > > 3. move to a different time zone (or set localTimeZone: to a different > tz) > > 4. open the image again > > 5. restore the DateAndTime e.g. #fromSeconds: > > It is a different DateAndTime!! > > > > I'm clear (but please review the tests) that whatever epoch we choose: > > - the implementation *around* it must be fixed > > - the VM should be changed > > - any existing integers representing DateAndTime's will be invalid > > > > I think the only reason we've gotten this far without anyone noticing is > > that they are converted to/from integers in the same incorrect way in > both > > directions, so unless you transport live instances into a different time > > zone, you would never notice. > > > > The only question that I see we've come down to is: > > - keep the Squeak epoch, because it is elegant (turn of the century...) > > or > > - use the Unix epoch, because it is well-known and documented > > This is honestly much less important than the givens above, so this is > what > > I'll do... I'm going to create a new issue and to fix the image-side > issues > > I mentioned, and we can have fun debating this last question, which > seems to > > come down to style, ad infinitum ;-) > > > > Sean > > > > -- > > View this message in context: > http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

June 19, 2012

[Pharo-project] ScriptManager config in 1.4

by Torsten Bergmann

The ConfigurationOfScriptManager is now also in the Pharo 1.4. repo and therefore directly available for easy loading in "Tools" -> "Configuration Browser" Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

June 19, 2012

Re: [Pharo-project] Process Tests and

by Eliot Miranda

On Thu, Jun 14, 2012 at 2:34 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 13 June 2012 23:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Wed, Jun 13, 2012 at 7:35 AM, Frank Shearar <frank.shearar(a)gmail.com> > > wrote: > >> > >> On 2 June 2012 09:28, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > >> > Hi Sean: > >> > > >> > On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: > >> > > >> >> During the process, I noticed that the Blue Book specifies that #fork > >> >> returns the block itself (pg. 252), while in Pharo it returns the > >> >> process > >> >> (see #testFork in the slice). Should our implementation be changed to > >> >> match the Blue Book? > Sorry to reply so late. I think the blue book definition is broken. fork should answer the process. It has been changed to do so in VisualWorks for a long time. I think the blue book definition is simply a bug. It can easily be implemented in the caller using yourself, i.e. [...] fork; yourself answers the block if one needs it. >> > > >> > Why would it be desirable to have the block? > >> > How would you obtain the process object after your change? > >> > > >> > Having the process directly is useful to do fork/join style > operations. > >> > >> How do you #join Processes? I can't see anything in Process' protocol > >> for doing so. so what am I missing? > > > > > > Nothing. Theres no support for join. You have to roll your own. > > OK, that's what I thought. Stefan's comment intrigued me. > > It would be kind've handy to be able to say - even though we don't use > native threads - something like this: > > (0..10).map {|i| > Thread.new { sleep(1); i } > }.map {|t| t.value} > > only in a decent language: > > ((0 to: 10) > collect: [:i | [(Delay forSeconds: 1) wait. i] fork]) > collect: [:p | p value]. > > frank > > >> > >> > >> frank > >> > >> > Best regards > >> > Stefan > >> > > >> > -- > >> > Stefan Marr > >> > Software Languages Lab > >> > Vrije Universiteit Brussel > >> > Pleinlaan 2 / B-1050 Brussels / Belgium > >> > http://soft.vub.ac.be/~smarr > >> > Phone: +32 2 629 2974 > >> > Fax: +32 2 629 3525 > >> > > >> > > >> > > > > > > > > -- > > best, > > Eliot > > > > -- best, Eliot

June 19, 2012

Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch

by Igor Stasenko

IMO epoch starting is completely orthogonal to timezone bug which should simply fixed. If you define epoch time as 1 jan 1970 (or any other date you prefer) but still will mess up with timezones, it won't change anything isn't? On 19 June 2012 21:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I wrote some tests to show the broken behavior. I'm attaching them to the > issue and > http://forum.world.st/file/n4635557/DateAndTimeTest-test_-_epoch.st to > Nabble . Comments inline below... > > > Eliot Miranda-2 wrote >> >>> Â We recently agreed that the Squeak epoch was well-defined, i.e. the >>> start of the 20th century in GMT. Â This is clear if you read the >>> SMalltalk-80 V2 sources. Â The reason advanced for changing to Unix was >>> that the Squeak epoch is not well-defined. Â That argument is incorrect. >> > > My understanding of what we found was that ST-80 referenced GMT, but Squeak > was cloudy (IMO wrong) from the beginning [1]. However, the actual constant > SqueakEpoch is actually a number of julian days, so that *could* stay > unchanged if we decide that way. > > [1] > http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-tp4630581… > > > Eliot Miranda-2 wrote >> >>> Further, the Squeak epoch is embedded in the VMs, in their answering both >>> seconds and microseconds from the epoch. Â So there's work involved in >>> getting rid of it. >> > This test indicates to me that the VM is using the same (wrong) logic as the > image: > Â Â testSqueakEpochClock > > Â Â Â Â | secondsFromClock secondsSinceEpochUTC | > Â Â Â Â self useTimeZone: 'EDT' during: [ > Â Â Â Â Â Â Â Â secondsFromClock := Time primSecondsClock. > Â Â Â Â Â Â Â Â secondsSinceEpochUTC := (DateAndTime now - '1901-01-01T00:00:00+00:00' > asDateAndTime) asSeconds. > > Â Â Â Â Â Â Â Â "Fails because the clock returns the number of seconds since > 1901-01-01T00:00:00+(localOffset)" > Â Â Â Â Â Â Â Â self deny: secondsFromClock = (secondsSinceEpochUTC + DateAndTime > localOffset asSeconds). > Â Â Â Â Â Â Â Â self assert: secondsFromClock equals: secondsSinceEpochUTC ]. > > > StÃ©phane Ducasse wrote >> >> Now Sean what was your problem? Because may be we can also improve >> Squeak-epoch. >> > Any time a DateAndTime is converted to seconds, the result is "the number of > seconds since 1901-01-01T00:00:00+(localOffset)", which is indeterminate. > For example (see #testSqueakEpochAcrossTimeZones): > 1. aDateAndTime asSeconds. > 2. quit the image > 3. move to a different time zone (or set localTimeZone: to a different tz) > 4. open the image again > 5. restore the DateAndTime e.g. #fromSeconds: > It is a different DateAndTime!! > > I'm clear (but please review the tests) that whatever epoch we choose: > - the implementation *around* it must be fixed > - the VM should be changed > - any existing integers representing DateAndTime's will be invalid > > I think the only reason we've gotten this far without anyone noticing is > that they are converted to/from integers in the same incorrect way in both > directions, so unless you transport live instances into a different time > zone, you would never notice. > > The only question that I see we've come down to is: > - keep the Squeak epoch, because it is elegant (turn of the century...) > or > - use the Unix epoch, because it is well-known and documented > This is honestly much less important than the givens above, so this is what > I'll do... I'm going to create a new issue and to fix the image-side issues > I mentioned, and we can have fun debating this last question, which seems to > come down to style, ad infinitum ;-) > > Sean > > -- > View this message in context: http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

June 19, 2012

[Pharo-project] Jenkins Pharo 2.0 build failing

by Sean P. DeNigris

>From the console output (https://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/153/console) it looks like maybe primitiveDirectoryEntry is returning nil... -- View this message in context: http://forum.world.st/Jenkins-Pharo-2-0-build-failing-tp4635571.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 19, 2012

[Pharo-project] Issue 6076: Pharo 2.0 Jenkins build trigger not working

by Sean P. DeNigris

Maybe I didn't cc the person responsible... Probably an easy fix. I've been triggering the builds manually for the last few days. http://code.google.com/p/pharo/issues/detail?id=6076 -- View this message in context: http://forum.world.st/Issue-6076-Pharo-2-0-Jenkins-build-trigger-not-workin… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 19, 2012

Re: [Pharo-project] flatten method is kind of broken

by Tudor Girba

I did not open the issue. Please go ahead :) Doru On 18 Jun 2012, at 20:59, Fabrizio Perin wrote: > Sorry, > back from long weekend offline. I can port the moose extensions to the core indeed. > Doru did you open the issue already? > > Cheers, > Fabrizio > > > 2012/6/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > doru > > can you open a bug entry and provide necessary information? > Package and tests? > > Stef > > On Jun 16, 2012, at 8:07 AM, Tudor Girba wrote: > > > Indeed. It would be great to integrate CollectionExtensions into Pharo. > > > > For example, we have: > > #(#(1) #(2 3) #(#(4) 5) ) deepFlatten > > ==> #(1 2 3 4 5) > > > > Cheers, > > Doru > > > > On 15 Jun 2012, at 21:04, StÃ©phane Ducasse wrote: > > > >> fabrizio we should really include some of the moose extensions to pharo. > >> Could you take the lead on that? > >> > >> Did you try gather:? > >> > >> Stef > >> > >> On Jun 15, 2012, at 10:05 AM, Fabrizio Perin wrote: > >> > >>> Hi, > >>> I need to flatten a collection which does not contain other collections necessarily. The method flatten doesn't really work: > >>> > >>> #(#(1 2) #(3 4)) flatten -> #(1 2 3 4) OK > >>> > >>> #(#(1) #(2 3) #(#(4) 5) ) flatten -> #(1 2 3 #(4) 5) I would have expected something like #(1 2 3 4 5) > >>> > >>> #(1 2 3) flatten -> error > >>> #(#(1) 2 3) flatten -> error > >>> > >>> Is this the meant behavior for flatten? Any other method I could use instead? > >>> > >>> Thanks, > >>> Fabrizio > >> > >> > > > > -- > > www.tudorgirba.com > > > > "We are all great at making mistakes." > > > > > > > > > > > > > > > > > > > -- www.tudorgirba.com "What we can governs what we wish."

June 19, 2012

Re: [Pharo-project] compiled method inherits from Collection?

by Igor Stasenko

On 19 June 2012 14:33, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 19.06.2012 11:46, Fernando Olivero wrote: >> >> Thanks for the info, its a shame we cant easily change the vm. >> >> Oh well, i should first ask for isCompiledMethod before isCollection >> now... >> >> Fernando > > > Why? > I mean, each CompiledMethod IS a collection of bytes, even though those > bytes hold a special meaning. > What do you do when you encounter normal ByteArrays? > i think CM inherit from Collection is abuse, and makes little sense: (Object>>#yourself) do: collect: select: add: remove: detect: so, only to reuse #at:/#at:put: ? but it could live with basicAt:/basicAt:put: just well. > Cheers, > Henry -- Best regards, Igor Stasenko.

June 19, 2012

[Pharo-project] Issue 6069: Test guard for 20132

by Sean P. DeNigris

This is an easy slice to review (SLICE-Issue-6069-Test-guard-for-20132-SeanDeNigris.1). Mostly one-liner changes, all with newly passing tests... http://code.google.com/p/pharo/issues/detail?id=6069 Sean -- View this message in context: http://forum.world.st/Issue-6069-Test-guard-for-20132-tp4635559.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 19, 2012