octave-dev — GNU Octave developers' list

Re: [OctDev] change to subversion

[Stefan v. d. W. <st...@su...>]

On Sun, Apr 02, 2006 at 11:24:15AM +0200, Stefan van der Walt wrote:
> Is anyone else interested in moving over to subversion?  Sourceforge
> provides detailed documentation at
>=20
> http://sourceforge.net/docs/E09/

Since there were no objections, would one of the admins be willing to
do this?  These are the steps required:

Import from SF.net CVS Repository:

   1. Backup your repository.
   2. Login to the SourceForge.net website.
   3. Go to the project summary page (https://www.sf.net/projects/PROJECT=
NAME).
   4. Click on the 'Admin' link.
   5. Click on the 'Subversion' admin page link.
   6. Click on the 'migrate' link on the 'Migration Instructions' section=
 of the page.
   7. Click on the 'SourceForge.net CVS Repository' radio button.
   8. Check the 'Replace' check box in the same column, if you wish to
      replace the existing content with the new content to be added.
   9. Enter the value you want passed to the --parent-dir argument of
      the "svnadmin load" command into the 'Destination' field. For
      most users, this would be left blank.
  10. Click on the 'Submit' button.
  11. The migration will be finished within 24 hours. It could be
      finished in as soon as an hour or two, depending on the size of
      your CVS repository and the number of projects queued for
      migration in front of yours. Returning to the page will display
      whether it completed, failed or is still in queue.

Regards
St=E9fan

[OctDev] Compiling octave-forge 2006.03.17 with Octave 2.1.73 and g++ 4.1

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

On  2-Apr-2006, Rafael Laboissiere wrote:

