octave-dev — GNU Octave developers' list

Re: [OctDev] "dispatch.oct is not a valid shared library".

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

This happened to me when I built octave-forge against an older 2.1.50
version and then rebuilt the CVS version of octave without rebuilding
octave-forge. As teh CVS version of octave has the name 2.1.50 still.

Maybe you have the same problem..

D.

Dapr=E8s Lute Kamstra <Lut...@cw...> (le 07/11/2003):
> Dear people,
>=20
> I've built octave-forge from CVS on top of octave from CVS.  Now,
> when I start octave-2.1.50, I see these messages:
>=20
> ,----
> | error: /export/scratch1/lute/software/cvs/libexec/octave/2.1.50/site/=
oct/i686-pc-linux-gnu/octave-forge/dispatch.oct is not a valid shared lib=
rary
> | error: `dispatch' undefined near line 2 column 1
> | error: near line 2 of file `/export/scratch1/lute/software/cvs/share/=
octave/2.1.50/site/m/octave-forge/comm//PKG_ADD'
> | error: source: error sourcing file `/export/scratch1/lute/software/cv=
s/share/octave/2.1.50/site/m/octave-forge/comm//PKG_ADD'
> `----
>=20
> It seems that octave doesn't recognize dispatch.oct as a valid shared
> lib.  I've got a number of octave versions installed in parallel, but
> I don't think that is causing the problem as .configure informed me
> that:
>=20
> ,----
> | octave-forge is configured with
> |    octave:      /export/scratch1/lute/software/cvs/bin/octave (versio=
n 2.1.50)
> |    mkoctfile:	/export/scratch1/lute/software/cvs/bin/mkoctfile for Oc=
tave 50
> `----
>=20
> Did I mess up the installation, or is this a bug?
>=20
>   Lute.
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

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

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] "dispatch.oct is not a valid shared library".

[Lute K. <Lut...@cw...>]

Dear people,

I've built octave-forge from CVS on top of octave from CVS.  Now,
when I start octave-2.1.50, I see these messages:

,----
| error: /export/scratch1/lute/software/cvs/libexec/octave/2.1.50/site/oct/i686-pc-linux-gnu/octave-forge/dispatch.oct is not a valid shared library
| error: `dispatch' undefined near line 2 column 1
| error: near line 2 of file `/export/scratch1/lute/software/cvs/share/octave/2.1.50/site/m/octave-forge/comm//PKG_ADD'
| error: source: error sourcing file `/export/scratch1/lute/software/cvs/share/octave/2.1.50/site/m/octave-forge/comm//PKG_ADD'
`----

It seems that octave doesn't recognize dispatch.oct as a valid shared
lib.  I've got a number of octave versions installed in parallel, but
I don't think that is causing the problem as .configure informed me
that:

,----
| octave-forge is configured with
|    octave:      /export/scratch1/lute/software/cvs/bin/octave (version 2.1.50)
|    mkoctfile:	/export/scratch1/lute/software/cvs/bin/mkoctfile for Octave 50
`----

Did I mess up the installation, or is this a bug?

  Lute.

Re: [OctDev] admin/mk{doc,texi} and multiple Octave versions.

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

Hi Lute,

Ok, I submitted a request on the suggested support page. Now I'll wait an=
d
see what happens....

D.

Dapr=E8s Lute Kamstra <Lut...@cw...> (le 07/11/2003):
> David Bateman <Dav...@mo...> writes:
>=20
> > So unless someone has RCS access on sourceforge, the old solution I
> > see is to rename these files.
>=20
> I took a quick look at the SourceForge docs.  The section:
>=20
>   http://sourceforge.net/docman/display_doc.php?docid=3D768&group_id=3D=
1#cleanup
>=20
> says:
>=20
> ,----
> |   CVS Repository Clean-Up
> |=20
> |     Through the course of learning to use CVS, and in long-term use
> |     of CVS, it is not uncommon to encounter cases where you need
> |     something within your repository to be manipulated directly (for
> |     example, files which have been removed via "cvs remove", but
> |     which should be purged from the Attic, as well). While
> |     SourceForge.net does not provide direct access for developers to
> |     modify their own repository contents via a shell, the
> |     SourceForge.net team is happy to perform actions of this nature
> |     on your behalf.
> `----
>=20
> So I guess you have to contact the SourceForge staff and ask them to
> chmod +x the RCS files..
>=20
>   Lute.
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

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

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] admin/mk{doc,texi} and multiple Octave versions.

[Lute K. <Lut...@cw...>]

David Bateman <Dav...@mo...> writes:

> So unless someone has RCS access on sourceforge, the old solution I
> see is to rename these files.

I took a quick look at the SourceForge docs.  The section:

  http://sourceforge.net/docman/display_doc.php?docid=768&group_id=1#cleanup

says:

,----
|   CVS Repository Clean-Up
| 
|     Through the course of learning to use CVS, and in long-term use
|     of CVS, it is not uncommon to encounter cases where you need
|     something within your repository to be manipulated directly (for
|     example, files which have been removed via "cvs remove", but
|     which should be purged from the Attic, as well). While
|     SourceForge.net does not provide direct access for developers to
|     modify their own repository contents via a shell, the
|     SourceForge.net team is happy to perform actions of this nature
|     on your behalf.
`----

So I guess you have to contact the SourceForge staff and ask them to
chmod +x the RCS files..

  Lute.

