Re: Implementation of convn

[David Bateman]

Soren Hauberg wrote:
> man, 24 03 2008 kl. 17:56 -0400, skrev John W. Eaton:
>   
>> | Don't we have "private" directories now? I would think all __functions__
>> | should be moved to "private" directories.
>>
>> We could do that for .m files relatively easily, though it would
>> require some changes to the Makefiles (and possibly the layout of the
>> sources).
>>
>> But doing this for .oct files is not as easy.  The rule for functions
>> in private directories is that they are only visible to the functions
>> in the parent directory.  But generally all .oct files live in the
>> same architecture dependent directory tree, separate from the
>> architecture independent .m files.  For example,
>>
>>   /usr/share/octave/3.0.0/m/polynomial
>>   /usr/lib/octave/3.0.0/oct/x86_64-pc-linux-gnu
>>
>> If you put your convn.m file in /usr/share/octave/3.0.0/m/polynomial,
>> functions that are "private" for it belong in
>>
>>   /usr/share/octave/3.0.0/m/polynomial/private
>>
>> but that is is an architecture independent directory, so it is not the
>> right place for a .oct file.
>>
>> I don't see a good solution for this problem.
>>     
>
> I'm not in anyway claiming to understand all the issues here (or rather:
> I don't understand them at all), but I see two things that might be
> helpful.
>
> 1) We might want to auto-add "x86_64-pc-linux-gnu" directories to the
> path. That is, if we add "/some/path" to the path, then the files in
> "/some/path/x86_64-pc-linux-gnu" should also be available. For
> "private" directories files
> in "/some/path/private/x86_64-pc-linux-gnu" would also be private. 
>
> 2) Perhaps we want a top-level private directory. That is, a directory
> containing functions that are available to other functions distributed
> with Octave, but not directly available to the user.
>
> Anyway, since I don't really understand the issues here, this mail just
> qualifies as brain-farting...
>
> Soren
>
>
>   
Matlab gets around this issue by having platform specific mex extensions
and storing the mex-files in the same directory as the m-files.. If we
follow the linux standard of a separation between architecture dependent
and independent files then this is not allowed. I'd suggest that taking
your example above

/usr/share/octave/3.0.0/m/polynomial
/usr/lib/octave/3.0.0/oct/x86_64-pc-linux-gnu

when then create a directory structure under the architecture dependent
directory, like

/usr/lib/octave/3.0.0/oct/x86_64-pc-linux-gnu/polynomial

where the architecture dependent and independent "polynomial"
directories are considered part of the same package. When can then have
the private directories

/usr/share/octave/3.0.0/m/polynomial/private
/usr/lib/octave/3.0.0/oct/x86_64-pc-linux-gnu/polynomial/private

and that both m-files and oct-files from the polynomial package can call
private functions in both the architecture dependent and independent
private directories..

Frankly given the constraint of support the architecture dependent split
of files and private directories I don't think there is any other way to
support this..

Regards
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