| [First of all, sorry for the cross-posting.  I wish that the Octave Forge
| developers and the Debian Octave Group to be aware of the issue discussed
| below, hence the Cc:s.  Please, respect the M-F-T header and keep this
| discussion in octave-maintainers.]
| 
| I am not sure I should have reported this to octave-bug.  Anyway, in
| trying to build the Debian package for octave-forge 2006.03.17 with
| Octave 2.1.73 and g++ 4.1.0, I stumbled on several error messages like
| this:
| 
| ====================================================================
| [...]
| Processing main/sparse/...
| make[3]: Entering directory `/root/octave-forge/octave-forge-2006.03.17/main/sparse'
| mkoctfile -Doctave_idx_type=int -DHAVE_OCTAVE_21 -v -c sparse_ops.cc -ISuperLU/SRC/ -ISuperLU/CBLAS -DNDEBUG -DHAVE_ND_ARRAYS -DTYPEID_HAS_CLASS -DCLASS_HAS_LOAD_SAVE -DHAVE_OCTAVE_CONCAT -DHAVE_OCTAVE_UPLUS -o sparse_ops.o
| /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.73 -I/usr/include/octave-2.1.73/octave -mieee-fp -O2 -ISuperLU/SRC/ -ISuperLU/CBLAS -Doctave_idx_type=int -DHAVE_OCTAVE_21 -DNDEBUG -DHAVE_ND_ARRAYS -DTYPEID_HAS_CLASS -DCLASS_HAS_LOAD_SAVE -DHAVE_OCTAVE_CONCAT -DHAVE_OCTAVE_UPLUS sparse_ops.cc -o sparse_ops.o
| [...]
| /usr/include/octave-2.1.73/octave/ArrayN.h: In constructor 'ArrayN<T>::ArrayN(const dim_vector&, const T&) [with T = bool]':
| /usr/include/octave-2.1.73/octave/boolNDArray.h:49:   instantiated from here
| /usr/include/octave-2.1.73/octave/ArrayN.h:66: error: no matching function for call to 'fill(const bool&)'
| /usr/lib/gcc/i486-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_algobase.h:573: note: candidates are: void std::fill(unsigned char*, unsigned char*, const unsigned char&)
| /usr/lib/gcc/i486-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_algobase.h:581: note:                 void std::fill(signed char*, signed char*, const signed char&)
| /usr/lib/gcc/i486-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_algobase.h:589: note:                 void std::fill(char*, char*, const char&)
| [...]
| ====================================================================
| 
| Compilation succeeded with the following patch to two Octave headers
| files:
| 
| ====================================================================
| --- ArrayN.h-orig	2005-05-02 13:16:12.000000000 +0200
| +++ ArrayN.h		2006-04-02 14:26:35.350510480 +0200
| @@ -63,7 +63,7 @@
|    ArrayN (const dim_vector& dv) : Array<T> (dv) { }
|  
|    ArrayN (const dim_vector& dv, const T& val)
| -    : Array<T> (dv) { fill (val); }
| +    : Array<T> (dv) { Array<T>::fill (val); }
|  
|    template <class U>
|    explicit ArrayN (const Array2<U>& a) : Array<T> (a, a.dims ()) { }
| --- DiagArray2.h-orig	2005-05-02 13:16:16.000000000 +0200
| +++ DiagArray2.h	2006-04-02 14:25:04.380340048 +0200
| @@ -125,7 +125,7 @@
|      {
|        this->dimensions = dim_vector (r, c);
|  
| -      fill (val);
| +      Array<T>::fill (val);
|      }
|  
|    DiagArray2 (const Array<T>& a) : Array<T> (a)
| ====================================================================
| 
| Are the patches above correct?  Would they be applied to CVS?

Yes, I applied these changes.

Thanks,

jwe

Re: [OctDev] Plot3-problems under Windows

[James R. P. <ant...@ya...>]

--- Patrich Rammelt wrote:

> Hi
> 
> My problem is this:
> Plot3 does not work as expected. The example from the help text (help
> plot3) does not create a single line. Instead plot(x,y,z) creates 3+N
> lines (where x, y and z are vectors with N elements each). 
> 
> More detailed description of what I see:
> One dimension on the plot is the sample-index (1..N), on the second
> dimension there is one value (1,2,3) for x,y and z and the third
> dimension shows the values of x,y and z itself. 
> There is one line connecting the values of x and one for y and one for
> z. Additionally there are N lines connecting x(i) with y(i) and z(i)
> for all i=1:N.
> 
> I tried to reinstall octave-forge and gnuplot but that did not make
> any difference.  
> OS: Windows XP,  
> Octave 2.1.72,  
> gnuplot 4.0 patchlevel 0 (Cygwin). 
> 
> Under Linux everything is just fine.
> 
> Any ideas? 
> Thanks, 
> Pat
> 

This issue probably belongs on the help list, not on the developers list.

Note that the current version of Octave on Cygwin is 2.1.73.  I don't know that
you would get different results with the newer version, but you should be aware
that you are not at the most current version.

You didn't state the versions of Octave and Gnuplot you are using under Linux,
or the distribution you are running.  This makes it much more difficult to
investigate the question of whether the issue is related to the octave software
of a particular version on any platform, or whether it is unique to the Cygwin
platform.

Generically speaking, the work-around for this issue on Cygwin (aside from
finding the issue in the code and fixing it) is to use octave to write ascii
data files in the proper format for gnuplot, and then to use gnuplot outside of
octave to make your plot.  As a quick "get me started" guide to gnuplot, I like
the "not so frequently asked questions" website (
http://t16web.lanl.gov/Kawano/gnuplot/index-e.html ).  On the other hand, if
everything is just fine on Linux, would just using Linux be an acceptable
workaround?

James R. Phillips
Cygwin Octave maintainer

Re: [OctDev] Plot3-problems under Windows

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

Patrich Rammelt wrote:

>Hi
>
>My problem is this:
>Plot3 does not work as expected. The example from the help text (help
>plot3) does not create a single line. Instead plot(x,y,z) creates 3+N
>lines (where x, y and z are vectors with N elements each). 
>
>More detailed description of what I see:
>One dimension on the plot is the sample-index (1..N), on the second
>dimension there is one value (1,2,3) for x,y and z and the third
>dimension shows the values of x,y and z itself. 
>There is one line connecting the values of x and one for y and one for
>z. Additionally there are N lines connecting x(i) with y(i) and z(i)
>for all i=1:N.
>
>I tried to reinstall octave-forge and gnuplot but that did not make
>any difference.  
>OS: Windows XP,  
>Octave 2.1.72,  
>gnuplot 4.0 patchlevel 0 (Cygwin). 
>  
>

With octave 2.9.5 I believe the code

    for i=1:columns(x)
      tmp = [x(:,i), y(:,i), z(:,i)];
      cmd =  ["__gnuplot_splot__ tmp ", fmt, ";\n"];
      eval (cmd);
    endfor

in __plt3__.m can be modified to

      sz = size(x,2);
      tmp = [([x; NaN*ones(1,sz)])(:), ([y; NaN*ones(1,sz)])(:), ([z;
NaN*ones(1,sz)])(:)];
      __gnuplot_splot__(tmp);

and this will probably help the issue. Though it doesn't do you much
good for 2.1.72..

Regards
David



>Under Linux everything is just fine.
>
>Any ideas? 
>Thanks, 
>Pat
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Octave-dev mailing list
>Oct...@li...
>https://lists.sourceforge.net/lists/listinfo/octave-dev
>
>  
>


-- 
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

[OctDev] Plot3-problems under Windows

[Patrich R. <ra...@cs...>]

Hi

My problem is this:
Plot3 does not work as expected. The example from the help text (help
plot3) does not create a single line. Instead plot(x,y,z) creates 3+N
lines (where x, y and z are vectors with N elements each). 

More detailed description of what I see:
One dimension on the plot is the sample-index (1..N), on the second
dimension there is one value (1,2,3) for x,y and z and the third
dimension shows the values of x,y and z itself. 
There is one line connecting the values of x and one for y and one for
z. Additionally there are N lines connecting x(i) with y(i) and z(i)
for all i=1:N.

I tried to reinstall octave-forge and gnuplot but that did not make
any difference.  
OS: Windows XP,  
Octave 2.1.72,  
gnuplot 4.0 patchlevel 0 (Cygwin). 

Under Linux everything is just fine.

Any ideas? 
Thanks, 
Pat

[OctDev] fir1 bug for odd orders?

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

I had a look at the long standing bug about fir1 and it seems to me that

1) The bug isn't in fir1 at all but rather it is in fir2
2) The problem is to do with the ifft method used to calculate the filter
3) If we interpolate between the ifft values we'll have the correct
coefficients
4) We can easily interpolate, by just adding zeros in the middle of the ifft

Here is a patch I created with the above in mind. I've basically done no
testing for it, but can I have some comments and if  people (Per you
posted the bug) think it is ok, I'd like to apply the patch and close
this bug...

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

[OctDev] Re: lp.cc??

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

> Feel free to purge.  It is still available on the 2.1.x branch if  
> anyone should suddenly decide to fix it.
>  

Ok, will do...

> By the way, thanks for clearing up the tracker.  I've been sending  
> people there lately since I'm not doing very well keeping my inbox  
> empty, and things on the tracker don't get lost.  Ignored for years,  
> maybe, but not lost.

I didn't really do anything. The vast majority were from one author who
hadn't mastered how to add attachments, and so there was nothing I could
do with the bug reports as is, so closed them. Basically, better to give
a person that generates 6 different patches CVS access to octave-forge
rather than deal with them personally :-).. I'm waiting for him to
recontact the octave-dev list to give him access..

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] lp.cc?

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

Feel free to purge.  It is still available on the 2.1.x branch if  
anyone should suddenly decide to fix it.

By the way, thanks for clearing up the tracker.  I've been sending  
people there lately since I'm not doing very well keeping my inbox  
empty, and things on the tracker don't get lost.  Ignored for years,  
maybe, but not lost.

- Paul

On Apr 7, 2006, at 8:51 AM, David Bateman wrote:

> There has been a bug report against lp.cc in octave-forge for 3 years.
> As octave 2.9.x now has glpk and we are stripping 2.1.x code from
> octave-forge, can we drop lp.cc and close this bug? Or is someone  
> really
> using and can justify why glpk can't be used?
>
> 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
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the live  
> webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] lp.cc?

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

There has been a bug report against lp.cc in octave-forge for 3 years.
As octave 2.9.x now has glpk and we are stripping 2.1.x code from
octave-forge, can we drop lp.cc and close this bug? Or is someone really
using and can justify why glpk can't be used?

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] change to subversion

[Bill D. <de...@se...>]

On Sun, 2 Apr 2006, Stefan van der Walt wrote:

> Is anyone else interested in moving over to subversion?

I like SVN significantly better than CVS.

Bill

-- 
"It is seldom that liberty of any kind is lost all at once."  -- Hume

Re: [OctDev] De-crufting octave-forge

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

On Apr 4, 2006, at 7:23 PM, Quentin Spencer wrote:

> David Bateman wrote:
>
>> Quentin Spencer wrote:
>>
>>
>>> David Bateman wrote:
>>>
>>>
>>>> Quentin Spencer wrote:
>>>>
>>>>
>>>>
>>>>> Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but 
>>>>> there
>>>>> are incompatibilities, as recently pointed out with the system
>>>>> function (should be fixed in CVS now), so I think we should make
>>>>> another release for 2.9.5+ soon. I'm willing to spend a little time
>>>>> doing some de-crufting, but I just wanted to ask first if there is
>>>>> anything I shouldn't touch. The obvious stuff is all of the 
>>>>> Makefiles
>>>>> and .m.in files for things that are now in octave, but even that is
>>>>> incomplete (most of the stuff in the main/time directory appears 
>>>>> to be
>>>>> in octave now, and there are probably more examples). I also was
>>>>> inclined to just remove the whole sparse directory, but I thought
>>>>> David said we needed to keep the superLU stuff. Any objections?
>>>>>
>>>>> -Quentin
>>>>>
>>>>>
>>>> A lot of stuff is conditionally built, and that can be removed. 
>>>> Also for
>>>> the sparse stuff the iteration stuff should be kept for 2.9, but 
>>>> not the
>>>> rest. That is the pcg.m and pcr.m functions, but nothing else.
>>>>
>>>>
>>> I have now cleaned out everything in main/sparse except for these two
>>> files.
>>>
>>> -Quentin
>>>
>>>
>>>
>> With all of the patches that John accepted you can completely remove 
>> the
>> FIXES directory...
>>
>
> I think we should have a new release before removing this, since the 
> changes aren't in 2.9.5, and the 2006.03.17 release has some 
> incompatibilities with 2.9.5 (with the system function, for example), 
> which have been fixed in CVS. By the way, I just did some more 
> removals: the extras/ver20 and extras/fake-sparse.

So you want a new 2.9.5 only release of octave-forge?

You are welcome to run through the instructions in release.sh whenever 
you think we are ready for a new release.

The main/path directory can be removed after the next release of octave.

- Paul

Re: [OctDev] De-crufting octave-forge

[Quentin S. <qsp...@ie...>]

David Bateman wrote:

>Quentin Spencer wrote:
>
>  
>
>>David Bateman wrote:
>>
>>    
>>
>>>Quentin Spencer wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there
>>>>are incompatibilities, as recently pointed out with the system
>>>>function (should be fixed in CVS now), so I think we should make
>>>>another release for 2.9.5+ soon. I'm willing to spend a little time
>>>>doing some de-crufting, but I just wanted to ask first if there is
>>>>anything I shouldn't touch. The obvious stuff is all of the Makefiles
>>>>and .m.in files for things that are now in octave, but even that is
>>>>incomplete (most of the stuff in the main/time directory appears to be
>>>>in octave now, and there are probably more examples). I also was
>>>>inclined to just remove the whole sparse directory, but I thought
>>>>David said we needed to keep the superLU stuff. Any objections?
>>>>
>>>>-Quentin
>>>>
>>>>  
>>>>        
>>>>
>>>A lot of stuff is conditionally built, and that can be removed. Also for
>>>the sparse stuff the iteration stuff should be kept for 2.9, but not the
>>>rest. That is the pcg.m and pcr.m functions, but nothing else.
>>>
>>>      
>>>
>>I have now cleaned out everything in main/sparse except for these two
>>files.
>>
>>-Quentin
>>
>>
>>    
>>
>With all of the patches that John accepted you can completely remove the
>FIXES directory...
>  
>

I think we should have a new release before removing this, since the 
changes aren't in 2.9.5, and the 2006.03.17 release has some 
incompatibilities with 2.9.5 (with the system function, for example), 
which have been fixed in CVS. By the way, I just did some more removals: 
the extras/ver20 and extras/fake-sparse.

-Quentin

Re: [OctDev] De-crufting octave-forge

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

Quentin Spencer wrote:

> David Bateman wrote:
>
>> Quentin Spencer wrote:
>>
>>  
>>
>>> Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there
>>> are incompatibilities, as recently pointed out with the system
>>> function (should be fixed in CVS now), so I think we should make
>>> another release for 2.9.5+ soon. I'm willing to spend a little time
>>> doing some de-crufting, but I just wanted to ask first if there is
>>> anything I shouldn't touch. The obvious stuff is all of the Makefiles
>>> and .m.in files for things that are now in octave, but even that is
>>> incomplete (most of the stuff in the main/time directory appears to be
>>> in octave now, and there are probably more examples). I also was
>>> inclined to just remove the whole sparse directory, but I thought
>>> David said we needed to keep the superLU stuff. Any objections?
>>>
>>> -Quentin
>>>
>>>   
>>
>> A lot of stuff is conditionally built, and that can be removed. Also for
>> the sparse stuff the iteration stuff should be kept for 2.9, but not the
>> rest. That is the pcg.m and pcr.m functions, but nothing else.
>>
>
> I have now cleaned out everything in main/sparse except for these two
> files.
>
> -Quentin
>
>
With all of the patches that John accepted you can completely remove the
FIXES directory...

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

[OctDev] addpath, rmpath, savepath

[Keith G. <kwg...@gm...>]

I changed the coding style of addpath, rmpath, and savepath to prepare
for moving the functions to Octave.

Re: [OctDev] change to subversion

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

On Apr 2, 2006, at 5:24 AM, Stefan van der Walt wrote:

> Is anyone else interested in moving over to subversion?  Sourceforge
> provides detailed documentation at
>
> http://sourceforge.net/docs/E09/

No objections from  me.

- Paul

[OctDev] Compiling octave-forge 2006.03.17 with Octave 2.1.73 and g++ 4.1

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

[First of all, sorry for the cross-posting.  I wish that the Octave Forge
developers and the Debian Octave Group to be aware of the issue discussed
below, hence the Cc:s.  Please, respect the M-F-T header and keep this
discussion in octave-maintainers.]

I am not sure I should have reported this to octave-bug.  Anyway, in
trying to build the Debian package for octave-forge 2006.03.17 with
Octave 2.1.73 and g++ 4.1.0, I stumbled on several error messages like
this:

====================================================================
[...]
Processing main/sparse/...
make[3]: Entering directory `/root/octave-forge/octave-forge-2006.03.17/main/sparse'
mkoctfile -Doctave_idx_type=int -DHAVE_OCTAVE_21 -v -c sparse_ops.cc -ISuperLU/SRC/ -ISuperLU/CBLAS -DNDEBUG -DHAVE_ND_ARRAYS -DTYPEID_HAS_CLASS -DCLASS_HAS_LOAD_SAVE -DHAVE_OCTAVE_CONCAT -DHAVE_OCTAVE_UPLUS -o sparse_ops.o
/usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.73 -I/usr/include/octave-2.1.73/octave -mieee-fp -O2 -ISuperLU/SRC/ -ISuperLU/CBLAS -Doctave_idx_type=int -DHAVE_OCTAVE_21 -DNDEBUG -DHAVE_ND_ARRAYS -DTYPEID_HAS_CLASS -DCLASS_HAS_LOAD_SAVE -DHAVE_OCTAVE_CONCAT -DHAVE_OCTAVE_UPLUS sparse_ops.cc -o sparse_ops.o
[...]
/usr/include/octave-2.1.73/octave/ArrayN.h: In constructor 'ArrayN<T>::ArrayN(const dim_vector&, const T&) [with T = bool]':
/usr/include/octave-2.1.73/octave/boolNDArray.h:49:   instantiated from here
/usr/include/octave-2.1.73/octave/ArrayN.h:66: error: no matching function for call to 'fill(const bool&)'
/usr/lib/gcc/i486-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_algobase.h:573: note: candidates are: void std::fill(unsigned char*, unsigned char*, const unsigned char&)
/usr/lib/gcc/i486-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_algobase.h:581: note:                 void std::fill(signed char*, signed char*, const signed char&)
/usr/lib/gcc/i486-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/stl_algobase.h:589: note:                 void std::fill(char*, char*, const char&)
[...]
====================================================================

