octave-dev — GNU Octave developers' list

Re: [OctDev] Segmentation fault with splot

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

Confirmed as being in octave cvs and octave-forge cvs... The GDB 
backtrace is

#0  0x41d2f987 in std::_List_base<GiNaC::ex, std::allocator<GiNaC::ex> >::__clear() (this=0xbfffc304) at ex.h:377
#1  0x41f8976f in GiNaC::lst::destroy(bool) () from /usr/lib/libginac-1.1.so.0
#2  0x41e50421 in GiNaC::basic::subs(GiNaC::ex const&, unsigned) const ()
   from /usr/lib/libginac-1.1.so.0
#3  0x41d1e81d in Fsubs(octave_value_list const&, int) (args=@0xbfffc4f0)
    at ex.h:283
#4  0x403b0d9d in octave_builtin::do_multi_index_op(int, octave_value_list const&) (this=0x8979210, nargout=1, args=@0x8a5ec18) at oct-obj.h:78
#5  0x403b0323 in octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (this=0x8979210, 
    type=@0x8ac4778, idx=@0xbfffc9a0, nargout=1) at stl_list.h:676
#6  0x4038ff54 in octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (this=0xbfffc9c0, 
    type=@0x8ac4778, idx=@0xbfffc9a0, nargout=1) at ov.cc:836
#7  0x404a2d7d in tree_index_expression::rvalue(int) (this=0x8ac4758, 
    nargout=1) at oct-obj.h:78
#8  0x404a3c16 in tree_index_expression::rvalue() (this=0x8ac4758)
    at pt-idx.cc:346
#9  0x40482917 in tree_argument_list::convert_to_const_vector(octave_value const*) (this=0x8ac4800, object=0x0) at pt-arg-list.cc:209
#10 0x404a54c1 in make_value_list (args=0x8ac4800, arg_nm=@0x8a632e0, 
    object=0xbfffceb0) at oct-obj.h:78

So it seems that there is a missing destructor...

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] Segmentation fault with splot

[edA-qa mort-ora-y <in...@tr...>]

Executing this series of commands will generate a segmentation fault.

symbols
m=sym("m")
splot(1/m,m,[0,1])

GNU Octave, version 2.1.50 (i586-mandrake-linux-gnu).
+octave-forge-2004.09.09
+GiNaC-1.2.3

-- 
edA-qa mort-ora-y (Producer)
Trostlos Records <http://trostlos.org/>

"What suffering would man know if not for his own?"

[OctDev] Wiki

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

Dear All,

I notice that there is no file http://wiki.octave.org/robots.txt ?
Does this mean that all of the website is indexed? If so RecentChanges
and all old versions of the pages are indexed and so be the spammers
to the website get what they want, page rank with google since even
after getting rid of their garbage google would see it.

I'm not sure who is in charge of the wiki, but can someone confirm
that the RecentChanges and old versions of the pages aren't being
indexed by google?

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] Test functions not working?

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

On Tue, Sep 14, 2004 at 09:39:50PM +0200, Josep Mon?s i Teixidor wrote:
> Hi David!
> 
> I apologize for the delay of my response... compiling Octave is sooo
> slow on my P2 :)


I have recently discovered the joys of distributed compiling!  Brought
my compile time down from half an hour to about 5 :)

Regards
Stefan

Re: [OctDev] Test functions not working?

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

According to Josep Mon=E9s i Teixidor <jm...@pu...> (on 09/14/04=
):
> I've tested your patch on Octave CVS version from last friday (or
> thursday). It works for nan but I still have problems with test
> functions because of substraction not being implemented actually, but
> perhaps you already know this issue because I thing you and John were
> discussing how to implement operations on 64 bits types:
>=20
> octave:9> uint64(1)-uint64(1)
> error: binary operator `-' not implemented for `uint64 scalar' by
> `uint64 scalar' operations
> error: evaluating binary operator `-' near line 9, column 10
>=20
> octave:9> uint64(1)+uint64(1)
> error: binary operator `+' not implemented for `uint64 scalar' by
> `uint64 scalar' operations
> error: evaluating binary operator `+' near line 9, column 10

Yes, they aren't implemented in octave or matlab R14 for that matter.

> octave:9> assert(uint64(1),uint64(1))
> error: binary operator `-' not implemented for `uint64 scalar' by
> `uint64 scalar' operations
> error: evaluating binary operator `-' near line 133, column 17
> error: evaluating argument list element number 1
> error: evaluating argument list element number 1
> error: evaluating assignment expression near line 133, column 6
> error: evaluating if command near line 132, column 7
> error: evaluating if command near line 120, column 5
> error: evaluating if command near line 58, column 3
> error: called from `assert' in file
> `/home/josep/source/cvs/cvs.sourceforge.net/octave-forge/extra/testfun/=
assert.m'


Ok this is a bug in assert.m, as it shouldn't try to do a subtraction
when the tolerance is zero. Rather it should do a compare.... I'd=20
suggest a patch like, that attached. I haven't committed it however
as its upto Paul to decide what he whats done in this case.

Cheers
David





>=20
>=20
>=20
> I'll have to setup a cron job to compile Octave and octave-forge every
> night :)
>=20
> Regards
>=20
> --=20
> Josep Mon=E9s i Teixidor
> Clau GnuPG: gpg --recv-keys 80E85CC4



--=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] allowing mex to pass in a help string?

[Dan M. <dan...@mc...>]

On Fri, Sep 10, 2004 at 12:38:04AM -0400, Paul Kienzle wrote:
> 
> On Sep 9, 2004, at 8:10 PM, Dan McMahill wrote:
> 
> >With matlab mex, I typically would do something like create
> >
> >myfn.c  -- the C-mex file
> >myfn.m  -- a matlab.m file which is only comments for the help output
> >
> >then when I do 'help myfn' in matlab I get the help text.
> >
> >With the octave mex interface it seems like I can sort of get there
> >by creating the .m file, but what I get for help output is
> >
> >type(file_in_loadpath('myfn.m'))
> >
> >If I execute that, I get the contents of myfn.m including the '%' 
> >comments
> >which means I can't just paste a multi-line example into octave.
> >
> >I guess I can use awk or sed to strip the leading '%' and have the .m
> >file really just be a text help file, but it would seem that it might 
> >be
> >nice to have a more automated way of getting the help to work.
> >
> >Any suggestions?
> >
> >I don't mind hacking on the mex script if thats whats needed.
> 
> Hacking the mex script is going to be the easiest.  I'm guessing
> you know what to do: if myfn.m exists when compiling a mex
> file, pipe it through sed to strip the comment characters and to
> add "\n\" to the end of every line, then put the output in place of
> the "type(file_in_loadpath" text in the cc-file that gets created.

I have a diff of mex (not mex.in) that seems to work.  I guess
there should probably be an autoconf check for awk and in particular
favor nawk over awk for systems such as solaris.

Had to jump through a few escaping hoops to get it to be reliable.

Should I make a patch against mex.in and file a bug report?

> Long term octave should be modified so that it includes mex.cc,
> and can load a precompiled mex file.  When it loads the myfun.mex,
> it can load myfn.m at the same time and populate  the docstring of
> the symbol.

I agree.

-Dan 

-- 

Re: [OctDev] Test functions not working?

[Josep i T. <jm...@pu...>]

Hi David!

I apologize for the delay of my response... compiling Octave is sooo
slow on my P2 :)

On dv, 2004-09-10 at 10:54, David Bateman wrote:

>=20
> octave:1> isnan(uint64(1))
> error: octave_base_value::double_value (): wrong type argument `uint64 sc=
alar'
> octave:2> isnan(uint64([1,1]))
> ans =3D
>=20
>   0  0
>=20

I've tested your patch on Octave CVS version from last friday (or
thursday). It works for nan but I still have problems with test
functions because of substraction not being implemented actually, but
perhaps you already know this issue because I thing you and John were
discussing how to implement operations on 64 bits types:

octave:7> isnan(uint64(1))
ans =3D 0

octave:8> uint64(1)=3D=3Duint64(1)
ans =3D 1

octave:9> uint64(1)-uint64(1)
error: binary operator `-' not implemented for `uint64 scalar' by
`uint64 scalar' operations
error: evaluating binary operator `-' near line 9, column 10

octave:9> uint64(1)+uint64(1)
error: binary operator `+' not implemented for `uint64 scalar' by
`uint64 scalar' operations
error: evaluating binary operator `+' near line 9, column 10

