The Trunk: Collections-dtl.548.mcz

> >
> >
> > > Because there has been no concrete vision/requirement for a Morphic-based
> > > emergency evaluator (EE).  EE is a relatively rare occurrence (one would
> > > hope!) and for developers only.  But developers typically use
> > _development
> > > images_ which tend to be fat, not "Stripped", and so might probably
> > include
> > > ST80 anyway..?  The cases seem pretty uncertain and so that's why I'm
> > > questioning engineering new stuff like this into the image.
> >
> > This is a bug. It needs to be fixed. It's not new functionality,
> > unless by "new" you mean "it actually works in Morphic".
> >
>
> By new I meant, "it works when ST80 is unloaded."
>
>
> > > Particularly we're at a time when I want to get 4.5 out the door, so that
> > > may be contributing to my aversion to new engineerings.  I ask you to at
> > > least consider simple stub error-handling in situations where
> > > packages/functionality would be unfulfilled.  We can fill in
> > implementations
> > > later, if needed, but at least you'll have made the structure.
> >
> > So you'll be happy with
> >
> > * move the current EE to ST-80,
> > * fix the EE for Morphic (at some point),
> > * add an AppRegistry for the EE (which is just a hook like ToolSet and
> > friends, so we don't tangle the two UI frameworks we have so carefully
> > untangled)
> >
> > ? If there's a simpler solution, I'm all ears.
> >
> >
> I too swamped to dig in today and know.  If its small and no potential
> issue for 4.5, I probably won't complain anymore.  But, in general, I do
> hope extreme TSTTCPW will be considered for cases during the detangling
> process.  We have a dynamic programming system.  We wax about developing in
> the debugger.  It's ok to leave some things simply stubbed if there's a
> chance they may never be encountered.

