April 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sven Van Caekenberghe

> On 9 Apr 2018, at 17:34, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Must watch :) > > The Problem with Time & Timezones - Computerphile > https://www.youtube.com/watch?v=-5wpm-gesOY Haha, that is indeed hilarious. I guess there is no complete, absolute 100% correct answer for all use cases, we can only try to be reasonably good. > On 9 April 2018 at 17:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 9 Apr 2018, at 15:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > Max Leske wrote > >> Assuming UTC is probably just as wrong as assuming the local time zone. > > > > I'll modify your statement slightly. "Assuming UTC is */almost/* as wrong as > > assuming the local time zone." > > > > I've never seemed to be able to drive the essential point home when these > > discussions have come up. Beyond all the wider issues, there is a bug, plain > > and simple: The offset of `'1/1/1990' asDate`, considering that you mean > > local time, is still not guaranteed to be the current local offset of the > > image, which is how we set it by default. That only makes sense if the > > historical date in question was in the same state of DST as the current > > image. For example, the historical date above is in winter, so if I eval > > that code in summer, it will /always/ give the objectively wrong offset. > > > > What I'm proposing is not a cure all, but a slightly-better way that fixes > > this bug by giving users consistent behavior that they may not want instead > > of inconsistent and often wrong behavior that they may not want. > > Sean, > > You are right, the current system cannot be fixed. It only knows about the current timezone's offset (via the OS), not about historical offsets. And it wrongly uses that offset because it does not know better. > > Neither > > '1/1/1990' asDate. > > nor > > Date today. > > can work without the context of a precise timezone. It is even relatively pointless to remember offsets without remembering timezones. You simply need a precise reference into the transitions database. > > New York is 5 hours behind UTC in winter. > > Question 1: When (in absolute UTC time) was the beginning of the 1st day of January in 1990 in New York's local time, when we express the date in UTC ? > > (ZTimezone id: 'America/New_York') gmtToLocal: (ZTimestamp @ '1990/01/01'). > > => "1989-12-31T19:00:00Z" > > So when the UTC day of January 1st 1990 starts, New York local time is still 5 hours behind. > > Question 2: When (in absolute UTC time) was the beginning of the 1st day of January in 1990 in UTC time, when we express the date locally ? > > (ZTimezone id: 'America/New_York') localToGmt: (ZTimestamp @ '1990/01/01'). > > => "1990-01-01T05:00:00Z" > > So when the New York day of January 1st 1990 starts, UTC time is already 5 hours ahead. > > Note that the question 'When does January 1st 1990 start in any timezone, when expressed in that timezone, is of course a constant, midnight'. > > > I think that making Date always UTC will probably not help, because you will want to be able to move between timezones. I guess the only solution is to add a class like ZTimezone (which has no dependencies). > > > Sven > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > > >

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Aliaksei Syrel

Must watch :) The Problem with Time & Timezones - Computerphile https://www.youtube.com/watch?v=-5wpm-gesOY On 9 April 2018 at 17:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 9 Apr 2018, at 15:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > Max Leske wrote > >> Assuming UTC is probably just as wrong as assuming the local time zone. > > > > I'll modify your statement slightly. "Assuming UTC is */almost/* as > wrong as > > assuming the local time zone." > > > > I've never seemed to be able to drive the essential point home when these > > discussions have come up. Beyond all the wider issues, there is a bug, > plain > > and simple: The offset of `'1/1/1990' asDate`, considering that you mean > > local time, is still not guaranteed to be the current local offset of the > > image, which is how we set it by default. That only makes sense if the > > historical date in question was in the same state of DST as the current > > image. For example, the historical date above is in winter, so if I eval > > that code in summer, it will /always/ give the objectively wrong offset. > > > > What I'm proposing is not a cure all, but a slightly-better way that > fixes > > this bug by giving users consistent behavior that they may not want > instead > > of inconsistent and often wrong behavior that they may not want. > > Sean, > > You are right, the current system cannot be fixed. It only knows about the > current timezone's offset (via the OS), not about historical offsets. And > it wrongly uses that offset because it does not know better. > > Neither > > '1/1/1990' asDate. > > nor > > Date today. > > can work without the context of a precise timezone. It is even relatively > pointless to remember offsets without remembering timezones. You simply > need a precise reference into the transitions database. > > New York is 5 hours behind UTC in winter. > > Question 1: When (in absolute UTC time) was the beginning of the 1st day > of January in 1990 in New York's local time, when we express the date in > UTC ? > > (ZTimezone id: 'America/New_York') gmtToLocal: (ZTimestamp @ '1990/01/01'). > > => "1989-12-31T19:00:00Z" > > So when the UTC day of January 1st 1990 starts, New York local time is > still 5 hours behind. > > Question 2: When (in absolute UTC time) was the beginning of the 1st day > of January in 1990 in UTC time, when we express the date locally ? > > (ZTimezone id: 'America/New_York') localToGmt: (ZTimestamp @ '1990/01/01'). > > => "1990-01-01T05:00:00Z" > > So when the New York day of January 1st 1990 starts, UTC time is already 5 > hours ahead. > > Note that the question 'When does January 1st 1990 start in any timezone, > when expressed in that timezone, is of course a constant, midnight'. > > > I think that making Date always UTC will probably not help, because you > will want to be able to move between timezones. I guess the only solution > is to add a class like ZTimezone (which has no dependencies). > > > Sven > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > > > > >

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sven Van Caekenberghe