Compilation succeeded with the following patch to two Octave headers
files:

====================================================================
--- ArrayN.h-orig	2005-05-02 13:16:12.000000000 +0200
+++ ArrayN.h		2006-04-02 14:26:35.350510480 +0200
@@ -63,7 +63,7 @@
   ArrayN (const dim_vector& dv) : Array<T> (dv) { }
 
   ArrayN (const dim_vector& dv, const T& val)
-    : Array<T> (dv) { fill (val); }
+    : Array<T> (dv) { Array<T>::fill (val); }
 
   template <class U>
   explicit ArrayN (const Array2<U>& a) : Array<T> (a, a.dims ()) { }
--- DiagArray2.h-orig	2005-05-02 13:16:16.000000000 +0200
+++ DiagArray2.h	2006-04-02 14:25:04.380340048 +0200
@@ -125,7 +125,7 @@
     {
       this->dimensions = dim_vector (r, c);
 
-      fill (val);
+      Array<T>::fill (val);
     }
 
   DiagArray2 (const Array<T>& a) : Array<T> (a)
====================================================================

Are the patches above correct?  Would they be applied to CVS?

-- 
Rafael

[OctDev] change to subversion

[Stefan v. d. W. <st...@su...>]

Is anyone else interested in moving over to subversion?  Sourceforge
provides detailed documentation at

