octave-dev — GNU Octave developers' list

Re: [OctDev] pkg manager

[David B. <Dav...@mo...>]

S=C3=B8ren Hauberg wrote:
>
>> First we need a build target for the packages themselves in the packag=
es/
>> directory with a temporary install directory.=20
>>    =20
> I don't understand what that means (sorry).
>  =20

Basically, main/, extra/, etc are just the repository used to create the
package tar-balls, and the code is no longer built there, but is rather
built by the package manager itself. Even if the code could be built in
these directories it is not in our interests to do so as we aren't doing
our test build in the same manner as the user will use the packages.

Better to have a Makefile in the newly created packages/ directory with
a build and test target, where the build target uses the package manager
to build all of the packages in the directory, or better still all of
the package currently built in main/, etc and not containing NOINSTALL.

>  =20
>> We need a test target to run the stand-alone and embedded test code in=
 the installation
>> directory.=20
>>    =20
> Okay. This code only relies on octave and not octave-forge right? It
> seems to me that the embedded code doesn't make sense to have as a
> package (right?). Shouldn't we just release that as a tar-ball which
> doesn't use the package manager. Perhaps I'm misunderstanding things --
> I'm not very familiar with octave-forge...
>  =20
There aren't many batch tests that are left as the embedded test code is
much more heavily used. They are basically only present for the comm,
fixed and image toolboxes. I haven't converted my test code, due to the
fact that it seemed quite complex to do it correctly (ie splitting the
tests to reside with the relevant functions. However, I suppose a quick
and dirty way to do it now that the test code allows functions, is just
to convert the existing code to a single test. I'll do this and get rid
of the batch tests.

As for the embedded tests, the admin/mktest.sh script needs to be
slightly modified as it would no longer need to worry about building a
local PKG_ADD file as the installed packages themselves would deal with
that.

>  =20
>> We need to check that the scripts in the admin/ directory
>> still work correct.=20
>>    =20
> How many of the scripts are actually needed? I'm under the impression
> that many of the scripts were designed to handle many different version=
s
> of octave, which isn't needed any more.
>  =20

We need to keep and check at least find_changes, get_authors,
get_contents, make_index, mkdoc, mktexi, mktests.sh, run_forge,
template.ndev and template.README. Most of the changes are probably
trivial. Though at least run_forge needs major modification to allow the
tests to be correctly run and built with a temporary package install
path. Honestly, I don't see that there is much code that allows specific
use of multiple versions of octave in these scripts.

OctRe.pm, change_va_arg.pm  and no_vr_val.pm  are no longer needed, but
were kept as examples of how to automate code changes in the future.

Equally we need to figure out what to do with the admin/RPM/ and
admin/Windows/ directories. In particular the Windows directory might
pose large problems.
>  =20
>> The top-level configure stuff is still used by the build of my
>> documentation in main/{fixed,comm}/doc, and might be used elsewhere. S=
o
>> it either needs to be kept, and largely simplified, or partially
>> duplicated in each of the package that use it for other things than th=
e
>> pkg/src directory. I think it might be better to keep the toplevel
>> configure to prevent duplication. Since if I copy it to the
>> sub-directories I'd have to copy the support scripts mkdoc and mktexi =
as
>> well.
>>    =20
> Agreed!
>
> We also need:
> * Scripts for creating RPM and DEB packages from a package.
> * Scripts that can create web pages for each package.
>  =20
How are the webpages created automatically? Are they just the
DESCRIPTION files with links to the function helps? Do we add a
mechanism to add additional documentation. Both the comm and fixed
toolboxes have html documentation, and I believe other do as well. If
you want to automate the production of this additional documentation,
then we probably also need to specify exactly how documentation should
be added to the package.
> Btw. is there a need to split octave-forge into main, extra, and
> non-free anymore? Can't we simply have one main directory?
>  =20
The non-free distinction can be probed from the DESCRIPTION file. Though
have you thought that the package itself might be under one license but
a dependent library under another. Think of the the nonfree/gpc package,
where the gpc library is non-distributable while the octave binding are.
Maybe you need another argument in the DESCRIPTION file similar to that
in the RPM spec files to define not only the license but whether a
library is generally distributable.

As for the extra/ directory, the reason for its existence was that the
scope of the packages in this directory were supposed to be much more
limited and so the majority of users probably wouldn't want to install
them. Making this distinction makes it easier for packagers to decide
which code to build and ignore. If the deb and rpm packages are on a
package by package basis, then yes we probably don't need extras/.
However, if we have an overall tar-ball (to aid deb and RPM packagers),
then shouldn't we still help them decide what to install by making the
distinction about code that most people would or wouldn't want to
install? Maybe the extras/ directory is not the best way to do this
however with packages.

Regards
David

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

The information contained in this communication has been classified as:=20

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

Re: [OctDev] pkg manager

[H. <so...@ha...>]

tir, 22 08 2006 kl. 23:01 +0200, skrev David Bateman:
> I can't reply on list at the moment.=20
I'm also sending my answer to the list.

> But your error is that there is
> bogus main/autom4te.cache directory in main/, this is part of the
> configure process and so should only be in the head. Can you remove thi=
s
> and check for other bogus directories and try again..
Okay, I just deleted the unwanted directories and things worked.=20

> I've thought about the rest of this a little further and basically I se=
e
> that the approach this implies need a couple of extra things.=20

> First we need a build target for the packages themselves in the package=
s/
> directory with a temporary install directory.=20
I don't understand what that means (sorry).

> We need a test target to run the stand-alone and embedded test code in =
the installation
> directory.=20
Okay. This code only relies on octave and not octave-forge right? It
seems to me that the embedded code doesn't make sense to have as a
package (right?). Shouldn't we just release that as a tar-ball which
doesn't use the package manager. Perhaps I'm misunderstanding things --
I'm not very familiar with octave-forge...

> We need to check that the scripts in the admin/ directory
> still work correct.=20
How many of the scripts are actually needed? I'm under the impression
that many of the scripts were designed to handle many different versions
of octave, which isn't needed any more.

> We need to upto the developer documentation to
> reflect the new means of including a package in the octave-forge CVS,
> while also stating that the package can equally exist independently fro=
m
> octave-forge.
Yes. And we (me, I guess) need to write tutorials on actually creating
packages.

> The top-level configure stuff is still used by the build of my
> documentation in main/{fixed,comm}/doc, and might be used elsewhere. So
> it either needs to be kept, and largely simplified, or partially
> duplicated in each of the package that use it for other things than the
> pkg/src directory. I think it might be better to keep the toplevel
> configure to prevent duplication. Since if I copy it to the
> sub-directories I'd have to copy the support scripts mkdoc and mktexi a=
s
> well.
Agreed!

We also need:
* Scripts for creating RPM and DEB packages from a package.
* Scripts that can create web pages for each package.

Btw. is there a need to split octave-forge into main, extra, and
non-free anymore? Can't we simply have one main directory?

S=C3=B8ren

Re: [OctDev] main ported to the package system

[John W. E. <jw...@be...>]

On 22-Aug-2006, David Bateman wrote:

| Soren,
|=20
| As this should be applied to the octave core pkg.m function I've cc'e=
d
| the maintainers list. John can you look at this?
|=20
| S=F8ren Hauberg wrote:
|=20
| >man, 21 08 2006 kl. 18:43 +0200, skrev David Bateman:
| > =20
| >
| >>Ok, this makes sense, and I'd propose something like the attached p=
atch
| >>to address this. Though this needs further testing, it seems to wor=
k for
| >>the test case I've used based on the comms toolbox. Basically, this=

| >>means that symbolic links should be handled by the developer either=

| >>embedded in the code or as a seperate PKG_ADD file that is appended=
 to
| >>the end of the PKG_ADD commands found in the source.
| >>   =20
| >>
| >Looks good, but there are a few details I don't understand:
| >
| > =20
| >
| >>+ function create_pkgadd (desc, packdir)
| >>+   pkgadd =3D [desc.dir "/PKG_ADD"];
| >>+   rm_rf(pkgadd);
| >>   =20
| >>
| >Why do you need to delete 'pkgadd'? 'desc.dir' should always be a ne=
wly
| >created directory, so 'pkgadd' should never exist.
| > =20
| >
| Ok, I'm not that familar with the package system yet.
|=20
| > =20
| >
| >>+   fid =3D fopen(pkgadd, "wt");
| >>+   if (fid >=3D 0)
| >>+     ## Search all dot-m files for PKG_ADD commands
| >>+     lst =3D dir ([packdir "inst"]);
| >>+     for i=3D1:length(lst)
| >>+       nm =3D lst(i).name;
| >>+       if (length(nm) > 3 && strcmp (nm((end-1):end), ".m"))
| >>+         fwrite (fid, extract_pkgadd (nm, '^[#%][#%]* *PKG_ADD: *(=
.*)$'));
| >>+       endif
| >>+     endfor
| >>   =20
| >>
| >Can't you simply write:
| >    lst =3D dir ([packdir "/inst/*.m"]);
| >    for i =3D 1:length(list)
| >      nm =3D list(i).name;
| >      fwrite (fid, extract_pkgadd (nm, '^[#%][#%]* *PKG_ADD: *(.*)$'=
));
| >    endfor
| >and similar for the C++ files.
| > =20
| >
| Hey, it was a first pass. Ok, I've adapted the changes you suggested.=

|=20
| >=20
| > =20
| >
| >>+     ## Search all C++ source files for PKG_ADD commands
| >>+     lst =3D dir ([packdir "src"]);
| >>+     for i=3D1:length(lst)
| >>+       nm =3D lst(i).name;
| >>+       if (length(nm) > 4 && strcmp (nm((end-2):end), ".cc"))
| >>   =20
| >>
| >Should we only handle *.cc files, or should we also handle *.cpp and=
 *.C
| >(are there others?) ? Which reminds me: is MS Windows case sensitive=
, or
| >do we also need to handle *.M, *.CPP, etc.?
| > =20
| >
| The existing mkpkgadd funcion only search *.m and *.cc files. Its eas=
y
| to make it search other files, but do we want it to?
|=20
| >Besides these details it looks good, and I think this should be appl=
ied
| >to CVS. Assuming this gets accepted into CVS, what else is needed to=
 aid
| >package developers?
| > =20
| >
| Some way of treating additional directories in the package other than=

| src/ and inst/, though I'll address that in a seperate mail..
|=20
| I attach the PKG_ADD patch for pkg.m that I'd like to see applied

OK, I checked in this change.

Thanks,

jwe

Re: [OctDev] main ported to the package system

[H. <so...@ha...>]

tir, 22 08 2006 kl. 15:10 +0200, skrev David Bateman:
> >I think it makes sense to let release.sh (or whatever we call the scri=
pt
> >that makes tarballs) check if a Makefile exist in the package director=
y.
> >If a Makefile exist in the package directory we run
> >  make -C package_dir release
> >Then the package maintainer can basicly do what ever he/she wants at
> >release-time.
> > =20
> >
> What, about something like in the attached patch. This essentially
> replaces your release.sh script with a Makefile, that if there is a
> Makefile in the sub-directory to uses this to define a variable
> PKG_FILES with the files to include in the package. It equally gives th=
e
> developer of the package access to three targets pre-pkg/%::,
> post-pkg/%::, and clean: that allow the developer to do things prior an=
d
> post creation of the package and define what needs to be done to clean
> up the directory.
I've just had a look at your patch, and I must say it looks good. I
wouldn't have been able to do this with out a lot of work (I think the
make language is hard).

> Note this code relies on the Makeconf in the root directory, and that I
> haven't addressed this issue yet.=20
Why does it rely on ../Makeconf? What does that file give us, that's
relevant in this situation?

> Therefore, "./configure" should be run
> in the root and "make" should be run in the "main/" directory. The
> packages can then be found in packages/*.tar.gz which will allow your
> overall tar-ball to be created as a seperate process.
The overall tar-ball should be a single tar-ball containing the
uncompressed packages, so I think it makes sense to integrate it's
creation into the process. (Personaly I don't see the great need for
this bundle package, but Paul thought it would be a good thing to have)

> I've converted the
> comm/ sub-directory to use the new make architecture to specify how to
> treat the doc/ sub-directory.
I've tried to run make, but I get the following error:
...
make[2]: Entering directory `/home/sh/Download/octave-forge/main/comm'
make[2]: `post-pkg/comm' is up to date.
make[2]: Leaving directory `/home/sh/Download/octave-forge/main/comm'
make[1]: Leaving directory `/home/sh/Download/octave-forge/main/comm'
ver=3D`grep "Version:" audio/DESCRIPTION | sed -e "s/Version: *//"`; \
        tar -zcf ../packages/audio-$ver.tar.gz audio/COPYING
audio/DESCRIPTION audio/INDEX audio/inst/au.m audio/inst/aucapture.m
audio/inst/auload.m audio/inst/auplot.m audio/inst/aurecord.m
audio/inst/ausave.m audio/inst/clip.m audio/inst/sound.m
audio/inst/soundsc.m audio/src/FILES audio/src/Makeconf.add
audio/src/Makeconf.base audio/src/Makeconf.in audio/src/Makefile
audio/src/aurecord.cc audio/src/autogen.sh audio/src/autom4te.cache
audio/src/configure audio/src/configure.add audio/src/configure.base
audio/src/endpoint.cc audio/src/endpoint.h audio/src/install-sh
audio/src/octinst.sh.in
ver=3D`grep "Version:" autom4te.cache/DESCRIPTION | sed -e "s/Version:
*//"`; \
        tar -zcf ../packages/autom4te.cache-$ver.tar.gz
autom4te.cache/COPYING autom4te.cache/DESCRIPTION
grep: autom4te.cache/DESCRIPTION: No such file or directory
tar: autom4te.cache/COPYING: Cannot stat: No such file or directory
tar: autom4te.cache/DESCRIPTION: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
make: *** [dopkg2/autom4te.cache] Error 2


> There is still quite a bit to do in this infrastructure, but I believe
> this is a good way forward as it gives the developer complete control o=
f
> what to include in the package. We'll need to address the toplevel,
> configure, extras and non-free directories before using it for the
> majority of users.
>=20
> Thoughts?
I think this is the right approach.

S=C3=B8ren

Re: [OctDev] main/path

[H. <so...@ha...>]

I didn't bother to move them to the package system, as it looks like
2.1.x stuff. I say, delete the directory.

s=C3=B8ren

tir, 22 08 2006 kl. 15:48 +0200, skrev David Bateman:
> Should the files in main/path be removed as these are now included in
> octave core? Is there any particular reason that they have been preserv=
ed?
>=20
> D.
>=20

[OctDev] main/path

[David B. <Dav...@mo...>]

Should the files in main/path be removed as these are now included in
octave core? Is there any particular reason that they have been preserved?

D.

-- 
David Bateman                                Dav...@mo...
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

Re: [OctDev] main ported to the package system

[David B. <Dav...@mo...>]

S=C3=B8ren Hauberg wrote:

>You're talking about things that should be done by the person releasing
>the package, not the person installing the package. So I don't think
>this should be integrated in pkg.m (otherwise the person installing the
>package needs programs like makeinfo, etc.).
> =20
>
Agreed

>I think it makes sense to let release.sh (or whatever we call the script
>that makes tarballs) check if a Makefile exist in the package directory.
>If a Makefile exist in the package directory we run
>  make -C package_dir release
>Then the package maintainer can basicly do what ever he/she wants at
>release-time.
> =20
>
What, about something like in the attached patch. This essentially
replaces your release.sh script with a Makefile, that if there is a
Makefile in the sub-directory to uses this to define a variable
PKG_FILES with the files to include in the package. It equally gives the
developer of the package access to three targets pre-pkg/%::,
post-pkg/%::, and clean: that allow the developer to do things prior and
post creation of the package and define what needs to be done to clean
up the directory.

Note this code relies on the Makeconf in the root directory, and that I
haven't addressed this issue yet. Therefore, "./configure" should be run
in the root and "make" should be run in the "main/" directory. The
packages can then be found in packages/*.tar.gz which will allow your
overall tar-ball to be created as a seperate process. I've converted the
comm/ sub-directory to use the new make architecture to specify how to
treat the doc/ sub-directory.

There is still quite a bit to do in this infrastructure, but I believe
this is a good way forward as it gives the developer complete control of
what to include in the package. We'll need to address the toplevel,
configure, extras and non-free directories before using it for the
majority of users.

Thoughts?

Regards
David

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

The information contained in this communication has been classified as:=20

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

Re: [OctDev] main ported to the package system

[H. <so...@ha...>]

tir, 22 08 2006 kl. 10:12 +0200, skrev David Bateman:
> Ideally, what I would like is that the documentation is built at the
> time the package is created from the CVS, with the pdf version left in
> the doc sub-directory and the info version copied to inst/. I'd also
> like that the examples directory is copied to the package without chang=
e.
Also, we would probably like to generate some information for the
webpage (right?).

> Basically I see that this requires several changes the the release.sh
> script where there is
>=20
> 1) A means of specifying the sub-directories that are to be copied
> directly to the package and which files in these sub-directories to
> include or ignore
> 2) A means at the time the package is constructed from the CVS to run
> configure/make on arbitrary sub-directory (to find makeinfo for example=
)
>=20
> There are probably multiple ways of implementing the above, but you
> Soren as the one with the most knowledge of the package manager might
> like to suggest the way that is the simpliest. Perhaps a Makefile in th=
e
> Root of each package directory, that is not included in the package.
> This might include a file from the directory above with basic directive=
s
> to construct the package, which might be supplemented by the developer
> as needed. That is including additional files and directories and
> building certain parts of the package when the package is constructed.
>=20
> Your thoughts?
You're talking about things that should be done by the person releasing
the package, not the person installing the package. So I don't think
this should be integrated in pkg.m (otherwise the person installing the
package needs programs like makeinfo, etc.).

I think it makes sense to let release.sh (or whatever we call the script
that makes tarballs) check if a Makefile exist in the package directory.
If a Makefile exist in the package directory we run
  make -C package_dir release
Then the package maintainer can basicly do what ever he/she wants at
release-time.

S=C3=B8ren

Re: [OctDev] main ported to the package system

[David B. <Dav...@mo...>]

Soren,

As this should be applied to the octave core pkg.m function I've cc'ed
the maintainers list. John can you look at this?

S=C3=B8ren Hauberg wrote:

>man, 21 08 2006 kl. 18:43 +0200, skrev David Bateman:
> =20
>
>>Ok, this makes sense, and I'd propose something like the attached patch
>>to address this. Though this needs further testing, it seems to work fo=
r
>>the test case I've used based on the comms toolbox. Basically, this
>>means that symbolic links should be handled by the developer either
>>embedded in the code or as a seperate PKG_ADD file that is appended to
>>the end of the PKG_ADD commands found in the source.
>>   =20
>>
>Looks good, but there are a few details I don't understand:
>
> =20
>
>>+ function create_pkgadd (desc, packdir)
>>+   pkgadd =3D [desc.dir "/PKG_ADD"];
>>+   rm_rf(pkgadd);
>>   =20
>>
>Why do you need to delete 'pkgadd'? 'desc.dir' should always be a newly
>created directory, so 'pkgadd' should never exist.
> =20
>
Ok, I'm not that familar with the package system yet.

> =20
>
>>+   fid =3D fopen(pkgadd, "wt");
>>+   if (fid >=3D 0)
>>+     ## Search all dot-m files for PKG_ADD commands
>>+     lst =3D dir ([packdir "inst"]);
>>+     for i=3D1:length(lst)
>>+       nm =3D lst(i).name;
>>+       if (length(nm) > 3 && strcmp (nm((end-1):end), ".m"))
>>+         fwrite (fid, extract_pkgadd (nm, '^[#%][#%]* *PKG_ADD: *(.*)$=
'));
>>+       endif
>>+     endfor
>>   =20
>>
>Can't you simply write:
>    lst =3D dir ([packdir "/inst/*.m"]);
>    for i =3D 1:length(list)
>      nm =3D list(i).name;
>      fwrite (fid, extract_pkgadd (nm, '^[#%][#%]* *PKG_ADD: *(.*)$'));
>    endfor
>and similar for the C++ files.
> =20
>
Hey, it was a first pass. Ok, I've adapted the changes you suggested.

>=20
> =20
>
>>+     ## Search all C++ source files for PKG_ADD commands
>>+     lst =3D dir ([packdir "src"]);
>>+     for i=3D1:length(lst)
>>+       nm =3D lst(i).name;
>>+       if (length(nm) > 4 && strcmp (nm((end-2):end), ".cc"))
>>   =20
>>
>Should we only handle *.cc files, or should we also handle *.cpp and *.C
>(are there others?) ? Which reminds me: is MS Windows case sensitive, or
>do we also need to handle *.M, *.CPP, etc.?
> =20
>
The existing mkpkgadd funcion only search *.m and *.cc files. Its easy
to make it search other files, but do we want it to?

>Besides these details it looks good, and I think this should be applied
>to CVS. Assuming this gets accepted into CVS, what else is needed to aid
>package developers?
> =20
>
Some way of treating additional directories in the package other than
src/ and inst/, though I'll address that in a seperate mail..

I attach the PKG_ADD patch for pkg.m that I'd like to see applied

Regards
David

2006-08-22  David Bateman  <dba...@fr...>

    * pkg/pkg.m: Search inst/*.m and src/*.m files in the package for
    PKG_ADD directives. Append user supplied PKG_ADD as well.

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

The information contained in this communication has been classified as:=20

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

Re: [OctDev] main ported to the package system

[David B. <Dav...@mo...>]

S=C3=B8ren Hauberg wrote:

>Besides these details it looks good, and I think this should be applied
>to CVS. Assuming this gets accepted into CVS, what else is needed to aid
>package developers?
>
> =20
>

Ok, one problem I have is how to treat additional directories in the
package. For example in the comm and fixed directories there are
directories called doc and in fixed there is a directory called
examples. The doc directories contains partial documentation that is
completed automagically using the mkdoc and mktexi files to create a
.texi file that can be treated with makeinfo, etc.

Ideally, what I would like is that the documentation is built at the
time the package is created from the CVS, with the pdf version left in
the doc sub-directory and the info version copied to inst/. I'd also
like that the examples directory is copied to the package without change.

Basically I see that this requires several changes the the release.sh
script where there is

1) A means of specifying the sub-directories that are to be copied
directly to the package and which files in these sub-directories to
include or ignore
2) A means at the time the package is constructed from the CVS to run
configure/make on arbitrary sub-directory (to find makeinfo for example)

There are probably multiple ways of implementing the above, but you
Soren as the one with the most knowledge of the package manager might
like to suggest the way that is the simpliest. Perhaps a Makefile in the
Root of each package directory, that is not included in the package.
This might include a file from the directory above with basic directives
to construct the package, which might be supplemented by the developer
as needed. That is including additional files and directories and
building certain parts of the package when the package is constructed.

Your thoughts?

D.

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

The information contained in this communication has been classified as:=20

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

Re: [OctDev] main ported to the package system

[H. <so...@ha...>]

man, 21 08 2006 kl. 14:45 +0200, skrev David Bateman:
> The .cvsignore file tells CVS the files that are created and so that
> therefore can be ignore. CVS ignore *.o and *~ for example. With
> .cvsignore we can make also ignore things like *.texi, etc. The basic
> thing to do with them would be to copy them as is the src/ and inst/. W=
e
> can deal with cutting down their contents later.
Okay I've copied .cvsignore's into src and inst directories in packages
that used to have a .cvsignore.

S=C3=B8ren

Re: [OctDev] main ported to the package system

[H. <so...@ha...>]

man, 21 08 2006 kl. 18:43 +0200, skrev David Bateman:
> Ok, this makes sense, and I'd propose something like the attached patch
> to address this. Though this needs further testing, it seems to work fo=
r
> the test case I've used based on the comms toolbox. Basically, this
> means that symbolic links should be handled by the developer either
> embedded in the code or as a seperate PKG_ADD file that is appended to
> the end of the PKG_ADD commands found in the source.
Looks good, but there are a few details I don't understand:

> + function create_pkgadd (desc, packdir)
> +   pkgadd =3D [desc.dir "/PKG_ADD"];
> +   rm_rf(pkgadd);
Why do you need to delete 'pkgadd'? 'desc.dir' should always be a newly
created directory, so 'pkgadd' should never exist.

> +   fid =3D fopen(pkgadd, "wt");
> +   if (fid >=3D 0)
> +     ## Search all dot-m files for PKG_ADD commands
> +     lst =3D dir ([packdir "inst"]);
> +     for i=3D1:length(lst)
> +       nm =3D lst(i).name;
> +       if (length(nm) > 3 && strcmp (nm((end-1):end), ".m"))
> +         fwrite (fid, extract_pkgadd (nm, '^[#%][#%]* *PKG_ADD: *(.*)$=
'));
> +       endif
> +     endfor
Can't you simply write:
    lst =3D dir ([packdir "/inst/*.m"]);
    for i =3D 1:length(list)
      nm =3D list(i).name;
      fwrite (fid, extract_pkgadd (nm, '^[#%][#%]* *PKG_ADD: *(.*)$'));
    endfor
and similar for the C++ files.
=20
> +     ## Search all C++ source files for PKG_ADD commands
> +     lst =3D dir ([packdir "src"]);
> +     for i=3D1:length(lst)
> +       nm =3D lst(i).name;
> +       if (length(nm) > 4 && strcmp (nm((end-2):end), ".cc"))
Should we only handle *.cc files, or should we also handle *.cpp and *.C
(are there others?) ? Which reminds me: is MS Windows case sensitive, or
do we also need to handle *.M, *.CPP, etc.?

Besides these details it looks good, and I think this should be applied
to CVS. Assuming this gets accepted into CVS, what else is needed to aid
package developers?

S=C3=B8ren

Re: [OctDev] main ported to the package system

[David B. <Dav...@mo...>]

S=C3=B8ren Hauberg wrote:

>Okay, I think I understand! I never thought that it would be that
>important to have stuff like this in the package manager. I just
>figured, that we would have some scripts to aid the package developer.
>
>You suggested that the package developer creates a file that contains
>lines like this
>	gf glu
>which is converted into a file that contains
>	autoload ("glu", which ("gf"));
>Personaly, I don't see the great win about this. Why not simply let the
>developer create the PKG_ADD file? We can provide scripts that can
>extract
>	## PKG_ADD: XXX
>comments from .m and .cc files to aid the developer.
>
> =20
>
Ok, this makes sense, and I'd propose something like the attached patch
to address this. Though this needs further testing, it seems to work for
the test case I've used based on the comms toolbox. Basically, this
means that symbolic links should be handled by the developer either
embedded in the code or as a seperate PKG_ADD file that is appended to
the end of the PKG_ADD commands found in the source.

>I don't see an easy way of integrating things like this in the package
>manager, simply because I don't think it is the job of the package
>manager, but the job of the package developer. I'll be happy to
>implement changes in the package manager, but I'll need to be told what
>to implement :-)
> =20
>
Can you check what I supplied?

D.


>S=C3=B8ren
> =20
>

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

The information contained in this communication has been classified as:=20

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

Re: [OctDev] main ported to the package system

[David B. <Dav...@mo...>]

S=C3=B8ren Hauberg wrote:

>I've copied the admin directories to the packages that needed the
>octlink.sh script. If I forgot to copy it into a package that actually
>needs the script, then I've made a mistake. Which packages are giving
>you problems because octlink.sh is missing?
>
>I've not been involved in octave long enough to actually know what these
>scripts does. But from what you are saying, I get the impression that
>octlink.sh needs to be removed from the individual packages and replaced
>by PKG_ADD files.
> =20
>

octlink.sh was a hack that allowed support of both symbolic links and
the use of the octave autoload function on systems that supportted it.
Version of octave later than 2.9.4 all support autoload and so
octlink.sh is no longer needed as such as what is done in this script
should be done for all symbolic links. However, with the way the pkg
build system seems to work this means it needs to be done on a package
by package basis (Soren comments)

This stuff hooks into the admin/mkpkgadd script. Again it doesn't seem
obvious to me how we can make mkpkgadd and octlink part of pkg.m rather
than the individual packages. Searching the *.m and *.cc files for
PKG_ADD commands is easy enough, but the treatment of the symbolic links
needs to be done on a package by package basis.

Perhaps we can make a pkg/src/symlinks and pkg/inst/symlinks file in the
package manager, that includes pairs like

gf glu
gf greal

etc, which repesent "ln -s gf.oct glu.oct". The pkg.m script can then
convert these to

autoload ("glu", which ("gf"));
autoload ("greal", which ("gf"));

in the PKG_ADD file. This of course requires a small modification the
pkg.m. So Soren your thoughts on this are necessary.. I'll try to
propose something since this is blocking my porting of the
communications toolbox.

D.

>S=C3=B8ren
>
>man, 21 08 2006 kl. 16:22 +0200, skrev David Bateman:
> =20
>
>>Ok, another nasty problem is that the admin/octlink.sh script is not
>>copied to the pkg src/ directories. Perhaps as teh package manager is
>>only in versions of octave which have the autoload function, this can
>>all be simplified, as only the .octlink fashion of dealing with the
>>files needs to be treated. That is we should probably generate the
>>appropriate PKD_ADD file directly rather than use octlink.sh.. This
>>problem occurs wherecer symbolic links are used in octave-forge. Its
>>vital that autoload is used if possible to allow significant reduction
>>in binary size especially for cygwin and mingw platforms...
>>
>>I'll work out a solution for the communications toolbox and propose it.
>>
>>D.
>>
>>
>>   =20
>>
>
>
>
> =20
>


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

The information contained in this communication has been classified as:=20

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

Re: [OctDev] main ported to the package system

[H. <so...@ha...>]

Okay, I think I understand! I never thought that it would be that
important to have stuff like this in the package manager. I just
figured, that we would have some scripts to aid the package developer.

You suggested that the package developer creates a file that contains
lines like this
	gf glu
which is converted into a file that contains
	autoload ("glu", which ("gf"));
Personaly, I don't see the great win about this. Why not simply let the
developer create the PKG_ADD file? We can provide scripts that can
extract
	## PKG_ADD: XXX
comments from .m and .cc files to aid the developer.

I don't see an easy way of integrating things like this in the package
manager, simply because I don't think it is the job of the package
manager, but the job of the package developer. I'll be happy to
implement changes in the package manager, but I'll need to be told what
to implement :-)

S=C3=B8ren

man, 21 08 2006 kl. 17:10 +0200, skrev David Bateman:
> S=C3=B8ren Hauberg wrote:
>=20
> >I've copied the admin directories to the packages that needed the
> >octlink.sh script. If I forgot to copy it into a package that actually
> >needs the script, then I've made a mistake. Which packages are giving
> >you problems because octlink.sh is missing?
> >
> >I've not been involved in octave long enough to actually know what the=
se
> >scripts does. But from what you are saying, I get the impression that
> >octlink.sh needs to be removed from the individual packages and replac=
ed
> >by PKG_ADD files.
> > =20
> >
>=20
> octlink.sh was a hack that allowed support of both symbolic links and
> the use of the octave autoload function on systems that supportted it.
> Version of octave later than 2.9.4 all support autoload and so
> octlink.sh is no longer needed as such as what is done in this script
> should be done for all symbolic links. However, with the way the pkg
> build system seems to work this means it needs to be done on a package
> by package basis (Soren comments)
>=20
> This stuff hooks into the admin/mkpkgadd script. Again it doesn't seem
> obvious to me how we can make mkpkgadd and octlink part of pkg.m rather
> than the individual packages. Searching the *.m and *.cc files for
> PKG_ADD commands is easy enough, but the treatment of the symbolic link=
s
> needs to be done on a package by package basis.
>=20
> Perhaps we can make a pkg/src/symlinks and pkg/inst/symlinks file in th=
e
> package manager, that includes pairs like
>=20
> gf glu
> gf greal
>=20
> etc, which repesent "ln -s gf.oct glu.oct". The pkg.m script can then
> convert these to
>=20
> autoload ("glu", which ("gf"));
> autoload ("greal", which ("gf"));
>=20
> in the PKG_ADD file. This of course requires a small modification the
> pkg.m. So Soren your thoughts on this are necessary.. I'll try to
> propose something since this is blocking my porting of the
> communications toolbox.
>=20
> D.
>=20
> >S=C3=B8ren
> >
> >man, 21 08 2006 kl. 16:22 +0200, skrev David Bateman:
> > =20
> >
> >>Ok, another nasty problem is that the admin/octlink.sh script is not
> >>copied to the pkg src/ directories. Perhaps as teh package manager is
> >>only in versions of octave which have the autoload function, this can
> >>all be simplified, as only the .octlink fashion of dealing with the
> >>files needs to be treated. That is we should probably generate the
> >>appropriate PKD_ADD file directly rather than use octlink.sh.. This
> >>problem occurs wherecer symbolic links are used in octave-forge. Its
> >>vital that autoload is used if possible to allow significant reductio=
n
> >>in binary size especially for cygwin and mingw platforms...
> >>
> >>I'll work out a solution for the communications toolbox and propose i=
t.
> >>
> >>D.
> >>
> >>
> >>   =20
> >>
> >
> >
> >
> > =20
> >
>=20
>=20

Re: [OctDev] main ported to the package system

[H. <so...@ha...>]

I've copied the admin directories to the packages that needed the
octlink.sh script. If I forgot to copy it into a package that actually
needs the script, then I've made a mistake. Which packages are giving
you problems because octlink.sh is missing?

I've not been involved in octave long enough to actually know what these
scripts does. But from what you are saying, I get the impression that
octlink.sh needs to be removed from the individual packages and replaced
by PKG_ADD files.

S=C3=B8ren

man, 21 08 2006 kl. 16:22 +0200, skrev David Bateman:
> Ok, another nasty problem is that the admin/octlink.sh script is not
> copied to the pkg src/ directories. Perhaps as teh package manager is
> only in versions of octave which have the autoload function, this can
> all be simplified, as only the .octlink fashion of dealing with the
> files needs to be treated. That is we should probably generate the
> appropriate PKD_ADD file directly rather than use octlink.sh.. This
> problem occurs wherecer symbolic links are used in octave-forge. Its
> vital that autoload is used if possible to allow significant reduction
> in binary size especially for cygwin and mingw platforms...
>=20
> I'll work out a solution for the communications toolbox and propose it.
>=20
> D.
>=20
>=20

Re: [OctDev] main ported to the package system

[David B. <Dav...@mo...>]

Ok, another nasty problem is that the admin/octlink.sh script is not
copied to the pkg src/ directories. Perhaps as teh package manager is
only in versions of octave which have the autoload function, this can
all be simplified, as only the .octlink fashion of dealing with the
files needs to be treated. That is we should probably generate the
appropriate PKD_ADD file directly rather than use octlink.sh.. This
problem occurs wherecer symbolic links are used in octave-forge. Its
vital that autoload is used if possible to allow significant reduction
in binary size especially for cygwin and mingw platforms...

I'll work out a solution for the communications toolbox and propose it.

D.


-- 
David Bateman                                Dav...@mo...
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

Re: [OctDev] main ported to the package system

[David B. <Dav...@mo...>]

S=C3=B8ren Hauberg wrote:

>
>I don't really know the first thing about CVS. What does .cvsignore do?
>And what should I do with them?
> =20
>
The .cvsignore file tells CVS the files that are created and so that
therefore can be ignore. CVS ignore *.o and *~ for example. With
.cvsignore we can make also ignore things like *.texi, etc. The basic
thing to do with them would be to copy them as is the src/ and inst/. We
can deal with cutting down their contents later.

> =20
>
>>The version numbers you added to fixed doesn't correspond to the
>>existing version number used internally in the code. Fixed should be
>>0.7.0...
>>   =20
>>
>Sorry :-)
>Since I didn't know anything about the internal version numbers, I've
>chosen that all packages are at version 1.0.0, which needs to be changed
>in the individual packages. Also, information about maintainers (etc.)
>needs to be corrected on a per package basis.
> =20
>

No problems... The maintainer, should be someone who will continue to
maintain the package, and not necessarily the original author. Not that
many people are active over the long term and so I wouldn't hesitate to
make the maintainer someone who isn't an author. However, the person
must agree to be the maintainer. I agree to be the maintainer of at
least comms and fixed. Maybe I'll agree to others later. We need
agreement from others to maintain the packages once the initial
development phase is complete. We can then identify orphaned packages.

Also with some of the directories it problem makes sense to convert them
to several packages. For example the xml stuff in miscellaneous should
probably be a seperate package.

> =20
>
>>> The file called octave-forge-main-<date>.tar.gz is a bundle of all th=
e
>>>packages, but it can't be installed without a patch to pkg that you ca=
n
>>>find on the octave-bug list.
>>>
>>> I can't install the packages called "parallel", "comm", "fixed", and
>>>"linear-algebra" due to a problem in ./configure. However, that proble=
m
>>>has been hunting me since before the move to the package system, so my
>>>problems shouldn't be related to the package system.
>>>=20
>>>
>>>     =20
>>>
>>I'll look at comm and fixed as these are my stuff.
>>   =20
>>
>My problems are related to the configure script, but once the #ifdef's
>go away, so will my problems.
> =20
>
Ok, then I'll work on removeing the ifdef's first..

>Okay, but this stuff can be handled on a per package basis, and we can
>easily make releases even though the #ifdef's, etc. haven't been removed
>(my point: we're not in a hurry).
> =20
>

Agreed...

Cheers
David



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

The information contained in this communication has been classified as:=20

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

Re: [OctDev] main ported to the package system

[H. <so...@ha...>]

Hi,

man, 21 08 2006 kl. 14:10 +0200, skrev David Bateman:
[snip]
> Some comments. I get the error message
>=20
> date: unrecognized option `--rfc-3339=3Ddate'
> Try `date --help' for more information.
Okay, I must have used some Ubuntu specific option for the date command
-- I'll change that

> when running release.sh. The packages are created, but without the
> date... I don't like the fact that the release.sh existing in the main
> sub-directory, only. I'd prefer to run something from the top level.
I don't like it either, I just wanted something the rest of you could
use quickly. So I don't consider that script to be a long term solution.

> Though there is a release.sh script already there from Paul, that is
> missing the execute permission. So you'll either need another name, or
> you'll need to ask for execute permission to be added by the sourceforg=
e
> admin...
>=20
> Probably better would be to use the Makefile to call the release.sh in
> the sub-directories.
Agreed. I just didn't want to overwrite Paul's Makefiles just yet.

>  Also can we include some means of removing the
> packages in the makefile, though the inclusion of the date in the
> package file name might make that interesting to do in a sensible way.
Perhaps, we just shouldn't use the date command? The individual packages
have versions, so the date command is only interessting in order to
create a bundle package that contains all the packages.

> Can we exclude the CVS and the .cvsignore files from the packages? This
> might be done with the --exclude option of tar, or alternatively with
> the --exclude-from (or -X) option and create an excludes file in each o=
f
> the sub-directories.
Yes, we should do this. I'll look at it when I get home from work. I
simply missed that detail.

> You've moved many of the source files, is src/ and inst/
> sub-directories. The corresponding .cvsignore files should also be
> moved, and maybe even split into two parts for each of these
> sub-directories.
I don't really know the first thing about CVS. What does .cvsignore do?
And what should I do with them?

> The version numbers you added to fixed doesn't correspond to the
> existing version number used internally in the code. Fixed should be
> 0.7.0...
Sorry :-)
Since I didn't know anything about the internal version numbers, I've
chosen that all packages are at version 1.0.0, which needs to be changed
in the individual packages. Also, information about maintainers (etc.)
needs to be corrected on a per package basis.

> >  The file called octave-forge-main-<date>.tar.gz is a bundle of all t=
he
> >packages, but it can't be installed without a patch to pkg that you ca=
n
> >find on the octave-bug list.
> >
> >  I can't install the packages called "parallel", "comm", "fixed", and
> >"linear-algebra" due to a problem in ./configure. However, that proble=
m
> >has been hunting me since before the move to the package system, so my
> >problems shouldn't be related to the package system.
> > =20
> >
> I'll look at comm and fixed as these are my stuff.
My problems are related to the configure script, but once the #ifdef's
go away, so will my problems.

> >  If you guys don't have any problems with the packages, I'll move
> >"nonfree" (and "extra"?) to the package system. The next step is then =
to
> >clean up the individual packages, so we can get rid of all the #ifdef'=
s
> >(right?)
> There is a lot of ifdef junk in the code that should be stripped in the
> C++ code. However, there is equally some try-catch blocks in the m-file=
s
> for features that are present or not in various versions of octave.
Okay, but this stuff can be handled on a per package basis, and we can
easily make releases even though the #ifdef's, etc. haven't been removed
(my point: we're not in a hurry).

Thanks,
S=C3=B8ren

Re: [OctDev] main ported to the package system

[David B. <Dav...@mo...>]

Soren,

Another problem I have can be seen in the following

pkg("install","octave-forge-main-.tar.gz")
warning: You have not defined an installation prefix, so the following
will be used: /opt/octave-2.9share/octave/packages/
warning: Creating installation directory
/opt/octave-2.9share/octave/packages/
error: Could not create installation directory: No such file or directory

Basically, but configure prefix arg was "/opt/ocatve-2.9" and so pkg.m
(with your bundle patch) needs to be modified as in the attached patch.
After that it seems to work, though its currently in the process of
building on my machine...

Regards
David



-- 
David Bateman                                Dav...@mo...
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

Re: [OctDev] main ported to the package system

[David B. <Dav...@mo...>]

S=C3=B8ren Hauberg wrote:

>Hi,
>  Since nobody had any problems with me moving octave-forge to the
>package system, I've started that process. Currently 'main' is ported in
>CVS.
> =20
>
Soren,

This is great.. I'll try it out more extensively soon. However, I have a
few initial comments.

>  It works on my system, but that's not really a great test. So it would
>be great if some of you guys could help me test it. So if you want to
>help, please check out pkg from octave cvs, and check out octave-forge
>from cvs. Then run './release.sh' in the 'main' directory in
>octave-forge.
>  This will generate a bunch of .tar.gz files that can be installed from
>octave with the command
>  pkg("install", "package_name.tar.gz")
> =20
>
Some comments. I get the error message

date: unrecognized option `--rfc-3339=3Ddate'
Try `date --help' for more information.

when running release.sh. The packages are created, but without the
date... I don't like the fact that the release.sh existing in the main
sub-directory, only. I'd prefer to run something from the top level.
Though there is a release.sh script already there from Paul, that is
missing the execute permission. So you'll either need another name, or
you'll need to ask for execute permission to be added by the sourceforge
admin...

Probably better would be to use the Makefile to call the release.sh in
the sub-directories. Also can we include some means of removing the
packages in the makefile, though the inclusion of the date in the
package file name might make that interesting to do in a sensible way.

Can we exclude the CVS and the .cvsignore files from the packages? This
might be done with the --exclude option of tar, or alternatively with
the --exclude-from (or -X) option and create an excludes file in each of
the sub-directories.

You've moved many of the source files, is src/ and inst/
sub-directories. The corresponding .cvsignore files should also be
moved, and maybe even split into two parts for each of these
sub-directories.

The version numbers you added to fixed doesn't correspond to the
existing version number used internally in the code. Fixed should be
0.7.0...

>  The file called octave-forge-main-<date>.tar.gz is a bundle of all the
>packages, but it can't be installed without a patch to pkg that you can
>find on the octave-bug list.
>
>  I can't install the packages called "parallel", "comm", "fixed", and
>"linear-algebra" due to a problem in ./configure. However, that problem
>has been hunting me since before the move to the package system, so my
>problems shouldn't be related to the package system.
> =20
>
I'll look at comm and fixed as these are my stuff.

>  If you guys don't have any problems with the packages, I'll move
>"nonfree" (and "extra"?) to the package system. The next step is then to
>clean up the individual packages, so we can get rid of all the #ifdef's
>(right?)
> =20
>

There is a lot of ifdef junk in the code that should be stripped in the
C++ code. However, there is equally some try-catch blocks in the m-files
for features that are present or not in various versions of octave.

Regards
David



>  Sorry about the long mail,
>S=C3=B8ren
>
>
>
>------------------------------------------------------------------------=
-
>Using Tomcat but need to do more? Need to support web services, security=
?
>Get stuff done quickly with pre-integrated technology to make your job e=
asier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geroni=
mo
>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
>_______________________________________________
>Octave-dev mailing list
>Oct...@li...
>https://lists.sourceforge.net/lists/listinfo/octave-dev
> =20
>


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

The information contained in this communication has been classified as:=20

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

[OctDev] main ported to the package system

[H. <so...@ha...>]

Hi,
  Since nobody had any problems with me moving octave-forge to the
package system, I've started that process. Currently 'main' is ported in
CVS.
  It works on my system, but that's not really a great test. So it would
be great if some of you guys could help me test it. So if you want to
help, please check out pkg from octave cvs, and check out octave-forge
from cvs. Then run './release.sh' in the 'main' directory in
octave-forge.
  This will generate a bunch of .tar.gz files that can be installed from
octave with the command
  pkg("install", "package_name.tar.gz")

  The file called octave-forge-main-<date>.tar.gz is a bundle of all the
packages, but it can't be installed without a patch to pkg that you can
find on the octave-bug list.

  I can't install the packages called "parallel", "comm", "fixed", and
"linear-algebra" due to a problem in ./configure. However, that problem
has been hunting me since before the move to the package system, so my
problems shouldn't be related to the package system.

  If you guys don't have any problems with the packages, I'll move
"nonfree" (and "extra"?) to the package system. The next step is then to
clean up the individual packages, so we can get rid of all the #ifdef's
(right?)

  Sorry about the long mail,
S=C3=B8ren

Re: [OctDev] becoming developer

[Sissou s. <syl...@gm...>]

I'm sorry I forgot one file :

expintbase.m:

## Copyright (C) 2006   Sissou   <syl...@gm...>
##
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; either version 2 of the License, or
## (at your option) any later version.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with this program; if not, write to the Free Software
## Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  US=
A

## EXPINT compute the the function :
##
##       expintbase(x) =3D exp(t)/t dt
##
## See also expint_Ei, expint_E1, expint.

function y =3D expintbase(x)
    if (nargin !=3D 1)
        usage ("expintbase(x)");
    endif
    y =3D exp(-x)./x;
endfunction


2006/8/17, sissou <syl...@gm...>:
>
>  David Bateman a =E9crit :
>
> sissou wrote:
>
> Hello,
>
> Can someone add me as developper please, my sourceforge user id is
> sis-sou.
> Thanks.
>
>
>
> Hi Sissou,
>
> In general it is fairly easy to get developer access to octave-forge, but
> its generally considered to be good etiquette to show some code to give a=
n
> idea of what you want  to add. I don't recognize you from the lists, thou=
gh
> perhaps I missed something. Please send some code to discuss to the lists
> and then I'd have no trouble adding you...
>
> Cheers
> David
>
>
>
>  Ok, so I wrote *expint_Ei,* *expint_E1* ant *expint *functions *(expint
> is expint_E1 but I did it only for matlab compatibility)*.
> This is the code :
>
> expint_Ei.m :
>
>  *## Copyright (C) 2006   Sissou   <syl...@gm...><sylvain.=
pel...@gm...>
> ##
> ## This program is free software; you can redistribute it and/or modify
> ## it under the terms of the GNU General Public License as published by
> ## the Free Software Foundation; either version 2 of the License, or
> ## (at your option) any later version.
> ##
> ## This program is distributed in the hope that it will be useful,
> ## but WITHOUT ANY WARRANTY; without even the implied warranty of
> ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ## GNU General Public License for more details.
> ##
> ## You should have received a copy of the GNU General Public License
> ## along with this program; if not, write to the Free Software
> ## Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
> USA
>
> ## EXPINT_EI compute the exponential integral,
> ##
> ##                      infinity
> ##                     /
> ##       expint(x) =3D - | exp(t)/t dt
> ##                     /
> ##                     -x
> ##
> ## See also expint, expint_E1.
>
> function y =3D expint_Ei(x)
>     if (nargin !=3D 1)
>         usage ("expint_Ei(x)");
>     endif
>
>     if(x<0)
>         y =3D -quad("expintbase",-x,Inf);
>     else
>         y =3D 0;
>         for i =3D 1:100;
>             y =3D y + x.^i./(i.*factorial(i));
>         endfor
>
>         y =3D 0.577215664901532860606512090082402431 + log(x) + y;
>     endif;
> endfunction;
>
> expint_E1.m :
>
> ## Copyright (C) 2006   Sissou   <syl...@gm...><sylvain.pe=
li...@gm...>
> ##
> ## This program is free software; you can redistribute it and/or modify
> ## it under the terms of the GNU General Public License as published by
> ## the Free Software Foundation; either version 2 of the License, or
> ## (at your option) any later version.
> ##
> ## This program is distributed in the hope that it will be useful,
> ## but WITHOUT ANY WARRANTY; without even the implied warranty of
> ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ## GNU General Public License for more details.
> ##
> ## You should have received a copy of the GNU General Public License
> ## along with this program; if not, write to the Free Software
> ## Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
> USA
>
> ## EXPINT_E1 compute the exponential integral,
> ##
> ##                    infinity
> ##                   /
> ##       expint(x) =3D | exp(t)/t dt
> ##                   /
> ##                  x
> ##
> ## See also expint_Ei, expint.
>
> function v =3D expint_E1(x)
>     if (nargin !=3D 1)
>         usage ("expint_E1(x)");
>     endif
>     if(x > 0 && imag(x) =3D=3D 0)
>         v =3D -expint_Ei(-x);
>     else
>         v =3D -expint_Ei(-x) - i.*pi;
>     endif
> endfunction
>
> expint.m :
>
> ## Copyright (C) 2006   Sissou   <syl...@gm...><sylvain.pe=
li...@gm...>
> ##
> ## This program is free software; you can redistribute it and/or modify
> ## it under the terms of the GNU General Public License as published by
> ## the Free Software Foundation; either version 2 of the License, or
> ## (at your option) any later version.
> ##
> ## This program is distributed in the hope that it will be useful,
> ## but WITHOUT ANY WARRANTY; without even the implied warranty of
> ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ## GNU General Public License for more details.
> ##
> ## You should have received a copy of the GNU General Public License
> ## along with this program; if not, write to the Free Software
> ## Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
> USA
>
> ## EXPINT compute the exponential integral,
> ##
> ##                    infinity
> ##                   /
> ##       expint(x) =3D | exp(t)/t dt
> ##                   /
> ##                  x
> ##
> ## See also expint_Ei, expint_E1.
>
> function y =3D expint(x)
>     if (nargin !=3D 1)
>         usage ("expint(x)");
>     endif
>     y =3D expint_E1(x);
> endfuncion;
>
> *And after that I would like to make some other special functions and wor=
k
> one the fill function because it's very ugly.
> Sorry for didn't explain that before.
>

Re: [OctDev] becoming developer

[sissou <syl...@gm...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
David Bateman a &eacute;crit&nbsp;:
<blockquote cite="mid...@mo..." type="cite">sissou
wrote:
  <br>
  <blockquote type="cite">Hello,
    <br>
    <br>
Can someone add me as developper please, my sourceforge user id is
sis-sou.
    <br>
Thanks.
    <br>
&nbsp; </blockquote>
  <br>
Hi Sissou,
  <br>
  <br>
In general it is fairly easy to get developer access to octave-forge,
but its generally considered to be good etiquette to show some code to
give an idea of what you want&nbsp; to add. I don't recognize you from the
lists, though perhaps I missed something. Please send some code to
discuss to the lists and then I'd have no trouble adding you...
  <br>
  <br>
Cheers
  <br>
David
  <br>
  <br>
  <br>
  <br>
</blockquote>
<font face="DejaVu Sans">Ok, so I wrote <i>expint_Ei,</i> <i>expint_E1</i>
ant <i>expint </i></font><font face="DejaVu Sans">functions </font><font
 face="DejaVu Sans"><i>(expint is expint_E1 but I did it only for
matlab compatibility)</i>.<br>
This is the code :</font><br>
<div align="left"><br>
<font face="DejaVu Sans">expint_Ei.m :</font><br>
<br>
</div>
<font face="DejaVu Sans"><i>## Copyright (C) 2006&nbsp;&nbsp; Sissou&nbsp;&nbsp;
<a class="moz-txt-link-rfc2396E" href="mailto:syl...@gm...">&lt;syl...@gm...&gt;</a><br>
##<br>
## This program is free software; you can redistribute it and/or modify<br>
## it under the terms of the GNU General Public License as published by<br>
## the Free Software Foundation; either version 2 of the License, or<br>
## (at your option) any later version.<br>
##<br>
## This program is distributed in the hope that it will be useful,<br>
## but WITHOUT ANY WARRANTY; without even the implied warranty of<br>
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.&nbsp; See the<br>
## GNU General Public License for more details.<br>
##<br>
## You should have received a copy of the GNU General Public License<br>
## along with this program; if not, write to the Free Software<br>
## Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA&nbsp;
02111-1307&nbsp; USA<br>
<br>
## EXPINT_EI compute the exponential integral,<br>
##<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; infinity<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; expint(x) = - | exp(t)/t dt<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -x<br>
##<br>
## See also expint, expint_E1.<br>
<br>
function y = expint_Ei(x)<br>
&nbsp;&nbsp;&nbsp; if (nargin != 1)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; usage ("expint_Ei(x)");<br>
&nbsp;&nbsp;&nbsp; endif<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; if(x&lt;0)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; y = -quad("expintbase",-x,Inf);<br>
&nbsp;&nbsp;&nbsp; else<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; y = 0;<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; for i = 1:100;<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; y = y + x.^i./(i.*factorial(i));<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; endfor<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; y = 0.577215664901532860606512090082402431 + log(x) + y;<br>
&nbsp;&nbsp;&nbsp; endif;<br>
endfunction;<br>
<br>
expint_E1.m :<br>
<br>
## Copyright (C) 2006&nbsp;&nbsp; Sissou&nbsp;&nbsp; <a class="moz-txt-link-rfc2396E" href="mailto:syl...@gm...">&lt;syl...@gm...&gt;</a><br>
##<br>
## This program is free software; you can redistribute it and/or modify<br>
## it under the terms of the GNU General Public License as published by<br>
## the Free Software Foundation; either version 2 of the License, or<br>
## (at your option) any later version.<br>
##<br>
## This program is distributed in the hope that it will be useful,<br>
## but WITHOUT ANY WARRANTY; without even the implied warranty of<br>
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.&nbsp; See the<br>
## GNU General Public License for more details.<br>
##<br>
## You should have received a copy of the GNU General Public License<br>
## along with this program; if not, write to the Free Software<br>
## Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA&nbsp;
02111-1307&nbsp; USA<br>
<br>
## EXPINT_E1 compute the exponential integral,<br>
##<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; infinity<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; expint(x) = | exp(t)/t dt<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x<br>
##<br>
## See also expint_Ei, expint.<br>
<br>
function v = expint_E1(x)<br>
&nbsp;&nbsp;&nbsp; if (nargin != 1)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; usage ("expint_E1(x)");<br>
&nbsp;&nbsp;&nbsp; endif<br>
&nbsp;&nbsp;&nbsp; if(x &gt; 0 &amp;&amp; imag(x) == 0)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; v = -expint_Ei(-x);<br>
&nbsp;&nbsp;&nbsp; else<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; v = -expint_Ei(-x) - i.*pi;<br>
&nbsp;&nbsp;&nbsp; endif<br>
endfunction<br>
<br>
expint.m :<br>
<br>
## Copyright (C) 2006&nbsp;&nbsp; Sissou&nbsp;&nbsp; <a class="moz-txt-link-rfc2396E" href="mailto:syl...@gm...">&lt;syl...@gm...&gt;</a><br>
##<br>
## This program is free software; you can redistribute it and/or modify<br>
## it under the terms of the GNU General Public License as published by<br>
## the Free Software Foundation; either version 2 of the License, or<br>
## (at your option) any later version.<br>
##<br>
## This program is distributed in the hope that it will be useful,<br>
## but WITHOUT ANY WARRANTY; without even the implied warranty of<br>
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.&nbsp; See the<br>
## GNU General Public License for more details.<br>
##<br>
## You should have received a copy of the GNU General Public License<br>
## along with this program; if not, write to the Free Software<br>
## Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA&nbsp;
02111-1307&nbsp; USA<br>
<br>
## EXPINT compute the exponential integral,<br>
##<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; infinity<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; expint(x) = | exp(t)/t dt<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /<br>
##&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x<br>
##<br>
## See also expint_Ei, expint_E1.<br>
<br>
function y = expint(x)<br>
&nbsp;&nbsp;&nbsp; if (nargin != 1)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; usage ("expint(x)");<br>
&nbsp;&nbsp;&nbsp; endif<br>
&nbsp;&nbsp;&nbsp; y = expint_E1(x);<br>
endfuncion;<br>
<br>
</i>And after that I would like to make some other special functions
and work one the fill function because it's very ugly.<br>
Sorry for didn't explain that before.<br>
</font>
</body>
</html>

Re: [OctDev] becoming developer

[David B. <Dav...@mo...>]

sissou wrote:
> Hello,
>
> Can someone add me as developper please, my sourceforge user id is sis-sou.
> Thanks.
>   

Hi Sissou,

In general it is fairly easy to get developer access to octave-forge, 
but its generally considered to be good etiquette to show some code to 
give an idea of what you want  to add. I don't recognize you from the 
lists, though perhaps I missed something. Please send some code to 
discuss to the lists and then I'd have no trouble adding you...

Cheers
David