> On 9 Apr 2018, at 15:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Max Leske wrote >> Assuming UTC is probably just as wrong as assuming the local time zone. > > I'll modify your statement slightly. "Assuming UTC is */almost/* as wrong as > assuming the local time zone." > > I've never seemed to be able to drive the essential point home when these > discussions have come up. Beyond all the wider issues, there is a bug, plain > and simple: The offset of `'1/1/1990' asDate`, considering that you mean > local time, is still not guaranteed to be the current local offset of the > image, which is how we set it by default. That only makes sense if the > historical date in question was in the same state of DST as the current > image. For example, the historical date above is in winter, so if I eval > that code in summer, it will /always/ give the objectively wrong offset. > > What I'm proposing is not a cure all, but a slightly-better way that fixes > this bug by giving users consistent behavior that they may not want instead > of inconsistent and often wrong behavior that they may not want. Sean, You are right, the current system cannot be fixed. It only knows about the current timezone's offset (via the OS), not about historical offsets. And it wrongly uses that offset because it does not know better. Neither '1/1/1990' asDate. nor Date today. can work without the context of a precise timezone. It is even relatively pointless to remember offsets without remembering timezones. You simply need a precise reference into the transitions database. New York is 5 hours behind UTC in winter. Question 1: When (in absolute UTC time) was the beginning of the 1st day of January in 1990 in New York's local time, when we express the date in UTC ? (ZTimezone id: 'America/New_York') gmtToLocal: (ZTimestamp @ '1990/01/01'). => "1989-12-31T19:00:00Z" So when the UTC day of January 1st 1990 starts, New York local time is still 5 hours behind. Question 2: When (in absolute UTC time) was the beginning of the 1st day of January in 1990 in UTC time, when we express the date locally ? (ZTimezone id: 'America/New_York') localToGmt: (ZTimestamp @ '1990/01/01'). => "1990-01-01T05:00:00Z" So when the New York day of January 1st 1990 starts, UTC time is already 5 hours ahead. Note that the question 'When does January 1st 1990 start in any timezone, when expressed in that timezone, is of course a constant, midnight'. I think that making Date always UTC will probably not help, because you will want to be able to move between timezones. I guess the only solution is to add a class like ZTimezone (which has no dependencies). Sven > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

April 9, 2018

Re: [Pharo-dev] Metacello/Iceberg Error: IceUndefinedRemote DNU #projectPath

by Dennis Schetinin