http://sourceforge.net/docs/E09/

Regards
St=E9fan

Re: [OctDev] De-crufting octave-forge

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

John, the context is the decrufting of octave-forge.

David, I don't believe John follows the octave-dev list.

- Paul

On Mar 29, 2006, at 9:36 AM, David Bateman wrote:
>>> grid.m: This is a compatibility extension of grid.m to allow 1)
>>> recovering the previous state with the gget function and toggling 
>>> grid
>>> state if no input arguments are used. It also supports minor tics if 
>>> you
>>> have an argument like "x#y#z#" where # is a digit. This is not
>>> texinfo-fied, so based on a very old octave version of grid.m, it 
>>> used
>>> gget which I don't see ever going into octave as it has some possibly
>>> nasty race conditions on temporary files. Perhaps with gnuplot 4.1
>>> something similar might be implemented with a pipe and be accepted in
>>> octave. So in its current implementation I don't see this code being
>>> accepted. That being the case, the minor tick stuff might be 
>>> included,
>>> just not the probing of the existing settings.
>>
>>
>> Rather than querying we could try keeping track of state on the
>> octave side.
>
> I suppose if there is a "PKG_ADD grid('off')" command in grid.m and a
> persistent variable tracking its state this would make sense. Easy
> enough to propose a patch.
>
>>
>> The syntax for minor tics is a bit hackish and may be rejected.
>
> John what do you want to do about the minors tics in o-f's grid.m?

