Class with nil environment?!
Locked
 
|
If you update at the moment, when you get to loading Morphic-fbs.663
you'll get a walkback because in Class >> #declare:, PianoRollNoteMorph's environment instvar is nil. Which is kind've odd. I thought that all classes MUST have an environment (and that right now that environment is Smalltalk). So I've tried moving Sound and Morphic (the source & destination packages for the PianoRollNoteMorph move) around in config maps, and that doesn't help. What gives? How can I fix this? frank |
Re: Class with nil environment?!
|
|
With the image you start with, PianoRollNoteMorph's environment
instvar is set correctly? But then, at some point, it gets set to nil? Does a halt catch that change? On Thu, Jul 4, 2013 at 4:00 PM, Frank Shearar <[hidden email]> wrote: > If you update at the moment, when you get to loading Morphic-fbs.663 > you'll get a walkback because in Class >> #declare:, > PianoRollNoteMorph's environment instvar is nil. > > Which is kind've odd. I thought that all classes MUST have an > environment (and that right now that environment is Smalltalk). > > So I've tried moving Sound and Morphic (the source & destination > packages for the PianoRollNoteMorph move) around in config maps, and > that doesn't help. > > What gives? How can I fix this? > > frank > |
Re: Class with nil environment?!
|
|
As it happens there are 249 classes in my starting-point image with a
nil environment, and somewhere in excess of 1k classes with environment == Smalltalk. One possibly dirty hack that seems to work is to remove the access to the instvar and use `self environment` instead (in Class >> #declare:). frank On 5 July 2013 04:30, Chris Muller <[hidden email]> wrote: > With the image you start with, PianoRollNoteMorph's environment > instvar is set correctly? But then, at some point, it gets set to > nil? Does a halt catch that change? > > On Thu, Jul 4, 2013 at 4:00 PM, Frank Shearar <[hidden email]> wrote: >> If you update at the moment, when you get to loading Morphic-fbs.663 >> you'll get a walkback because in Class >> #declare:, >> PianoRollNoteMorph's environment instvar is nil. >> >> Which is kind've odd. I thought that all classes MUST have an >> environment (and that right now that environment is Smalltalk). >> >> So I've tried moving Sound and Morphic (the source & destination >> packages for the PianoRollNoteMorph move) around in config maps, and >> that doesn't help. >> >> What gives? How can I fix this? >> >> frank >> > |
Re: Class with nil environment?!
|
|
On 5 July 2013 09:47, Frank Shearar <[hidden email]> wrote:
> As it happens there are 249 classes in my starting-point image with a > nil environment, and somewhere in excess of 1k classes with > environment == Smalltalk. > > One possibly dirty hack that seems to work is to remove the access to > the instvar and use `self environment` instead (in Class >> > #declare:). Er, so should we ever have classes with a nil environment? Is my proposed change a stinky hack, or the right thing to do to lazily fix the issue? frank > frank > > On 5 July 2013 04:30, Chris Muller <[hidden email]> wrote: >> With the image you start with, PianoRollNoteMorph's environment >> instvar is set correctly? But then, at some point, it gets set to >> nil? Does a halt catch that change? >> >> On Thu, Jul 4, 2013 at 4:00 PM, Frank Shearar <[hidden email]> wrote: >>> If you update at the moment, when you get to loading Morphic-fbs.663 >>> you'll get a walkback because in Class >> #declare:, >>> PianoRollNoteMorph's environment instvar is nil. >>> >>> Which is kind've odd. I thought that all classes MUST have an >>> environment (and that right now that environment is Smalltalk). >>> >>> So I've tried moving Sound and Morphic (the source & destination >>> packages for the PianoRollNoteMorph move) around in config maps, and >>> that doesn't help. >>> >>> What gives? How can I fix this? >>> >>> frank >>> >> |
Re: Class with nil environment?!
|
|
On Wed, Jul 10, 2013 at 6:52 AM, Frank Shearar <[hidden email]> wrote:
We should never have classes with a nil environment. |
Re: Class with nil environment?!
|
|
On 10 July 2013 19:02, Colin Putney <[hidden email]> wrote:
> > > > On Wed, Jul 10, 2013 at 6:52 AM, Frank Shearar <[hidden email]> > wrote: > >> >> Er, so should we ever have classes with a nil environment? Is my >> proposed change a stinky hack, or the right thing to do to lazily fix >> the issue? > > > We should never have classes with a nil environment. OK, that's what I thought. But I have such an image. In fact, I daresay that every alpha image produced in the 4.5 line has for months and months had such classes. Making #declare: use the #environment method instead of directly accessing the instvar "solves" the problem - Morphic-fbs.633 will load - but I have no idea if that's a good solution, or a bad, bad bandaid. frank |
Re: Class with nil environment?!
|
|
On Wed, Jul 10, 2013 at 07:21:56PM +0100, Frank Shearar wrote:
> On 10 July 2013 19:02, Colin Putney <[hidden email]> wrote: > > > > > > > > On Wed, Jul 10, 2013 at 6:52 AM, Frank Shearar <[hidden email]> > > wrote: > > > >> > >> Er, so should we ever have classes with a nil environment? Is my > >> proposed change a stinky hack, or the right thing to do to lazily fix > >> the issue? > > > > > > We should never have classes with a nil environment. > > > OK, that's what I thought. But I have such an image. In fact, I > daresay that every alpha image produced in the 4.5 line has for months > and months had such classes. Making #declare: use the #environment > method instead of directly accessing the instvar "solves" the problem > - Morphic-fbs.633 will load - but I have no idea if that's a good > solution, or a bad, bad bandaid. > I have run into the nil environment problem in the course of updating images from trunk, so I suspect there is or was some kind of problem at some point. I worked around it manually in the update whenever a debugger popped up. The "fix" was to look at the class in the debugger, and do "environment := Array environment" (I used Array, but it could be any class that does have its environment set properly). That seemed to work but I'm sure there must be a better way to do it. Is there something we should put into the trunk update stream so that other people don't get stuck on the problem during updates? Dave |
Re: Class with nil environment?!
|
|
On 10 July 2013 20:44, David T. Lewis <[hidden email]> wrote:
> On Wed, Jul 10, 2013 at 07:21:56PM +0100, Frank Shearar wrote: >> On 10 July 2013 19:02, Colin Putney <[hidden email]> wrote: >> > >> > >> > >> > On Wed, Jul 10, 2013 at 6:52 AM, Frank Shearar <[hidden email]> >> > wrote: >> > >> >> >> >> Er, so should we ever have classes with a nil environment? Is my >> >> proposed change a stinky hack, or the right thing to do to lazily fix >> >> the issue? >> > >> > >> > We should never have classes with a nil environment. >> >> >> OK, that's what I thought. But I have such an image. In fact, I >> daresay that every alpha image produced in the 4.5 line has for months >> and months had such classes. Making #declare: use the #environment >> method instead of directly accessing the instvar "solves" the problem >> - Morphic-fbs.633 will load - but I have no idea if that's a good >> solution, or a bad, bad bandaid. >> > > I have run into the nil environment problem in the course of updating > images from trunk, so I suspect there is or was some kind of problem > at some point. I worked around it manually in the update whenever a > debugger popped up. The "fix" was to look at the class in the debugger, > and do "environment := Array environment" (I used Array, but it could > be any class that does have its environment set properly). > > That seemed to work but I'm sure there must be a better way to do it. > Is there something we should put into the trunk update stream so that > other people don't get stuck on the problem during updates? > > Dave I sort've expected to see an explicit assigning of environments somewhere. But Environment class >> #install doesn't do this. It inserts itself in Smalltalk globals' place, which is great if a (class instVarNamed: 'environment') == Smalltalk globals. But if a class' environment was already nil, installing Environments would not have touched the instvar, leaving busted state. (As in, leaving busted state in the same, busted, state.) frank |
Re: Class with nil environment?!
|
|
On 10 July 2013 22:19, Frank Shearar <[hidden email]> wrote:
> On 10 July 2013 20:44, David T. Lewis <[hidden email]> wrote: >> On Wed, Jul 10, 2013 at 07:21:56PM +0100, Frank Shearar wrote: >>> On 10 July 2013 19:02, Colin Putney <[hidden email]> wrote: >>> > >>> > >>> > >>> > On Wed, Jul 10, 2013 at 6:52 AM, Frank Shearar <[hidden email]> >>> > wrote: >>> > >>> >> >>> >> Er, so should we ever have classes with a nil environment? Is my >>> >> proposed change a stinky hack, or the right thing to do to lazily fix >>> >> the issue? >>> > >>> > >>> > We should never have classes with a nil environment. >>> >>> >>> OK, that's what I thought. But I have such an image. In fact, I >>> daresay that every alpha image produced in the 4.5 line has for months >>> and months had such classes. Making #declare: use the #environment >>> method instead of directly accessing the instvar "solves" the problem >>> - Morphic-fbs.633 will load - but I have no idea if that's a good >>> solution, or a bad, bad bandaid. >>> >> >> I have run into the nil environment problem in the course of updating >> images from trunk, so I suspect there is or was some kind of problem >> at some point. I worked around it manually in the update whenever a >> debugger popped up. The "fix" was to look at the class in the debugger, >> and do "environment := Array environment" (I used Array, but it could >> be any class that does have its environment set properly). >> >> That seemed to work but I'm sure there must be a better way to do it. >> Is there something we should put into the trunk update stream so that >> other people don't get stuck on the problem during updates? >> >> Dave > > I sort've expected to see an explicit assigning of environments > somewhere. But Environment class >> #install doesn't do this. It > inserts itself in Smalltalk globals' place, which is great if a (class > instVarNamed: 'environment') == Smalltalk globals. But if a class' > environment was already nil, installing Environments would not have > touched the instvar, leaving busted state. (As in, leaving busted > state in the same, busted, state.) And lo! In a Squeak 4.4 image: (Class allSubclasses collect: #theNonMetaClass) select: [:cls | (cls instVarNamed: 'environment') isNil] "=> " an OrderedCollection(ProtoObject ObjectViewer ObjectOut BalloonState SoundCodec UndefinedObject Boolean SimpleMIDIPort FillStyle Password SharedQueue MidiPrimTester MailAddressParser WindowingTransformation FormButtonCache BalloonEdgeData View AbstractScoreEvent LimitingLineStreamWrapper Message EllipseMidpointTracer DamageRecorder ImageReadWriter TextContainer MIDIScore ClassCategoryReader BalloonSolidFillSimulation MorphExtension MIDISynth MIMEDocument FWT TextAttribute MIDIFileReader Stream Link BalloonBuffer SerialPort MimeConverter CornerRounder CompressedBoundaryShape MailAddressToken BalloonLineSimulation DiskProxy LineSegment Point DisplayObject CompressedSoundData InstructionStream BalloonFillData GraphicSymbolInstance PluggableTest KeyboardBuffer ParseStack Morph MIDISynthChannel DisplayTransform ObjectScanner Envelope SampledInstrument MIDIInputParser ClassBuilder FFT ExceptionSet ObjectViewer WaveletCodec MuLawCodec GSMCodec ADPCMCodec True False OrientedFillStyle SolidFillStyle Pen WarpBlt FormView DisplayTextView StringHolderView ListView PluggableButtonView Number LookupKey NoteEvent ControlChangeEvent PitchBendEvent ProgramChangeEvent AmbientEvent TempoEvent DualChangeSorter TranslucentColor PCXReadWriter XBMReadWriter Quadrangle Bag SequenceableCollection TextAction TextKern TextEmphasis TextIndent TextColor TextFontChange PositionableStream DummyStream QuotedPrintableMimeConverter RepeatingSound ScorePlayer SequentialSound RestSound ReverbSound FMSound PluckedSound MixedSound UnixFileDirectory DosFileDirectory Bezier2Segment Bezier3Segment DisplayText DisplayMedium Path InfiniteForm GenericUrl PianoRollNoteMorph ImageMorph MenuLineMorph StringMorph BorderedMorph MovieMorph MatrixTransform2x3 CompositeTransform MorphicTransform VolumeEnvelope RandomEnvelope PitchEnvelope SoundInputStream AssignmentNode DecompilerConstructor CascadeNode BraceNode Error IllegalResumeAttempt Notification FormMenuController ModalController NoController BitmapFillStyle FormHolderView FormInspectView FillInTheBlankView PluggableTextView PluggableListView FormEditorView ColorSystemView Fraction Association SyntaxError SelectorBrowser ArrayedCollection LinkedList OrderedCollection Interval TextDoIt TextLink TextURL TextFontReference ReadStream WriteStream RFC2047MimeConverter FMClarinetSound FMBassoonSound UnloadedSound Form Spline CurveFitter Line LinearFit Arc BlockContext MailtoUrl BrowserUrl HttpUrl FtpUrl ThreePhaseButtonMorph Sonogram PopUpChoiceMorph MorphicModel RectangleMorph Canvas SelectorNode VariableNode LiteralNode MessageAsTempNode ExceptionAboutToReturn Warning PluggableListViewByItem SmallInteger LargePositiveInteger WeakKeyAssociation OrderedCollectionInspector DictionaryInspector InspectorBrowser ChangeList WordArray RunArray Array ShortIntegerArray Bitmap FloatArray ShortRunArray ByteArray IntegerArray Semaphore GraphicSymbol TextLineInterval IdentityDictionary WeakValueDictionary PluggableDictionary TextSqkPageLink LimitedWriteStream ReadWriteStream TextStream ListParagraph ColorForm Circle NameStringInHalo ProjectController ListController LargeNegativeInteger ChangeListForProjects FileContentsBrowser PackagePaneBrowser ChangedMessageSet RecentMessageSet TimeProfileBrowser ShortPointArray PointArray RWBinaryOrTextStream Transcripter CursorWithMask PreDebugWindow SystemWindowWithButton ScorePlayerMorph UpdatingSimpleButtonMorph TextMorphForEditView StringMorphEditor ColorPatchCanvas PluggableListController PluggableListControllerOfMany FillInTheBlankController PluggableTextController ReadOnlyTextController) Note PianoRollNoteMorph's presence in the list! So. It's not Environments' fault, because it just replaced Smalltalk globals. It's just long old busted state. We thus need (a) an update step to fix the busted state or (b) lazily correct it. > frank |
Re: Class with nil environment?!
|
|
Not sure why you think it's busted. It's been
that way for a very long time and Class>>environment seems
to take care of things:
environment environment == nil ifTrue: [^ super environment]. ^ environment Cheers, Bob On 7/10/13 5:38 PM, Frank Shearar
wrote:
On 10 July 2013 22:19, Frank Shearar [hidden email] wrote:On 10 July 2013 20:44, David T. Lewis [hidden email] wrote:On Wed, Jul 10, 2013 at 07:21:56PM +0100, Frank Shearar wrote:On 10 July 2013 19:02, Colin Putney [hidden email] wrote:On Wed, Jul 10, 2013 at 6:52 AM, Frank Shearar [hidden email] wrote:Er, so should we ever have classes with a nil environment? Is my proposed change a stinky hack, or the right thing to do to lazily fix the issue?We should never have classes with a nil environment.OK, that's what I thought. But I have such an image. In fact, I daresay that every alpha image produced in the 4.5 line has for months and months had such classes. Making #declare: use the #environment method instead of directly accessing the instvar "solves" the problem - Morphic-fbs.633 will load - but I have no idea if that's a good solution, or a bad, bad bandaid.I have run into the nil environment problem in the course of updating images from trunk, so I suspect there is or was some kind of problem at some point. I worked around it manually in the update whenever a debugger popped up. The "fix" was to look at the class in the debugger, and do "environment := Array environment" (I used Array, but it could be any class that does have its environment set properly). That seemed to work but I'm sure there must be a better way to do it. Is there something we should put into the trunk update stream so that other people don't get stuck on the problem during updates? DaveI sort've expected to see an explicit assigning of environments somewhere. But Environment class >> #install doesn't do this. It inserts itself in Smalltalk globals' place, which is great if a (class instVarNamed: 'environment') == Smalltalk globals. But if a class' environment was already nil, installing Environments would not have touched the instvar, leaving busted state. (As in, leaving busted state in the same, busted, state.)And lo! In a Squeak 4.4 image: (Class allSubclasses collect: #theNonMetaClass) select: [:cls | (cls instVarNamed: 'environment') isNil] "=> " an OrderedCollection(ProtoObject ObjectViewer ObjectOut BalloonState SoundCodec UndefinedObject Boolean SimpleMIDIPort FillStyle Password SharedQueue MidiPrimTester MailAddressParser WindowingTransformation FormButtonCache BalloonEdgeData View AbstractScoreEvent LimitingLineStreamWrapper Message EllipseMidpointTracer DamageRecorder ImageReadWriter TextContainer MIDIScore ClassCategoryReader BalloonSolidFillSimulation MorphExtension MIDISynth MIMEDocument FWT TextAttribute MIDIFileReader Stream Link BalloonBuffer SerialPort MimeConverter CornerRounder CompressedBoundaryShape MailAddressToken BalloonLineSimulation DiskProxy LineSegment Point DisplayObject CompressedSoundData InstructionStream BalloonFillData GraphicSymbolInstance PluggableTest KeyboardBuffer ParseStack Morph MIDISynthChannel DisplayTransform ObjectScanner Envelope SampledInstrument MIDIInputParser ClassBuilder FFT ExceptionSet ObjectViewer WaveletCodec MuLawCodec GSMCodec ADPCMCodec True False OrientedFillStyle SolidFillStyle Pen WarpBlt FormView DisplayTextView StringHolderView ListView PluggableButtonView Number LookupKey NoteEvent ControlChangeEvent PitchBendEvent ProgramChangeEvent AmbientEvent TempoEvent DualChangeSorter TranslucentColor PCXReadWriter XBMReadWriter Quadrangle Bag SequenceableCollection TextAction TextKern TextEmphasis TextIndent TextColor TextFontChange PositionableStream DummyStream QuotedPrintableMimeConverter RepeatingSound ScorePlayer SequentialSound RestSound ReverbSound FMSound PluckedSound MixedSound UnixFileDirectory DosFileDirectory Bezier2Segment Bezier3Segment DisplayText DisplayMedium Path InfiniteForm GenericUrl PianoRollNoteMorph ImageMorph MenuLineMorph StringMorph BorderedMorph MovieMorph MatrixTransform2x3 CompositeTransform MorphicTransform VolumeEnvelope RandomEnvelope PitchEnvelope SoundInputStream AssignmentNode DecompilerConstructor CascadeNode BraceNode Error IllegalResumeAttempt Notification FormMenuController ModalController NoController BitmapFillStyle FormHolderView FormInspectView FillInTheBlankView PluggableTextView PluggableListView FormEditorView ColorSystemView Fraction Association SyntaxError SelectorBrowser ArrayedCollection LinkedList OrderedCollection Interval TextDoIt TextLink TextURL TextFontReference ReadStream WriteStream RFC2047MimeConverter FMClarinetSound FMBassoonSound UnloadedSound Form Spline CurveFitter Line LinearFit Arc BlockContext MailtoUrl BrowserUrl HttpUrl FtpUrl ThreePhaseButtonMorph Sonogram PopUpChoiceMorph MorphicModel RectangleMorph Canvas SelectorNode VariableNode LiteralNode MessageAsTempNode ExceptionAboutToReturn Warning PluggableListViewByItem SmallInteger LargePositiveInteger WeakKeyAssociation OrderedCollectionInspector DictionaryInspector InspectorBrowser ChangeList WordArray RunArray Array ShortIntegerArray Bitmap FloatArray ShortRunArray ByteArray IntegerArray Semaphore GraphicSymbol TextLineInterval IdentityDictionary WeakValueDictionary PluggableDictionary TextSqkPageLink LimitedWriteStream ReadWriteStream TextStream ListParagraph ColorForm Circle NameStringInHalo ProjectController ListController LargeNegativeInteger ChangeListForProjects FileContentsBrowser PackagePaneBrowser ChangedMessageSet RecentMessageSet TimeProfileBrowser ShortPointArray PointArray RWBinaryOrTextStream Transcripter CursorWithMask PreDebugWindow SystemWindowWithButton ScorePlayerMorph UpdatingSimpleButtonMorph TextMorphForEditView StringMorphEditor ColorPatchCanvas PluggableListController PluggableListControllerOfMany FillInTheBlankController PluggableTextController ReadOnlyTextController) Note PianoRollNoteMorph's presence in the list! So. It's not Environments' fault, because it just replaced Smalltalk globals. It's just long old busted state. We thus need (a) an update step to fix the busted state or (b) lazily correct it.frank |
Re: Class with nil environment?!
|
|
Well, with my nil-hating hat on, I'd say that Class >> #environment is
also busted. There's no value in having environment = nil. You're not saving any space, for instance. What you _do_ have is a piece of uninitialised state, waiting for someone to reference the instvar directly (as Class >> #declare: does) and fail with an MNU on nil. I'm waiting to hear what Colin has to say, but I'd say that Class >> #declare: has every reason to assume that an instvar's initialised, and that #environment should simply say "^ environment". And that we need _something_ to crawl the Class instances and fix the instvar, of course. So _maybe_ saying ^ environment ifNil: [environment := Smalltalk globals] might be OK in #environment. frank On 10 July 2013 22:49, Bob Arning <[hidden email]> wrote: > Not sure why you think it's busted. It's been that way for a very long time > and Class>>environment seems to take care of things: > > environment > > environment == nil ifTrue: [^ super environment]. > ^ environment > > Cheers, > Bob > > On 7/10/13 5:38 PM, Frank Shearar wrote: > > On 10 July 2013 22:19, Frank Shearar <[hidden email]> wrote: > > On 10 July 2013 20:44, David T. Lewis <[hidden email]> wrote: > > On Wed, Jul 10, 2013 at 07:21:56PM +0100, Frank Shearar wrote: > > On 10 July 2013 19:02, Colin Putney <[hidden email]> wrote: > > > On Wed, Jul 10, 2013 at 6:52 AM, Frank Shearar <[hidden email]> > wrote: > > Er, so should we ever have classes with a nil environment? Is my > proposed change a stinky hack, or the right thing to do to lazily fix > the issue? > > We should never have classes with a nil environment. > > OK, that's what I thought. But I have such an image. In fact, I > daresay that every alpha image produced in the 4.5 line has for months > and months had such classes. Making #declare: use the #environment > method instead of directly accessing the instvar "solves" the problem > - Morphic-fbs.633 will load - but I have no idea if that's a good > solution, or a bad, bad bandaid. > > I have run into the nil environment problem in the course of updating > images from trunk, so I suspect there is or was some kind of problem > at some point. I worked around it manually in the update whenever a > debugger popped up. The "fix" was to look at the class in the debugger, > and do "environment := Array environment" (I used Array, but it could > be any class that does have its environment set properly). > > That seemed to work but I'm sure there must be a better way to do it. > Is there something we should put into the trunk update stream so that > other people don't get stuck on the problem during updates? > > Dave > > I sort've expected to see an explicit assigning of environments > somewhere. But Environment class >> #install doesn't do this. It > inserts itself in Smalltalk globals' place, which is great if a (class > instVarNamed: 'environment') == Smalltalk globals. But if a class' > environment was already nil, installing Environments would not have > touched the instvar, leaving busted state. (As in, leaving busted > state in the same, busted, state.) > > And lo! In a Squeak 4.4 image: > > (Class allSubclasses collect: #theNonMetaClass) select: [:cls | (cls > instVarNamed: 'environment') isNil] > "=> " an OrderedCollection(ProtoObject ObjectViewer ObjectOut > BalloonState SoundCodec UndefinedObject Boolean SimpleMIDIPort > FillStyle Password SharedQueue MidiPrimTester MailAddressParser > WindowingTransformation FormButtonCache BalloonEdgeData View > AbstractScoreEvent LimitingLineStreamWrapper Message > EllipseMidpointTracer DamageRecorder ImageReadWriter TextContainer > MIDIScore ClassCategoryReader BalloonSolidFillSimulation > MorphExtension MIDISynth MIMEDocument FWT TextAttribute MIDIFileReader > Stream Link BalloonBuffer SerialPort MimeConverter CornerRounder > CompressedBoundaryShape MailAddressToken BalloonLineSimulation > DiskProxy LineSegment Point DisplayObject CompressedSoundData > InstructionStream BalloonFillData GraphicSymbolInstance PluggableTest > KeyboardBuffer ParseStack Morph MIDISynthChannel DisplayTransform > ObjectScanner Envelope SampledInstrument MIDIInputParser ClassBuilder > FFT ExceptionSet ObjectViewer WaveletCodec MuLawCodec GSMCodec > ADPCMCodec True False OrientedFillStyle SolidFillStyle Pen WarpBlt > FormView DisplayTextView StringHolderView ListView PluggableButtonView > Number LookupKey NoteEvent ControlChangeEvent PitchBendEvent > ProgramChangeEvent AmbientEvent TempoEvent DualChangeSorter > TranslucentColor PCXReadWriter XBMReadWriter Quadrangle Bag > SequenceableCollection TextAction TextKern TextEmphasis TextIndent > TextColor TextFontChange PositionableStream DummyStream > QuotedPrintableMimeConverter RepeatingSound ScorePlayer > SequentialSound RestSound ReverbSound FMSound PluckedSound MixedSound > UnixFileDirectory DosFileDirectory Bezier2Segment Bezier3Segment > DisplayText DisplayMedium Path InfiniteForm GenericUrl > PianoRollNoteMorph ImageMorph MenuLineMorph StringMorph BorderedMorph > MovieMorph MatrixTransform2x3 CompositeTransform MorphicTransform > VolumeEnvelope RandomEnvelope PitchEnvelope SoundInputStream > AssignmentNode DecompilerConstructor CascadeNode BraceNode Error > IllegalResumeAttempt Notification FormMenuController ModalController > NoController BitmapFillStyle FormHolderView FormInspectView > FillInTheBlankView PluggableTextView PluggableListView FormEditorView > ColorSystemView Fraction Association SyntaxError SelectorBrowser > ArrayedCollection LinkedList OrderedCollection Interval TextDoIt > TextLink TextURL TextFontReference ReadStream WriteStream > RFC2047MimeConverter FMClarinetSound FMBassoonSound UnloadedSound Form > Spline CurveFitter Line LinearFit Arc BlockContext MailtoUrl > BrowserUrl HttpUrl FtpUrl ThreePhaseButtonMorph Sonogram > PopUpChoiceMorph MorphicModel RectangleMorph Canvas SelectorNode > VariableNode LiteralNode MessageAsTempNode ExceptionAboutToReturn > Warning PluggableListViewByItem SmallInteger LargePositiveInteger > WeakKeyAssociation OrderedCollectionInspector DictionaryInspector > InspectorBrowser ChangeList WordArray RunArray Array ShortIntegerArray > Bitmap FloatArray ShortRunArray ByteArray IntegerArray Semaphore > GraphicSymbol TextLineInterval IdentityDictionary WeakValueDictionary > PluggableDictionary TextSqkPageLink LimitedWriteStream ReadWriteStream > TextStream ListParagraph ColorForm Circle NameStringInHalo > ProjectController ListController LargeNegativeInteger > ChangeListForProjects FileContentsBrowser PackagePaneBrowser > ChangedMessageSet RecentMessageSet TimeProfileBrowser ShortPointArray > PointArray RWBinaryOrTextStream Transcripter CursorWithMask > PreDebugWindow SystemWindowWithButton ScorePlayerMorph > UpdatingSimpleButtonMorph TextMorphForEditView StringMorphEditor > ColorPatchCanvas PluggableListController PluggableListControllerOfMany > FillInTheBlankController PluggableTextController > ReadOnlyTextController) > > Note PianoRollNoteMorph's presence in the list! So. It's not > Environments' fault, because it just replaced Smalltalk globals. It's > just long old busted state. We thus need (a) an update step to fix the > busted state or (b) lazily correct it. > > frank > > > > > |
Re: Class with nil environment?!
|
|
On 7/10/13 5:59 PM, Frank Shearar wrote: > Well, with my nil-hating hat on, I'd say that Class >> #environment is > also busted. There's no value in having environment = nil. It allows subclasses to track the superclass environment. You can change the environment for a class and all subclasses that have not explicitly declared an environment will share it. Subclasses that have had an explicit environment set will keep that that even when the superclass changes. > You're not > saving any space, for instance. What you _do_ have is a piece of > uninitialised state, waiting for someone to reference the instvar > directly (as Class >> #declare: does) and fail with an MNU on nil. > > I'm waiting to hear what Colin has to say, but I'd say that Class >> > #declare: has every reason to assume that an instvar's initialised, > and that #environment should simply say "^ environment". The counter-argument, of course, is to use the accessors and not tinker directly with the instvars unless you are sure you know what you are doing. > And that we > need _something_ to crawl the Class instances and fix the instvar, of > course. So _maybe_ saying ^ environment ifNil: [environment := > Smalltalk globals] might be OK in #environment. > > frank > > On 10 July 2013 22:49, Bob Arning <[hidden email]> wrote: >> Not sure why you think it's busted. It's been that way for a very long time >> and Class>>environment seems to take care of things: >> >> environment >> >> environment == nil ifTrue: [^ super environment]. >> ^ environment >> >> Cheers, >> Bob >> >> On 7/10/13 5:38 PM, Frank Shearar wrote: >> >> On 10 July 2013 22:19, Frank Shearar <[hidden email]> wrote: >> >> On 10 July 2013 20:44, David T. Lewis <[hidden email]> wrote: >> >> On Wed, Jul 10, 2013 at 07:21:56PM +0100, Frank Shearar wrote: >> >> On 10 July 2013 19:02, Colin Putney <[hidden email]> wrote: >> >> >> On Wed, Jul 10, 2013 at 6:52 AM, Frank Shearar <[hidden email]> >> wrote: >> >> Er, so should we ever have classes with a nil environment? Is my >> proposed change a stinky hack, or the right thing to do to lazily fix >> the issue? >> >> We should never have classes with a nil environment. >> >> OK, that's what I thought. But I have such an image. In fact, I >> daresay that every alpha image produced in the 4.5 line has for months >> and months had such classes. Making #declare: use the #environment >> method instead of directly accessing the instvar "solves" the problem >> - Morphic-fbs.633 will load - but I have no idea if that's a good >> solution, or a bad, bad bandaid. >> >> I have run into the nil environment problem in the course of updating >> images from trunk, so I suspect there is or was some kind of problem >> at some point. I worked around it manually in the update whenever a >> debugger popped up. The "fix" was to look at the class in the debugger, >> and do "environment := Array environment" (I used Array, but it could >> be any class that does have its environment set properly). >> >> That seemed to work but I'm sure there must be a better way to do it. >> Is there something we should put into the trunk update stream so that >> other people don't get stuck on the problem during updates? >> >> Dave >> >> I sort've expected to see an explicit assigning of environments >> somewhere. But Environment class >> #install doesn't do this. It >> inserts itself in Smalltalk globals' place, which is great if a (class >> instVarNamed: 'environment') == Smalltalk globals. But if a class' >> environment was already nil, installing Environments would not have >> touched the instvar, leaving busted state. (As in, leaving busted >> state in the same, busted, state.) >> >> And lo! In a Squeak 4.4 image: >> >> (Class allSubclasses collect: #theNonMetaClass) select: [:cls | (cls >> instVarNamed: 'environment') isNil] >> "=> " an OrderedCollection(ProtoObject ObjectViewer ObjectOut >> BalloonState SoundCodec UndefinedObject Boolean SimpleMIDIPort >> FillStyle Password SharedQueue MidiPrimTester MailAddressParser >> WindowingTransformation FormButtonCache BalloonEdgeData View >> AbstractScoreEvent LimitingLineStreamWrapper Message >> EllipseMidpointTracer DamageRecorder ImageReadWriter TextContainer >> MIDIScore ClassCategoryReader BalloonSolidFillSimulation >> MorphExtension MIDISynth MIMEDocument FWT TextAttribute MIDIFileReader >> Stream Link BalloonBuffer SerialPort MimeConverter CornerRounder >> CompressedBoundaryShape MailAddressToken BalloonLineSimulation >> DiskProxy LineSegment Point DisplayObject CompressedSoundData >> InstructionStream BalloonFillData GraphicSymbolInstance PluggableTest >> KeyboardBuffer ParseStack Morph MIDISynthChannel DisplayTransform >> ObjectScanner Envelope SampledInstrument MIDIInputParser ClassBuilder >> FFT ExceptionSet ObjectViewer WaveletCodec MuLawCodec GSMCodec >> ADPCMCodec True False OrientedFillStyle SolidFillStyle Pen WarpBlt >> FormView DisplayTextView StringHolderView ListView PluggableButtonView >> Number LookupKey NoteEvent ControlChangeEvent PitchBendEvent >> ProgramChangeEvent AmbientEvent TempoEvent DualChangeSorter >> TranslucentColor PCXReadWriter XBMReadWriter Quadrangle Bag >> SequenceableCollection TextAction TextKern TextEmphasis TextIndent >> TextColor TextFontChange PositionableStream DummyStream >> QuotedPrintableMimeConverter RepeatingSound ScorePlayer >> SequentialSound RestSound ReverbSound FMSound PluckedSound MixedSound >> UnixFileDirectory DosFileDirectory Bezier2Segment Bezier3Segment >> DisplayText DisplayMedium Path InfiniteForm GenericUrl >> PianoRollNoteMorph ImageMorph MenuLineMorph StringMorph BorderedMorph >> MovieMorph MatrixTransform2x3 CompositeTransform MorphicTransform >> VolumeEnvelope RandomEnvelope PitchEnvelope SoundInputStream >> AssignmentNode DecompilerConstructor CascadeNode BraceNode Error >> IllegalResumeAttempt Notification FormMenuController ModalController >> NoController BitmapFillStyle FormHolderView FormInspectView >> FillInTheBlankView PluggableTextView PluggableListView FormEditorView >> ColorSystemView Fraction Association SyntaxError SelectorBrowser >> ArrayedCollection LinkedList OrderedCollection Interval TextDoIt >> TextLink TextURL TextFontReference ReadStream WriteStream >> RFC2047MimeConverter FMClarinetSound FMBassoonSound UnloadedSound Form >> Spline CurveFitter Line LinearFit Arc BlockContext MailtoUrl >> BrowserUrl HttpUrl FtpUrl ThreePhaseButtonMorph Sonogram >> PopUpChoiceMorph MorphicModel RectangleMorph Canvas SelectorNode >> VariableNode LiteralNode MessageAsTempNode ExceptionAboutToReturn >> Warning PluggableListViewByItem SmallInteger LargePositiveInteger >> WeakKeyAssociation OrderedCollectionInspector DictionaryInspector >> InspectorBrowser ChangeList WordArray RunArray Array ShortIntegerArray >> Bitmap FloatArray ShortRunArray ByteArray IntegerArray Semaphore >> GraphicSymbol TextLineInterval IdentityDictionary WeakValueDictionary >> PluggableDictionary TextSqkPageLink LimitedWriteStream ReadWriteStream >> TextStream ListParagraph ColorForm Circle NameStringInHalo >> ProjectController ListController LargeNegativeInteger >> ChangeListForProjects FileContentsBrowser PackagePaneBrowser >> ChangedMessageSet RecentMessageSet TimeProfileBrowser ShortPointArray >> PointArray RWBinaryOrTextStream Transcripter CursorWithMask >> PreDebugWindow SystemWindowWithButton ScorePlayerMorph >> UpdatingSimpleButtonMorph TextMorphForEditView StringMorphEditor >> ColorPatchCanvas PluggableListController PluggableListControllerOfMany >> FillInTheBlankController PluggableTextController >> ReadOnlyTextController) >> >> Note PianoRollNoteMorph's presence in the list! So. It's not >> Environments' fault, because it just replaced Smalltalk globals. It's >> just long old busted state. We thus need (a) an update step to fix the >> busted state or (b) lazily correct it. >> >> frank >> >> >> >> >> > |
Re: Class with nil environment?!
|
|
On Wed, Jul 10, 2013 at 06:50:09PM -0400, Bob Arning wrote:
> > On 7/10/13 5:59 PM, Frank Shearar wrote: > >Well, with my nil-hating hat on, I'd say that Class >> #environment is > >also busted. There's no value in having environment = nil. Well ok but ... this isn't Java you know, so you don't need to hate a perfectly respectable object just because it happens to represent nothingness ;-) > > It allows subclasses to track the superclass environment. You can change > the environment for a class and all subclasses that have not explicitly > declared an environment will share it. Subclasses that have had an > explicit environment set will keep that that even when the superclass > changes. > > >You're not > >saving any space, for instance. What you _do_ have is a piece of > >uninitialised state, waiting for someone to reference the instvar > >directly (as Class >> #declare: does) and fail with an MNU on nil. > > > >I'm waiting to hear what Colin has to say, but I'd say that Class >> > >#declare: has every reason to assume that an instvar's initialised, > >and that #environment should simply say "^ environment". > > The counter-argument, of course, is to use the accessors and not tinker > directly with the instvars unless you are sure you know what you are doing. That sounds like good advice to me. And I agree with Frank that we should hear what Colin has to say about it. Dave |
Re: Class with nil environment?!
|
|
On 11 July 2013 01:01, David T. Lewis <[hidden email]> wrote:
> On Wed, Jul 10, 2013 at 06:50:09PM -0400, Bob Arning wrote: >> >> On 7/10/13 5:59 PM, Frank Shearar wrote: >> >Well, with my nil-hating hat on, I'd say that Class >> #environment is >> >also busted. There's no value in having environment = nil. > > Well ok but ... this isn't Java you know, so you don't need to hate > a perfectly respectable object just because it happens to represent > nothingness ;-) Class >> environment environment = #deferToSuperclass ifTrue: [ ^ super environment ]. ^ environment would still give the whatever-my-superclass-does while also clearly indicating that noone accidentally forgot to initialise the instvar. Not a nil in sight! >> It allows subclasses to track the superclass environment. You can change >> the environment for a class and all subclasses that have not explicitly >> declared an environment will share it. Subclasses that have had an >> explicit environment set will keep that that even when the superclass >> changes. Fair enough. That suggests to me that Class >> #declare: _must_ use `self environment` rather than access the instvar directly. I'm more than happy to make the change, once we hear back from Colin. (Nudge.) >> >You're not >> >saving any space, for instance. What you _do_ have is a piece of >> >uninitialised state, waiting for someone to reference the instvar >> >directly (as Class >> #declare: does) and fail with an MNU on nil. >> > >> >I'm waiting to hear what Colin has to say, but I'd say that Class >> >> >#declare: has every reason to assume that an instvar's initialised, >> >and that #environment should simply say "^ environment". >> >> The counter-argument, of course, is to use the accessors and not tinker >> directly with the instvars unless you are sure you know what you are doing. > > That sounds like good advice to me. > > And I agree with Frank that we should hear what Colin has to say about it. > > Dave frank |
|
|
>
> Class >> environment > environment = #deferToSuperclass ifTrue: [ ^ super environment ]. > ^ environment > > would still give the whatever-my-superclass-does while also clearly > indicating that noone accidentally forgot to initialise the instvar. > Not a nil in sight! nil is a pretty standard way of indicating nothing…. A decent comment would have solved this issue before it became an issue. Another way of implementing similar functionality without even having a class instance variable (wait a minute, is an instance variable of class Class a class variable or a class' instance variable or an instance of class class instance variable or what?) would just use normal method inheritance and global(ish) variables for the environments - (root class)> environment ^RootEnvironment (some other class)>environment ^SpecialEnvironment Of course, you have to be able to look up SpecialEnvironment in your environment that applies when you compile that, which maybe isn't SpecialEnvironment? And obviously it doesn't allow for resetting the environment on the fly (except with a recompile) But seriously, having code that says do I have Thing set? If so, return my Thing, otherwise return what my parent thinks Thing is is pretty common in any hierarchy. I really think that fixing it with a comment is the most useful answer. But then I wouldn't accept a bit of code that didn't have a clear, meaningful comment in any code review. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Comment my code? Why do you think it's called 'code'? |
Re: Class with nil environment?!
|
|
On 11 July 2013 18:07, tim Rowledge <[hidden email]> wrote:
>> >> Class >> environment >> environment = #deferToSuperclass ifTrue: [ ^ super environment ]. >> ^ environment >> >> would still give the whatever-my-superclass-does while also clearly >> indicating that noone accidentally forgot to initialise the instvar. >> Not a nil in sight! > > nil is a pretty standard way of indicating nothing…. It's an excellent way of leaving the reader puzzling "is this nothing, or did the author just not bother to initialise this variable?" It's the kind of thing that makes far distant code fail (admittedly not in this case), leaving you wondering "do where did this nil come from, anyway?" Or remember the hilarity around wanting a nil in a Set, only nil was also used as the theres-a-space-here marker. Simply using a unique sentinel object removes the uninitialised/missing confusion. > A decent comment would have solved this issue before it became an issue. I don't think it would have, actually. Not in this instance. But ANYWAY, there is a proposed solution that needs careful eyes and brains to look at and ponder over: make Class >> #declare: send the #environment message instead of accessing the instvar directly. frank > Another way of implementing similar functionality without even having a class instance variable (wait a minute, is an instance variable of class Class a class variable or a class' instance variable or an instance of class class instance variable or what?) would just use normal method inheritance and global(ish) variables for the environments - > > (root class)> environment > ^RootEnvironment > > (some other class)>environment > ^SpecialEnvironment > > Of course, you have to be able to look up SpecialEnvironment in your environment that applies when you compile that, which maybe isn't SpecialEnvironment? And obviously it doesn't allow for resetting the environment on the fly (except with a recompile) > > But seriously, having code that says > do I have Thing set? If so, return my Thing, otherwise return what my parent thinks Thing is > is pretty common in any hierarchy. I really think that fixing it with a comment is the most useful answer. But then I wouldn't accept a bit of code that didn't have a clear, meaningful comment in any code review. > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Comment my code? Why do you think it's called 'code'? > > > |
|
|
On 11-07-2013, at 11:25 AM, Frank Shearar <[hidden email]> wrote: > But ANYWAY, there is a proposed solution that needs careful eyes and > brains to look at and ponder over: make Class >> #declare: send the > #environment message instead of accessing the instvar directly. There are lots of good reasons for rarely referring to instance variables directly and this is one good example. Personally I'm not keen on using the same name for the message if at all possible; I really hate to see code that reads like a bad C program "foo list first top left" etc. Ought to be more like "foo firstBlockTopLeft" with obvious methods in appropriate classes. Yes, this makes for many more methods in the image. That's what images are for. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim An elephant is a mouse with an operating system. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |