octave-dev — GNU Octave developers' list

Re: [OctDev] Dispatch broken on OS X(?) No.

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

Indeed a local screw-up, please disregard...

/P

On Jun 19, 2004, at 17:31, Per Persson wrote:

> Hi,
> I just ran a build of octave-forge to check that everything works 
> before the release and found dispatch to be broken.
> Strange thing is that I'm sure it did work a week ago, and I can't see 
> any changes that (could/should) affect dispatch.cc
>
> I'm not having my brightest moment right now (watched Sweden - Italy 
> at the pub yesterday[1]), so if anybody with access to a Mac could 
> verify that it is not a local screw-up I'd be grateful.
>
> /Per
>
> [1] European Soccer Championship, the game ended 1-1 which must be 
> considered reason to celebrate!
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
> NWMGYKND
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Re: [OctDev] Re: release notes

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

<< I >> am not interested in back porting.  If somebody else
wants to, they can send patches to octave-dev which
extends support  backward.  If you build with make -k,
it will build what can be built and ignore the rest.

Note that not all m-files have tests written for them, so changes
in syntax may go unnoticed during check.

We have a new issue to deal with:  deal, isunix, unix and struct
are now part of octave.  I'm inclined to remove them from the
octave-forge, which will break scripts that depend on them in
older versions of octave.  Someone can volunteer to create
extra/shadow to support this.  I would suggest configure.add
script with lines such as:
	AC_SUBST(SHADOWED)
	OCTAVE_CHECK_EXIST(xxx,,[SHADOWED="$SHADOWED xxx"])
Makeconf.add with:
	SHADOWED=@SHADOWED@
and a Makefile which copies xxx.m.in to xxx.m if xxx is in
$(SHADOWED) and removes xxx.m if it isn't. For oct-files,
you need to build xxx.oct if xxx is in $(SHADOWED) or
remove xxx.oct if it isn't.

This way all and only the shadowed functions will be available
during make check and make install.

Paul Kienzle
pki...@us...

On Jun 19, 2004, at 10:46 AM, Chris Caudle wrote:

> On Saturday 19 June 2004 01:00 am, Paul Kienzle wrote:
>> I'm not interested in backporting
>> support to older octave
>
> What is considered "officially" supported now, just 2.1.57?  I 
> installed
> Fedora Core 2 recently, which installs 2.1.50.  Is that too old, or do 
> you
> just mean the 2.0.X series?
>
> thanks,
> Chris Caudle
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
> NWMGYKND
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] Re: release notes

[Chris C. <ch...@ch...>]

On Saturday 19 June 2004 01:00 am, Paul Kienzle wrote:
> I'm not interested in backporting
> support to older octave 

What is considered "officially" supported now, just 2.1.57?  I installed 
Fedora Core 2 recently, which installs 2.1.50.  Is that too old, or do you 
just mean the 2.0.X series?

thanks,
Chris Caudle

[OctDev] Dispatch broken on OS X(?)

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

Hi,
I just ran a build of octave-forge to check that everything works 
before the release and found dispatch to be broken.
Strange thing is that I'm sure it did work a week ago, and I can't see 
any changes that (could/should) affect dispatch.cc

I'm not having my brightest moment right now (watched Sweden - Italy at 
the pub yesterday[1]), so if anybody with access to a Mac could verify 
that it is not a local screw-up I'd be grateful.

/Per

[1] European Soccer Championship, the game ended 1-1 which must be 
considered reason to celebrate!

[OctDev] Fixed still broken on OS X

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

David,
fixed is still broken on OS X, I should have checked sooner but got 
distracted.

On Jun 16, 2004, at 13:15, David Bateman wrote:

> You are right that they need to be instantiated. But cat_ra is an
> NDArray thing and so should be in "#ifdef HAVE_ND_ARRAYS ... #endif".
                                      ^^^^^^^^^^^^^^^^^^^^