>
>
>
> On Fri, Dec 13, 2013 at 11:38 AM, David T. Lewis <[hidden email]>
> wrote:
>>
>> On Fri, Dec 13, 2013 at 06:37:19PM +0000, Frank Shearar wrote:
>> > On 13 December 2013 16:59, Chris Muller <[hidden email]> wrote:
>> > >> > Dave, the only thing I don't like about this change is I thought we
>> > >> > said
>> > >> > we
>> > >> > were going to migrate away from using the Dictionary API on
>> > >> > Smalltalk.
>> > >> > This
>> > >> > was back when Andreas and community came up with the idea of the
>> > >> > wrapped
>> > >> > 'globals'.
>> > >> >
>> > >> > I think it would be better to use
>> > >> >
>> > >> >     (Smalltalk classNamed: #Paragraph) ifNotNil: [ : classParagraph
>> > >> > |
>> > >> > ... ]
>> > >> >
>> > >> > otherwise we can never find all the places where we try to do
>> > >> > logical
>> > >> > access
>> > >> > to class.
>> > >>
>> > >> In which case we should have #bindingOf:ifPresent, or similar. An API
>> > >> that forces you to acknowledge the potential not-there-ness of a
>> > >> thing
>> > >> is far preferable, in my book, to a separate-check-then-use. The
>> > >> latter also have fun time-of-check-time-of-use issues in a
>> > >> multiprocessing environment... which we happen to have.
>> > >
>> > >
>> > > I used to prefer Potential-not-thereness API's in "my book" too until
>> > > one
>> > > day I found it unnecessarily expanding and complicating API's.  Users
>> > > of
>> > > API's must write defensive code anyway.  The ifNotNil: approach allows
>> > > a
>> > > simpler API that can provide either existence-testing OR access via
>> > > one
>> > > simple message rather than two.
>> > >
>> > > As for "fun time-of-check-time-of-use issues" that's just bunk.  You
>> > > think
>> > > the ifPresent: method doesn't do the same ifNotNil: check or could not
>> > > be
>> > > interrupted?  Unless you're thinking to put a Mutex into
>> > > SmalltalkImage to
>> > > make it "thread safe".  What, for background unloading?  If you need
>> > > that
>> > > guard it from the outside.
>> > >
>> > >>
>> > >>
>> > >> >> >> Well, that definitely stops a DNU and such when running in
>> > >> >> >> Morphic
>> > >> >> >> (yay!) but it still won't work in a non-MVC/Morphic world.
>> > >> >> >> That's
>> > >> >> >> when
>> > >> >> >> you accused me of overengineering, David :)
>> > >> >> >
>> > >> >> > Yes you're right, I meant that with a smiley, sorry :)
>> > >> >>
>> > >> >> I knew there was something of a smiley in there :) I just meant
>> > >> >> that
>> > >> >> if we want to preserve the Transcripter's emergencyEvaluator we
>> > >> >> would
>> > >> >> need this "complexity" because we'd need an emergencyEvaluator per
>> > >> >> UI
>> > >> >> framework.
>> > >> >
>> > >> >
>> > >> > -1.  Please be more conservative and lazy about putting new
>> > >> > code/elements
>> > >> > into the system.  TSTTCPW demands that we don't start building out
>> > >> > infrastructure for new UI frameworks until those frameworks are
>> > >> > being
>> > >> > pushed
>> > >> > into existence and such a factoring is actually NEEDED.  Please
>> > >> > only
>> > >> > write
>> > >> > code for the "now" not for some "potential future".  10 years could
>> > >> > go
>> > >> > by
>> > >> > with no new graphical frameworks and then someone looking at your
>> > >> > class-hierarchy will regard it as "cruft".
>> > >>
>> > >> (a) The emergency evaluator's there _for good reason_.
>> > >> (b) We HAVE two UI frameworks right now. They're part of the standard
>> > >> image.
>> > >> (c) "Stripped" 4.5 base images do not have ST80, so this code is
>> > >> broken.
>> > >> (d) To fix it _requires_ two separate UI implementations because of
>> > >> point
>> > >> (b).
>> > >>
>> > >> Unless you're specifically saying "we should not have an emergency
>> > >> evaluator". But then say that, not -1 me suggesting a way to fix
>> > >> something broken. (Please feel free to suggest a simpler way of
>> > >> solving the problem that works for all CURRENT UI frameworks.)
>> > >
>> > >
>> > > Ok, all I'm saying is, part of your work is about reorganizing, and
>> > > other
>> > > parts are about engineering new functionality just to accomodate the
>> > > reorganizations.  (What's worse is when you want to remove
>> > > functionality
>> > > just to accomodate but I'll be lazy about addressing that).
>> > >
>> > > Whenever there's an arbitrary piece of new functionality (e.g.,
>> > > Morphic-based emergency evaluator) just to avoid crossing package
>> > > boundaries
>> > > you don't want to cross, then engineering "solutions" to that I think
>> > > could
>> > > end up being code for ghost situations.
>> > >
>> > > Because there has been no concrete vision/requirement for a
>> > > Morphic-based
>> > > emergency evaluator (EE).  EE is a relatively rare occurrence (one
>> > > would
>> > > hope!) and for developers only.  But developers typically use
>> > > _development
>> > > images_ which tend to be fat, not "Stripped", and so might probably
>> > > include
>> > > ST80 anyway..?  The cases seem pretty uncertain and so that's why I'm
>> > > questioning engineering new stuff like this into the image.
>> >
>> > This is a bug. It needs to be fixed. It's not new functionality,
>> > unless by "new" you mean "it actually works in Morphic".
>> >
>> > > Particularly we're at a time when I want to get 4.5 out the door, so
>> > > that
>> > > may be contributing to my aversion to new engineerings.  I ask you to
>> > > at
>> > > least consider simple stub error-handling in situations where
>> > > packages/functionality would be unfulfilled.  We can fill in
>> > > implementations
>> > > later, if needed, but at least you'll have made the structure.
>> >
>> > So you'll be happy with
>> >
>> > * move the current EE to ST-80,
>> > * fix the EE for Morphic (at some point),
>> > * add an AppRegistry for the EE (which is just a hook like ToolSet and
>> > friends, so we don't tangle the two UI frameworks we have so carefully
>> > untangled)
>> >
>>
>> No.
>>
>> > ? If there's a simpler solution, I'm all ears.
>> >
>>
>> Hopefully there is a simpler solution, aalthough I cannot look into it
>> right now.
>
>
> Do we have a place-holder?  It is much better to have a string appear in
> top-left that says "The Morphic emergency evaluator is current;y
> unimplemented.  this is an oversight it is intended to fix." than have the
> system lock-up silently.  I'm worried that in a few weeks or months we'll
> have completely orgotten about the Morphic EE and it'll present a mystery
> when it is needed.

>> Dave
>>
>> > frank
>>
>
>
>
> --
> best,
> Eliot

> On Fri, Dec 13, 2013 at 11:06 AM, Frank Shearar <[hidden email]>wrote:
>
> (a) The emergency evaluator's there _for good reason_.
> > (b) We HAVE two UI frameworks right now. They're part of the standard
> > image.
> > (c) "Stripped" 4.5 base images do not have ST80, so this code is broken.
> > (d) To fix it _requires_ two separate UI implementations because of point
> > (b).
> >
>
> I thought the point of the emergency evaluator was that it the fewest
> dependencies possible. Since it scribbles directly on the Display, it
> should work independently of any UI, and thus be useful when the UI is
> broken.
>
> If the EE currently depends on MVC, then we remove that dependency, rather
> than just generalize the dependency to MVC-or-Morphic. We could either
> rewrite the bit that depends on MVC, or move the functionality that it does
> depend on out of MVC and into a lower-level part of the system.