Re: [OctDev] De-crufting octave-forge

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

>> Preserving the old random number generator seems crufty.  Could it
>> be made into an external package that the few people who care
>> about it can download it separately?
>>
> John's stated he want to keep the capability to generate the same
> sequences as the old generators. That being the case I don't see a way
> around having both.

One can have the capability in an external package if one
really needs it.

I'm not going to argue too much though since I'm not the
one maintaining the cruft.

- Paul

Re: [OctDev] De-crufting octave-forge

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

On Mar 29, 2006, at 9:36 AM, David Bateman wrote:

>> I've been living with the current octave-mod.
>
> So the octave-mod in extras/patches goes..

I think it might be worth keeping, but I've been living
without it.  The amount of octave work I'm doing is
minimal and much of that is over a ssh link using vi.

- Paul

Re: [OctDev] De-crufting octave-forge

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

On Mar 29, 2006, at 11:43 AM, Andy Adler wrote:

> On 3/29/06, Quentin Spencer <qsp...@ie...> wrote:
>> David Bateman wrote:
>>> A lot of stuff is conditionally built, and that can be removed. Also 
>>> for
>>> the sparse stuff the iteration stuff should be kept for 2.9, but not 
>>> the
>>> rest. That is the pcg.m and pcr.m functions, but nothing else.
>>>
>>
>> I have now cleaned out everything in main/sparse except for these two 
>> files.
>
> Note that the old sparse stuff is required for sparse support
> for 2.1.x. Do we still intend to provide o-f for 2.1.x,