Right now the fix is conditioned on #ifndef HAVE_ND_ARRAYS ...
How about the following patch?

/Per


Index: Array-f.cc
===================================================================
RCS file: /cvsroot/octave/octave-forge/main/fixed/Array-f.cc,v
retrieving revision 1.3
diff -u -d -b -w -r1.3 Array-f.cc
--- Array-f.cc  16 Jun 2004 11:22:20 -0000      1.3
+++ Array-f.cc  19 Jun 2004 14:35:48 -0000
@@ -71,12 +71,6 @@
  template class MArray2<FixedPointComplex>;

  #ifndef HAVE_ND_ARRAYS
-template int cat_ra (Array<FixedPoint>& ra, const Array<FixedPoint>& 
ra_arg,
-                    int dim, int idx, int move);
-template int cat_ra (Array<FixedPointComplex>& ra,
-                    const Array<FixedPointComplex>& ra_arg,
-                    int dim, int idx, int move);
-
  template int assign (Array2<FixedPoint>&, const Array2<FixedPoint>&);
  template int assign (Array2<FixedPointComplex>&, const 
Array2<FixedPoint>&);
  template int assign (Array2<FixedPointComplex>&,
@@ -99,6 +93,9 @@
  #include <octave/MArrayN.h>
  #include <octave/MArrayN.cc>

+INSTANTIATE_ARRAY_CAT (FixedPoint);
+INSTANTIATE_ARRAY_CAT (FixedPointComplex);
+
  template class ArrayN<FixedPoint>;
  template class MArrayN<FixedPoint>;
  template class ArrayN<FixedPointComplex>;

[OctDev] release notes

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

I have a first cut at the June '04 release notes.  Please update the
RELEASE-NOTES file as appropriate.  Bug fixes may continue
while I update INDEX files, etc.  I'm not interested in backporting
support to older octave --- if you don't want to upgrade (or don't
want to force your customers/users/students to upgrade), please
post the necessary patches to build on older systems.

Here's what I gleaned from the ChangeLog:


* Extends support to Octave 2.1.57.

* The optimization functions have been replaced but the new interface
   is not yet settled.  See the files in the optim directory.

* New package gsl: GNU Scientific library bindings.

* New package fixed: Fixed point numeric operations.

* New functions: polyconf wsolve fullfact pcg princomp filtic
   rande azimuth deg2rad rad2deg distance zoom inputname fnval

* Bug fixes everywhere they are found.

Paul Kienzle
pki...@us...

Re: [OctDev] new release?

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

OK, I tested your changes to the coding stuff and this is what I found:

bchpoly appears to give correct results for the cases I tested
cyclgen(255,bchpoly(255,247)) gives the correct result
cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the
first 8x8 submatrix, and zeros everywhere else !?
cyclpoly gives a vector containing all zeros for every input I tried.

Well, I guess there's at least some progress since one case worked. I'm
sorry the news isn't better.

-Quentin


David Bateman wrote:

>According to Quentin Spencer <qsp...@ie...> (on 06/16/04):
>  
>
>>David,
>>
>>Thanks. The updates fixed hammgen. However, now I've found another bug. 
>>I don't know if it was there all along or newly introduced. The 
>>following command should produce the 16x255 parity check matrix for a 
>>BCH 2-error correcting code:
>>cyclgen(255,bchpoly(255,239))
>>
>>The result instead is:
>>error: cyclgen: generator polynomial does not produce cyclic code
>>
>>I verified the resulting polynomial against MATLAB and they matched.
>>    
>>
>
>Ok, I'm a bit draft. The test I added checks if the polynomial is primitive
>rather than just irreducible. I'd previously tried to adapt this test in
>the older code, but failed.
>
>So I went back to the basic implementation of dividing x^n-1 by the
>polynomial and checking that there was no remainder. It appears to
>work correctly for you test case now. Though maybe you want to give
>it a bit more testing.. Changes checked into the CVS
>
>Regards
>David
>
>  
>