Re: [OctDev] admin/mk{doc,texi} and multiple Octave versions.

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

Hi Etienne,

This is exactly the procedure I tried. I did it again just to prove that this
doesn't work, and got the message

cvs server: re-adding file mkdoc (in place of dead revision 1.5)
cvs server: re-adding file mktexi (in place of dead revision 1.5)
cvs server: use 'cvs commit' to add these files permanently

What happened was the file was sent to the Attic directory in the RCS and
revived when the file was re-added, with the OLD permissions. I read in
the manual for cvs that "cvs commit -f" would submit permission changes
but this didn't work either.

So unless someone has RCS access on sourceforge, the old solution I see 
is to rename these files. What a major pain!!!!

D.


According to et...@is... <et...@is...> (on 11/06/03):
> 
>   If you don't mind losing the file's history in CVS, you may do (after
> checking whether these commands are ok)
> 
>   # Hide and remove from repository
>   mv <file> <file>.hidden
>   cvs remove <file>
>   cvs commit <file>
> 
>   # Restore with good perm
>   mv <file>.hidden file
>   chmod <mode> <file>
> 
>   # Put in repository
>   cvs add <file>
>   cvs commit <file>
> 
>   I don't remember if it is possible to do much better w/out accessing the
> repository (I don't have my CVS doc with me).
> 
>   Hth,
> 
>   Etienne
> 
> > According to Lute Kamstra <Lut...@cw...> (on 11/06/03):
> >>
> >> Yes, if you accidentally add a file before making it executable, you
> >> must go into the repository and manually chmod +x the RCS file.
> >
> > Ok, now who has the rights to do this? If not the only other option I see
> > is to change the name of these scripts and use the new names elsewhere in
> > the make process....
> >
> > D.
> >
> > --
> > David Bateman                                Dav...@mo...
> > Motorola CRM                                 +33 1 69 35 48 04 (Ph)
> > Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
> > 91193 Gif-Sur-Yvette FRANCE
> >
> > The information contained in this communication has been classified as:
> >
> > [x] General Business Information
> > [ ] Motorola Internal Use Only
> > [ ] Motorola Confidential Proprietary
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?   SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Octave-dev mailing list
> > Oct...@li...
> > https://lists.sourceforge.net/lists/listinfo/octave-dev
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

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

Re: [OctDev] admin/mk{doc,texi} and multiple Octave versions.

[<pki...@us...>]

On 6 Nov 2003 at 15:05, Lute Kamstra wrote:

> Dear octave-forge hackers,
> 
> I just tried to get CVS HEAD from octave forge installed in
> conjunctions with Octave's CVS HEAD.  I encountered two minor
> problems:
> 
> 1. admin/mk{doc,texi} do not have their execute bit set.  I had to do
>    this by hand to convince the Makefiles to build the docs.
> 
> 2. I have several versions of Octave in my path.  configure picks the
>    first one it encounters, which was not the right one.  I convinced
>    the configure script to pick the right one with:
> 
>      ./configure OCTAVE=/the/right/octave
> 
>    Maybe this var should be mentioned in INSTALL?

I believe you will also need to set MKOCTFILE=/the/right/mkoctfile

Also, I found the CVS was unable to build because Makeconf is not
being updated correctly.  I will post this change shortly.

Paul Kienzle
pki...@us...

Re: [OctDev] admin/mk{doc,texi} and multiple Octave versions.

[<et...@is...>]

  If you don't mind losing the file's history in CVS, you may do (after
checking whether these commands are ok)

  # Hide and remove from repository
  mv <file> <file>.hidden
  cvs remove <file>
  cvs commit <file>

  # Restore with good perm
  mv <file>.hidden file
  chmod <mode> <file>

  # Put in repository
  cvs add <file>
  cvs commit <file>

  I don't remember if it is possible to do much better w/out accessing the
repository (I don't have my CVS doc with me).

  Hth,

  Etienne

> According to Lute Kamstra <Lut...@cw...> (on 11/06/03):
>>
>> Yes, if you accidentally add a file before making it executable, you
>> must go into the repository and manually chmod +x the RCS file.
>
> Ok, now who has the rights to do this? If not the only other option I see
> is to change the name of these scripts and use the new names elsewhere in
> the make process....
>
> D.
>
> --
> David Bateman                                Dav...@mo...
> Motorola CRM                                 +33 1 69 35 48 04 (Ph)
> Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
> 91193 Gif-Sur-Yvette FRANCE
>
> The information contained in this communication has been classified as:
>
> [x] General Business Information
> [ ] Motorola Internal Use Only
> [ ] Motorola Confidential Proprietary
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Re: [OctDev] admin/mk{doc,texi} and multiple Octave versions.

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

According to Lute Kamstra <Lut...@cw...> (on 11/06/03):
> 
> Yes, if you accidentally add a file before making it executable, you
> must go into the repository and manually chmod +x the RCS file.

Ok, now who has the rights to do this? If not the only other option I see
is to change the name of these scripts and use the new names elsewhere in
the make process....

D.

-- 
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

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

Re: [OctDev] admin/mk{doc,texi} and multiple Octave versions.

[Lute K. <Lut...@cw...>]

David Bateman <Dav...@mo...> writes:

> According to Lute Kamstra <Lut...@cw...> (on 11/06/03):
>
>> I just tried to get CVS HEAD from octave forge installed in
>> conjunctions with Octave's CVS HEAD.  I encountered two minor
>> problems:
>> 
>> 1. admin/mk{doc,texi} do not have their execute bit set.  I had to do
>>    this by hand to convince the Makefiles to build the docs.
>
> Sorry, my fault... But I'm damned if I see how I can add this flag
> to the file in the CVS. I tried adding a single space to the files
> and adding the execute flag, but only the space was
> added. Arrgggghhhh...

Normally, to force a commit, touch would be enough.

> How to do this??? I've even tried removing the files and re-adding
> them.  But they get revived from the Attic with the old permissions.
> I think the only way is to do the chmod in the RCS tree, but I don't
> have access to this. Does anyone have this type of access to
> sourceforge???

Yes, if you accidentally add a file before making it executable, you
must go into the repository and manually chmod +x the RCS file.

>> 2. I have several versions of Octave in my path.  configure picks the
>>    first one it encounters, which was not the right one.  I convinced
>>    the configure script to pick the right one with:
>> 
>>      ./configure OCTAVE=/the/right/octave
>> 
>>    Maybe this var should be mentioned in INSTALL?
>
>
> ./configure --help
>
> I always run this to figure the correct install options for me
> everytime I install a new package.

Yup, that's what I do as well.  The help text doesn't mention the
OCTAVE variable (nor the MKOCTFILE variable, by the way).

  Lute.

Re: [OctDev] admin/mk{doc,texi} and multiple Octave versions.

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

According to Lute Kamstra <Lut...@cw...> (on 11/06/03):
> Dear octave-forge hackers,
> 
> I just tried to get CVS HEAD from octave forge installed in
> conjunctions with Octave's CVS HEAD.  I encountered two minor
> problems:
> 
> 1. admin/mk{doc,texi} do not have their execute bit set.  I had to do
>    this by hand to convince the Makefiles to build the docs.

Sorry, my fault... But I'm damned if I see how I can add this flag to 
the file in the CVS. I tried adding a single space to the files and
adding the execute flag, but only the space was added. Arrgggghhhh...
How to do this??? I've even tried removing the files and re-adding them.
But they get revived from the Attic with the old permissions.  I think 
the only way is to do the chmod in the RCS tree, but I don't have access 
to this. Does anyone have this type of access to sourceforge???

> 
> 2. I have several versions of Octave in my path.  configure picks the
>    first one it encounters, which was not the right one.  I convinced
>    the configure script to pick the right one with:
> 
>      ./configure OCTAVE=/the/right/octave
> 
>    Maybe this var should be mentioned in INSTALL?


./configure --help

I always run this to figure the correct install options for me everytime I
install a new package.

D.

-- 
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

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

[OctDev] admin/mk{doc,texi} and multiple Octave versions.

[Lute K. <Lut...@cw...>]

Dear octave-forge hackers,

I just tried to get CVS HEAD from octave forge installed in
conjunctions with Octave's CVS HEAD.  I encountered two minor
problems:

1. admin/mk{doc,texi} do not have their execute bit set.  I had to do
   this by hand to convince the Makefiles to build the docs.

2. I have several versions of Octave in my path.  configure picks the
   first one it encounters, which was not the right one.  I convinced
   the configure script to pick the right one with:

     ./configure OCTAVE=/the/right/octave

   Maybe this var should be mentioned in INSTALL?


  Lute.


PS. Is this the right place for bug reports?

[OctDev] dmodce

[Pinchak <ax...@po...>]

Hello,
    I am currently working on a simulation model which could use the
capabilities provided by the equavilent of Matlab's dmodce.  I noticed
on the octave-forge website that the communications tool box will
contain this block, but that it is currently unimplemented.  I am
willing to help code this function, but I don't want to encroach on any
developers who may be working on this already.

Stanley Pinchak

Re: [OctDev] Re: Octave-Forge build problems with latest Octave CVS

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

According to pki...@us... <pki...@us...> (on 09/15/03):
> Thanks for doing this.
> 
> I was planning something considerably simpler, which is to set
> the matlab compatible values in the functions that need them
> and not bother restoring them later.  Newer versions of Octave
> won't care because the symbols don't have magic names, and
> older versions will work okay since for the most part these
> variables don't affect semantics and just serve to annoy.  
> prefer_zero_one_indexing and prefer_column_vectors are
> exceptions in that changing them will change the results
> of the calculation.  For those my preference is to assume 
> compatible values.
> 
> Is that too brutal?

I really don't know what is best. My feeling was that at this point it is
better to have the minimum distrubance to the functioning of the code for
versions prior to 2.1.50, and let 2.1.51 and later work properly. The 
downside of what I did is that it introduces a lot of extra "try .. catch"
code. In a yea or so, I imagine that stuff like do_fortran_indexing will
be pretty much forgotten and we can cut out the code completely.

I'm not sure your idea is good at this point, since it forces the 2.1.51
defaults for people using older versions of octave. However, in a year
or so, I imagine it will be the preferred solution.

Regards
David


> 
> Paul Kienzle
> pki...@us...
> 
> On 12 Sep 2003 at 16:44, David Bateman wrote:
> 
> > Seeing as no one responded to this message and that I wanted 
> > OctaveForge to work with the latest CVS I've gone ahead and
> > committed the follwoing modifications:
> > 
> > * Protected the in-built variables that are used in 2.1.50 and
> >   earlier that no longer exist in the CVS and included as appropriate
> >   the corresponding warn variable in the dot-m files. An example is
> > 
> >     dfi = do_fortran_indexing;
> >     unwind_protect
> >       do_fortran_indexing = 1;
> >     unwind_protect_cleanup
> >       do_fortran_indexing = dfi;
> >     end_unwind_protect
> > 
> >   is replaced with 
> > 
> >     try dfi = do_fortran_indexing;
> >     catch dfi = 0; end
> >     try wfi = warn_fortran_indexing;
> >     catch wfi = 0; end
> >     unwind_protect
> >       do_fortran_indexing = 1;
> >       warn_fortran_indexing = 0;
> >     unwind_protect_cleanup
> >       do_fortran_indexing = dfi;
> >       warn_fortrabn_indexing = wfi;
> >     end_unwind_protect
> > 
> >   This was done for the following variables if I found them in the entire
> >   OctaveForge sources 
> > 
> >        Old Variable                        New Variable
> >       --------------                      --------------
> >     empty_list_elements_ok		warn_empty_list_elements
> >     ok_to_lose_imaginary_part		warn_imag_to_real
> >     treat_neg_dim_as_zero		warn_neg_dim_as_zero
> >     implicit_num_to_str_ok		warn_num_to_str
> >     resize_on_range_error		warn_resize_on_range_error
> >     implicit_str_to_num_ok		warn_str_to_num
> >     do_fortran_indexing			warn_fortran_indexing
> >     prefer_zero_one_indexing		<none>
> >     prefer_column_vectors		<none>
> >     propagate_empty_matrices		<none>
> > 
> >   If I missing a variable tell me. The changes I made should maintain 
> >   backwards compatibility
> > 
> > * Added to configure.base and Makeconf.base the variables
> > 
> > 	HAVE_DO_FORTRAN_INDEXING
> > 	HAVE_PROPAGATE_EMPTY_MATRICES
> > 	HAVE_OK_TO_LOSE_IMAGINARY_PART
> > 
> >   to test for the Vdo_fortran_indexing, Vpropagate_empty_matrices and
> >   Vok_to_lose_imaginary_part variables. These are for use in the C++ code
> >   that requires them (I think this is only in the comms toolbox at the moment).
> >   Although OctaveForge doesn't contain code using Vok_to_lose_imaginary_part
> >   yet, I intend to submit some code soon with this and so its presence helps
> >   me.
> > 
> > * Got rid of the references to resize_fill_value() method instatiated from
> >   Array.h that is no longer in the octave CVS. Again this appears to only be
> >   in the comms toolbox
> > 
> > * Changes the name of the matrix_identity function in optim/lp.cc to
> >   lp_matrix_identity function so as not to clash with the one in utils.h
> >   in the current octave CVS. I couldn't use the one in the octave CVS 
> >   since I didn't want to break backwards compatiablity.
> > 
> > I think that is all of the changes I had to make
> > 
> > Regards
> > David
> > 
> > 
> > According to David Bateman <Dav...@mo...> (on 09/09/03):
> > > Dear All,
> > > 
> > > There are a number of problems with Octave-Forge for the latest CVS.
> > > Firstly the 
> > > 
> > >   static T resize_fill_value (void) { return T (); }
> > > 
> > > has been commented out of Array.h, so if you use this template in a
> > > type this no longer works. I think I'm the only who supplied code that
> > > did this, so this one isn't too big a problem.
> > > 
> > > The major problem is that the variables do_fortran_indexing,
> > > propagate_empty_matrices etc no longer exist. Removing them and using
> > > the new options like warn_fortran_indexing will break all backwards
> > > compatiablity within Octave-Forge. No doing it and the functions
> > > will fail when a new release is made.
> > > 
> > > A solution like
> > > 
> > > have_fortran_indexing = 1;
> > > try
> > >   tmp = do_fortran_indexing;
> > > catch
> > >   have_fortran_indexing = 0;
> > > end
> > > 
> > > is possible, but looking at the number of places it'll need doing (including
> > > in some C++ code) this is an ugly solution.
> > > 
> > > Does anyone have any ideas?
> > > 
> > > Regards
> > > David
> > > 
> > > 
> > > -- 
> > > David Bateman                                Dav...@mo...
> > > Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
> > > Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
> > > 91193 Gif-Sur-Yvette FRANCE
> > > 
> > > The information contained in this communication has been classified as: 
> > > 
> > > [x] General Business Information 
> > > [ ] Motorola Internal Use Only 
> > > [ ] Motorola Confidential Proprietary
> > 
> > -- 
> > David Bateman                                Dav...@mo...
> > Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
> > Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
> > 91193 Gif-Sur-Yvette FRANCE
> > 
> > The information contained in this communication has been classified as: 
> > 
> > [x] General Business Information 
> > [ ] Motorola Internal Use Only 
> > [ ] Motorola Confidential Proprietary
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Octave-dev mailing list
> > Oct...@li...
> > https://lists.sourceforge.net/lists/listinfo/octave-dev
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

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

Re: [OctDev] Re: Octave-Forge build problems with latest Octave CVS

[<pki...@us...>]

Thanks for doing this.

I was planning something considerably simpler, which is to set
the matlab compatible values in the functions that need them
and not bother restoring them later.  Newer versions of Octave
won't care because the symbols don't have magic names, and
older versions will work okay since for the most part these
variables don't affect semantics and just serve to annoy.  
prefer_zero_one_indexing and prefer_column_vectors are
exceptions in that changing them will change the results
of the calculation.  For those my preference is to assume 
compatible values.

Is that too brutal?

Paul Kienzle
pki...@us...

On 12 Sep 2003 at 16:44, David Bateman wrote:

> Seeing as no one responded to this message and that I wanted 
> OctaveForge to work with the latest CVS I've gone ahead and
> committed the follwoing modifications:
> 
> * Protected the in-built variables that are used in 2.1.50 and
>   earlier that no longer exist in the CVS and included as appropriate
>   the corresponding warn variable in the dot-m files. An example is
> 
>     dfi = do_fortran_indexing;
>     unwind_protect
>       do_fortran_indexing = 1;
>     unwind_protect_cleanup
>       do_fortran_indexing = dfi;
>     end_unwind_protect
> 
>   is replaced with 
> 
>     try dfi = do_fortran_indexing;
>     catch dfi = 0; end
>     try wfi = warn_fortran_indexing;
>     catch wfi = 0; end
>     unwind_protect
>       do_fortran_indexing = 1;
>       warn_fortran_indexing = 0;
>     unwind_protect_cleanup
>       do_fortran_indexing = dfi;
>       warn_fortrabn_indexing = wfi;
>     end_unwind_protect
> 
>   This was done for the following variables if I found them in the entire
>   OctaveForge sources 
> 
>        Old Variable                        New Variable
>       --------------                      --------------
>     empty_list_elements_ok		warn_empty_list_elements
>     ok_to_lose_imaginary_part		warn_imag_to_real
>     treat_neg_dim_as_zero		warn_neg_dim_as_zero
>     implicit_num_to_str_ok		warn_num_to_str
>     resize_on_range_error		warn_resize_on_range_error
>     implicit_str_to_num_ok		warn_str_to_num
>     do_fortran_indexing			warn_fortran_indexing
>     prefer_zero_one_indexing		<none>
>     prefer_column_vectors		<none>
>     propagate_empty_matrices		<none>
> 
>   If I missing a variable tell me. The changes I made should maintain 
>   backwards compatibility
> 
> * Added to configure.base and Makeconf.base the variables
> 
> 	HAVE_DO_FORTRAN_INDEXING
> 	HAVE_PROPAGATE_EMPTY_MATRICES
> 	HAVE_OK_TO_LOSE_IMAGINARY_PART
> 
>   to test for the Vdo_fortran_indexing, Vpropagate_empty_matrices and
>   Vok_to_lose_imaginary_part variables. These are for use in the C++ code
>   that requires them (I think this is only in the comms toolbox at the moment).
>   Although OctaveForge doesn't contain code using Vok_to_lose_imaginary_part
>   yet, I intend to submit some code soon with this and so its presence helps
>   me.
> 
> * Got rid of the references to resize_fill_value() method instatiated from
>   Array.h that is no longer in the octave CVS. Again this appears to only be
>   in the comms toolbox
> 
> * Changes the name of the matrix_identity function in optim/lp.cc to
>   lp_matrix_identity function so as not to clash with the one in utils.h
>   in the current octave CVS. I couldn't use the one in the octave CVS 
>   since I didn't want to break backwards compatiablity.
> 
> I think that is all of the changes I had to make
> 
> Regards
> David
> 
> 
> According to David Bateman <Dav...@mo...> (on 09/09/03):
> > Dear All,
> > 
> > There are a number of problems with Octave-Forge for the latest CVS.
> > Firstly the 
> > 
> >   static T resize_fill_value (void) { return T (); }
> > 
> > has been commented out of Array.h, so if you use this template in a
> > type this no longer works. I think I'm the only who supplied code that
> > did this, so this one isn't too big a problem.
> > 
> > The major problem is that the variables do_fortran_indexing,
> > propagate_empty_matrices etc no longer exist. Removing them and using
> > the new options like warn_fortran_indexing will break all backwards
> > compatiablity within Octave-Forge. No doing it and the functions
> > will fail when a new release is made.
> > 
> > A solution like
> > 
> > have_fortran_indexing = 1;
> > try
> >   tmp = do_fortran_indexing;
> > catch
> >   have_fortran_indexing = 0;
> > end
> > 
> > is possible, but looking at the number of places it'll need doing (including
> > in some C++ code) this is an ugly solution.
> > 
> > Does anyone have any ideas?
> > 
> > Regards
> > David
> > 
> > 
> > -- 
> > David Bateman                                Dav...@mo...
> > Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
> > Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
> > 91193 Gif-Sur-Yvette FRANCE
> > 
> > The information contained in this communication has been classified as: 
> > 
> > [x] General Business Information 
> > [ ] Motorola Internal Use Only 
> > [ ] Motorola Confidential Proprietary
> 
> -- 
> David Bateman                                Dav...@mo...
> Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
> Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
> 91193 Gif-Sur-Yvette FRANCE
> 
> The information contained in this communication has been classified as: 
> 
> [x] General Business Information 
> [ ] Motorola Internal Use Only 
> [ ] Motorola Confidential Proprietary
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

