- Pharo-dev - lists.pharo.org

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

by Sean P. DeNigris

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.

June 19, 2012

[Pharo-project] [update 2.0] #20142

by StÃ©phane Ducasse

20142 ----- - Issue 6084: [BUG]: File Browser cannot load mcz files. Thanks Sean DeNigris http://code.google.com/p/pharo/issues/detail?id=6084 - Issue 6088: primitive:numArgs:numTemps:stackSize:literals:bytecodes:trailer: should use #needsFrameSize:. Thanks Marcus Denker. http://code.google.com/p/pharo/issues/detail?id=6088 - Issue 6087: make doPerformOldLargeFrame to decompile with the temps Thanks Marcus Denker. http://code.google.com/p/pharo/issues/detail?id=6087 - Issue 6083: Mouse down events are being processed twice. Thanks Sean DeNigris. http://code.google.com/p/pharo/issues/detail?id=6083

June 19, 2012

[Pharo-project] [update 2.0] #20141

by StÃ©phane Ducasse

20141 ----- - Issue 4734: file out of packages raises an exception with Nautilus. Thanks Sean DeNigris, Guillermo and others :) http://code.google.com/p/pharo/issues/detail?id=4734 - Issue 6054: Error when reading zip files with Squeak date/time format. Thanks Sean DeNigris. http://code.google.com/p/pharo/issues/detail?id=6054

June 19, 2012

Re: [Pharo-project] The Magic of FileSystem

by StÃ©phane Ducasse

:) I want the same with OPAL :) Stef > This... > localFileName: aString > | dir entry parent fileNameWithoutTrailingSlash | > super localFileName: aString. > parent := FileDirectory default. > > self flag: 'directoryExists: fails if trailing slash. Replace this whole > mess with FS'. > fileNameWithoutTrailingSlash := fileName last = $/ ifTrue: [ fileName > allButLast ] ifFalse: [ fileName ]. > (parent directoryExists: fileNameWithoutTrailingSlash) ifTrue: [ > dir := FileDirectory on: (parent fullNameFor: fileName). > entry := dir directoryEntry. > self modifiedAt: (DateAndTime fromSeconds: entry modificationTime) ]. > fileName last = $/ ifFalse: [ fileName := fileName, '/' ]. > (which I *think* had an undiscovered bug, invisible due to the complexity) > > vs. This... > localFileName: aString > > | file | > super localFileName: aString. > file := aString asFileReference. > file exists ifFalse: [ ^ self ]. > self modifiedAt: file entry modificationTime. > > Ahhhh... > > Cheers, > Sean > > -- > View this message in context: http://forum.world.st/The-Magic-of-FileSystem-tp4635471.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 19, 2012

Re: [Pharo-project] Integer>>asDateFromZip

by StÃ©phane Ducasse

ok I will have a look at it later this evening. Thanks. Thanks. Thanks. > I tagged issue 6054 as FixToInclude. > > Sven Van Caekenberghe wrote >>> >>> Is there some quick patch that I could do to get passed this, as it is >>> blocking the loading of code, which is rather fundamental. >>> >> >> I didn't realize this hadn't been integrated... >> http://code.google.com/p/pharo/issues/detail?id=6054 >> >> -- >> View this message in context: http://forum.world.st/Integer-asDateFromZip-tp4635452p4635460.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

June 19, 2012

Re: [Pharo-project] Array size in inspector

by Sean P. DeNigris

Davide Varvello wrote > > I've a very long array I'd like to inspect, unfortunately inspector shows > only first 100 elements and few last elements of my array. How can change > that behavior? > Hey Davide! Please ask user questions on StackOverflow (tagged with Pharo) or the Pharo Users list, so they do not get lost/confused with the development issues discussed here. If you explore your array instead of inspecting it, you should see all the elements (may take a long time, depending on the size). HTH, Sean -- View this message in context: http://forum.world.st/Array-size-in-inspector-tp4635484p4635503.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 19, 2012

Re: [Pharo-project] Integer>>asDateFromZip

by Sean P. DeNigris

Sven Van Caekenberghe wrote > > I tagged issue 6054 as FixToInclude. > While making a slice, I found a related bug and needed to cleanup some FS-related stuff. The slice needs a review (although I'm confident about it, see "Successfully loaded" part below). Like Sven said, not being able to load code is a severe bug, so let's get this checked and integrated!! Fix in inbox: SLICE-Issue-6054-Error-when-reading-zip-files-with-Squeak-datetime-format-SeanDeNigris.1 * When reading zip files, treat invalid, error-causing DOS timestamps as the old, incorrect format from Squeak - Fix ZipFileMember>>read*DirectoryFileHeader* methods - Add (now)-passing test for timestamp that caused the issue to be reported (see comment 1 in issue or test comment) * Delegate DOS timestamp processing to DateAndTime - Remove date/time zip/unzip methods from ArchiveMember - Update Zip*Member reading/writing methods - Remove zip-related methods and protocols from Date, Time, and Integer - Remove associated tests * When writing directories to zip files, append trailing slash to name, which is required (at least Mac OS X can't handle without) Successfully loaded slice into 20140 * all compression tests pass * The following fails before slice, passes after "ZipArchive new readFrom: '/path/to/Balloon-CamilloBruni.85.mcz'" -- View this message in context: http://forum.world.st/Integer-asDateFromZip-tp4635452p4635501.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 19, 2012

Re: [Pharo-project] [XMLRPC] Little client clean up

by Noury Bouraqadi

Thanx a lot germÃ n On 19 juin 2012, at 02:05, garduino wrote: > And updated ConfigurationOfXMLRPC adding 'version100Beta4' to install the > latest client code. > > -- > View this message in context: http://forum.world.st/XMLRPC-Little-client-clean-up-tp4635363p4635405.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

June 19, 2012

[Pharo-project] Array size in inspector

by Davide Varvello

Hi, I've a very long array I'd like to inspect, unfortunately inspector shows only first 100 elements and few last elements of my array. How can change that behavior? Thanks Davide -- View this message in context: http://forum.world.st/Array-size-in-inspector-tp4635484.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 19, 2012

Re: [Pharo-project] Version of method broken

by Davide Varvello

Done. http://code.google.com/p/pharo/issues/detail?id=6085 Davide Benjamin Van Ryseghem-2 wrote > > I can have a look. Now I can't, but I will in the end of the week :) > > > Think about opening an issue on the issue tracker, with me as cc, type > nautilus and milestone 1.4 :) > Thanks in advance, > > Ben > > On Jun 18, 2012, at 11:11 PM, Mariano Martinez Peck wrote: > >> >> >> On Mon, Jun 18, 2012 at 9:21 PM, Davide Varvello <varvello@> wrote: >> Hi, >> Suddenly methods' version is broken, i.e. when I click on a method and >> select "versions", the "recent versions" panel appears but looking at >> method >> versions, no differences is displayed with standard red and green colors >> and >> moreover revert button does not work anymore. >> >> Hi Davide. All I can say is that I remember seeing this bug in previous >> versions of Nautilus. >> Of course this has been fixed in latest Nautilus versions but they are >> available only for Pharo 2.0. >> I guess the version of Nautilus that works in 1.4 is a little bit old. We >> (Ben) cannot maintain Nautilus working with both versions so in 1.4.1 you >> need to stick to that version. >> Maybe someone can take that version and create a new one with the bug >> fix... >> >> I'm on Pharo 1.4 with Nautilus. >> Hints? >> Thanks >> Davide >> >> -- >> View this message in context: >> http://forum.world.st/Version-of-method-broken-tp4635379.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > -- View this message in context: http://forum.world.st/Version-of-method-broken-tp4635379p4635483.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 19, 2012