Hello Sean, did you resolve the problem? I experience the same trying to update Calypso in 6.1 via Metacello new > baseline: 'Calypso'; > repository: 'github://dionisiydk/Calypso'; > load. The stack: IceUndefinedRemote(Object)>>doesNotUnderstand: #projectPath > IceMetacelloRepositoryAdapter>>projectPath > IceMetacelloRepositoryAdapter>>hasNoLoadConflicts: > MetacelloRepositorySpec>>hasNoLoadConflicts: > MetacelloRepositoriesSpec>>hasNoLoadConflicts: > > MetacelloMCBaselineOfProjectSpec(MetacelloGenericProjectSpec)>>hasNoLoadConflicts: > > MetacelloMCBaselineOfProjectSpec(MetacelloMCProjectSpec)>>hasNoLoadConflicts: > MetacelloMCBaselineOfProjectSpec(MetacelloProjectSpec)>>hasLoadConflicts: > > MetacelloMCBaselineOfProjectSpec(MetacelloMCProjectSpec)>>hasConflictWithBaselineSpec: > MetacelloMCBaselineOfProjectSpec>>hasConflictWithProjectSpec: > MetacelloProjectRegistration>>hasLoadConflicts: > [ :existing :new | > (existing hasLoadConflicts: new) > ifTrue: [ ((existing canUpgradeTo: new) > ifTrue: [ MetacelloAllowProjectUpgrade new ] > ifFalse: [ (existing canDowngradeTo: new) > ifTrue: [ MetacelloAllowProjectDowngrade new ] > ifFalse: [ MetacelloAllowConflictingProjectUpgrade new ] ]) > existingProjectRegistration: existing; > newProjectRegistration: new; > signal ] > ifFalse: [ new ] ] in MetacelloScriptEngine>>lookupProjectSpecFor: > [ :existing | ^ presentBlock value: existing value: newRegistration ] in > MetacelloProjectRegistration > class>>registrationForProjectSpec:ifAbsent:ifPresent: > [ :existing | ^ presentBlock value: existing ] in > MetacelloProjectRegistry>>registrationFor:ifPresent:ifAbsent: > BlockClosure>>cull: > Dictionary>>at:ifPresent: > MetacelloProjectRegistry>>registrationFor:ifPresent:ifAbsent: > MetacelloProjectRegistration > class>>registrationForProjectSpec:ifAbsent:ifPresent: > MetacelloScriptEngine>>lookupProjectSpecFor: > [ loadedSpec := (self lookupProjectSpecFor: self projectSpec) copy ] in [ > | version loadedSpec | > self setDefaultsAndValidateProjectSpec. > [ loadedSpec := (self lookupProjectSpecFor: self projectSpec) copy ] > on: MetacelloAllowProjectDowngrade , MetacelloAllowProjectUpgrade > do: > [ :ex | ex handleOnDownGrade: onDownGradeBlock onUpgrade: onUpgradeBlock ]. > version := loadedSpec versionForScriptEngine: self. > self > root: > (required isEmpty > ifTrue: [ version load ] > ifFalse: [ version load: required ]) loadDirective. > loadedSpec loads: required. > MetacelloProjectRegistration > registrationForProjectSpec: loadedSpec > ifAbsent: [ :new | > new > loadedInImage: true; > registerProject ] > ifPresent: [ :existing :new | > existing > copyOnWrite: [ :existingCopy | > existingCopy > loadedInImage: true; > merge: new ] ] ] in [ self > handleNotificationsForAction: [ | version loadedSpec | > self setDefaultsAndValidateProjectSpec. > [ loadedSpec := (self lookupProjectSpecFor: self projectSpec) copy ] > on: MetacelloAllowProjectDowngrade , MetacelloAllowProjectUpgrade > do: > [ :ex | ex handleOnDownGrade: onDownGradeBlock onUpgrade: onUpgradeBlock ]. > version := loadedSpec versionForScriptEngine: self. > self > root: > (required isEmpty > ifTrue: [ version load ] > ifFalse: [ version load: required ]) loadDirective. > loadedSpec loads: required. > MetacelloProjectRegistration > registrationForProjectSpec: loadedSpec > ifAbsent: [ :new | > new > loadedInImage: true; > registerProject ] > ifPresent: [ :existing :new | > existing > copyOnWrite: [ :existingCopy | > existingCopy > loadedInImage: true; > merge: new ] ] ] ] in > MetacelloScriptEngine>>load:onProjectDownGrade:onProjectUpgrade: > BlockClosure>>on:do: > [ | version loadedSpec | > self setDefaultsAndValidateProjectSpec. > [ loadedSpec := (self lookupProjectSpecFor: self projectSpec) copy ] > on: MetacelloAllowProjectDowngrade , MetacelloAllowProjectUpgrade > do: > [ :ex | ex handleOnDownGrade: onDownGradeBlock onUpgrade: onUpgradeBlock ]. > version := loadedSpec versionForScriptEngine: self. > self > root: > (required isEmpty > ifTrue: [ version load ] > ifFalse: [ version load: required ]) loadDirective. > loadedSpec loads: required. > MetacelloProjectRegistration > registrationForProjectSpec: loadedSpec > ifAbsent: [ :new | > new > loadedInImage: true; > registerProject ] > ifPresent: [ :existing :new | > existing > copyOnWrite: [ :existingCopy | > existingCopy > loadedInImage: true; > merge: new ] ] ] in [ self > handleNotificationsForAction: [ | version loadedSpec | > self setDefaultsAndValidateProjectSpec. > [ loadedSpec := (self lookupProjectSpecFor: self projectSpec) copy ] > on: MetacelloAllowProjectDowngrade , MetacelloAllowProjectUpgrade > do: > [ :ex | ex handleOnDownGrade: onDownGradeBlock onUpgrade: onUpgradeBlock ]. > version := loadedSpec versionForScriptEngine: self. > self > root: > (required isEmpty > ifTrue: [ version load ] > ifFalse: [ version load: required ]) loadDirective. > loadedSpec loads: required. > MetacelloProjectRegistration > registrationForProjectSpec: loadedSpec > ifAbsent: [ :new | > new > loadedInImage: true; > registerProject ] > ifPresent: [ :existing :new | > existing > copyOnWrite: [ :existingCopy | > existingCopy > loadedInImage: true; > merge: new ] ] ] ] in > MetacelloScriptEngine>>load:onProjectDownGrade:onProjectUpgrade: > BlockClosure>>on:do: > [ actionBlock > on: > MetacelloLookupProjectSpec , MetacelloLookupProjectSpecForLoad > , MetacelloProjectSpecLoadedNotification > , MetacelloScriptEnsureProjectLoadedForDevelopment > , MetacelloLookupBaselineSpecForEnsureLoad > do: > [ :ex | "lookup and registration handlers need to be innermost set of > handlers ...they may throw option notifications" ex handleResolutionFor: > self ] ] in [ [ actionBlock > on: > MetacelloLookupProjectSpec , MetacelloLookupProjectSpecForLoad > , MetacelloProjectSpecLoadedNotification > , MetacelloScriptEnsureProjectLoadedForDevelopment > , MetacelloLookupBaselineSpecForEnsureLoad > do: > [ :ex | "lookup and registration handlers need to be innermost set of > handlers ...they may throw option notifications" ex handleResolutionFor: > self ] ] > on: > MetacelloAllowProjectDowngrade , MetacelloAllowProjectUpgrade > , MetacelloAllowConflictingProjectUpgrade > do: > [ :ex | "option handlers need to be outermost set of handlers ... last > line of defense before users are involved" ex handleResolutionFor: self ] ] > in [ [ [ actionBlock > on: > MetacelloLookupProjectSpec , MetacelloLookupProjectSpecForLoad > , MetacelloProjectSpecLoadedNotification > , MetacelloScriptEnsureProjectLoadedForDevelopment > , MetacelloLookupBaselineSpecForEnsureLoad > do: > [ :ex | "lookup and registration handlers need to be innermost set of > handlers ...they may throw option notifications" ex handleResolutionFor: > self ] ] > on: > MetacelloAllowProjectDowngrade , MetacelloAllowProjectUpgrade > , MetacelloAllowConflictingProjectUpgrade > do: > [ :ex | "option handlers need to be outermost set of handlers ... last > line of defense before users are involved" ex handleResolutionFor: self ] ] > on: MetacelloAllowLockedProjectChange > do: > [ :ex | "MetacelloAllowLockedProjectChange need to be outermost handler > ... since it is signaled from second line of handlers" ex > handleResolutionFor: self ] ] in > MetacelloScriptEngine>>handleNotificationsForAction: > BlockClosure>>on:do: > [ [ actionBlock > on: > MetacelloLookupProjectSpec , MetacelloLookupProjectSpecForLoad > , MetacelloProjectSpecLoadedNotification > , MetacelloScriptEnsureProjectLoadedForDevelopment > , MetacelloLookupBaselineSpecForEnsureLoad > do: > [ :ex | "lookup and registration handlers need to be innermost set of > handlers ...they may throw option notifications" ex handleResolutionFor: > self ] ] > on: > MetacelloAllowProjectDowngrade , MetacelloAllowProjectUpgrade > , MetacelloAllowConflictingProjectUpgrade > do: > [ :ex | "option handlers need to be outermost set of handlers ... last > line of defense before users are involved" ex handleResolutionFor: self ] ] > in [ [ [ actionBlock > on: > MetacelloLookupProjectSpec , MetacelloLookupProjectSpecForLoad > , MetacelloProjectSpecLoadedNotification > , MetacelloScriptEnsureProjectLoadedForDevelopment > , MetacelloLookupBaselineSpecForEnsureLoad > do: > [ :ex | "lookup and registration handlers need to be innermost set of > handlers ...they may throw option notifications" ex handleResolutionFor: > self ] ] > on: > MetacelloAllowProjectDowngrade , MetacelloAllowProjectUpgrade > , MetacelloAllowConflictingProjectUpgrade > do: > [ :ex | "option handlers need to be outermost set of handlers ... last > line of defense before users are involved" ex handleResolutionFor: self ] ] > on: MetacelloAllowLockedProjectChange > do: > [ :ex | "MetacelloAllowLockedProjectChange need to be outermost handler > ... since it is signaled from second line of handlers" ex > handleResolutionFor: self ] ] in > MetacelloScriptEngine>>handleNotificationsForAction: > BlockClosure>>on:do: > [ [ [ actionBlock > on: > MetacelloLookupProjectSpec , MetacelloLookupProjectSpecForLoad > , MetacelloProjectSpecLoadedNotification > , MetacelloScriptEnsureProjectLoadedForDevelopment > , MetacelloLookupBaselineSpecForEnsureLoad > do: > [ :ex | "lookup and registration handlers need to be innermost set of > handlers ...they may throw option notifications" ex handleResolutionFor: > self ] ] > on: > MetacelloAllowProjectDowngrade , MetacelloAllowProjectUpgrade > , MetacelloAllowConflictingProjectUpgrade > do: > [ :ex | "option handlers need to be outermost set of handlers ... last > line of defense before users are involved" ex handleResolutionFor: self ] ] > on: MetacelloAllowLockedProjectChange > do: > [ :ex | "MetacelloAllowLockedProjectChange need to be outermost handler > ... since it is signaled from second line of handlers" ex > handleResolutionFor: self ] ] in > MetacelloScriptEngine>>handleNotificationsForAction: > BlockClosure>>on:do: > MetacelloScriptEngine>>handleNotificationsForAction: > [ self > handleNotificationsForAction: [ | version loadedSpec | > self setDefaultsAndValidateProjectSpec. > [ loadedSpec := (self lookupProjectSpecFor: self projectSpec) copy ] > on: MetacelloAllowProjectDowngrade , MetacelloAllowProjectUpgrade > do: > [ :ex | ex handleOnDownGrade: onDownGradeBlock onUpgrade: onUpgradeBlock ]. > version := loadedSpec versionForScriptEngine: self. > self > root: > (required isEmpty > ifTrue: [ version load ] > ifFalse: [ version load: required ]) loadDirective. > loadedSpec loads: required. > MetacelloProjectRegistration > registrationForProjectSpec: loadedSpec > ifAbsent: [ :new | > new > loadedInImage: true; > registerProject ] > ifPresent: [ :existing :new | > existing > copyOnWrite: [ :existingCopy | > existingCopy > loadedInImage: true; > merge: new ] ] ] ] in > MetacelloScriptEngine>>load:onProjectDownGrade:onProjectUpgrade: > BlockClosure>>ensure: > MetacelloProjectRegistration class>>copyRegistryRestoreOnErrorWhile: > MetacelloScriptEngine>>load:onProjectDownGrade:onProjectUpgrade: > MetacelloScriptEngine>>load: > [ :projectSpec | > | engine | > engine := MetacelloScriptEngine new > options: self options copy; > projectSpec: projectSpec; > yourself. > engine perform: actionArg key withArguments: actionArg value. > engine root ifNotNil: [ :root | self roots add: root ] ] in > MetacelloScriptApiExecutor(MetacelloScriptExecutor)>>execute: > [ :projectSpec | > projectSpec > ifNotNil: [ projectSpecBlock > value: (self applyArgsToProjectSpec: projectSpec copy) ] ] in > MetacelloScriptApiExecutor>>executeString:do: > Array(SequenceableCollection)>>do: > MetacelloScriptApiExecutor>>executeString:do: > ByteString(String)>>execute:against: > MetacelloScriptApiExecutor(MetacelloScriptExecutor)>>execute: > Metacello>>execute:args: > Metacello>>load > UndefinedObject>>DoIt > OpalCompiler>>evaluate > RubSmalltalkEditor>>evaluate:andDo: > RubSmalltalkEditor>>highlightEvaluateAndDo: > [ textMorph textArea editor highlightEvaluateAndDo: ann action. > textMorph shoutStyler style: textMorph text ] in [ textMorph textArea > handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. > textMorph shoutStyler style: textMorph text ] ] in > GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: > RubEditingArea(RubAbstractTextArea)>>handleEdit: > [ textMorph textArea > handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. > textMorph shoutStyler style: textMorph text ] ] in > GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: > WorldState>>runStepMethodsIn: > WorldMorph>>runStepMethods > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > WorldMorph class>>doOneCycle > [ [ WorldMorph doOneCycle. > Processor yield. > false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess > [ self value. > Processor terminateActive ] in BlockClosure>>newProcess -- Best regards, Dennis Schetinin 2018-02-21 18:56 GMT+03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > I was loading a project via: > Metacello new > baseline: 'BabyPhexample'; > repository: 'github://seandenigris/Baby-Phexample/repository'; > onConflict: [ :ex | ex allow ]; > load. > > into a Moose 6.1 image obtained from Launcher which already contained > StateSpecs and got this: > IceUndefinedRemote(Object)>>doesNotUnderstand: #projectPath > IceMetacelloRepositoryAdapter>>projectPath > IceMetacelloRepositoryAdapter>>hasNoLoadConflicts: > MetacelloRepositorySpec>>hasNoLoadConflicts: > MetacelloRepositoriesSpec>>hasNoLoadConflicts: > MetacelloMCBaselineOfProjectSpec(MetacelloGenericProjectSpec)>> > hasNoLoadConflicts: > MetacelloMCBaselineOfProjectSpec(MetacelloMCProjectSpec)>> > hasNoLoadConflicts: > MetacelloMCBaselineOfProjectSpec(MetacelloProjectSpec)>>hasLoadConflicts: > MetacelloMCBaselineOfProjectSpec(MetacelloMCProjectSpec)>> > hasConflictWithBaselineSpec: > MetacelloMCBaselineOfProjectSpec>>hasConflictWithProjectSpec: > MetacelloProjectRegistration>>hasLoadConflicts: > > Ideas? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