[OctDev] Re: Octave-Forge build problems with latest Octave CVS

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

Seeing as no one responded to this message and that I wanted 
OctaveForge to work with the latest CVS I've gone ahead and
committed the follwoing modifications:

* Protected the in-built variables that are used in 2.1.50 and
  earlier that no longer exist in the CVS and included as appropriate
  the corresponding warn variable in the dot-m files. An example is

    dfi = do_fortran_indexing;
    unwind_protect
      do_fortran_indexing = 1;
    unwind_protect_cleanup
      do_fortran_indexing = dfi;
    end_unwind_protect

  is replaced with 

    try dfi = do_fortran_indexing;
    catch dfi = 0; end
    try wfi = warn_fortran_indexing;
    catch wfi = 0; end
    unwind_protect
      do_fortran_indexing = 1;
      warn_fortran_indexing = 0;
    unwind_protect_cleanup
      do_fortran_indexing = dfi;
      warn_fortrabn_indexing = wfi;
    end_unwind_protect

  This was done for the following variables if I found them in the entire
  OctaveForge sources 

       Old Variable                        New Variable
      --------------                      --------------
    empty_list_elements_ok		warn_empty_list_elements
    ok_to_lose_imaginary_part		warn_imag_to_real
    treat_neg_dim_as_zero		warn_neg_dim_as_zero
    implicit_num_to_str_ok		warn_num_to_str
    resize_on_range_error		warn_resize_on_range_error
    implicit_str_to_num_ok		warn_str_to_num
    do_fortran_indexing			warn_fortran_indexing
    prefer_zero_one_indexing		<none>
    prefer_column_vectors		<none>
    propagate_empty_matrices		<none>

  If I missing a variable tell me. The changes I made should maintain 
  backwards compatibility

* Added to configure.base and Makeconf.base the variables

	HAVE_DO_FORTRAN_INDEXING
	HAVE_PROPAGATE_EMPTY_MATRICES
	HAVE_OK_TO_LOSE_IMAGINARY_PART

  to test for the Vdo_fortran_indexing, Vpropagate_empty_matrices and
  Vok_to_lose_imaginary_part variables. These are for use in the C++ code
  that requires them (I think this is only in the comms toolbox at the moment).
  Although OctaveForge doesn't contain code using Vok_to_lose_imaginary_part
  yet, I intend to submit some code soon with this and so its presence helps
  me.

* Got rid of the references to resize_fill_value() method instatiated from
  Array.h that is no longer in the octave CVS. Again this appears to only be
  in the comms toolbox

* Changes the name of the matrix_identity function in optim/lp.cc to
  lp_matrix_identity function so as not to clash with the one in utils.h
  in the current octave CVS. I couldn't use the one in the octave CVS 
  since I didn't want to break backwards compatiablity.

I think that is all of the changes I had to make

Regards
David


According to David Bateman <Dav...@mo...> (on 09/09/03):
> Dear All,
> 
> There are a number of problems with Octave-Forge for the latest CVS.
> Firstly the 
> 
>   static T resize_fill_value (void) { return T (); }
> 
> has been commented out of Array.h, so if you use this template in a
> type this no longer works. I think I'm the only who supplied code that
> did this, so this one isn't too big a problem.
> 
> The major problem is that the variables do_fortran_indexing,
> propagate_empty_matrices etc no longer exist. Removing them and using
> the new options like warn_fortran_indexing will break all backwards
> compatiablity within Octave-Forge. No doing it and the functions
> will fail when a new release is made.
> 
> A solution like
> 
> have_fortran_indexing = 1;
> try
>   tmp = do_fortran_indexing;
> catch
>   have_fortran_indexing = 0;
> end
> 
> is possible, but looking at the number of places it'll need doing (including
> in some C++ code) this is an ugly solution.
> 
> Does anyone have any ideas?
> 
> Regards
> David
> 
> 
> -- 
> David Bateman                                Dav...@mo...
> Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
> Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
> 91193 Gif-Sur-Yvette FRANCE
> 
> The information contained in this communication has been classified as: 
> 
> [x] General Business Information 
> [ ] Motorola Internal Use Only 
> [ ] Motorola Confidential Proprietary

