Re: Another package manager issue

[David Bateman]

John W. Eaton wrote:
> On 28-Aug-2006, David Bateman wrote:
>
> | Ok, I have another issue with the package manager. Firstly in trying to
> | treat both PKG_ADD and PKG_DEL I introduced a error. However the more
> | interesting issue is how addpath work in pkg.m. Both addpath and pkg are
> | marked as commands, but the addpath in pkg are called in sub-functions
> | of pkg, Therefore we aren't at the top-level when addpath is called. If
> | the PKG_ADD file in a package includes a "mark_as_command" line then
> | this can't be executed.
>
> We choose to make this an error to prevent confusion about things like
>
>   function foo ()
>     mark_as_command ("cmd");
>     cmd args                     ## parse error
>   endfunction
>
> There will be an parse error because cmd is not marked as a command
> until the function is evaluated.
>
> As far as I can see, there is no other reason to require that
> mark_as_command only work at the top level.
>   
Thats a pretty good reason to do it though.

> | I see two solutions. Mark all of the
> | sub-functions that call addpath in pkg.m as commands,
>
> I don't understand how this helps.
>   
Think about addpath which is a function marked as a command. When it
adds a path with a PKG_ADD file in it is is evaluated correctly. I
haven't looked at the code, but I suspect that if a function marked as a
command is run, the level is not incremented. Therefore if all of the
functions up to and including the function with the addpath are marked
as commands, then addpath will appear at the top-level.

> | or use evalin to
> | run the addpath command in the top-level (which is what the attached
> | patch does). Can this be applied
>
> This would also work, but would it be better to eliminate the
> requirement that mark_as_command may only be called at the top level?
> Or would the potential for confusion be too great?#
>   
Your call, though I can see that the above is a nasty syntax error whose
reason is not clear. I suppose that a warning might be added for when
functions are marked as commands within other functions, and I can turn
this warning off in the case of the package manager, so do it however
you want.

Note though that the change in the patch I sent for extract_pkgadddel
sub-function is necessary as there is a variable name clash in this
function that I accidentally introduced..

Cheers
David

-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary