Smalltalk › Squeak › Squeak - Dev

SM deps: Yet Another Stab

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Göran Krampe

SM deps: Yet Another Stab

Hi folks!

Ok, so I want to give dependencies in SM Yet Another Stab. :)

This time around I am going for a *much* simpler approach.

The idea is simple: By analyzing the code in the packages (most are
code, and most are in mcz format I think) we can probably figure out the
dependencies in 95% of the cases (or another round figure).

So if we for each package release on SM knew:

1. What globals it defines (=classes in practice)
2. What globals it accesses that it does not define itself (=classes in
practice)

Then we should quite easily be able to find releases it depends on.

Figuring out 1) and 2) seems to be easily done (even though one could
possibly do it in a naive source code manual scanning method) by
adjusting Monticello (and we also need to support other source code
formats of course) so that it can load an .mcz into a "sandbox" (it
builds classes just like normal, but don't put them in Smalltalk, nor
hook them up as subclasses in forreign super classes - even though I am
uncertain about if that can disturb compilation).

I have done the above and it seems to work without having tested it
thoroughly. So why do we compile stuff? It is because otherwise it gets
hairy to figure out what references are actually globals (think class
vars, class inst vars, pool dicts, inheritance etc).

So the SM server can then "scan" all releases in its server side cache
using the above technique, build some dictionaries and then hopefully
automatically be able to figure out plausible dependencies.

If we match this with a bit of user controlled policy and questions that
we can ask the user - we might get something nice, simple and automatic.

regards, Göran

Ralph Johnson

Re: SM deps: Yet Another Stab

On 5/25/06, [hidden email] <[hidden email]> wrote:

> If we match this with a bit of user controlled policy and questions that
> we can ask the user - we might get something nice, simple and automatic.

It is crucial that it is nice and simple. Automatic would be nice,
but I would be happy with a manual system.

If we are using Spoon for defining modules then it will have a perfect
way of both defining modules (all the code run by the module's test
suite that is not in any existing module) and detecting dependencies
on other modules (all modules in the system at the time you traced the
module).

I propose you make it nice and simple and wait for Spoon to make it
nice and simple and automatic.

-Ralph Johnson

stéphane ducasse-2

Re: SM deps: Yet Another Stab

In reply to this post by Göran Krampe

> Ok, so I want to give dependencies in SM Yet Another Stab. :)

Cool!

Now I have a stupid question. Why trying to guess the dependencies?
Goran what I would love to have is a simple way to express dependencies.
After we can find a smart way to guess then.
For now I would really like to be able to give an MCZ package and
that my user
does not have to fight the dependencies hell alone.

Stef

>
> This time around I am going for a *much* simpler approach.
>
> The idea is simple: By analyzing the code in the packages (most are
> code, and most are in mcz format I think) we can probably figure
> out the
> dependencies in 95% of the cases (or another round figure).
>
> So if we for each package release on SM knew:
>
> 1. What globals it defines (=classes in practice)
> 2. What globals it accesses that it does not define itself
> (=classes in
> practice)
>
> Then we should quite easily be able to find releases it depends on.
>
> Figuring out 1) and 2) seems to be easily done (even though one could
> possibly do it in a naive source code manual scanning method) by
> adjusting Monticello (and we also need to support other source code
> formats of course) so that it can load an .mcz into a "sandbox" (it
> builds classes just like normal, but don't put them in Smalltalk, nor
> hook them up as subclasses in forreign super classes - even though
> I am
> uncertain about if that can disturb compilation).
>
> I have done the above and it seems to work without having tested it
> thoroughly. So why do we compile stuff? It is because otherwise it
> gets
> hairy to figure out what references are actually globals (think class
> vars, class inst vars, pool dicts, inheritance etc).
>
> So the SM server can then "scan" all releases in its server side cache
> using the above technique, build some dictionaries and then hopefully
> automatically be able to figure out plausible dependencies.
>
> If we match this with a bit of user controlled policy and questions
> that
> we can ask the user - we might get something nice, simple and
> automatic.
>
> regards, Göran
>