-- 
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

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

[OctDev] Patch for fsolve.cc

[Thomas W. <th...@ma...>]

Hi, 

the following patch applied to fsolve.cc (as distributed in
octave-forge-2003.06.02.tar.gz) makes it possible to compile it with
gcc-3.3 (tested on x86 under Debian GNU/Linx testing).


*** fsolve.cc	2003-09-09 12:02:11.000000000 +0200
--- fsolve-patched.cc	2003-09-09 12:04:32.000000000 +0200
*************** are passed directly to @var{fcn}.\n\
*** 230,236 ****
  }
  
  typedef void (NLEqn_options::*d_set_opt_mf) (double);
! typedef double (NLEqn_options::*d_get_opt_mf) (void);
  
  #define MAX_TOKENS 1
  
--- 230,236 ----
  }
  
  typedef void (NLEqn_options::*d_set_opt_mf) (double);
! typedef double (NLEqn_options::*d_get_opt_mf) (void) const;
  
  #define MAX_TOKENS 1


Additional note:
My personal C++-knowledge tends to zero, so if there are problems with
this patch, I won't be able to help. The change (it's only one word) was
done by someone with some experience in C++. He gave me permission to
submit this patch. 

I have tested the compiled oct-file, it seems to give correct results
(read: the same as fsolve-function distributed with Octave).