[OctDev] Re: vrml_transfo syntax error

[Etienne G. <et...@cs...>]

  Hi Laurent,

so, you seem to say, freewrl now requires two dashes in front of
options, rather than one. We should either find a way to determine the
version and set the number of dashes accordingly, or suppose that the
newest freewrl is installed (not the case at my place).

   The file /tmp/octave_browser_out.txt, is used only to get some
feedback from the user: function vrml_select_points() uses it to know
which 3D points in the visualized set (s)he selected (by clicking on
the points). Functions that need no feedback don't create this file,
so not finding may be normal.

  However, /tmp/octave_vrml_output.wrl should exist, as it contains
the vrml data passed to the browser. Do you have it?

  Cheers,

  Etienne

PS : I cc to octave-forge rather than octave.

On Thu, Jun 17, 2004 at 09:50:41AM +0200, Laurent Mazet wrote:
# Few days ago, I fix some "space bug" into the vrml package. I also try the demo
# files on a recent version of freewml (1.06) compiled from source archive. So I
# need to adapt some command line options (see the patch attached). However, the
# browser did not display anything and no output file(/tmp/octave_browser_out.txt)
# is produced.
# 
# Does anyone know how to fix this trouble ?
# 
#       Laurent
# 
# ===================================================================
# RCS file: /cvsroot/octave/octave-forge/main/vrml/vrml_browse.m,v
# retrieving revision 1.5
# diff -r1.5 vrml_browse.m
# 35c35
# < out_option = "-ps -psout /tmp/octave_browser_out.txt " ;
# ---
# > out_option = "--ps --psout /tmp/octave_browser_out.txt " ;
# 62c62
# < b_opt = [out_option," ",bop," ",best_option," -server -snapb octave.snap "] ;
# ---
# > b_opt = [out_option," ",bop," ",best_option," --server --snapb octave.snap "]
# > ;
# 
# -- 
# Dr. Laurent Mazet: Research Engineer /V\ Centre de Recherche de MOTOROLA
# Tel: +33 (0)1 69 35 48 30 =-=-=-=-=-=-=-=-=-=-= Email: ma...@cr...
[snip]

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] new release?

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

According to Quentin Spencer <qsp...@ie...> (on 06/16/04):
> David,
> 
> Thanks. The updates fixed hammgen. However, now I've found another bug. 
> I don't know if it was there all along or newly introduced. The 
> following command should produce the 16x255 parity check matrix for a 
> BCH 2-error correcting code:
> cyclgen(255,bchpoly(255,239))
> 
> The result instead is:
> error: cyclgen: generator polynomial does not produce cyclic code
> 
> I verified the resulting polynomial against MATLAB and they matched.

Ok, I'm a bit draft. The test I added checks if the polynomial is primitive
rather than just irreducible. I'd previously tried to adapt this test in
the older code, but failed.

So I went back to the basic implementation of dividing x^n-1 by the
polynomial and checking that there was no remainder. It appears to
work correctly for you test case now. Though maybe you want to give
it a bit more testing.. Changes checked into the CVS

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] new release?

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

David,

Thanks. The updates fixed hammgen. However, now I've found another bug. 
I don't know if it was there all along or newly introduced. The 
following command should produce the 16x255 parity check matrix for a 
BCH 2-error correcting code:
cyclgen(255,bchpoly(255,239))

The result instead is:
error: cyclgen: generator polynomial does not produce cyclic code

I verified the resulting polynomial against MATLAB and they matched.

regards,
Quentin

David Bateman wrote:

>Quentin,
>
>I wrote the hammgen function over a year ago now and I'm scratching
>my head to think why I wrote the test for an irreducible polynomial
>the way I did in cyclgen.cc and cyclpoly.cc. I vaguely remember that
>there was a reason, but not the details. I think it might have been 
>a limitation elsewhere that I later removed and have now fixed. In
>any case hammgen upto 16 seems to work correctly and a quick test
>of cyclgen and cyclpoly seperately seem to be ok. 
>
>However, if you have any specific tests of these three functions, 
>could you try them and see that they now give the right result,
>with the code I just checked into the CVS...
>
>Regards
>David
>  
>

