Sorry diego I disagree.
We can do our best now, we are working on ST2003 but for now we need a 
cleaner stuff.
I think that your frustration just came for a process issue. I have no 
problem that a group of people work on something because they need it 
and that the result gets in the image as soon as it does not break 
obvious rules or other architectures.
See my previous email

Stef

On Wednesday, May 7, 2003, at 09:45 AM, <diegogomezdeck at consultar.com> 
wrote:

> 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.
>
>
>
>