Regards,
Thomas

[OctDev] Octave-Forge build problems with latest Octave CVS

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

Dear All,

There are a number of problems with Octave-Forge for the latest CVS.
Firstly the 

  static T resize_fill_value (void) { return T (); }

has been commented out of Array.h, so if you use this template in a
type this no longer works. I think I'm the only who supplied code that
did this, so this one isn't too big a problem.

The major problem is that the variables do_fortran_indexing,
propagate_empty_matrices etc no longer exist. Removing them and using
the new options like warn_fortran_indexing will break all backwards
compatiablity within Octave-Forge. No doing it and the functions
will fail when a new release is made.

A solution like

have_fortran_indexing = 1;
try
  tmp = do_fortran_indexing;
catch
  have_fortran_indexing = 0;
end

is possible, but looking at the number of places it'll need doing (including
in some C++ code) this is an ugly solution.

Does anyone have any ideas?

Regards
David


-- 
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

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

Re: [OctDev] Providing alternative functions

[Per P. <per...@ma...>]

Just disregard my previous mail. Everything works fine, except the 
pilot...

$(ALTMPATH) and $(GRDESTDIR) and were indeed empty strings, and rightly 
so.

for i=1:100
  printf("I will henceforth remember to rebuild configure after updating 
from CVS\n");
endfor

/Per


On Thursday, September 4, 2003, at 10:27 PM, Per Persson wrote:

> Hi,
> I'm having a small (possibly two) problem(s) with target 
> grace_octave_path.m in graceplot/Makefile on OS X.
>
> grace_octave_path.m: grace_octave_path.m.in
>         cat grace_octave_path.m.in | sed -e 
> "s:@ALTMPATH@:$(ALTMPATH)/$(GRDESTDIR):" > grace_octave_path.m
>
> In the file grace_octave_path.m @ALTMPATH@ comes out as "/" as if 
> $(ALTMPATH) and $(GRDESTDIR) would evaluate to an empty string in the 
> sed command.
>

Re: [OctDev] Providing alternative functions

[Per P. <per...@ma...>]

Hi,
I'm having a small (possibly two) problem(s) with target 
grace_octave_path.m in graceplot/Makefile on OS X.

grace_octave_path.m: grace_octave_path.m.in
         cat grace_octave_path.m.in | sed -e 
"s:@ALTMPATH@:$(ALTMPATH)/$(GRDESTDIR):" > grace_octave_path.m

In the file grace_octave_path.m @ALTMPATH@ comes out as "/" as if 
$(ALTMPATH) and $(GRDESTDIR) would evaluate to an empty string in the 
sed command.

A little fiddling gives the following:
1) % cat extra/graceplot/grace_octave_path.m.in | sed -e 
"s:@ALTMPATH@:$(ALTMPATH)/$(GRDESTDIR):"
Illegal variable name.
2) % cat extra/graceplot/grace_octave_path.m.in | sed -e 
"s:@ALTMPATH@:$ALTMPATH/$GRDESTDIR:"
Bad : modifier in $ (").
3) % cat extra/graceplot/grace_octave_path.m.in | sed -e 
"s.@ALTMPATH@.$ALTMPATH/$GRDESTDIR."
(Works as intended)