Re: [OctDev] new release?

[Etienne G. <et...@cs...>]

  Hi all,

just to say that I fixed minimize(), test_min_[1-4] and
test_minimize_1 so that they use bfgsmin() instead of bfgs().

  I should still do some list -> cell work, but that will wait a
little more.

  Cheers,

  Etienne

On Mon, Jun 14, 2004 at 06:37:58PM -0400, Paul Kienzle wrote:
# I would like make a new octave-forge release.  Please let me
# know when you all are ready.
# 
# - Paul
# 
# 
# 
# -------------------------------------------------------
# This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
# Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
# Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
# REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] new release?

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

Quentin,

I wrote the hammgen function over a year ago now and I'm scratching
my head to think why I wrote the test for an irreducible polynomial
the way I did in cyclgen.cc and cyclpoly.cc. I vaguely remember that
there was a reason, but not the details. I think it might have been=20
a limitation elsewhere that I later removed and have now fixed. In
any case hammgen upto 16 seems to work correctly and a quick test
of cyclgen and cyclpoly seperately seem to be ok.=20

However, if you have any specific tests of these three functions,=20
could you try them and see that they now give the right result,
with the code I just checked into the CVS...

Regards
David

Dapr=E8s Quentin Spencer <qsp...@ie...> (le 15/06/2004):
> Here's another bug I found recently:
>=20
> hammgen's documentation claims it can take input arguments M between 3
> and 16, but it actually fails for M>6. This appears to be an
> undocumented limitation in cyclgen. Looking at the source code to
> cyclgen, the ceiling appears to be fixed at 64 bits because a 64-bit
> number is used in the computation. I would love to see someone figure
> out how to support larger sizes than 64 (like up to 65535 as hammgen
> suggests, for example), but I don't have time to figure this out by
> myself. If this isn't fixed before a new release, at least the
> documentation of hammgen should be modified until it is.
>=20
> -Quentin
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> 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] new release?

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

You are right that they need to be instantiated. But cat_ra is an
NDArray thing and so should be in "#ifdef HAVE_ND_ARRAYS ... #endif".
Apart from that it is fine...

I've applied this patch...

Cheers
David

According to Per Persson <per...@ma...> (on 06/16/04):
> 
> 
> >>
> >>I've committed this to the cvs, but unless you have access to the 
> >>developers
> >>site you won't see this change for a few hours. Could you check and 
> >>see
> >>that this fixes all the build problems you are/were having...
> >
> >That problem is gone! Now I see this (seems unrelated...)
> >ld: Undefined symbols:
> >int cat_ra<FixedPoint>(Array<FixedPoint>&, Array<FixedPoint> const&, 
> >int, int, int)
> >int cat_ra<FixedPointComplex>(Array<FixedPointComplex>&, 
> >Array<FixedPointComplex> const&, int, int, int)
> >make: *** [fixed.oct] Error 1
> 
> David,
> I think the following patch fixes the above problem.
> As I understand things, the templates need to be instantiated for the 
> corresponding symbols to be requested by the linker on OS X.
> Beware though that this is Cargo Cult programming, my C++ knowledge is 
> limited. Sanity check is necessary!!!
> 
> /Per
> 
> Index: main/fixed/Array-f.cc
> ===================================================================
> RCS file: /cvsroot/octave/octave-forge/main/fixed/Array-f.cc,v
> retrieving revision 1.2
> diff -u -d -b -w -u -w -r1.2 Array-f.cc
> --- main/fixed/Array-f.cc       26 May 2004 14:18:51 -0000      1.2
> +++ main/fixed/Array-f.cc       15 Jun 2004 21:57:06 -0000
> @@ -43,6 +43,10 @@
>  template class Array<FixedPointComplex>;
>  template class MArray<FixedPointComplex>;
> 
> +template int cat_ra (Array<FixedPoint>& ra, const Array<FixedPoint>& 
> ra_arg, \
> +                    int dim, int idx, int move);
> +template int cat_ra (Array<FixedPointComplex>& ra, const 
> Array<FixedPointComplex>& ra_arg, \
> +                    int dim, int idx, int move);
>  template int assign (Array<FixedPoint>&, const Array<FixedPoint>&);
>  template int assign (Array<FixedPointComplex>&, const 
> Array<FixedPoint>&);
>  template int assign (Array<FixedPointComplex>&,
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> 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] new release?

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

