how things go wrong between packages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

how things go wrong between packages

Lex Spoon-3
Most of the problems that came up in putting together the 3.9 stable
universe were the kind Viktor ran into with Classboxes.  The
individual package is simply bitrotten and no longer plays nicely is
the current version of Squeak.  It refers to a class no longer
existing, or it defines a class that now has a conflicting definition
in the standard image.

A more incidious kind of prolbem is those due to interactions between
multiple packages.  There were 5 such problems I found with the 3.9
stable universe, simply by trying to load all of the packages
simultaneously into the same image.  The problems were:

  Package Algebraic overwrites the "new" method in class Matrix,
  leading to other code crashing.

  Zigzag opens and enters a new project when it starts, and thus
  causes the package-loading thread to stop.  This is a classic
  problem from using a SAR for distribution.  One way to repackage
  this would be to post two packgaes, one with an mcz with the code,
  another with the morphic demo project.  Package Universes and
  SqueakMap both can load projects just fine.

  ODBC overwrites the TimeStamp class with its own, and the tools
  quietly allow this.  (Incidentally, people, we have had the
  ANSI-standard DateAndTime since before any of the various TimeStamp
  classes were posted.  Let's use the good stuff.)

  SmallDEVS defines a global variable Timer, which conflicts with a
  class variable in Exupery.  I wish the loader would allow this
  situation, but in 3.9 it does not.

  TimeZoneDB redefines DateAndTimeNow in such a way that TimeStamp no
  longer works.  Specifically, "TimeStamp now" returns a DateAndTime
  instead of a TimeStamp.  While I think we should deprecate
  TimeStamp, we must keep it working for now due to all the packages
  still using it.


By the way, I found it hard to debug where these problems came from.
I'd see a crash in one package, and then have to figure out why, for
example, Matrix no longer functions correctly.  I don't know what went
wrong; either we need to use Monticello more, or we need to update
Monticello to provide more help when these overwrites happen.


Lex


Reply | Threaded
Open this post in threaded view
|

how things go wrong between packages

Bryce Kampjes
Lex Spoon writes:
 >   SmallDEVS defines a global variable Timer, which conflicts with a
 >   class variable in Exupery.  I wish the loader would allow this
 >   situation, but in 3.9 it does not.

I'll fix that in Exupery. The next release should be out in a few
weeks. Looking at it, I really should have been using a temporary,
that variable is only used in one method.

I also agree that the loader should allow it. Personally, I don't
think we should prevent class variables from having the same name as
classes. A warning should be enough. The class variable has a local
scope.

Bryce

Reply | Threaded
Open this post in threaded view
|

Re: how things go wrong between packages

Lex Spoon-3
<[hidden email]> writes:

> Lex Spoon writes:
>  >   SmallDEVS defines a global variable Timer, which conflicts with a
>  >   class variable in Exupery.  I wish the loader would allow this
>  >   situation, but in 3.9 it does not.
>
> I'll fix that in Exupery. The next release should be out in a few
> weeks. Looking at it, I really should have been using a temporary,
> that variable is only used in one method.
>
> I also agree that the loader should allow it. Personally, I don't
> think we should prevent class variables from having the same name as
> classes. A warning should be enough. The class variable has a local
> scope.

Yes.  All that said, if you can make this change, then it will remove
the conflict with SmallDEVS immediately, thus allowing SmallDEVS to go
into the 3.10 stable universe.


-Lex



Reply | Threaded
Open this post in threaded view
|

Re: how things go wrong between packages

David T. Lewis
In reply to this post by Lex Spoon-3
On Sun, Feb 11, 2007 at 11:25:38AM -0600, Lex Spoon wrote:
>
>   TimeZoneDB redefines DateAndTimeNow in such a way that TimeStamp no
>   longer works.  Specifically, "TimeStamp now" returns a DateAndTime
>   instead of a TimeStamp.  While I think we should deprecate
>   TimeStamp, we must keep it working for now due to all the packages
>   still using it.

Lex,

Thanks for spotting this bug. I fixed it and put a new version of
TimeZoneDatabase on SqueakMap.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: how things go wrong between packages

Bryce Kampjes
In reply to this post by Lex Spoon-3
Lex Spoon writes:
 > Yes.  All that said, if you can make this change, then it will remove
 > the conflict with SmallDEVS immediately, thus allowing SmallDEVS to go
 > into the 3.10 stable universe.

It's fixed in Exupery 0.11 which will be out in the next week or so.

If you wanted to you could put it in the 3.9 stable universe.

Bryce

Reply | Threaded
Open this post in threaded view
|

Re: how things go wrong between packages

Lex Spoon-3
In reply to this post by David T. Lewis
"David T. Lewis" <[hidden email]> writes:
> Thanks for spotting this bug. I fixed it and put a new version of
> TimeZoneDatabase on SqueakMap.

Dave, Bryce, I finally got around to opening the 3.10 universe to
edits.  I'll leave it open until the universe is finalized, so that
people can post updates more quickly than I can manage.  I am just
barely finding enough time to keep the machinery working and to do
final checkups at the end.

To post updates, use the "package universe editor".  The first time
you open it you must create an account.  After that, click on an
existing package and do "create new version".  The tool will prompt
you for any info it needs.

To the group in general: realize that anyone can become a maintainer
for a universes entry, not just me or the original authors.  If your
favorite package is out of date in the 3.10 universe, then go ahead
and post an update and name yourself as the "maintainer".  In the
unlikely event two people scramble to maintain the same package, just
email each other and/or me and we'll work it out.


-Lex