So, it seems that
(1) sed dissaproves of $(VARNAME)
(2) sed dissaproves : as delimiter
(since ':' was the path delimiter in OS 4 through 9, OS X sometimes has 
funny interpretations of : and / when used together)
(3) works fine on OS X, don't know if it is acceptable elsewhere.

FWIW, sed -e "s/@ALTMPATH@/$ALTMPATH\/$GRDESTDIR/" also works.

My knowledge of sed et al. is limited, so this is about as much info as 
I can provide on the problem.

/Per


On Monday, August 25, 2003, at 05:41 PM, Teemu Ikonen wrote:
>
> It's up to the package to provide scripts to shuffle the loadpath so 
> that
> the functions are actually visible, the graceplot package contains an
> example on how to do this.
>
> Any comments or suggestions are welcome.
>
> Teemu
------------
Per Persson
Blekinge Institute of Technology
Dept. of Signal Processing and Telecommunications

www:   http://www.its.bth.se/staff/pee
e-mail: per...@bt...

[OctDev] compile erorrs with current octave-forge

[Kai H. <kai...@gm...>]

Hi,

I've got the following errors during a octave-forge compilation.
I made fresh octave-forge checkout today. I have octave 2.1.50 (cvs, 
28.08.03)

octave --version
GNU Octave, version 2.1.50 (i686-pc-linux-gnu).

gcc --version
gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Here are the errors

1.) main/comm:

Compiling galois.o
g++ -c -fPIC -I/usr/local/include/octave-2.1.50 
-I/usr/local/include/octave-2.1.50/octave -I/usr/local/include -mieee-fp 
-g -O2 -Wall -DHAVE_OCTAVE_21 -DGALOIS_DISP_PRIVATES galois.cc -o galois.o
In file included from galois.cc:31:
galois.h:84: error: 'class galois' has no member named 'resize_fill_value'
galois.h:81: error: 'class galois' has no member named 'resize_fill_value'
make[2]: *** [galois.o] Fehler 1

This is a bit suprising since galois.[c,h] are 5 month old. The class 
galois is derived from MArray2 which has resize_fill_value. I have no 
idea whats going on here.

