Fwd: [V3dot9] Another try for pre-gamma: #7051

>
> Marcus Denker puso en su mail :
>
> > Hi,
> >
> > Yes, same here. Very strange. I did not change anything with
> > SqueakMap...
> > can you add a report to mantis?
> I add this what I using for a long time, send to Goran , suggest to have a
> button on Flaps, etc.
>
> Install in your image , no need of delete sm dir.
> Do SMLoader newWhitoutNet, should load your last saved map.
> >From here you could update.
> And as bonus , could use all what download without net connection.
>

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Andreas Raab
> Sent: Friday, August 04, 2006 3:06 PM
> To: The general-purpose Squeak developers list
> Subject: Modularity agin (was: Re: [V3dot9] Another try for pre-gamma:
> #7051)
>
> Hi Marcus -
>
> Marcus Denker wrote:
> >>> So just consider it to be the new "full" image...
> >>
> >> So it's back to kitchen-sink.
> >
> > Why? For me, this is just a sign that
> >
> > a) we have only a limited amount of man power available
> > b) we don't have abstractions and tools that are good
> >      enough to make a real modular world practical.
>
> Yes and no. The limited amount of man power can be seen both ways: You
> use it to justify a single image, I'd use it to justify a smaller image.
> In other words, the less scope you have to deal with the more man power
> you can invest to make sure those portions that you deal with are
> handled in the best way possible. The more responsibility is with
> package maintainers the less man power you need to invest.
>
> For the abstractions and tools: Sure, we don't have the perfect solution
> for these issues. But how about dealing with the parts that are utterly
> trivial to deal with? Like, for example, why not immediately remove all
> the packages that have almost no further dependencies, like: FFI,
> Speech, Nebraska, Sound, OB? Those (and others; there are definitely
> more in the image) would be steps into the right direction. And they
> really don't require many tools, and for the lacking abstractions (if
> any) new ones can and will be proposed. There are many practical things
> that can be done if the goal is modularity. Alas, the current goal does
> not appear to be modularity, or if it is, I can't see any tangible steps
> into that direction.
>
> > e.g. as soon as we build the image from components, we *need* a
> > automatic build-and-test server.
>
> The classic "we have no tools" excuse ;-) Then how about finding a
> process which doesn't require the tools. How about making use of the
> community instead? We've got people out there, if we can get them
> involved we might be able to get significant amounts of feedback without
> the automatic server (which would be great, no question, but I don't
> think that's a prerequisite).
>
> Personally, having used Mantis extensively over the last Squeak versions
> I find the process, painful as it is at times, extremely useful. It is
> almost guaranteed that if you take the time to file a bug, it will be
> something that really matters (to you or your project). Which implies
> that people provide pretty good information, discussions etc. That in
> turn (at least to me) makes it a very different medium than, say,
> mailing lists. I don't read all my emails, but I *do* look at all my bug
> reports carefully.
>
> > The way the 3.8full image was put together after the release of the
> > basic image was completely
> > wrong: this would never scale to a real modular system.
>
> In which way? Could you explain this? It strikes me that the process by
> which the 3.8 image was put together is exactly the process that we look
> at for any real usage situation of Squeak: Given a base image, load a
> set of packages that do what you'd like them to do and expect them to
> work together. If you really think that this process is completely wrong
> then we got a problem that is much deeper than this discussion.
>
> > And I am quite sure that the abstractions we have (e.g. PackageInfo) is
> > not good enough for a true
> > modular image. We already now have huge problems that make even the
> > maintenance of 3.9 in the current state a huge pain.
>
> Please give some detail. I'm curious in which way for example PI isn't
> good enough or in which way 3.9 maintenance is problematic. In
> particular it would be interesting to me if the problems couldn't be
> solved by some more robust requirements for packages, for example, no
> overrides etc.
>
> >> How disappointing. How very, very disappointing.
> >
> > It's nice to know that are so much pro modularity... I really should
> > read again the discussions of way-back-when. I don't recall to
> understood
> > this position from your postings back when people had lots of energy
> (3.8)
> > for this...
>
> Then why do you think I've spent so much time trying to fix the 3.3a
> module system or on actually getting stuff out of 3.6? Why do you think
> I started ToolBuilder, UIManager and made the ToolSet abstraction?
>
> Cheers,
>    - Andreas

>>> How disappointing. How very, very disappointing.
>> It's nice to know that are so much pro modularity... I really  
>> should read again the discussions of way-back-when. I don't recall  
>> to understood
>> this position from your postings back when people had lots of  
>> energy (3.8) for this...
>
> Then why do you think I've spent so much time trying to fix the  
> 3.3a module system or on actually getting stuff out of 3.6? Why do  
> you think I started ToolBuilder, UIManager and made the ToolSet  
> abstraction?
>
> Cheers,
>   - Andreas
>

> stéphane ducasse wrote:
>>> For the abstractions and tools: Sure, we don't have the perfect  
>>> solution for these issues. But how about dealing with the parts  
>>> that are utterly trivial to deal with? Like, for example, why not  
>>> immediately remove all the packages that have almost no further  
>>> dependencies, like: FFI, Speech, Nebraska, Sound, OB?
>> We will try to remove what can be remove easily:
>>     FFI, Speech, Nebraska (sound I do not know),
>>     and declare that the mini image.
>
> That's not what I mean. I don't want to "declare" a mini image -  
> that's a pointless exercise if we start with the definition that a  
> mini image contains everything that we can't remove easily. The  
> whole point of making headway towards modularity is that step by  
> step we decrease dependencies. As such, removing the above is  
> useful if and only if it is seen as a stepping stone for the next  
> version (which will hopefully remove even more) not as an end-goal.

> What Stef suggested would get you back what you wanted: A big and a
> small version, I guess as kind of a symbolic statement, just like we
> would have if we would do a "full" version that
> is 3.9 + vmmaker + yaxo + webbrowser.
>
> And now you call it a "pointless exercise". Maybe it was not such a bad
> idea to not to have "full" and "basic" for 3.9 as I suggested? I never
> suggested to stop making the parts
> less dependend of each other, I only said that it makes no sense to ship
> a "full" image for 3.9. You know, "pointless exercise".

> Regarding modularity, wasn't there an Idea that future work would be
> based on Craig's Spoon work?  That at least offers a repeatable process:
>
>         1) Start with a "full" image version X.Y-Z, execute some
> method(s) designed to exercize the desired funcionality to imprint a new
> "minimal" image
>         2) Save the minimal image and give it a name/version.
>
> It seems that S-unit tests of some sort would provide the basis for the
> method to imprint the desired functionality.
>
> Is there any reason why this isn't a good path to follow?

