[squeak-dev] Etoys help needed loading e.g. CarAndPen.014.pr (was: Changeset: Eliminating global state from Morphic)

karl ramberg karlramberg at gmail.com
Tue Sep 15 17:03:04 UTC 2020


Now that project loading works again (thanks) I was able to do a few tests.
I found no problems with projects after executing  Smalltalk globals
unbind: #World

Best,
Karl


On Sun, Sep 13, 2020 at 10:34 PM David T. Lewis <lewis at mail.msen.com> wrote:

> Is anyone is a position to try loading old Etoys projects such as
> CarAndPen.014.pr
> into an up to date trunk image? I have not tried this in a while, and I
> get errors
> on loading the project. I don't know how to easily fix that so I am asking
> for
> help from anyone who may be more up to date on the topic.
>
> The reason I am asking is that I would like to know if removing the global
> variable #World from trunk would cause any new or unusual problems with
> respect
> to Etoys project loading.
>
> To be specific, if you have a trunk image and are able to load any Etoys
> project, then I would like to know what sort of errors you encounter if
> you first do this before loading that same Etoys project:
>
>    Smalltalk globals unbind: #World
>
> I would expect that this will lead to some kind of error condition, and
> what I would like to know is whether that failure or error message gives
> a good clue as to the problem, such that you might be able to figure out
> that you would need to fix it by doing this:
>
>    Smalltalk at: #World put: Project current world
>
>
> Thanks!
> Dave
>
>
>
> On Sat, Sep 12, 2020 at 07:32:17PM +0000, Thiede, Christoph wrote:
> > Hi David,
> >
> >
> > I think I understand the dilemma: If we keep #World in the bindings, it
> will keep being used (I have to admit that, for personal scripts, I'm doing
> so, too). If we remove it, we don't provide backward compatibility for
> older projects. This would be really a pity because even if you write in
> your inbox version: "If a package is loaded that does need World, then
> 'Smalltalk at: #World put: Project current world' will restore prior
> behavior.", how many people will know that when they attempt to refloat an
> ancient piece of Squeak code?
> >
> > As far as we only have these two options, I'm tending to vote for the
> first one. Unless we use it in the Trunk, it does no harm, and actual bugs
> should occur rather seldom because some third-party package is still using
> #World. If there should be a bug somewhere, it can be easily fixed.
> >
> >
> > But hypothetically, there would be a third option, which would be my
> favorite: Handle accesses to #World like calls on a deprecated method, i.e.
> by signaling a DeprecationWarning. That way we could even make sure that
> novices do not learn to use a deprecated variable.
> >
> > This could be realized by wrapping the value of #World into an
> ObjectTracer or a similar class that raises a DeprecationWarning on every
> call that is made to it.
> >
> > But I fear this could be a piece of overengineering, what do you think?
> Also, this would not protect the global variable from being reassigned ...
> >
> > The very last solution could be to make a (global) list of deprecated
> bindings and raise a Warning from the Compiler when an attempt is made to
> access one of them. Unfortunately, this would also be the most invasive
> change.
> >
> >
> > @Levente: It seemed kind of overengineering to me to create three
> subclasses of ProcessLocalVariable for this purpose. Or am I misunderstand
> their concept? Maybe we could also need something like a
> PluggableProcessLocalVariable that can be instantiated with two accessor
> blocks?
> >
> >
> > Best,
> >
> > Christoph
> >
> > ________________________________
> > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von David T. Lewis <lewis at mail.msen.com>
> > Gesendet: Samstag, 12. September 2020 21:10:59
> > An: The general-purpose Squeak developers list
> > Betreff: Re: [squeak-dev] Changeset: Eliminating global state from
> Morphic
> >
> > On Sat, Sep 12, 2020 at 06:38:38PM +0000, Thiede, Christoph wrote:
> > > Glad you like it, David! :-)
> > >
> > > <http://www.hpi.de/>
> > >
> > > > In the case of the global World variable, we were able to make it an
> instance variable in Project.
> > >
> > > I heard of this, but where can you see the difference? If I evaluate
> "World" in my fresh trunk image, I get a PasteUpMorph instance ... #World
> is still listed in my Smalltalk bindings.
> >
> >
> > I just put System-dtl.1170 in the inbox to make it go away. For a long
> > time, the World variable was shared all over the place, even in MVC if
> > you can believe that. From a modularity perspective it was a real mess.
> > Basically, the solution was to make it an instance variable in Project.
> > The current project always has a world, and when transitioning from one
> > project to another, you can do the handoff between those two worlds
> > without referencing a global.
> >
> > All that got done about two years ago, but I intentionally left the
> #World
> > binding in place on the theory that there might be external packages (or
> > Etoys projects) that expect to have access to global World.
> >
> > The way it works now (see MorphicProject>>setWorld:) is that the global
> > World will be updated as before, but this happens if and only if the
> > global binding exists. If you remove the binding, the World no longer
> > exists. If you load a package or project that does have references to
> > World, then restoring the #World binding in the current environment
> should
> > make it work again.
> >
> > I don't really know if it's a good idea to remove the #World binding now
> > (that's why it's in the inbox). But leaving it in the image is confusing
> > because it gives the wrong impression that it is still being used.
> >
> > Dave
> >
> >
>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200915/469da281/attachment.html>


More information about the Squeak-dev mailing list