Hummm, another one of my bugs.... Ok, I'll look at it...

Cheers
David

Dapr=E8s Quentin Spencer <qsp...@ie...> (le 15/06/2004):
> Here's another bug I found recently:
>=20
> hammgen's documentation claims it can take input arguments M between 3
> and 16, but it actually fails for M>6. This appears to be an
> undocumented limitation in cyclgen. Looking at the source code to
> cyclgen, the ceiling appears to be fixed at 64 bits because a 64-bit
> number is used in the computation. I would love to see someone figure
> out how to support larger sizes than 64 (like up to 65535 as hammgen
> suggests, for example), but I don't have time to figure this out by
> myself. If this isn't fixed before a new release, at least the
> documentation of hammgen should be modified until it is.
>=20
> -Quentin
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> 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] new release?

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

On Jun 15, 2004, at 00:37, Paul Kienzle wrote:

> I would like make a new octave-forge release.  Please let me
> know when you all are ready.
>

CVS as of today (with my patch for main/fixed/Array-f.cc) builds 
cleanly on OS X 10.3.4 and octave 2.1.57.

"cleanly" == "./configure; make; make check"

FWIW, I can't get octave-forge to build with octave from CVS (today), 
but it's late and I can't look into it now.

/Per

Re: [OctDev] CVS acting up?

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

The only time I see that happen is if I create a new file on
one machine, copy it to another for testing, upload it to the
net, then sync on the old machine.  It doesn't happen that
often.

Maybe with the recent name change of the sourceforge
octave server is causing your problems?

Paul Kienzle
pki...@us...

On Jun 15, 2004, at 7:01 PM, Per Persson wrote:

> Hi,
> quite often I get a lot of garbage when I try to update from CVS.
> Basically, for almost every file I get:
>
> cvs update: move away <foo>; it is in the way
> C <foo>
>
> The only thing I've found to workk is to wipe the old stuff and 
> perform a fresh checkout.
> This is a PITA and I'd really like to know if this is just bad 
> piloting on my part and what to do about it.
>
> /Per
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
> NWMGYKND
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] CVS acting up?

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

Hi,
quite often I get a lot of garbage when I try to update from CVS.
Basically, for almost every file I get:

cvs update: move away <foo>; it is in the way
C <foo>

The only thing I've found to workk is to wipe the old stuff and perform 
a fresh checkout.
This is a PITA and I'd really like to know if this is just bad piloting 
on my part and what to do about it.

/Per

Re: [OctDev] new release?

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

>>
>> I've committed this to the cvs, but unless you have access to the 
>> developers
>> site you won't see this change for a few hours. Could you check and 
>> see
>> that this fixes all the build problems you are/were having...
>
> That problem is gone! Now I see this (seems unrelated...)
> ld: Undefined symbols:
> int cat_ra<FixedPoint>(Array<FixedPoint>&, Array<FixedPoint> const&, 
> int, int, int)
> int cat_ra<FixedPointComplex>(Array<FixedPointComplex>&, 
> Array<FixedPointComplex> const&, int, int, int)
> make: *** [fixed.oct] Error 1