> [hidden email] wrote:
>> Regarding modularity, wasn't there an Idea that future work would  
>> be based on Craig's Spoon work?  That at least offers a repeatable  
>> process:
>>         1) Start with a "full" image version X.Y-Z, execute some  
>> method(s) designed to exercize the desired funcionality to imprint  
>> a new "minimal" image
>>         2) Save the minimal image and give it a name/version.
>> It seems that S-unit tests of some sort would provide the basis  
>> for the method to imprint the desired functionality.
>> Is there any reason why this isn't a good path to follow?
>
> As the *only* path? Or as part of an overall strategy? If the  
> first, I'd say that I'll answer that question once I've seen the  
> first system that has been built that way ;-) [*] As part of an  
> overall strategy it's perfectly fine - there are various  
> interesting ideas in Spoon which can be helpful in many different  
> contexts.

> Regarding modularity, wasn't there an Idea that future work would be
> based on Craig's Spoon work?  That at least offers a repeatable
> process:
>
> 1) Start with a "full" image version X.Y-Z, execute some method(s)
> designed to exercize the desired funcionality to imprint a new
> "minimal" image
>
> 2) Save the minimal image and give it a name/version. It seems that
> S-unit tests of some sort would provide the basis for the method to
> imprint the desired functionality.
>
> Is there any reason why this isn't a good path to follow?

> Regarding modularity, wasn't there an Idea that future work would be
> based on Craig's Spoon work?  That at least offers a repeatable
> process:
>
> 1) Start with a "full" image version X.Y-Z, execute some method(s)
> designed to exercize the desired funcionality to imprint a new
> "minimal" image
>
> 2) Save the minimal image and give it a name/version. It seems that
> S-unit tests of some sort would provide the basis for the method to
> imprint the desired functionality.
>
> Is there any reason why this isn't a good path to follow?

> I mean that Spoon doesn't untangle the current mess of behavior.  
> Yes, it provides tools that might help with that. Yes, it provides  
> tools for dealing with modules once they have been separated from  
> the mess. These are excellent things.
>
> So far, though, nobody has used those tools to do any untangling.  
> Note also that Dean's proposed path, which I've quoted above,  
> doesn't involve any rewriting or refactoring, only unloading. So I  
> think Andreas is right. A modularization strategy that involves  
> Spoon is a fine idea, as long as it also includes the kind of ugly  
> grunt work that Andreas, Pavel, Edgar and others have been doing to  
> disentangle the mess.

> > I certainly agree that any successful modularization strategy
> > includes ugly grunt work (I'm doing it too). But I think Andreas
> > said more than that: that the fitness of Spoon's tools for this task
> > can only be evaluated when the task is finished. If everyone held
> > that view, then no one would  use Spoon's tools for the task. It
> > seems to imply that I, Craig, must disentangle the entire system
> > before it's worth anyone else's while to use Spoon. I don't think
> > this is true.
>
> And I don't think it's fair to accuse me of that.