April 9, 2018

Re: [Pharo-dev] Multiple Inheritance

by Esteban A. Maringolo

Are you in the "release the Kraken" mood? :) I haven't used stateful traits, and barely traits at all (when I wanted to use it extensively the tools weren't ready). But I see Traits more as a mix-in approach, rather than a multiple inheritance one. Also, in my experience building software with Smalltalk, I didn't have the need to use multiple inheritance, but I did have the need to reuse some behavior like Singleton, "named objects" (implementors of #name/#name:), and have "Interface" like behavior (as in Java's `implements ABCInterface`) I can query, and all that can be done with Traits and, IMO, it better represents the purpose of a "trait" rather than a multiple inheritance mechanism. Regards! On 09/04/2018 11:09, Sean P. DeNigris wrote: > I was just thinking about all the freedom brought by stateful traits, and the > thought occurred: why not just simplify and remove another hurdle by having > multiple inheritance with the conflict resolution and scoping of traits? > > Forgive me if I'm missing something obviousâ¦ > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- Esteban A. Maringolo

April 9, 2018

Multiple Inheritance

by Sean P. DeNigris

I was just thinking about all the freedom brought by stateful traits, and the thought occurred: why not just simplify and remove another hurdle by having multiple inheritance with the conflict resolution and scoping of traits? Forgive me if I'm missing something obviousâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 9, 2018