octave:9> assert(uint64(1),uint64(1))
error: binary operator `-' not implemented for `uint64 scalar' by
`uint64 scalar' operations
error: evaluating binary operator `-' near line 133, column 17
error: evaluating argument list element number 1
error: evaluating argument list element number 1
error: evaluating assignment expression near line 133, column 6
error: evaluating if command near line 132, column 7
error: evaluating if command near line 120, column 5
error: evaluating if command near line 58, column 3
error: called from `assert' in file
`/home/josep/source/cvs/cvs.sourceforge.net/octave-forge/extra/testfun/asse=
rt.m'



I'll have to setup a cron job to compile Octave and octave-forge every
night :)

Regards

--=20
Josep Mon=E9s i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] octave-forge build failure on FreeBSD

[NAKATA M. <ch...@ma...>]

In Message-ID: <200...@zf...> 
David Bateman <Dav...@mo...> wrote:

> So try the 2004.09.09 version, and everything should work fine...
okay, I'll update asap, but little bit busy at the moment and
now we are in ports freeze, so as reminder, I raise an PR...

http://www.freebsd.org/cgi/query-pr.cgi?pr=71702
thanks for your suggestions!
--nakata maho

Re: [OctDev] octave-forge build failure on FreeBSD

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

Going back through the CVS lines 90, etc in sort.cc are

         template octave_sort<unsigned EIGHT_BYTE_INT>;
         template octave_sort<vec_index *>;

which should be "template class" under g++ 3.4.x and is fixed in later
versions of octave-forge as you've found out...

And for the dispatch.cc issue, you aren't using the latest octave-forge
as there is a 2004-09-09 which explains Paul's reponse. It seems to me
that you are using 2004.07.07, which I can surmise by the absence of the
HAVE_OCTAVE_CONCAT flag in the sparse, fixed and comm's toolboxes.. So
looking at what is on line 543 in 2004.07.07 version and surprise, its

template std::map<std::string,std::string>;

which of course should read

template class std::map<std::string,std::string>;

for g+ 3.4.x also... This was fixed with the patch


  Revision 1.16 
  Fri Jul 9 00:51:59 2004 UTC (2 months ago) by pkienzle
  Branch: MAIN
  Changes since 1.15: +1 -1 lines

  [for Philippe Leroux] fix use of template instantiation without class keyword


So try the 2004.09.09 version, and everything should work fine...

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] Problem compiling octave-forge (octave: message 4 of 20)

[Ralph <oct...@sp...>]

On Saturday 11 September 2004 02:32, Paul Kienzle - pki...@us... 
wrote:
> What version of octave are you using?  What OS?  What compiler?


I'm using octave 2.1.50 and gcc version 3.3.4

Re: [OctDev] octave-forge build failure on FreeBSD

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

On Sep 1, 2004, at 9:16 AM, Joan Picanyol wrote:

> [please honour MFT:, not subscribed; Cc:'ed mantainer]
>
> And the latest version fails with:
>
> c++ -c -I/usr/local/include -fPIC -I/usr/local/include/octave-2.1.57
> -I/usr/local/include/octave-2.1.57/octave -I/usr/local/include 
> -mieee-fp
> -g -O -pipe -march=athlon-mp -DHAVE_OCTAVE_21 -DUSE_TERM -DHAVE_TERM_H
> -DTYPEID_HAS_CLASS dispatch.cc -o dispatch.o
> dispatch.cc:543: error: expected unqualified-id before ';
> ke[2]: *** [dispatch.oct] Error 1
> rm -f dispatch_help.oct

542	 dispatch_record(f,n,t);
543	
544	 return retval;

No idea.

Paul Kienzle
pki...@us...

Re: [OctDev] Problem compiling octave-forge

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

What version of octave are you using?  What OS?  What compiler?

- Paul

On Sep 10, 2004, at 11:44 AM, Ralph wrote:

> Something is missing, but I don't know the library. Could someone help 
> me?
>
>  The first error msg is:
>  ======================
>  rand.cc: In function `void do_size(octave_value_list, int&, int&)':
>  rand.cc:139: error: `xisnan' undeclared (first use this function)
>  rand.cc:139: error: (Each undeclared identifier is reported only once 
> for
> each
>  function it appears in.)
>  make[1]: *** [rand.oct] Error 1
>  =======================
>
>  and the 2nd:
>
>  =======================
>  coupling_3j.cc: In function `octave_value_list Fcoupling_3j(const
>  octave_value_list&, int)':
>  coupling_3j.cc:74: error: `NDArray' undeclared (first use this 
> function)
>  =======================

