Stephen,

The problem is not to try to modularize the image. The problem is to ignore
that it's really hard (close to imposible) to avoid somebody break the
reallyGoodDesign in a couple of hours.

The current evolution-state of Smalltalk (and Squeak) allows the mess, so
the mess will be there.

To *really* change theBigMess to a reallyGoodDesign we have to talk about
Smalltalk-2003 (the next Smalltalk).

The solution we're trying is to spend much more power on cleaning and
refactoring that the time used to create something.

To say in a short sentence: The current state of Smalltalk allows bad
designs so we'll have always bad-designs.  (You know: Thermodynamic rules!)

Cheers,

Diego

> I'm having a hard time figuring out how any of these problems magically
>  disappear in the absence of system that is well factored into
> packages.   The ugly dependency graphs are all still there...you just
> can't see them  and it's difficult to cope with them.
>
> For example, if I download base Squeak 3.5, and try to load Zurgle
> directly from your website...I'll bet I run into the same issues you
> described (if you haven't dealt with them already).  Right now, the
> only  way for you to deal with that issue is to build your own
> pre-packaged  image with Zurgle included...and nothing stops you from
> doing so in the  presence of a well-factored Squeak.
>
> However, if I want to use Zurgle with a different version of Squeak,
> then I've potentially got some work to do.  I can't see how having the
> system properly factored into packages with dependencies clearly
> understood would do anything but help that situation.
>
> - Stephen
>
> Jim Benson wrote:
>
>>Stephen,
>>
>>I agree with the SqueakMap stuff. However, another part of the
>>'packaging' effort is refactoring the image and making large chunks of
>>the image 'unloadable'. For me, that's problematic (ok, I think it
>>sucks) ; what happens is that you end up with a whole lot of different
>>configurations of Squeak. I'll give you a example:
>>
>>- I write a package, let's call it Zurgle.
>>- By request, I place it in a SAR package on SqueakMap.
>>- Let's say that going from 3.2 to 3.4 a bug is introduced,. For the
>>sake of argument, let's say it introduces a problem in 32-bit color
>>management. This manifests itself as making IconicButtons invisible,
>>and confuses FlapMorphs in their layout when different fonts are
>>assignd. Both problems in the stock image.
>>- By coincidence, let's say that Zurgle happens to try to load itself
>>in 32-bit color. People who download the SAR complain, and the
>>'reliability' of the Zurgle package is questioned. User downloads
>>Zurgle, it don't work. - As another coincidence, let's say we have an
>>image upgrade going from 3.4 to 3.5. (Zurgle package is still marked as
>>3.4 on SqueakMap, so it doesn't show up under packages).
>>- User does magic incantation, figures out the 'show all versions'
>>deally and tries to load the Zurgle SAR.
>>- Squeak starts barking, "server not responding" error, though you can
>>use the download menu item to download the SAR.
>>-- This is a SqueakMap bug
>>- There's another problem;  compatibility with the StarBrowser package.
>>StarBrowser needs a little magic incantation to work in harmony with
>>the zurg.
>>
>>As with any new image release, there are some problems. At the end of
>>the day, Zurgle comes out looking unusable, with which I have to agree.
>>Regardless of who, what, when, where or why it doesn't work. The
>>feedback I get, "Zurgle isn't a very reliable package". OK.
>>
>>So, just like in the old days, I would hunt up the bugs and submit
>>fixes (or more likely whine loudly and the amazing Ned would magically
>>fix them :-) Submit them to the list with the appropriate tag. But
>>here's the rub. Once people start splitting the core image up, you can
>>bet that whole silly dependencies graph thing rears it's ugly head. To
>>run this package you need version 1.2 of this and 3.2 of that and 2.7
>>of the other thing. I'm not close to smart enough to figure all that
>>out. I couldn't even get my simple package to work going from 3.2 to
>>3.5 when virtually no changes were introduced within the monolithic
>>image.
>>
>>At the end of the day, what did all of the packaging stuff buy me? I'm
>>sure that there are benefits, I just can't think of any.
>>
>>Jim
>>
>>
>>
>>
>>
>>>Jim Benson wrote:
>>>
>>>
>>>
>>>>Bob Arning wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>My dislike for the packagizing effort stems from:
>>>>>- it does not solve any problem that I face now or forsee facing in
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>near future
>>>>
>>>>My sentiments exactly.
>>>>
>>>>Jim Benson
>>>>
>>>>
>>>>
>>>I sort of look at SqueakMap as a kind of Google for Squeak stuff.  It
>>>makes it very easy to find and install Squeak goodies that people
>>>create that are not included in the base image.  For me, that's the
>>>most important thing that SqueakMap does.  The packaging effort is
>>>nothing more than a refactoring effort.
>>>
>>>- Stephen
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> --
> - Stephen
> _________
> Do you need:
>  Web/Domain/Application Hosting?
>  Mailing List Services?
>  IMAP/POP3/Web Email Accounts?
>  Instant Messaging Accounts hosted on your domain?
>
> Email me for information.