Re: [Pharo-dev] call for help: answer on HN :)

by Thierry Goubier

2018-04-09 15:28 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On 9 April 2018 at 14:50, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> 2018-04-09 2:18 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: >> > Even if he is a troll, he pointed out many things that aren't given >> > priority because we're building "next great stuff" and with the limited >> > resource you either stop to world to fix what's already made or you move >> > forward. >> > >> > And IMO it is true that the next great stuff is being built, a better >> > paradigm, moldability, and whatnot, but that means that, for a while, >> > tools, and the image itself won't be "rock solid", and since most things >> > are not backportable or maintained (there are no resources to have LTS >> > versions), it is hard to define what's the minimum rock-solid core on >> > which to build upon. >> >> I wonder if some things could be solved by taking a slightly different >> path... >> >> - Non rock solid base could be cared for by debugging that allways work >> >> - Not threaded image could be solved by "image sharing between processes" > > > Can you expand on this. I can't follow. Have objects freely moving between images (or being duplicated between images). Nothing really outlandish, just your standard either distributed object stuff, or software distributed shared memory (image segments could be the right abstraction). A use case: main image with full tools (one window), linked image with application-only code (one window), each time you compile a method in the main image, linked image gets it because it track system announcer changes. >> - Multiple host windows would mean forking the image > > > I presume your mean native fork(), rather than Smalltalk #fork. Exactly. Thierry > cheers -ben > >> >> >> Imagine a world where: >> - The smalltalk debugger can remote debug via gdb(*) a locked image >> (or one where you have crashed the world because you played with core >> graphics stuff)... >> - The smalltalk debugger can inject new code into a remote image via >> gdb again (**). >> - Two images can easily share objects with almost zero overhead(***) >> - One image can easily keeps its code in sync with another one (object >> duplication between images) >> >> I know of TelePharo, and, after looking at the underlying >> implementation, it's not good enough. The core undebuggability of the >> platform is not solved (at all). >> >> The undebuggability of the platform is a significant barrier. I worked >> on the SmaCC GT debugger because my students were regularly locking >> their images with it (usually something as simple as stepping over the >> end of the computation) so I've added many, many guards, to try to >> protect from that; I know think a strong limitation of exploring new >> debug modes is mainly linked to the ease of locking your image with >> it. >> >> Regards, >> >> Thierry >> >> (*) gdb over serial talking to a boot eeprom equivalent, mapped with a >> remapping of step to smalltalk instructions (like in a true debugger) >> (**) So that, from that smalltalk over gdb debugger, you can fix, >> compile and proceed >> (***) And so, no story of running a "determine the right object graph >> with more smalltalk code... ", that is too slow >> >> > E.g. The infinite walkback error pointed in this screenshot >> > https://i.imgur.com/7jiKIhd.png still chases me from time to time, and I >> > remember having reported it a long time ago, and it was considered >> > fixed. >> > >> > So I wouldn't feed the troll, but I woudln't kill the messenger either. >> > >> > Regards, >> > >> > >> > On 07/04/2018 14:26, Dimitris Chloupis wrote: >> >> yeah the guy (martin whatever) is a troll, if I remember correctly its >> >> the same dude we had on the reddit forum for Smalltalk that has been >> >> attacking Pharo with pure lies. He is a typical troll that blows off >> >> steam by annoying other people. I am with Stef with this one, the only >> >> way to win against a troll is silence. I had a very recent experience >> >> where the person in charge underestimated a troll, he overflown the >> >> mailing list with negative, many people took the bait and tried to have >> >> a civilized discussions with him, he drag it one for month until people >> >> started abandoning the community and the community essentially died. >> >> >> >> I adviced them not to feed the troll but as in many other cases, people >> >> dont even listen. >> >> >> >> Pharo is far from perfect, but this is not a logical discussion , its >> >> pure troll tactic. Do not underestimate the power of a troll, it is >> >> more >> >> powerful than you can imagine and feed on politeness and rationality. >> >> >> >> Don't feed the troll. >> >> >> >> On Sat, Apr 7, 2018 at 8:13 PM phil(a)highoctane.be >> >> <mailto:phil@highoctane.be> <phil(a)highoctane.be >> >> <mailto:phil@highoctane.be>> wrote: >> >> >> >> interruptible.. yes! >> >> >> >> On Sat, Apr 7, 2018, 19:10 Thierry Goubier >> >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> >> >> wrote: >> >> >> >> Hi Alex, >> >> >> >> Le 07/04/2018 Ã 17:48, Aliaksei Syrel a Ã©crit : >> >> > Hi >> >> > >> >> > Here is a link to a report about their experience with Pharo: >> >> > https://gitlab.fit.cvut.cz/taibrmar/sokoban-using-bloc >> >> > >> >> > There definitely exist things that should be improved. It is >> >> a >> >> pity when >> >> > tiny âminorâ issues leave such an unpleasant aftertaste. >> >> >> >> Some of them are, sadly, quite unacceptable, IMHO. >> >> >> >> I would really dream of a stable, correctly interruptible (i.e. >> >> a Cmd-. >> >> that really works), limited Pharo core. That would help >> >> development so >> >> significantly and allow more experiments. >> >> >> >> I solve that by making stuff that distance itself as much as >> >> possible >> >> from a lot of the Pharo stuff that evolves far too much, far >> >> too >> >> fast to >> >> be relied upon (widgets, graphics, editors), and I'm looking >> >> forward to >> >> building a limited(*) image with just and only the things I >> >> rely on. >> >> >> >> One of the thing I need is a CI that triggers both on my code >> >> releases >> >> and any Pharo update (including the stable ones) since even >> >> stable >> >> releases may change core APIs. >> >> >> >> > Anyway, there are lovers and haters of every language. >> >> >> >> That I can agree with :) >> >> >> >> > Some people even >> >> > give dislikes to videos on YouTube that show how >> >> veterinarians >> >> heal cats... >> >> > >> >> > All the best >> >> > Alex >> >> >> >> Regards, >> >> >> >> Thierry >> >> >> >> (*) I did try with the minimal image, and the tools are clearly >> >> limiting. >> >> >> >> > On Sat, 7 Apr 2018 at 17:27, Stephane Ducasse >> >> <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com> >> >> > <mailto:stepharo.self@gmail.com >> >> <mailto:stepharo.self@gmail.com>>> wrote: >> >> > >> >> > I tend to not care about people pissing on me via a >> >> pseudo. This is >> >> > too easy and too microscopic to have any value. >> >> > Thanks Philippe, Luke and Ben because you use your real >> >> names. >> >> > >> >> > On Thu, Apr 5, 2018 at 2:07 PM, Esteban Lorenzano >> >> > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> >> >> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> >> >> wrote: >> >> > > Hi, >> >> > > >> >> > > yesterday someone posted an article on HN about the >> >> Pharo MOOC >> >> > and there has >> >> > > been some negative posts there. >> >> > > I would like to call people who can have the time to >> >> answer there >> >> > and help >> >> > > to explain better and also contribute to contest that >> >> FUD >> >> > someones (we know >> >> > > who they areâ¦ sames as always) are spreading. >> >> > > >> >> > > here the link : >> >> https://news.ycombinator.com/item?id=16754872 >> >> > > >> >> > > (this is not loosing time, people searching for Pharo >> >> will likely >> >> > see this >> >> > > kind of messagesâ¦ at least we need to offer our point >> >> of view) >> >> > > >> >> > > cheers! >> >> > > Esteban >> >> > >> >> > -- >> >> > Cheers, >> >> > Alex >> >> >> >> >> > >> > -- >> > Esteban A. Maringolo >> > >> >

