Hi jecel

I would like to have your point of view on the classBox.
The paper has been accepted and we are including bench now.
http://scgwiki.iam.unibe.ch:8080/SCG/559

if you have time :)
Stef

On Thursday, May 15, 2003, at 12:30 AM, Jecel Assumpcao Jr wrote:

> On Wednesday 14 May 2003 08:56, Lex Spoon wrote:
>> Jecel Assumpcao Jr <jecel at merlintec.com> wrote:
>>> The Debian package format has a richer dependency structure than
>>> the Red Hat format.
>>
>> The parts that are richer don't seem to be what you are talking
>> about, though.  I'm sure that if you used DEB's from different
>> distributions, then you'd have the same versioning madness that
>> happens with RPM's.
>
> You are right - the social differences far outweigh any technical
> differences. I actually did use DEBs from two different distributions
> when I upgraded a working Debian system to Corel Linux.
>
>> Yeah, that's what I was figuring.  But, umm, isn't the user being a
>> little optimistic in these cases to pull in these different RPM's?
>> Put another way, does anyone have any trouble if they stick to the
>> actual RedHat-created RPM's?
>
> No, that should mostly work. But what if you want to run Squeak and Red
> Hat/Mandrake/Conectiva/etc weren't the ones who packaged it up as a
> .rpm? There will always be interesting stuff not included in the
> popular distributions.
>
>>> With proper inter-module pointers and universal IDs, you eliminate
>>> the human factor of reusing a name for slightly different things.
>>
>> I don't get this at all.  If we could agree on what the
>> name+version's were, then that would be the end of it.
>
> Ok - I am worried about the case where there is no global coordination.
> Perhaps this is overkill...
>
>> The problem
>> seems to be that different distributions label the same code with
>> different versions or even different names.  Adding an extra lookup
>> table doesn't seem to help this fundamental problem.
>
> What I was complaining about was a lack of agreement on what the public
> interface of a module was. Packages from different vendors with the
> same name included the exact same version of the code, but some
> libraries were present in one and not the other. The code included in
> both distributions did not use this library, so some maintainer had the
> bright idea of eliminating it or moving it to another module.
>
> Now gEDA was saying it needed the guile module, but what it should have
> been able to say was that it needed such and such library.
>
> In Squeak, it would be nice to say that an application needs a given
> class and not that it needs a certain module that happens to include
> that class (for now....).
>
>> I guess you are talking about building a sort of virtual
>> distribution, where there is a top-level distribution uses packages
>> from multiple other distributions?  That doesn't seem very practical
>> to me.  In the Linux world, good distributions do a lot of little
>> tweaks to the packages to make them work together nicely.  Why should
>> it be different in the Squeak world?
>
> I want an object system, not one built from a bunch of text files. 
> Never
> send a person to do a computer's job. If I want object #12423980890 to
> point to object #54234234238254 then I would rather that Squeak take
> care of this in a way that is easy for it. Having it do that by
> embedding a file name like "c:\winnt\system\sqmods\basic\kgr-1.7.49" as
> a pointer so that I can feel that I am in control will only cause
> problems later on.
>
>> If there is a better way to handle dependencies then let's do it, but
>> name+version seems to be a fine way to go.
>>
>> And at any rate, as you say forks are a long way off -- mostly
>> everyone is happy with SqueakMap right now.
>
> It is a great start. The 3.3 module system actually did try to address
> my complaints above (with proper export/import declarations for modules
> and other stuff) but I wasn't surprised to see it run into problems as
> it was at once too simple (there were lots of things it couldn't do,
> like replace projects for example) and too complex (many different
> mechanisms that were essentially doing the same thing).
>
> -- Jecel
>