- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sven Van Caekenberghe

> On 9 Apr 2018, at 18:52, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe-2 wrote >> I think that making Date always UTC will probably not help, because you >> will want to be able to move between timezones > > Two things: > - I don't think changing timezones will be affected, because my proposal is > only: "default to 0 offset for new Date[AndTime] instances where no offset > is specified". This would not prevent changing the offset later on (although > one would make the case that since guessing default offset is unfixable in > practice in the core, it should be removed altogether), and it also wouldn't > affect the offset of the image, so `Date today` would still use the local > offset. > - I'm not saying that it is a panacea, but it will avoid the bug in > question. It is less wrong than the current behavior and will allow those of > us on DST to keep our sanity while we come up with a more perfect long term > solution. > > What is the downside to this change? So you want to change '1/1/1990' asDate. so that it does the equivalent of (DateAndTime fromString: '1990-01-01T00:00:00Z') asDate. While you would not want to change Date today. so that it does the equivalent of DateAndTime now asUTC asDate. ? Is that the key change ? And why not the second ? > ----- > 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 Sean P. DeNigris

Dennis Schetinin wrote > did you resolve the problem? I can't reproduce. I followed the same steps just now and it worked in Moose 6.1 on top of Pharo 60540 It did however give me a warning that there were unsaved changes in StateSpecs-DSL-ClassWords-Tests. When I tried to browse the changes in MC Browser, I got "Instance of IceMetacelloRepositoryAdapter did not understand #closestAncestorVersionFor:ifNone:" ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > I think that making Date always UTC will probably not help, because you > will want to be able to move between timezones Two things: - I don't think changing timezones will be affected, because my proposal is only: "default to 0 offset for new Date[AndTime] instances where no offset is specified". This would not prevent changing the offset later on (although one would make the case that since guessing default offset is unfixable in practice in the core, it should be removed altogether), and it also wouldn't affect the offset of the image, so `Date today` would still use the local offset. - I'm not saying that it is a panacea, but it will avoid the bug in question. It is less wrong than the current behavior and will allow those of us on DST to keep our sanity while we come up with a more perfect long term solution. What is the downside to this change? ----- 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 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