No.

> and if so, is there a branch of o-f to support it?

Yes.

- Paul

Re: [OctDev] De-crufting octave-forge

[Andy A. <ad...@nc...>]

On 3/29/06, Quentin Spencer <qsp...@ie...> wrote:
> David Bateman wrote:
> >A lot of stuff is conditionally built, and that can be removed. Also for
> >the sparse stuff the iteration stuff should be kept for 2.9, but not the
> >rest. That is the pcg.m and pcr.m functions, but nothing else.
> >
>
> I have now cleaned out everything in main/sparse except for these two fil=
es.

Note that the old sparse stuff is required for sparse support
for 2.1.x. Do we still intend to provide o-f for 2.1.x, and if so, is
there a branch of o-f to support it?
--
Andy

Re: [OctDev] De-crufting octave-forge

[Quentin S. <qsp...@ie...>]

David Bateman wrote:

>Quentin Spencer wrote:
>
>  
>
>>Theoretically, the 2006.03.17 o-f release builds with 2.9.5, but there
>>are incompatibilities, as recently pointed out with the system
>>function (should be fixed in CVS now), so I think we should make
>>another release for 2.9.5+ soon. I'm willing to spend a little time
>>doing some de-crufting, but I just wanted to ask first if there is
>>anything I shouldn't touch. The obvious stuff is all of the Makefiles
>>and .m.in files for things that are now in octave, but even that is
>>incomplete (most of the stuff in the main/time directory appears to be
>>in octave now, and there are probably more examples). I also was
>>inclined to just remove the whole sparse directory, but I thought
>>David said we needed to keep the superLU stuff. Any objections?
>>
>>-Quentin
>>
>>    
>>
>A lot of stuff is conditionally built, and that can be removed. Also for
>the sparse stuff the iteration stuff should be kept for 2.9, but not the
>rest. That is the pcg.m and pcr.m functions, but nothing else.
>

I have now cleaned out everything in main/sparse except for these two files.

-Quentin

Re: [OctDev] octave-forge dependencies

[Rafael L. <rla...@us...>]

* Alexander Barth <ab...@ma...> [2006-03-29 09:36]:

> With the octcdf toolbox, octave-forge depends now on the NetCDF library. 
> Most distributions (Debian, Fedora, SUSE,...) provide a pre-compiled 
> package of this library. Where would be the appropriate place to inform 
> the user and those who make the distribution package? Is an entry in the 
> INSTALL file sufficient?

The current version of the Debian octave-forge package (in the unstable
distribution) depend on libnetcdf3. See:

    http://packages.debian.org/unstable/math/octave-forge

-- 
Rafael

[OctDev] octave-forge dependencies

[Alexander B. <ab...@ma...>]

Hi all,

With the octcdf toolbox, octave-forge depends now on the NetCDF library. 
Most distributions (Debian, Fedora, SUSE,...) provide a pre-compiled 
package of this library. Where would be the appropriate place to inform 
the user and those who make the distribution package? Is an entry in the 
INSTALL file sufficient?

Cheers,
Alex