> The alpha image is nothing more than an updated 4.4 image (clicking through
> all the merge requests), trimming MC cache, save image, done.
>
>
> On Sat, Dec 14, 2013 at 2:20 PM, Chris Muller <[hidden email]> wrote:
>>
>> Dave just FYI I recently posted a new alpha image at
>> http://ftp.squeak.org/4.5-alpha.  Filelist works there and it is currently
>> basis for moving toward a release.
>>
>>
>> On Sat, Dec 14, 2013 at 8:23 AM, David T. Lewis <[hidden email]>
>> wrote:
>>>
>>> On Fri, Dec 13, 2013 at 05:05:27PM -0800, tim Rowledge wrote:
>>> >
>>> > On 13-12-2013, at 4:50 PM, David T. Lewis <[hidden email]> wrote:
>>> >
>>> > > I cannot open a file list (world -> open... -> file list) in a fully
>>> > > updated trunk image.
>>> > >
>>> > > Is it just me?
>>> >
>>> > Possibly; my latest was -297 which worked ok and I just updated to 321
>>> > and opening the filelist works ok. OS X 10.9, iMac, Cog vm. Only thing I
>>> > noticed was a merge dialog popping up relating to some ST80 packages stuff.
>>> >
>>>
>>> It is indeed my image. I took another much older image and updated it
>>> fully
>>> to trunk, and the file list works fine.
>>>
>>> Sorry for the noise.
>>>
>>> Dave
>>>
>>>
>>
>
>
>
>

> Dave just FYI I recently posted a new alpha image at
> http://ftp.squeak.org/4.5-alpha.  Filelist works there and it is currently
> basis for moving toward a release.
>
>
> On Sat, Dec 14, 2013 at 8:23 AM, David T. Lewis <[hidden email]> wrote:
>
> > On Fri, Dec 13, 2013 at 05:05:27PM -0800, tim Rowledge wrote:
> > >
> > > On 13-12-2013, at 4:50 PM, David T. Lewis <[hidden email]> wrote:
> > >
> > > > I cannot open a file list (world -> open... -> file list) in a fully
> > updated trunk image.
> > > >
> > > > Is it just me?
> > >
> > > Possibly; my latest was -297 which worked ok and I just updated to 321
> > and opening the filelist works ok. OS X 10.9, iMac, Cog vm. Only thing I
> > noticed was a merge dialog popping up relating to some ST80 packages stuff.
> > >
> >
> > It is indeed my image. I took another much older image and updated it fully
> > to trunk, and the file list works fine.
> >
> > Sorry for the noise.
> >
> > Dave
> >
> >
> >