2.) main/optim:

make[2]: Entering directory `/home/kai/cvs-octrep/octave-forge/main/optim'
mkoctfile -DHAVE_OCTAVE_21 -v lp.cc
g++ -c -fPIC -I/usr/local/include/octave-2.1.50 
-I/usr/local/include/octave-2.1.50/octave -I/usr/local/include -mieee-fp 
-g -O2 -Wall -DHAVE_OCTAVE_21 lp.cc -o lp.o
lp.cc: In function `Matrix identity_matrix(int, int)':
lp.cc:31: error: `Matrix identity_matrix(int, int)' was declared 
`extern' and
   later `static'
/usr/local/include/octave-2.1.50/octave/utils.h:84: error: previous 
declaration
   of `Matrix identity_matrix(int, int)'
make[2]: *** [lp.oct] Fehler 1

It seems identity_matrix is defined 2 times. Could anyone look at this too.


Bye Kai

Re: [OctDev] Providing alternative functions

[<pki...@us...>]

On 25 Aug 2003 at 18:41, Teemu Ikonen wrote:

> The modifications I made to the installation scripts are general, so that
> any m-files in directory extra/<package>/alternatives are installed to 
> /usr/share/octave/<version>/site/octave-forge-alternatives/m/<package>
> and oct-files to
> /usr/lib/octave/<version>/site/octave-forge-alternatives/oct/<arch>/<package> 

So for example, Alois could put a select few of his NaN toolbox 
functions into alternatives (those that treat NaN as NA) and the NaN
toolbox could then be installed by default?  Sounds great!

I'm surprised, though, that all the site package tree is not on the 
default load path.

- Paul

Re: [OctDev] Providing alternative functions

[Rafael L. <ra...@de...>]

* Teemu Ikonen <tpi...@pc...> [2003-08-25 18:41]:

> I've committed my grace plotting code to extra/graceplot and modified the
> Makefiles and configure scripts to install the overlapping m-files to

Great, it works fine for me.

What about creating a wrapper like this:

    function grace_command (str)
        __grcmd__ (str);
        __grcmd__ ("redraw");
    endfunction
    
At any rate, it is nice to be able to control nearly all aspects of the
graph directly from Octave scripts.

-- 
Rafael

Re: [OctDev] Providing alternative functions

[Teemu I. <tpi...@pc...>]

On 08/08/03 18:50, Teemu Ikonen wrote:
> Maybe a new
> directory hierachy like main/alternatives is needed? Directories which are
> found there could then be installed in something like
> $prefix/share/octave-forge-alternatives 

I've committed my grace plotting code to extra/graceplot and modified the
Makefiles and configure scripts to install the overlapping m-files to

/usr/share/octave/2.1.50/site/octave-forge-alternatives/m/graceplot

The modifications I made to the installation scripts are general, so that
any m-files in directory extra/<package>/alternatives are installed to 
/usr/share/octave/<version>/site/octave-forge-alternatives/m/<package>
and oct-files to
/usr/lib/octave/<version>/site/octave-forge-alternatives/oct/<arch>/<package> 

In a local installation the alternative files go to $path-alternatives/m
(and $path-alternatives/oct) where $path is provided by --with-path
parameter to configure.

It's up to the package to provide scripts to shuffle the loadpath so that
the functions are actually visible, the graceplot package contains an
example on how to do this.

Any comments or suggestions are welcome.

Teemu

[OctDev] Providing alternative functions

[Teemu I. <tpi...@pc...>]

Hi everyone,

I've made a set of functions which replace the standard gnuplot based 2d
plotting commands by similar functions using Grace
(http://plasma-gate.weizmann.ac.il/Grace/). They're available in
http://www.physics.helsinki.fi/~tpikonen/octave/grplot-2003.08.08.tgz

I'd like to contribute these to octave-forge, but as the functions have
same names as their gnuplot counterparts in standard Octave, normal
octave-forge installation would cause these functions to override the
defaults. Of course, this is probably not what most people installing
octave-forge would want.

The octave-plplot package (available in Debian, at least) avoids this
problem by installing it's m-files to a location which is not in the default
LOADPATH (/usr/share/plplot_octave to be exact) and then modifying the
LOADPATH to include or not to include this path via a script
(toggle_plplot_use).

I've implemented (i.e. copied) a similar thing in my Grace package, but I'm
not sure where should I upload the files in octave-forge. Maybe a new
directory hierachy like main/alternatives is needed? Directories which are
found there could then be installed in something like
$prefix/share/octave-forge-alternatives 

Comments?

Teemu

Re: [OctDev] Makefile stalls

[WJ A. <oc...@wy...>]

Note for others:

It turns out my automake tools and friends were outdated. It took
me a while to figure this out but it works again. A bit of a pain.

thanks,

Willem



On 2003.07.30 00:44 Paul Kienzle wrote:
> WJ Atsma wrote:
>=20
>> I just synchronised with the cvs and make stalls at the start:
>>=20
>>   # make
>>   Makeconf:49: *** missing separator.  Stop.
>>=20
> I don't know if it will help, but you need to
> do the following before make:
>=20
>    # ./autogen.sh
>    # ./configure
>=20
> Paul Kienzle
> pki...@us...
>=20
> PS, please reply to the list as I will be away
> for a bit.
>=20
>=20