[OctDev] Problem compiling octave-forge

[Ralph <oct...@sp...>]

Something is missing, but I don't know the library. Could someone help me?
 
 The first error msg is:
 ======================
 rand.cc: In function `void do_size(octave_value_list, int&, int&)':
 rand.cc:139: error: `xisnan' undeclared (first use this function)
 rand.cc:139: error: (Each undeclared identifier is reported only once for 
each 
 function it appears in.)
 make[1]: *** [rand.oct] Error 1
 =======================
 
 and the 2nd:
 
 =======================
 coupling_3j.cc: In function `octave_value_list Fcoupling_3j(const 
 octave_value_list&, int)':
 coupling_3j.cc:74: error: `NDArray' undeclared (first use this function)
 =======================
 
Ralph

Re: [OctDev] Test functions not working?

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

On 10-Sep-2004, David Bateman <Dav...@mo...> wrote:

| So the work around for 2.1.58 is to change your assert to
| assert(uint64([1,1]),uint64([1,1])). The really fix is to apply the
| attached patch.

I applied this patch.

Thanks,

jwe

Re: [OctDev] Test functions not working?

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

According to Josep Mon=E9s i Teixidor <jm...@pu...> (on 09/09/04=
):
> Hi!
>=20
> My computer finally finished building Octave 2.1.58 and Octave-forge an=
d
> I run the tests.
>=20
> I noticed "error" tests don't work... is this only in my copy or is thi=
s
> a known issue?
>=20
> uintlut fails too because it compares 2 uint64 in an assert, which
> doesn't work. Try assert(uint64(1),uint64(1)). Should I comment out thi=
s
> test?

This fails due to the fact that isnan and isinf in octave itself haven't
been converted to accept int/uint args. Or rather the double_value()
method doesn't exist in the integer method. You can see this with the
test case