April 9, 2018

Re: [Pharo-dev] Did magritte change? Magritte-Morph-SeasnDeNigris.95 is not found

by Serge Stinckwich

On Mon, Apr 9, 2018 at 2:07 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephane Ducasse-3 wrote > > I will create one > > There is https://github.com/magritte-metamodel/magritte which I forked > from. > I wonder if we can make that canonical. It would be easy for me to sync my > changes back and from the README, it appears that most other Smalltalk load > Magritte from elsewhere. Regarding Sqeak, there are the mcz repos, and > IFAICT Squeak has not shown much interest in git, so we're probably safe > there. Either way, please coordinate with me because the StHub repo is > waaaay behind my forkâ¦ > > âYes I guess, this is better to reuse existing org on github. Sean or me can invite people. âRegards,â -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

April 9, 2018

Re: [Pharo-dev] call for help: answer on HN :)

by Ben Coman

On 9 April 2018 at 14:50, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > 2018-04-09 2:18 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > Even if he is a troll, he pointed out many things that aren't given > > priority because we're building "next great stuff" and with the limited > > resource you either stop to world to fix what's already made or you move > > forward. > > > > And IMO it is true that the next great stuff is being built, a better > > paradigm, moldability, and whatnot, but that means that, for a while, > > tools, and the image itself won't be "rock solid", and since most things > > are not backportable or maintained (there are no resources to have LTS > > versions), it is hard to define what's the minimum rock-solid core on > > which to build upon. > > I wonder if some things could be solved by taking a slightly different > path... > > - Non rock solid base could be cared for by debugging that allways work > > - Not threaded image could be solved by "image sharing between processes" > Can you expand on this. I can't follow. > > - Multiple host windows would mean forking the image > I presume your mean native fork(), rather than Smalltalk #fork. cheers -ben > > Imagine a world where: > - The smalltalk debugger can remote debug via gdb(*) a locked image > (or one where you have crashed the world because you played with core > graphics stuff)... > - The smalltalk debugger can inject new code into a remote image via > gdb again (**). > - Two images can easily share objects with almost zero overhead(***) > - One image can easily keeps its code in sync with another one (object > duplication between images) > > I know of TelePharo, and, after looking at the underlying > implementation, it's not good enough. The core undebuggability of the > platform is not solved (at all). > > The undebuggability of the platform is a significant barrier. I worked > on the SmaCC GT debugger because my students were regularly locking > their images with it (usually something as simple as stepping over the > end of the computation) so I've added many, many guards, to try to > protect from that; I know think a strong limitation of exploring new > debug modes is mainly linked to the ease of locking your image with > it. > > Regards, > > Thierry > > (*) gdb over serial talking to a boot eeprom equivalent, mapped with a > remapping of step to smalltalk instructions (like in a true debugger) > (**) So that, from that smalltalk over gdb debugger, you can fix, > compile and proceed > (***) And so, no story of running a "determine the right object graph > with more smalltalk code... ", that is too slow > > > E.g. The infinite walkback error pointed in this screenshot > > https://i.imgur.com/7jiKIhd.png still chases me from time to time, and I > > remember having reported it a long time ago, and it was considered fixed. > > > > So I wouldn't feed the troll, but I woudln't kill the messenger either. > > > > Regards, > > > > > > On 07/04/2018 14:26, Dimitris Chloupis wrote: > >> yeah the guy (martin whatever) is a troll, if I remember correctly its > >> the same dude we had on the reddit forum for Smalltalk that has been > >> attacking Pharo with pure lies. He is a typical troll that blows off > >> steam by annoying other people. I am with Stef with this one, the only > >> way to win against a troll is silence. I had a very recent experience > >> where the person in charge underestimated a troll, he overflown the > >> mailing list with negative, many people took the bait and tried to have > >> a civilized discussions with him, he drag it one for month until people > >> started abandoning the community and the community essentially died. > >> > >> I adviced them not to feed the troll but as in many other cases, people > >> dont even listen. > >> > >> Pharo is far from perfect, but this is not a logical discussion , its > >> pure troll tactic. Do not underestimate the power of a troll, it is more > >> powerful than you can imagine and feed on politeness and rationality. > >> > >> Don't feed the troll. > >> > >> On Sat, Apr 7, 2018 at 8:13 PM phil(a)highoctane.be > >> <mailto:phil@highoctane.be> <phil(a)highoctane.be > >> <mailto:phil@highoctane.be>> wrote: > >> > >> interruptible.. yes! > >> > >> On Sat, Apr 7, 2018, 19:10 Thierry Goubier > >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> > wrote: > >> > >> Hi Alex, > >> > >> Le 07/04/2018 Ã 17:48, Aliaksei Syrel a Ã©crit : > >> > Hi > >> > > >> > Here is a link to a report about their experience with Pharo: > >> > https://gitlab.fit.cvut.cz/taibrmar/sokoban-using-bloc > >> > > >> > There definitely exist things that should be improved. It is a > >> pity when > >> > tiny âminorâ issues leave such an unpleasant aftertaste. > >> > >> Some of them are, sadly, quite unacceptable, IMHO. > >> > >> I would really dream of a stable, correctly interruptible (i.e. > >> a Cmd-. > >> that really works), limited Pharo core. That would help > >> development so > >> significantly and allow more experiments. > >> > >> I solve that by making stuff that distance itself as much as > >> possible > >> from a lot of the Pharo stuff that evolves far too much, far too > >> fast to > >> be relied upon (widgets, graphics, editors), and I'm looking > >> forward to > >> building a limited(*) image with just and only the things I > rely on. > >> > >> One of the thing I need is a CI that triggers both on my code > >> releases > >> and any Pharo update (including the stable ones) since even > stable > >> releases may change core APIs. > >> > >> > Anyway, there are lovers and haters of every language. > >> > >> That I can agree with :) > >> > >> > Some people even > >> > give dislikes to videos on YouTube that show how veterinarians > >> heal cats... > >> > > >> > All the best > >> > Alex > >> > >> Regards, > >> > >> Thierry > >> > >> (*) I did try with the minimal image, and the tools are clearly > >> limiting. > >> > >> > On Sat, 7 Apr 2018 at 17:27, Stephane Ducasse > >> <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com> > >> > <mailto:stepharo.self@gmail.com > >> <mailto:stepharo.self@gmail.com>>> wrote: > >> > > >> > I tend to not care about people pissing on me via a > >> pseudo. This is > >> > too easy and too microscopic to have any value. > >> > Thanks Philippe, Luke and Ben because you use your real > names. > >> > > >> > On Thu, Apr 5, 2018 at 2:07 PM, Esteban Lorenzano > >> > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > >> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> > wrote: > >> > > Hi, > >> > > > >> > > yesterday someone posted an article on HN about the > >> Pharo MOOC > >> > and there has > >> > > been some negative posts there. > >> > > I would like to call people who can have the time to > >> answer there > >> > and help > >> > > to explain better and also contribute to contest that > FUD > >> > someones (we know > >> > > who they areâ¦ sames as always) are spreading. > >> > > > >> > > here the link : > >> https://news.ycombinator.com/item?id=16754872 > >> > > > >> > > (this is not loosing time, people searching for Pharo > >> will likely > >> > see this > >> > > kind of messagesâ¦ at least we need to offer our point > >> of view) > >> > > > >> > > cheers! > >> > > Esteban > >> > > >> > -- > >> > Cheers, > >> > Alex > >> > >> > > > > -- > > Esteban A. Maringolo > > > >

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sean P. DeNigris

Max Leske wrote > Assuming UTC is probably just as wrong as assuming the local time zone. I'll modify your statement slightly. "Assuming UTC is */almost/* as wrong as assuming the local time zone." I've never seemed to be able to drive the essential point home when these discussions have come up. Beyond all the wider issues, there is a bug, plain and simple: The offset of `'1/1/1990' asDate`, considering that you mean local time, is still not guaranteed to be the current local offset of the image, which is how we set it by default. That only makes sense if the historical date in question was in the same state of DST as the current image. For example, the historical date above is in winter, so if I eval that code in summer, it will /always/ give the objectively wrong offset. What I'm proposing is not a cure all, but a slightly-better way that fixes this bug by giving users consistent behavior that they may not want instead of inconsistent and often wrong behavior that they may not want. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 9, 2018