June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ScriptManager config in 1.4

by StÃ©phane Ducasse

I do not know. I think that since we do not have a real process, fill up these repo is random. I will try to see if I can come up with a sketch of the vision I have. But I have limited amount of time (so I'm frustrated). Stef On Jun 20, 2012, at 9:03 AM, Sven Van Caekenberghe wrote: > > On 20 Jun 2012, at 02:42, HernÃ¡n Morales Durand wrote: > >> Thanks Torsten, very useful package. > > +1 > > Why is the repo for the metacello config browser for 2.0 empty ? > Are these repos world writeable ? > > Sven

June 20, 2012

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

by StÃ©phane Ducasse

It is historical to gain space. Now would be good to clean that but â¦ not yet. > 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 20, 2012

Re: [Pharo-project] ScriptManager config in 1.4

by Sven Van Caekenberghe

On 20 Jun 2012, at 02:42, HernÃ¡n Morales Durand wrote: > Thanks Torsten, very useful package. +1 Why is the repo for the metacello config browser for 2.0 empty ? Are these repos world writeable ? Sven

June 20, 2012

Re: [Pharo-project] FileSystem and file extensions

by Sean P. DeNigris

Eliot Miranda-2 wrote > > Why not > #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: > [:thing| thing extension] => #('' 'tar' 'gz' 'tar' 'gz') > and > #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: > [:thing| thing extensions] => #(#() #('tar') #('gz' 'tar') #('tar' '1') > #('gz' 'tar' '1')) > or > #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: > [:thing| thing extensions] => #(#() #('tar') #('tar' 'gz') #('1' 'tar') > #('1' 'tar' 'gz')) > ? > I opened an issue (http://code.google.com/p/pharo/issues/detail?id=6091) which order do we like for extensions? -- View this message in context: http://forum.world.st/FileSystem-and-file-extensions-tp4635256p4635617.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 20, 2012

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

by David T. Lewis

On Tue, Jun 19, 2012 at 03:32:47PM -0700, Eliot Miranda wrote: > > 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? > > Absolutely right. > > +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. > Eliot, Could I ask you to please take a second look at primitiveUtcWithOffset? This has been in trunk VMMaker with platform support for Windows/Unix/Mac for a couple of years now, and the background and discussion is on Mantis at http://bugs.squeak.org/view.php?id=7458. The underlying platform call is ioUtcWithOffset(&clock, &offset) which could presumably be adapted to support your Cog primitives. Would this make sense? Dave

June 20, 2012

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