David,
I think the following patch fixes the above problem.
As I understand things, the templates need to be instantiated for the 
corresponding symbols to be requested by the linker on OS X.
Beware though that this is Cargo Cult programming, my C++ knowledge is 
limited. Sanity check is necessary!!!

/Per

Index: main/fixed/Array-f.cc
===================================================================
RCS file: /cvsroot/octave/octave-forge/main/fixed/Array-f.cc,v
retrieving revision 1.2
diff -u -d -b -w -u -w -r1.2 Array-f.cc
--- main/fixed/Array-f.cc       26 May 2004 14:18:51 -0000      1.2
+++ main/fixed/Array-f.cc       15 Jun 2004 21:57:06 -0000
@@ -43,6 +43,10 @@
  template class Array<FixedPointComplex>;
  template class MArray<FixedPointComplex>;

+template int cat_ra (Array<FixedPoint>& ra, const Array<FixedPoint>& 
ra_arg, \
+                    int dim, int idx, int move);
+template int cat_ra (Array<FixedPointComplex>& ra, const 
Array<FixedPointComplex>& ra_arg, \
+                    int dim, int idx, int move);
  template int assign (Array<FixedPoint>&, const Array<FixedPoint>&);
  template int assign (Array<FixedPointComplex>&, const 
Array<FixedPoint>&);
  template int assign (Array<FixedPointComplex>&,

[OctDev] Re: tk_octave

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

Done.

I'm not entirely happy with the soctcl solution because
of the overhead of transferring data around, but it continues
to work well enough that I don't have to fix it.  Oh, well!

- Paul

On Jun 15, 2004, at 2:48 PM, Mark P. Esplin wrote:

> Warning: tk_octave is mostly unsupported.  Probably a better solution 
> is to
> use extra/soctcl from octave-forge.
>
> If you decide to pursue tk_octave, please bear in mind that
> the code is not safe as it is currently written.   Since octave's
> reference counting classes do not use semaphores, there
> is a small window in which a task switch could delete
> an array in octave while tcl wanted to access it.

Re: [OctDev] new release?

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

Here's another bug I found recently:

hammgen's documentation claims it can take input arguments M between 3
and 16, but it actually fails for M>6. This appears to be an
undocumented limitation in cyclgen. Looking at the source code to
cyclgen, the ceiling appears to be fixed at 64 bits because a 64-bit
number is used in the computation. I would love to see someone figure
out how to support larger sizes than 64 (like up to 65535 as hammgen
suggests, for example), but I don't have time to figure this out by
myself. If this isn't fixed before a new release, at least the
documentation of hammgen should be modified until it is.

-Quentin

[OctDev] tk_octave

[Mark P. E. <ma...@sr...>]

Paul,

Could we add something like the following near the top of the extra/tk_octave 
README file?  Most of it is from an email that you sent me.  That way people 
wont be like me and compile octave with pthreads and install  tk_octave only 
to find that it really isn't a very good solution.

                                   -Mark

======================

Warning: tk_octave is mostly unsupported.  Probably a better solution is to 
use extra/soctcl from octave-forge.  

If you decide to pursue tk_octave, please bear in mind that
the code is not safe as it is currently written.   Since octave's
reference counting classes do not use semaphores, there
is a small window in which a task switch could delete
an array in octave while tcl wanted to access it.

Re: [OctDev] new release?

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

I finally got octave-forge to build with qhull support using the patches
John sent to the octave list yesterday. I can't build without the
changes (I'm using Fedora Core 2). I'm surprised this problem hasn't
come up sooner. Are the lines he removed necessary for anyone? This
definitely needs to be fixed before a release, but I'm not very familiar
with the geometry functions, so I would prefer to defer to someone who
is to make these changes.

-Quentin

Re: [OctDev] new release?

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

Dapr=E8s Per Persson <per...@ma...> (le 15/06/2004):
> FWIW, I'm seeing the same thing here:
> fixedCNDArray.cc: In member function `FixedComplexNDArray
>    FixedComplexNDArray::sumsq(int) const':
> fixedCNDArray.cc:638: error: operands to ?: have different types
> make[2]: *** [fixedCNDArray.o] Error 1
> make[1]: *** [fixed/] Error 2
> make: *** [main/] Error 2

Ok, on the assumption that the "pow" function is returning double,=20
and that the "if" statement is basically a costing me speed, I
eliminated both in an attempt to resolve this issue. This is=20
probably the best thing to do in any case. The function "sumsq"
in fixedCNDArray.cc should now read

FixedComplexNDArray
FixedComplexNDArray::sumsq (int dim) const
{
  FixedPointComplex zero;
  MX_ND_REDUCTION (acc +=3D elem (iter_idx) * conj (elem (iter_idx)),
		   retval.elem (iter_idx) =3D acc, zero,=20
		   FixedPointComplex acc =3D zero, FixedComplexNDArray);
}

I've committed this to the cvs, but unless you have access to the develop=
ers
site you won't see this change for a few hours. Could you check and see
that this fixes all the build problems you are/were having...

Cheers
David

--=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] new release?

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

Dapr=E8s Per Persson <per...@ma...> (le 15/06/2004):
> >The only other possible thing in my code was a bug report by Tom
> >G. Smith about the building of fixedCNDArray::sumsq. I can't duplicate
> >his problem, and I can make no sense of why this problem occurs for
> >him, except to think he might have a problem with the install of his
> >compiler.
>=20
> FWIW, I'm seeing the same thing here:
> fixedCNDArray.cc: In member function `FixedComplexNDArray
>    FixedComplexNDArray::sumsq(int) const':
> fixedCNDArray.cc:638: error: operands to ?: have different types
> make[2]: *** [fixedCNDArray.o] Error 1
> make[1]: *** [fixed/] Error 2
> make: *** [main/] Error 2
>=20
> Mac OS X 10.3, GCC 3.3

Damn, so its likely a bug then. What a pain I can't generate it myself.
Time to dig a bit further into the issue...

cheers
David



--=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] new release?

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

On Jun 15, 2004, at 09:56, David Bateman wrote:

> The stuff in the directory main/fixed/examples doesn't build on OS X,
> but as I don't have this OS I can't debug it. It was Per Persson who
> pointed this out, and suggested he might find time to fix it, but as
> he hasn't yet, I just added a test to disable building of this code
> if the canonical_host_type includes the string "darwin".

Thanks!

>
> The only other possible thing in my code was a bug report by Tom
> G. Smith about the building of fixedCNDArray::sumsq. I can't duplicate
> his problem, and I can make no sense of why this problem occurs for
> him, except to think he might have a problem with the install of his
> compiler.

FWIW, I'm seeing the same thing here:
fixedCNDArray.cc: In member function `FixedComplexNDArray
    FixedComplexNDArray::sumsq(int) const':
fixedCNDArray.cc:638: error: operands to ?: have different types
make[2]: *** [fixedCNDArray.o] Error 1
make[1]: *** [fixed/] Error 2
make: *** [main/] Error 2

Mac OS X 10.3, GCC 3.3

/Per
(just now checking octave-forge CVS against octave 2.1.57 and CVS on OS=20=

X...)


> So at this point I can propose no fix. If you really want to
> be on the save side, I can disable the building of the parts of the
> code that caused his problem as it only occurs in the classes for
> fixed point NDArrays. As I haven't integrated this with the rest of
> the code yet, they could only be used from within an oct-file in any
> case. during the lead-up to a release I expect more people will do
> builds of octave-forge and we'll see if other people have the same
> problems as Tom G. Smith and if so we can then think about disabling
> the build..
>
> Cheers
> David
>
> Dapr=E8s Paul Kienzle <pki...@us...> (le =
15/06/2004):
>> I would like make a new octave-forge release.  Please let me
>> know when you all are ready.
>>
>> - Paul
>>
>>