>
> Dave, the only thing I don't like about this change is I thought we said we
> were going to migrate away from using the Dictionary API on Smalltalk.
>  This was back when Andreas and community came up with the idea of the
> wrapped 'globals'.
>
> I think it would be better to use
>
>     (Smalltalk classNamed: #Paragraph) ifNotNil: [ : classParagraph | ... ]
>
> otherwise we can never find all the places where we try to do logical
> access to class.
>

>
> 2013/12/14 David T. Lewis <[hidden email]>
>
> > On Sat, Dec 14, 2013 at 03:10:32PM -0500, Colin Putney wrote:
> > > On Fri, Dec 13, 2013 at 11:06 AM, Frank Shearar <[hidden email]
> > >wrote:
> > >
> > > (a) The emergency evaluator's there _for good reason_.
> > > > (b) We HAVE two UI frameworks right now. They're part of the standard
> > > > image.
> > > > (c) "Stripped" 4.5 base images do not have ST80, so this code is
> > broken.
> > > > (d) To fix it _requires_ two separate UI implementations because of
> > point
> > > > (b).
> > > >
> > >
> > > I thought the point of the emergency evaluator was that it the fewest
> > > dependencies possible. Since it scribbles directly on the Display, it
> > > should work independently of any UI, and thus be useful when the UI is
> > > broken.
> > >
> > > If the EE currently depends on MVC, then we remove that dependency,
> > rather
> > > than just generalize the dependency to MVC-or-Morphic. We could either
> > > rewrite the bit that depends on MVC, or move the functionality that it
> > does
> > > depend on out of MVC and into a lower-level part of the system.
> >
> > Exactly right.
> >
> > I have a working implementation right now, please give me a day or so to
> > play around with it.
> >
> > Whatever I post can go away if someone gets around to unifying NewParagraph
> > with Paragraph (this is what Juan did in Cuis, and I am borrowing his code
> > shamelessly).
> >
> > Dave
> >
> >
> >

> automated build server is great for doing continuous *testing* and
> reporting, but it seems like for end-user downloads we should have a copy
> available at the usual place (ftp.squeak.org).
> - When I downloaded the image from CI, updated, and ran the tests, I found
> there were more tests failing than in another image that was simply updated
> from 4.4.  Something seemed to be wrong with the image state.
> - Since I was not really certain what all was done in that image, I could
> not trust putting it on the squeak.org FTP site.  The only way I could be
> SURE enough about the state of an image put there was to take the archive
> release image (4.4) and simply update it myself and save it.
>
> So, the overarching requirements:
>
>   - Downloadable from squeak.org domains.
>   - A way to know exactly how it was built:  This means knowing which prior
> _full release image_ was started with, and what changes (both code and
> objects) were made.
>   - Reproducible build.  My idea since 4.2 was to have a utility method on
> ReleaseBuilder do all of this so it would be visible straight in the trunk
> repository.  I guess I always thought of the CI's responsibility as a
> on-going "test-status reporting" mechanism more than a deployment tool.

>  - Chris
>
>
> On Sat, Dec 14, 2013 at 2:24 PM, Frank Shearar <[hidden email]>
> wrote:
>>
>> That's great for easing David's pain - something well worth doing
>> (especially since I'm almost certainly a large contributing factor) -
>> but as a general rule, if we can't use the automated builds to do
>> this, I need to know, so I can fix it. Because we should, in a later
>> version than 4.4, be producing and publishing artifacts in a
>> completely automated fashion. We're not _quite_ there yet, but I need
>> to know any shortcomings in the process if we're ever to reach that
>> happy day.
>>
>> frank
>>
>> On 14 December 2013 20:21, Chris Muller <[hidden email]> wrote:
>> > The alpha image is nothing more than an updated 4.4 image (clicking
>> > through
>> > all the merge requests), trimming MC cache, save image, done.
>> >
>> >
>> > On Sat, Dec 14, 2013 at 2:20 PM, Chris Muller <[hidden email]>
>> > wrote:
>> >>
>> >> Dave just FYI I recently posted a new alpha image at
>> >> http://ftp.squeak.org/4.5-alpha.  Filelist works there and it is
>> >> currently
>> >> basis for moving toward a release.
>> >>
>> >>
>> >> On Sat, Dec 14, 2013 at 8:23 AM, David T. Lewis <[hidden email]>
>> >> wrote:
>> >>>
>> >>> On Fri, Dec 13, 2013 at 05:05:27PM -0800, tim Rowledge wrote:
>> >>> >
>> >>> > On 13-12-2013, at 4:50 PM, David T. Lewis <[hidden email]>
>> >>> > wrote:
>> >>> >
>> >>> > > I cannot open a file list (world -> open... -> file list) in a
>> >>> > > fully
>> >>> > > updated trunk image.
>> >>> > >
>> >>> > > Is it just me?
>> >>> >
>> >>> > Possibly; my latest was -297 which worked ok and I just updated to
>> >>> > 321
>> >>> > and opening the filelist works ok. OS X 10.9, iMac, Cog vm. Only
>> >>> > thing I
>> >>> > noticed was a merge dialog popping up relating to some ST80 packages
>> >>> > stuff.
>> >>> >
>> >>>
>> >>> It is indeed my image. I took another much older image and updated it
>> >>> fully
>> >>> to trunk, and the file list works fine.
>> >>>
>> >>> Sorry for the noise.
>> >>>
>> >>> Dave
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>> >
>>
>
>
>
>

> On Sat, Dec 14, 2013 at 11:13:10AM -0800, tim Rowledge wrote:
>>
>> On 14-12-2013, at 8:22 AM, David T. Lewis <[hidden email]> wrote:
>>>
>>> In Cuis, the distinction between Paragraph (MVC) and NewParagraph (Morphic)
>>> has been eliminanted, and class Paragraph is used. The Transcripter uses
>>> Paragraph (same as Squeak), and Paragraph works in Morphic.
>>
>> Dang - didn?t nice & I go that far? I thought we?d ended up unifying the whole lot. Obviously, we should finish the job sometime soon.
>>
>
> It's hard to know when you have reached the other side of a swamp.