octave:1> isnan(uint64(1))
error: octave_base_value::double_value (): wrong type argument `uint64 sc=
alar'
octave:2> isnan(uint64([1,1]))
ans =3D

  0  0

So the work around for 2.1.58 is to change your assert to
assert(uint64([1,1]),uint64([1,1])). The really fix is to apply the
attached patch.

> Some days ago I send an email about test don't working ok for int* and
> uint* types (current test doesn't work for int* and uint* scalars, and
> doesn't fail if values in arrays differ),  including a patch. I didn't
> commit it because I'm not 100% sure and this can break a lot of thing,
> specially now.

Could you try the attached patch, it should probably address this issue
too.

D.

--=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] passing -R to mkoctfile

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

On Sep 10, 2004, at 12:41 AM, dan...@mc... wrote:

>
>
>> On Sep 9, 2004, at 8:03 PM, dan...@mc... wrote:
>>
>>> I'm wondering if the mkoctfile script should be extended to allow
>>> -Rpath or maybe
>>> -Wl,-Rpath to be passed on to the compiler?  I was working on
>>> something which
>>> links to a shared lib which may or may not be installed in a place
>>> where shared
>>> libs are searched for.  Without mkoctfile accepting -Rpath I end up
>>> having to
>>> set LD_LIBRARY_PATH.
>>>
>>> Basically, the -[lL] line in mkoctfile could be changed to -[lLR].
>>>
>>> Thoughts?
>>>
>>> -Dan
>>
>>
>
> On Fri, Sep 10, 2004 at 12:15:07AM -0400, Paul Kienzle wrote:
>> You should also be able to do something like:
>>
>> 	RLD_FLAG="-Rpath" mkoctfile ...
>>
>> or if you already have some rpath,
>>
>> 	RLD_FLAG="`mkoctfile -p RLD_FLAG`:path" mkoctfile ...
>>
>> - Paul
>>
>
> RLD_FLAG is only used if --link-stand-alone is specified (at least in 
> octave-2.1.57
> which is what I have installed).

So it is.  How about the same trick with DL_LDFLAGS then?

I agree with your earlier point, though, that it would be nice to be 
able
to pass flags directly to the compiler.  How about if mkoctfile blindly
gathers all flags it doesn't otherwise understand and passes them
through to the compiler?  That should be easy enough to write.

- Paul

Re: [OctDev] passing -R to mkoctfile

[<dan...@mc...>]

> On Sep 9, 2004, at 8:03 PM, dan...@mc... wrote:
> 
> >I'm wondering if the mkoctfile script should be extended to allow 
> >-Rpath or maybe
> >-Wl,-Rpath to be passed on to the compiler?  I was working on 
> >something which
> >links to a shared lib which may or may not be installed in a place 
> >where shared
> >libs are searched for.  Without mkoctfile accepting -Rpath I end up 
> >having to
> >set LD_LIBRARY_PATH.
> >
> >Basically, the -[lL] line in mkoctfile could be changed to -[lLR].
> >
> >Thoughts?
> >
> >-Dan
> 
> 

On Fri, Sep 10, 2004 at 12:15:07AM -0400, Paul Kienzle wrote:
> You should also be able to do something like:
> 
> 	RLD_FLAG="-Rpath" mkoctfile ...
> 
> or if you already have some rpath,
> 
> 	RLD_FLAG="`mkoctfile -p RLD_FLAG`:path" mkoctfile ...
> 
> - Paul
> 

RLD_FLAG is only used if --link-stand-alone is specified (at least in octave-2.1.57
which is what I have installed).

-Dan

-- 

Re: [OctDev] allowing mex to pass in a help string?

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

On Sep 9, 2004, at 8:10 PM, Dan McMahill wrote:

> With matlab mex, I typically would do something like create
>
> myfn.c  -- the C-mex file
> myfn.m  -- a matlab.m file which is only comments for the help output
>
> then when I do 'help myfn' in matlab I get the help text.
>
> With the octave mex interface it seems like I can sort of get there
> by creating the .m file, but what I get for help output is
>
> type(file_in_loadpath('myfn.m'))
>
> If I execute that, I get the contents of myfn.m including the '%' 
> comments
> which means I can't just paste a multi-line example into octave.
>
> I guess I can use awk or sed to strip the leading '%' and have the .m
> file really just be a text help file, but it would seem that it might 
> be
> nice to have a more automated way of getting the help to work.
>
> Any suggestions?
>
> I don't mind hacking on the mex script if thats whats needed.

Hacking the mex script is going to be the easiest.  I'm guessing
you know what to do: if myfn.m exists when compiling a mex
file, pipe it through sed to strip the comment characters and to
add "\n\" to the end of every line, then put the output in place of
the "type(file_in_loadpath" text in the cc-file that gets created.

Long term octave should be modified so that it includes mex.cc,
and can load a precompiled mex file.  When it loads the myfun.mex,
it can load myfn.m at the same time and populate  the docstring of
the symbol.

- Paul

Re: [OctDev] passing -R to mkoctfile

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

You should also be able to do something like:

	RLD_FLAG="-Rpath" mkoctfile ...

or if you already have some rpath,

	RLD_FLAG="`mkoctfile -p RLD_FLAG`:path" mkoctfile ...

- Paul

On Sep 9, 2004, at 8:03 PM, dan...@mc... wrote:

> I'm wondering if the mkoctfile script should be extended to allow 
> -Rpath or maybe
> -Wl,-Rpath to be passed on to the compiler?  I was working on 
> something which
> links to a shared lib which may or may not be installed in a place 
> where shared
> libs are searched for.  Without mkoctfile accepting -Rpath I end up 
> having to
> set LD_LIBRARY_PATH.
>
> Basically, the -[lL] line in mkoctfile could be changed to -[lLR].
>
> Thoughts?
>
> -Dan

[OctDev] allowing mex to pass in a help string?

[Dan M. <dan...@mc...>]

With matlab mex, I typically would do something like create

myfn.c  -- the C-mex file
myfn.m  -- a matlab.m file which is only comments for the help output

then when I do 'help myfn' in matlab I get the help text.

With the octave mex interface it seems like I can sort of get there
by creating the .m file, but what I get for help output is

type(file_in_loadpath('myfn.m'))

If I execute that, I get the contents of myfn.m including the '%' comments
which means I can't just paste a multi-line example into octave.  

I guess I can use awk or sed to strip the leading '%' and have the .m
file really just be a text help file, but it would seem that it might be
nice to have a more automated way of getting the help to work.

Any suggestions?

I don't mind hacking on the mex script if thats whats needed.

Thanks

-Dan

-- 

[OctDev] passing -R to mkoctfile

[<dan...@mc...>]

I'm wondering if the mkoctfile script should be extended to allow -Rpath or maybe
-Wl,-Rpath to be passed on to the compiler?  I was working on something which
links to a shared lib which may or may not be installed in a place where shared
libs are searched for.  Without mkoctfile accepting -Rpath I end up having to
set LD_LIBRARY_PATH.

Basically, the -[lL] line in mkoctfile could be changed to -[lLR].

Thoughts?

-Dan

-- 

[OctDev] octave-forge release

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

New octave-forge release: 2004-09-09

Extends support to Octave 2.1.58

* Base
   - getfield/setfield now have a compatible interface; for the
     old behaviour, use setfields/getfields.
   - Fill full 53-bit mantissa with the random number generators; new
     sequences will be different from old sequences with the same seed.
   - Removed restrictions on datenum/datevec and added calendar/eomday
   - Added nthroot to return real root if available
   - Added isa to test for class membership
   - clf resets to line graphs
   - Quiver plot is faster and no longer requires clf
   - Added audio playback on OS X

* Image processing
   - Initial support for int* types.
   - Added dilate erode bweuler bwmorph houghtf stretchlim
     makelut applylut uintlut padarray roicolor poly2mask
     qtdecomp qtgetblk qtsetblk bestblk blkproc nlfilter
     cmunique cmpermute col2im im2col graycomatrix conndef isrgb

* Optimization
   - Replacement fzero using Brent's root finder

* Communications:
   - Support for concatenation operator [] on galois type
   - Reduce restrictions on bchpoly syndtable

* Signal processing:
   - Added flattopwin
   - fir1/fir2 have more flexible argument handling

* Sparse:
   - Load/save support
   - Support for concatenation operator []
   - Added pcr for preconditioned conjugate gradient

* Statistics:
   - Added histfit pareto tabulate anderson_darling_cdf 
anderson_darling_test

[OctDev] CVSfoo

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

Can somebody with CVSfoo please move

	extra/pdb/bin

to

	extra/pdb/scripts

?

I know on the answer is somewhere on the list, but I prefer
to have people who know what they are doing messing
with the archive.

Thanks,

- Paul

[OctDev] Test functions not working?

[Josep i T. <jm...@pu...>]

Hi!

My computer finally finished building Octave 2.1.58 and Octave-forge and
I run the tests.

I noticed "error" tests don't work... is this only in my copy or is this
a known issue?

uintlut fails too because it compares 2 uint64 in an assert, which
doesn't work. Try assert(uint64(1),uint64(1)). Should I comment out this
test?

Some days ago I send an email about test don't working ok for int* and
uint* types (current test doesn't work for int* and uint* scalars, and
doesn't fail if values in arrays differ),  including a patch. I didn't
commit it because I'm not 100% sure and this can break a lot of thing,
specially now.

Regards,

--=20
Josep Mon=E9s i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] Release details

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

On Sep 9, 2004, at 3:54 AM, David Bateman wrote:

> According to Josep Mon=E9s i Teixidor <jm...@pu...> (on=20
> 09/09/04):
>> cmpermute and uintlut don't work in 2.1.57 (with all the uint=BF =
stuff=20
>> it
>> hasn't got much sense) but qtdecomp does.
>
> Then it probably makes sense to move cpermute.m and uintlut.m to
> cpermute.m.in and uintlut.m.in respectively, then add something
> like the following to your makefile
>
> t2.1.58=3Dcpermute.m uintlut.m
> UINT_TARGETS=3D$($(word 1, $(sort t$(OCTAVE_VERSION) t2.1.58)))
>
> all : $(UINT_TARGETS) onv2.oct cordflt2.oct bwlabel.oct bwfill.oct \
> 	rotate_scale.oct houghtf.oct graycomatrix.oct \
> 	$(JPEG) $(PNG)
>
> %.m: %.m.in
>         -$(INSTALL) $< $@
>
> In that way the m-files don't exist for vesrions of octave prior to=20
> 2.1.58

I'm not so keen on this.  I don't mind shipping a function that doesn't=20=

work
on older versions of octave, so long as it doesn't crash.  In this case=20=

the
functions exit with errors saying things like uint8 doesn't exist.

This is different from functions which are removed to avoid conflict=20
with
new octave functions.

- Paul