octave-dev — GNU Octave developers' list

Re: [OctDev] Problems with CVS checkout

[Thomas W. <tho...@gm...>]

Hi, 

Am Mittwoch, den 10.05.2006, 11:34 +0200 schrieb Rafael Laboissiere:
> This may help you (from the CVS documentation):
> 
>     7.3 Removing directories
>     ========================
> 
>     [snip] specify the `-P' option to `cvs update' or `cvs checkout',
>     which will cause CVS to remove empty directories from working
>     directories. 

Eh, no. As the directory is still in HEAD, I obviously get it in my CVS
tree. The problem happens with a totally fresh checkout.

	Thomas

Re: [OctDev] Problems with CVS checkout

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

* Thomas Weber <tho...@gm...> [2006-05-09 19:04]:

> after trying to build octave-forge (CVS) with a CVS checkout of Octave,
> I noticed that in my checkout, the FIXES/ directory is still present. I
> thought David deleted it?

This may help you (from the CVS documentation):

    7.3 Removing directories
    ========================

    [snip] specify the `-P' option to `cvs update' or `cvs checkout',
    which will cause CVS to remove empty directories from working
    directories. 


-- 
Rafael

Re: [OctDev] Problems with CVS checkout

[Jorge B. de A. <fic...@so...>]

Dont use anonymous login.
This is disabled in sourceforge.
[]=B4s
Em Tue 09 May 2006 14:04, Thomas Weber escreveu:
> Hi,
>
> after trying to build octave-forge (CVS) with a CVS checkout of Octave,
> I noticed that in my checkout, the FIXES/ directory is still present. I
> thought David deleted it?
>
> Is this a problem with SF or am I doing something wrong?
>
> CVS commit message:
> http://sourceforge.net/mailarchive/forum.php?thread_id=3D10222073&forum_i=
d=3D33
>111
>
> HEAD trunk:
> http://cvs.sourceforge.net/viewcvs.py/octave/octave-forge/FIXES/?only_wit=
h_
>tag=3DHEAD
>
>
>
> Regards
> 	Thomas
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

=2D-=20
Data Estelar 2453865.819329
http://usr.solar.com.br/~ficmatin
Desejo-lhe Paz, Vida Longa e Prosperidade.
S=E3o Bem Vindas Mensagens no Formato Texto Gen=E9rico com Acentos.

[OctDev] Problems with CVS checkout

[Thomas W. <tho...@gm...>]

Hi,  

after trying to build octave-forge (CVS) with a CVS checkout of Octave,
I noticed that in my checkout, the FIXES/ directory is still present. I
thought David deleted it?

Is this a problem with SF or am I doing something wrong?

CVS commit message:
http://sourceforge.net/mailarchive/forum.php?thread_id=10222073&forum_id=33111

HEAD trunk:
http://cvs.sourceforge.net/viewcvs.py/octave/octave-forge/FIXES/?only_with_tag=HEAD



Regards
	Thomas

Re: [OctDev] warn_* built-in variables

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

John W. Eaton wrote:
> On  2-May-2006, David Bateman wrote:
>
> | > The following patch will also adapt Octave Forge to this change and
> | > also removes some old #ifdef cruft.
> | >   
> | Want it applied?
>
> Yes, provided that it is OK to require the latest CVS version of
> Octave to build the latest CVS version Octave Forge.
>   
We are already at that point already pretty much, so I don't see that 
changes much
> | You have to work against the developer CVS with SSH,
>
> OK.
>
> jwe
>   

Re: [OctDev] warn_* built-in variables

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

On  2-May-2006, David Bateman wrote:

| > The following patch will also adapt Octave Forge to this change and
| > also removes some old #ifdef cruft.
| >   
| Want it applied?

Yes, provided that it is OK to require the latest CVS version of
Octave to build the latest CVS version Octave Forge.

| You have to work against the developer CVS with SSH,

OK.

jwe

Re: [OctDev] warn_* built-in variables

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

John W. Eaton wrote:
> I just checked in a largeish change that eliminates all warn_*
> built-in variables.  Here is the NEWS file entry I wrote for this
> change:
>
>   * Previous versions of Octave had a number of built-in variables to
>     control warnings (for example, warn_divide_by_zero).  These
>     variables have been replaced by warning identifiers that are used
>     with the warning function to control the state of warnings.  Now,
>     instead of writing
>
>       warn_divide_by_zero = false;
>
>     to disable divide-by-zero warnings, you should write
>
>       warning ("off", "Octave:divide-by-zero");
>
>     You may use the same technique in your own code to control
>     warnings.  For example, you can use
>
>       warning ("My-package:phase-of-the-moon",
>                "the phase of the moon could cause trouble today");
>
>     to allow users to control this warning using the
>     "My-package:phase-of-the-moon" warning identifier.
>
>     You may also enable or disable all warnings, or turn them into
>     errors:
>
>       warning ("on", "all");
>       warning ("off", "all");
>       warning ("error", "Octave:divide-by-zero");
>       warning ("error", "all");
>
>     You can query the state of current warnings using
>
>       warning ("query", ID)
>       warning ("query")
>
>     (only those warning IDs which have been explicitly set are
>     returned).
>
>     A partial list and description of warning identifiers is available
>     using
>
>       help warning_ids
>
>
> The following patch will also adapt Octave Forge to this change and
> also removes some old #ifdef cruft.
>   
Want it applied?

> BTW, when I updated my copy of Octave Forge, it did not include the
> recent changes I posted to handle changes in the structure of the
> octave_value classes.  Am I missing something?  Should I be using CVS
> HEAD or a branch to get the latest Octave Forge sources that are
> intended to work with the Octave CVS sources?
>   
You have to work against the developer CVS with SSH, as the public CVS 
is not being synchronized to the developer CVS till the new sourceforge 
hardware comes on line.

> Thanks,
>
> jwe
>   

[OctDev] warn_* built-in variables

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

I just checked in a largeish change that eliminates all warn_*
built-in variables.  Here is the NEWS file entry I wrote for this
change:

  * Previous versions of Octave had a number of built-in variables to
    control warnings (for example, warn_divide_by_zero).  These
    variables have been replaced by warning identifiers that are used
    with the warning function to control the state of warnings.  Now,
    instead of writing

      warn_divide_by_zero = false;

    to disable divide-by-zero warnings, you should write

      warning ("off", "Octave:divide-by-zero");

    You may use the same technique in your own code to control
    warnings.  For example, you can use

      warning ("My-package:phase-of-the-moon",
               "the phase of the moon could cause trouble today");

    to allow users to control this warning using the
    "My-package:phase-of-the-moon" warning identifier.

    You may also enable or disable all warnings, or turn them into
    errors:

      warning ("on", "all");
      warning ("off", "all");
      warning ("error", "Octave:divide-by-zero");
      warning ("error", "all");

    You can query the state of current warnings using

      warning ("query", ID)
      warning ("query")

    (only those warning IDs which have been explicitly set are
    returned).

    A partial list and description of warning identifiers is available
    using

      help warning_ids


The following patch will also adapt Octave Forge to this change and
also removes some old #ifdef cruft.

BTW, when I updated my copy of Octave Forge, it did not include the
recent changes I posted to handle changes in the structure of the
octave_value classes.  Am I missing something?  Should I be using CVS
HEAD or a branch to get the latest Octave Forge sources that are
intended to work with the Octave CVS sources?

Thanks,

jwe


Index: main/comm/ov-galois.cc
===================================================================
RCS file: /cvsroot/octave/octave-forge/main/comm/ov-galois.cc,v
retrieving revision 1.13
diff -u -r1.13 ov-galois.cc
--- main/comm/ov-galois.cc	9 Nov 2004 23:34:49 -0000	1.13
+++ main/comm/ov-galois.cc	2 May 2006 19:44:29 -0000
@@ -322,20 +326,13 @@
 {
   double retval = lo_ieee_nan_value ();
 
-  // XXX FIXME XXX -- maybe this should be a function, valid_as_scalar()
-#if defined(HAVE_DO_FORTRAN_INDEXING)
-  if ((rows () == 1 && columns () == 1)
-      || (Vdo_fortran_indexing && rows () > 0 && columns () > 0))
-    retval = (double) gval (0, 0);
-#else
   if (rows () > 0 && columns () > 0)
     {
-      if (Vwarn_fortran_indexing)
-        gripe_implicit_conversion ("real matrix", "real scalar");
+      gripe_implicit_conversion ("Octave:array-as-scalar",
+				 "real matrix", "real scalar");
 
       retval = (double) gval (0, 0);
     }
-#endif
   else
     gripe_invalid_conversion ("galois", "real scalar");
 
@@ -349,19 +346,13 @@
 
   Complex retval (tmp, tmp);
 
-#if defined(HAVE_DO_FORTRAN_INDEXING)
-  if ((rows () == 1 && columns () == 1)
-      || (Vdo_fortran_indexing && rows () > 0 && columns () > 0))
-    retval = (double) gval (0, 0);
-#else
   if (rows () > 0 && columns () > 0)
     {
-      if (Vwarn_fortran_indexing)
-        gripe_implicit_conversion ("real matrix", "real scalar");
+      gripe_implicit_conversion ("Octave:array-as-scalar",
+				 "real matrix", "real scalar");
 
       retval = (double) gval (0, 0);
     }
-#endif
   else
     gripe_invalid_conversion ("galois", "complex scalar");
 
Index: main/fixed/ov-fixed-complex.cc
===================================================================
RCS file: /cvsroot/octave/octave-forge/main/fixed/ov-fixed-complex.cc,v
retrieving revision 1.4
diff -u -r1.4 ov-fixed-complex.cc
--- main/fixed/ov-fixed-complex.cc	9 Nov 2004 23:34:49 -0000	1.4
+++ main/fixed/ov-fixed-complex.cc	2 May 2006 19:44:30 -0000
@@ -73,20 +73,12 @@
 octave_fixed_complex::array_value (bool force_conversion) const
 {
   NDArray retval;
-  int flag = force_conversion;
 
-#if defined(HAVE_OK_TO_LOSE_IMAGINARY_PART)
-  if (! flag)
-    flag = Vok_to_lose_imaginary_part;
-#else
-  if (! flag)
-    flag = (Vwarn_imag_to_real ? -1 : 1);
-#endif
+  if (! force_conversion)
+    gripe_implicit_conversion ("Octave:imag-to-real",
+			       "fixed complex", "matrix");
 
-  if (flag > 0)
-    retval = NDArray (dim_vector (1, 1), real (scalar.fixedpoint ()));
-  else
-    gripe_implicit_conversion ("fixed complex", "matrix");
+  retval = NDArray (dim_vector (1, 1), real (scalar.fixedpoint ()));
 
   return retval;
 }
@@ -247,23 +239,11 @@
 {
   FixedPoint retval;
 
-  int flag = force_conversion;
-
-#if defined(HAVE_OK_TO_LOSE_IMAGINARY_PART)
-  if (! flag)
-    flag = Vok_to_lose_imaginary_part;
-#else
-  if (! flag)
-    flag = (Vwarn_imag_to_real ? -1 : 1);
-#endif
-
-  if (flag < 0)
-    gripe_implicit_conversion ("fixed complex", "fixed scalar");
+  if (! force_conversion)
+    gripe_implicit_conversion ("Octave:imag-to-real",
+			       "fixed complex", "fixed scalar");
 
-  if (flag)
-    retval = FixedPoint(real (scalar));
-  else
-    gripe_invalid_conversion ("fixed complex", "fixed scalar");
+  retval = FixedPoint(real (scalar));
 
   return retval;
 }
@@ -273,20 +253,11 @@
 {
   FixedMatrix retval;
 
-  int flag = force_conversion;
-
-#if defined(HAVE_OK_TO_LOSE_IMAGINARY_PART)
-  if (! flag)
-    flag = Vok_to_lose_imaginary_part;
-#else
-  if (! flag)
-    flag = (Vwarn_imag_to_real ? -1 : 1);
-#endif
-
-  if (flag > 0)
-    retval = FixedMatrix(1,1,real (scalar));
-  else
-    gripe_invalid_conversion ("fixed complex", "fixed matrix");
+  if (! force_conversion)
+    gripe_implicit_conversion ("Octave:imag-to-real",
+			       "fixed complex", "fixed matrix");
+    
+  retval = FixedMatrix(1,1,real (scalar));
 
   return retval;
 }
Index: main/fixed/ov-fixed-cx-mat.cc
===================================================================
RCS file: /cvsroot/octave/octave-forge/main/fixed/ov-fixed-cx-mat.cc,v
retrieving revision 1.5
diff -u -r1.5 ov-fixed-cx-mat.cc
--- main/fixed/ov-fixed-cx-mat.cc	9 Nov 2004 23:34:49 -0000	1.5
+++ main/fixed/ov-fixed-cx-mat.cc	2 May 2006 19:44:30 -0000
@@ -94,29 +94,19 @@
 octave_fixed_complex_matrix::array_value (bool force_conversion) const
 {
   NDArray retval;
-  int flag = force_conversion;
 
-#if defined(HAVE_OK_TO_LOSE_IMAGINARY_PART)
-  if (! flag)
-    flag = Vok_to_lose_imaginary_part;
-#else
-  if (! flag)
-    flag = (Vwarn_imag_to_real ? -1 : 1);
-#endif
+  if (! force_conversion)
+    gripe_implicit_conversion ("Octave:imag-to-real",
+			       "fixed complex", "matrix");
 
-  if (flag > 0)
-    {
-      int nr = rows ();
-      int nc = columns ();
-      dim_vector dv(nr,nc);
-      retval.resize (dv);
-
-      for (int i=0; i<nr; i++)
-	for (int j=0; j<nc; j++)
-	  retval(i + j*nr) = real (matrix(i,j).fixedpoint());
-    }
-  else
-    gripe_implicit_conversion ("fixed complex", "matrix");
+  int nr = rows ();
+  int nc = columns ();
+  dim_vector dv(nr,nc);
+  retval.resize (dv);
+
+  for (int i=0; i<nr; i++)
+    for (int j=0; j<nc; j++)
+      retval(i + j*nr) = real (matrix(i,j).fixedpoint());
 
   return retval;
 }
@@ -349,37 +339,16 @@
 {
   double retval = lo_ieee_nan_value ();
 
-  int flag = force_conversion;
+  if (! force_conversion)
+    gripe_implicit_conversion ("Octave:imag-to-real",
+			       "fixed complex matrix", "real scalar");
 
-#if defined(HAVE_OK_TO_LOSE_IMAGINARY_PART)
-  if (! flag)
-    flag = Vok_to_lose_imaginary_part;
-#else
-  if (! flag)
-    flag = (Vwarn_imag_to_real ? -1 : 1);
-#endif
-
-  if (flag < 0)
-    gripe_implicit_conversion ("fixed complex matrix", "real scalar");
-
-  if (flag)
+  if (rows () > 0 && columns () > 0)
     {
-
-#if defined(HAVE_DO_FORTRAN_INDEXING)
-      if ((rows () == 1 && columns () == 1)
-	  || (Vdo_fortran_indexing && rows () > 0 && columns () > 0))
-	retval = std::real (matrix (0, 0) .fixedpoint());
-#else
-      if (rows () > 0 && columns () > 0)
-	{
-	  if (Vwarn_fortran_indexing)
-	    gripe_implicit_conversion ("real matrix", "real scalar");
+      gripe_implicit_conversion ("Octave:array-as-scalar",
+				 "real matrix", "real scalar");
 	  
-	  retval = std::real (matrix (0, 0) .fixedpoint());
-	}
-#endif
-      else
-	gripe_invalid_conversion ("fixed complex matrix", "real scalar");
+      retval = std::real (matrix (0, 0) .fixedpoint());
     }
   else
     gripe_invalid_conversion ("fixed complex matrix", "real scalar");
@@ -392,36 +361,16 @@
 {
   FixedPoint retval;
 
-  int flag = force_conversion;
-
-#if defined(HAVE_OK_TO_LOSE_IMAGINARY_PART)
-  if (! flag)
-    flag = Vok_to_lose_imaginary_part;
-#else
-  if (! flag)
-    flag = (Vwarn_imag_to_real ? -1 : 1);
-#endif
+  if (! force_conversion)
+    gripe_implicit_conversion ("Octave:imag-to-real",
+			       "fixed complex matrix", "fixed scalar");
 
-  if (flag < 0)
-    gripe_implicit_conversion ("fixed complex matrix", "fixed scalar");
-
-  if (flag)
+  if (rows () > 0 && columns () > 0)
     {
-#if defined(HAVE_DO_FORTRAN_INDEXING)
-      if ((rows () == 1 && columns () == 1)
-	  || (Vdo_fortran_indexing && rows () > 0 && columns () > 0))
-	retval = real( matrix (0, 0));
-#else
-      if (rows () > 0 && columns () > 0)
-	{
-	  if (Vwarn_fortran_indexing)
-	    gripe_implicit_conversion ("real matrix", "real scalar");
-	  
-	  retval = real( matrix (0, 0));
-	}
-#endif
-      else
-	gripe_invalid_conversion ("fixed complex matrix", "fixed scalar");
+      gripe_implicit_conversion ("Octave:array-as-scalar",
+				 "real matrix", "real scalar");
+
+      retval = real( matrix (0, 0));
     }
   else
     gripe_invalid_conversion ("fixed complex matrix", "fixed scalar");
@@ -434,23 +383,12 @@
 {
   Matrix retval;
 
-  int flag = force_conversion;
+  if (! force_conversion)
+    gripe_implicit_conversion ("Octave:imag-to-real",
+			       "fixed complex matrix", "real matrix");
 
-#if defined(HAVE_OK_TO_LOSE_IMAGINARY_PART)
-  if (! flag)
-    flag = Vok_to_lose_imaginary_part;
-#else
-  if (! flag)
-    flag = (Vwarn_imag_to_real ? -1 : 1);
-#endif
 
-  if (flag < 0)
-    gripe_implicit_conversion ("fixed complex matrix", "real matrix");
-
-  if (flag)
-    retval = ::real (matrix.fixedpoint());
-  else
-    gripe_invalid_conversion ("fixed complex matrix", "real matrix");
+  retval = ::real (matrix.fixedpoint());
 
   return retval;
 }
@@ -460,23 +398,11 @@
 {
   FixedMatrix retval;
 
-  int flag = force_conversion;
+  if (! force_conversion)
+    gripe_implicit_conversion ("Octave:imag-to-real",
+			       "fixed complex matrix", "fixed matrix");
 
-#if defined(HAVE_OK_TO_LOSE_IMAGINARY_PART)
-  if (! flag)
-    flag = Vok_to_lose_imaginary_part;
-#else
-  if (! flag)
-    flag = (Vwarn_imag_to_real ? -1 : 1);
-#endif
-
-  if (flag < 0)
-    gripe_implicit_conversion ("fixed complex matrix", "fixed matrix");
-
-  if (flag)
-    retval = real (matrix);
-  else
-    gripe_invalid_conversion ("fixed complex matrix", "fixed matrix");
+  retval = real (matrix);
 
   return retval;
 }
@@ -488,19 +414,13 @@
 
   Complex retval (tmp, tmp);
 
-#if defined(HAVE_DO_FORTRAN_INDEXING)
-      if ((rows () == 1 && columns () == 1)
-	  || (Vdo_fortran_indexing && rows () > 0 && columns () > 0))
-	retval = matrix (0, 0) .fixedpoint();
-#else
-      if (rows () > 0 && columns () > 0)
-	{
-	  if (Vwarn_fortran_indexing)
-	    gripe_implicit_conversion ("real matrix", "real scalar");
+  if (rows () > 0 && columns () > 0)
+    {
+      gripe_implicit_conversion ("Octave:array-as-scalar",
+				 "real matrix", "real scalar");
 	  
-	  retval = matrix (0, 0) .fixedpoint();
-	}
-#endif
+      retval = matrix (0, 0) .fixedpoint();
+    }
   else
     gripe_invalid_conversion ("fixed matrix", "complex scalar");
 
Index: main/fixed/ov-fixed-mat.cc
===================================================================
RCS file: /cvsroot/octave/octave-forge/main/fixed/ov-fixed-mat.cc,v
retrieving revision 1.6
diff -u -r1.6 ov-fixed-mat.cc
--- main/fixed/ov-fixed-mat.cc	9 Nov 2004 23:34:49 -0000	1.6
+++ main/fixed/ov-fixed-mat.cc	2 May 2006 19:44:30 -0000
@@ -309,20 +309,13 @@
 {
   double retval = lo_ieee_nan_value ();
 
-  // XXX FIXME XXX -- maybe this should be a function, valid_as_scalar()
-#if defined(HAVE_DO_FORTRAN_INDEXING)
-  if ((rows () == 1 && columns () == 1)
-      || (Vdo_fortran_indexing && rows () > 0 && columns () > 0))
-    retval = matrix (0, 0) .fixedpoint();
-#else
   if (rows () > 0 && columns () > 0)
     {
-      if (Vwarn_fortran_indexing)
-        gripe_implicit_conversion ("real matrix", "real scalar");
+      gripe_implicit_conversion ("Octave:array-as-scalar",
+				 "real matrix", "real scalar");
 
       retval = matrix (0, 0) .fixedpoint();
     }
-#endif
   else
     gripe_invalid_conversion ("fixed matrix", "real scalar");
 
@@ -349,19 +342,13 @@
 
   Complex retval (tmp, tmp);
 
-#if defined(HAVE_DO_FORTRAN_INDEXING)
-  if ((rows () == 1 && columns () == 1)
-      || (Vdo_fortran_indexing && rows () > 0 && columns () > 0))
-    retval = matrix (0, 0) .fixedpoint();
-#else
   if (rows () > 0 && columns () > 0)
     {
-      if (Vwarn_fortran_indexing)
-        gripe_implicit_conversion ("real matrix", "real scalar");
+      gripe_implicit_conversion ("Octave:array-as-scalar",
+				 "real matrix", "real scalar");
 
       retval = matrix (0, 0) .fixedpoint();
     }
-#endif
   else
     gripe_invalid_conversion ("fixed matrix", "complex scalar");
 

Re: [OctDev] Build problems with gcc 4.1

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

Hi Quentin,
You are right, I didn't test the autoload feature using octlinks. I will 
also change the NCTARGET in CVS accordingly.

Thanks again,
Alex

Quentin Spencer wrote:
> Alexander Barth wrote:
>> Quentin Spencer wrote:
>>> Alexander Barth wrote:
>>>> I downloaded the 2006.03.17 release and I found a bug in the 
>>>> configure.add script. I attached the corrected version which simply 
>>>> replaces the version you have.
>>> Thanks. That seems to fix the configuration problem.
>>>
>>>
>>>> The current CVS version doesn't work with octave-2.9.4-8.fc5. I 
>>>> needed to undo some changes ("Commit changes from JWE for 
>>>> octave_value/octave_base_value changes in 2.9.5+") made by adb014 
>>>> (David Bateman ?) in my local copy to make things work. But I 
>>>> haven't had time to dig in this problem.
>>> It doesn't work with 2.9.5 either. The problem appears to be that 
>>> "which ov-netcdf" does not give the path to ov-netcdf.oct as 
>>> expected. As far as I can tell, this appears to be due to the 
>>> presence of the "-" character, which seems to be confusing the 
>>> octave parser. I don't know if this is intended behavior in octave 
>>> or not, but you could work around it by renaming ov-netcdf.oct to 
>>> ov_netcdf.oct (and making the appriopriate changes to all the other 
>>> things that link to it).
>> Are you packing the CVS version of octave-forge or release 2006.03.17 ?
> I'm using 2006.03.17, with a lot of patches for compatibility with 
> octave 2.9.5.
>
>> On my end, octcdf from release 2006.03.17 compiled from source 
>> actually do work with octave-2.9.4-8.fc5 and octave-2.9.5-2.fc5. In 
>> case you are using the CVS version, you would need the CVS version of 
>> today (2nd May) for octcdf.
>>
>> Concerning the hyphen in ov-netcdf.oct, I can make the change if it 
>> is really necessary, but it  never posed a problem to me. Instead of 
>> "which ov-netcdf" you can type "which netcdf":
>> octave:1> which netcdf
>> netcdf is the dynamically-linked function from the file
>> /home/abarth/Octave/octcdf/netcdf.oct
>>
>> Did you tried to run example_netcdf.m or nctest.m ?
>>
>> In order to verify if ov-netcdf.oct contains undefined symbol, you 
>> can check the linked libraries with:
>> $ ldd ov-netcdf.oct
>>        libnc-dap.so.3 => /usr/lib64/libnc-dap.so.3 (0x00002aaaaabfc000)
>> [...]
>> The ov-netcdf.oct file in octave-forge seems not to be linked against 
>> nc-dap (or netcdf).
>
> With your configure.add patch, there's no problem linking to the 
> libraries. The problem is that with octave 2.9.5 and later, 
> octave-forge no longer creates symbolic links for cases where a 
> DLD_FUNCTION a is found in b.oct. Instead, it uses the autoload 
> function, using syntax something like: autoload("a","b.oct"). (This 
> was done to for the benefit of cygwin, which I understand doesn't deal 
> with symlinks well.) So, when you build octave-forge, instead of 
> symlinking ncatt.oct to ov-netcdf.oct, it does this:
> autoload ("ncatt", which ("ov-netcdf"));
>
> It turns out the problem with this is not the '-' character in 
> ov-netcdf, but the fact that octave apparently can't find ov-netcdf if 
> it does not contain a DLD_FUNCTION ov-netcdf, although I'm sure it 
> probably couldn't given C naming rules. I tried patching the Makefile 
> to name the file ov_netcdf.oct, but that doesn't solve the problem. 
> However, naming it netcdf.oct does, because it contains a function 
> called netcdf.oct. The reason you are not seeing this problem is 
> probably that you are not building all of octave-forge but only 
> octcdf. The Makefile in the octcdf directory does something different 
> in that case--it creates the symbolic links. That still works with 
> octave-2.9.4 and 2.9.5, but it doesn't solve the problem for someone 
> packing all of octave-forge. You can go ahead and send a bug report if 
> you think octave shouldn't do this, but regardless, I was able to get 
> it to work properly with the following patch:
>
>
> Index: main/octcdf/Makefile
> ===================================================================
> RCS file: /cvsroot/octave/octave-forge/main/octcdf/Makefile,v
> retrieving revision 1.6
> diff -u -r1.6 Makefile
> --- main/octcdf/Makefile        19 Apr 2006 19:09:51 -0000      1.6
> +++ main/octcdf/Makefile        28 Apr 2006 17:51:17 -0000
> @@ -34,7 +34,7 @@
>        RM = rm -f
> endif
>
> -NCTARGET = ov-netcdf.oct
> +NCTARGET = netcdf.oct
>
> NCSOURCES = ov-netcdf.cc ov-ncfile.cc ov-ncvar.cc ov-ncatt.cc ov-ncdim.cc
> OBJECTS = $(patsubst %.cc,%.o,$(NCSOURCES))
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>


-- 
_______________________________________________________________

  Alexander Barth

  Ocean Circulation Group
  University of South Florida
  College of Marine Science
  140 Seventh Avenue South 
  St. Petersburg, Florida  33701
  USA

  Phone: +1-727-553-3508     FAX:   +1-727-553-1189

_______________________________________________________________

Re: [OctDev] Build problems with gcc 4.1

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

Alexander Barth wrote:
> Quentin Spencer wrote:
>> Alexander Barth wrote:
>>> I downloaded the 2006.03.17 release and I found a bug in the 
>>> configure.add script. I attached the corrected version which simply 
>>> replaces the version you have.
>> Thanks. That seems to fix the configuration problem.
>>
>>
>>> The current CVS version doesn't work with octave-2.9.4-8.fc5. I 
>>> needed to undo some changes ("Commit changes from JWE for 
>>> octave_value/octave_base_value changes in 2.9.5+") made by adb014 
>>> (David Bateman ?) in my local copy to make things work. But I 
>>> haven't had time to dig in this problem.
>> It doesn't work with 2.9.5 either. The problem appears to be that 
>> "which ov-netcdf" does not give the path to ov-netcdf.oct as 
>> expected. As far as I can tell, this appears to be due to the 
>> presence of the "-" character, which seems to be confusing the octave 
>> parser. I don't know if this is intended behavior in octave or not, 
>> but you could work around it by renaming ov-netcdf.oct to 
>> ov_netcdf.oct (and making the appriopriate changes to all the other 
>> things that link to it).
> Are you packing the CVS version of octave-forge or release 2006.03.17 ?
I'm using 2006.03.17, with a lot of patches for compatibility with 
octave 2.9.5.

> On my end, octcdf from release 2006.03.17 compiled from source 
> actually do work with octave-2.9.4-8.fc5 and octave-2.9.5-2.fc5. In 
> case you are using the CVS version, you would need the CVS version of 
> today (2nd May) for octcdf.
>
> Concerning the hyphen in ov-netcdf.oct, I can make the change if it is 
> really necessary, but it  never posed a problem to me. Instead of 
> "which ov-netcdf" you can type "which netcdf":
> octave:1> which netcdf
> netcdf is the dynamically-linked function from the file
> /home/abarth/Octave/octcdf/netcdf.oct
>
> Did you tried to run example_netcdf.m or nctest.m ?
>
> In order to verify if ov-netcdf.oct contains undefined symbol, you can 
> check the linked libraries with:
> $ ldd ov-netcdf.oct
>        libnc-dap.so.3 => /usr/lib64/libnc-dap.so.3 (0x00002aaaaabfc000)
> [...]
> The ov-netcdf.oct file in octave-forge seems not to be linked against 
> nc-dap (or netcdf).

With your configure.add patch, there's no problem linking to the 
libraries. The problem is that with octave 2.9.5 and later, octave-forge 
no longer creates symbolic links for cases where a DLD_FUNCTION a is 
found in b.oct. Instead, it uses the autoload function, using syntax 
something like: autoload("a","b.oct"). (This was done to for the benefit 
of cygwin, which I understand doesn't deal with symlinks well.) So, when 
you build octave-forge, instead of symlinking ncatt.oct to 
ov-netcdf.oct, it does this:
autoload ("ncatt", which ("ov-netcdf"));

It turns out the problem with this is not the '-' character in 
ov-netcdf, but the fact that octave apparently can't find ov-netcdf if 
it does not contain a DLD_FUNCTION ov-netcdf, although I'm sure it 
probably couldn't given C naming rules. I tried patching the Makefile to 
name the file ov_netcdf.oct, but that doesn't solve the problem. 
However, naming it netcdf.oct does, because it contains a function 
called netcdf.oct. The reason you are not seeing this problem is 
probably that you are not building all of octave-forge but only octcdf. 
The Makefile in the octcdf directory does something different in that 
case--it creates the symbolic links. That still works with octave-2.9.4 
and 2.9.5, but it doesn't solve the problem for someone packing all of 
octave-forge. You can go ahead and send a bug report if you think octave 
shouldn't do this, but regardless, I was able to get it to work properly 
with the following patch:


Index: main/octcdf/Makefile
===================================================================
RCS file: /cvsroot/octave/octave-forge/main/octcdf/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- main/octcdf/Makefile        19 Apr 2006 19:09:51 -0000      1.6
+++ main/octcdf/Makefile        28 Apr 2006 17:51:17 -0000
@@ -34,7 +34,7 @@
        RM = rm -f
 endif

-NCTARGET = ov-netcdf.oct
+NCTARGET = netcdf.oct

 NCSOURCES = ov-netcdf.cc ov-ncfile.cc ov-ncvar.cc ov-ncatt.cc ov-ncdim.cc
 OBJECTS = $(patsubst %.cc,%.o,$(NCSOURCES))

Re: [OctDev] Build problems with gcc 4.1

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

Quentin Spencer wrote:
> Alexander Barth wrote:
>> I downloaded the 2006.03.17 release and I found a bug in the 
>> configure.add script. I attached the corrected version which simply 
>> replaces the version you have.
> Thanks. That seems to fix the configuration problem.
>
>
>> The current CVS version doesn't work with octave-2.9.4-8.fc5. I 
>> needed to undo some changes ("Commit changes from JWE for 
>> octave_value/octave_base_value changes in 2.9.5+") made by adb014 
>> (David Bateman ?) in my local copy to make things work. But I haven't 
>> had time to dig in this problem.
> It doesn't work with 2.9.5 either. The problem appears to be that 
> "which ov-netcdf" does not give the path to ov-netcdf.oct as expected. 
> As far as I can tell, this appears to be due to the presence of the 
> "-" character, which seems to be confusing the octave parser. I don't 
> know if this is intended behavior in octave or not, but you could work 
> around it by renaming ov-netcdf.oct to ov_netcdf.oct (and making the 
> appriopriate changes to all the other things that link to it).
Are you packing the CVS version of octave-forge or release 2006.03.17 ?

On my end, octcdf from release 2006.03.17 compiled from source actually 
do work with octave-2.9.4-8.fc5 and octave-2.9.5-2.fc5. In case you are 
using the CVS version, you would need the CVS version of today (2nd May) 
for octcdf.

Concerning the hyphen in ov-netcdf.oct, I can make the change if it is 
really necessary, but it  never posed a problem to me. Instead of "which 
ov-netcdf" you can type "which netcdf":
octave:1> which netcdf
netcdf is the dynamically-linked function from the file
/home/abarth/Octave/octcdf/netcdf.oct

Did you tried to run example_netcdf.m or nctest.m ?

In order to verify if ov-netcdf.oct contains undefined symbol, you can 
check the linked libraries with:
$ ldd ov-netcdf.oct
        libnc-dap.so.3 => /usr/lib64/libnc-dap.so.3 (0x00002aaaaabfc000)
[...]
The ov-netcdf.oct file in octave-forge seems not to be linked against 
nc-dap (or netcdf).

Thanks and regards,
Alex

>
> -Quentin
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>


-- 
_______________________________________________________________

  Alexander Barth

  Ocean Circulation Group
  University of South Florida
  College of Marine Science
  140 Seventh Avenue South 
  St. Petersburg, Florida  33701
  USA

  Phone: +1-727-553-3508     FAX:   +1-727-553-1189

_______________________________________________________________

[OctDev] Re: problems with OV_REP_TYPE in subsasgn

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

Alexander Barth wrote:

> Hi David,
>
> I have problems getting octcdf working under octave 2.9.5 (Fedora Core
> 5) after the modification you made called "Commit changes from JWE for
> octave_value/octave_base_value changes in 2.9.5+". The crash comes
> from the subsasgn methods. Lines like
>
> retval = octave_value(this, count + 1);
>
> have been replaced by:
>
> #ifdef  OV_REP_TYPE
>  count++;
>  retval = octave_value(this);
> #else
>  retval = octave_value(this, count + 1);
> #endif
>
> and OV_REP_TYPE is indeed defined. The following is a minimal example
> that makes octave crash:
>

Alex,

This patch is from John as I stated in the CVS message and so I'm not
quite sure what he had in mind. However, the way you created the
octave_value return value with the construct

octave_value::octave_value (const octave_value *rep, int count = 1)

can no longer work, as the constructor itself has been deleted. The way
I construct octave_value return values is more like

retval = new octave_ncvar (*this);

So, I'd suggest the attached patch as a possible fix for this, though
all of the optional code should eventually disappear. As I don't have
netcdf installed I can't test this..

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] Patch for awgn.m and further errors with 'make check'

[Thomas W. <tho...@gm...>]

Hi, 

Am Freitag, den 28.04.2006, 18:29 +0200 schrieb David Bateman: 
> This is a buglet certainly, but might need more checking as I'm unsure
> what regexp, etc you are using (the one in octave-forge or in octave)..

That question is not too difficult to anser: the one from Octave. regexp
from octave-forge is not built, due to the following snippet from the
Makefile in main/strings/:

t2.9.5=regexp.oct str2double.m strmatch.m strcmpi.m
DEPRECIATED_TARGETS=$($(word 2, $(sort t$(OCTAVE_VERSION) t2.9.5)))
PROGS=$(DEPRECIATED_TARGETS)

'sort' filters double entries, so for Octave 2.9.5 DEPRECIATED_TARGETS
is empty.

(The Makefile is from the octave-forge release. Quentin has since
cleaned it up, but regexp won't be built neither).

Is this behaviour intentional (i.e. should Octave's regexp be used for
versions >= 2.9.5)?

Anyway, after building regexp.oct manually, the fntests.m part finishes
(though a small warning regarding [main/sparse] might be in order; I
thought the test failed when it justs takes some time (and > 1 GB
memory) to finish).



The 'batch_test.m' of 'make check' however crashes in the
"comms('test')" part; more precisely, the line
	  tmp = rand (n, m)
results in
panic: Segmentation fault -- stopping myself...
admin/run_forge: line 56: 19134 Segmentation fault      (core dumped) $*
make: *** [check] Error 139

According to strace, rand.oct from octave-forge is used. However, my
debugging knowledge is very limited, so if you need more information,
just ask.

Thomas

Re: [OctDev] Patch for awgn.m and further errors with 'make check'

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

Thomas Weber wrote:

>Hi, 
>
>there's a bracket missing in awgn.m. Strangely enough, 
>	make check 
>fails with Octave 2.9.5 without it.
>
>But even with it, it fails with the following error:
>=======================================================================
>extra/testfun [tests 3 of 7 files]
>warning: warning: setting state with structure not implemented
>warning: warning: setting state with structure not implemented
>error: regexp: missing terminating ] for character class at position 57
>of expression
>error: evaluating argument list element number 1
>error: if: error evaluating conditional expression
>error: evaluating if command near line 628, column 11
>error: evaluating if command near line 604, column 7
>error: evaluating if command near line 491, column 5
>error: evaluating for command near line 461, column 3
>error: called from `test' in file
>`/tmp/octave-forge-2006.03.17/extra/testfun/test.m'
>error: near line 373 of file `fntests.m'
>
>make: *** [check] Error 1
>=======================================================================
>
>This means it fails with 
>	[p,n] = test('extra/testfun/assert.m','quiet',fid);
>
>However, if I start Octave myself and run the tests in assert.m,
>everything works. In case it's important, I have compiled both Octave
>and Octave-Forge with pcre support.
>
>	Thomas
>  
>

This is a buglet certainly, but might need more checking as I'm unsure
what regexp, etc you are using (the one in octave-forge or in octave)..

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] problems with OV_REP_TYPE in subsasgn

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

Hi David,

I have problems getting octcdf working under octave 2.9.5 (Fedora Core 
5) after the modification you made called "Commit changes from JWE for 
octave_value/octave_base_value changes in 2.9.5+". The crash comes from 
the subsasgn methods. Lines like

retval = octave_value(this, count + 1);

have been replaced by:

#ifdef  OV_REP_TYPE
  count++;
  retval = octave_value(this);
#else
  retval = octave_value(this, count + 1);
#endif

and OV_REP_TYPE is indeed defined. The following is a minimal example 
that makes octave crash:

octave:1> nc = netcdf('test.nc','c');
octave:2> nc('dim') = 10;
octave:3> whos nc
panic: Segmentation fault -- stopping myself...

Below is the output of gdb, in case it is helpful. If I undo the changes 
in all subsasgn methods octcdf works fine. Can you explain me the reason 
why you changed the return value in the subsasgn function?

Thanks,
Alex


$ gdb /usr/bin/octave core.18388
(gdb) where
#0  0x0000003d0512f765 in raise () from /lib64/libc.so.6
#1  0x0000003d05131050 in abort () from /lib64/libc.so.6
#2  0x00002aaaaadf1f4e in install_signal_handlers () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#3  <signal handler called>
#4  0x0000000000000000 in ?? ()
#5  0x00002aaaaacea5c0 in write_header () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#6  0x00002aaaaacedb3c in dump_octave_core () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#7  0x00002aaaaadf1f28 in install_signal_handlers () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#8  <signal handler called>
#9  0x0000000001773730 in ?? ()
#10 0x00002aaaaae11520 in symbol_table::parse_whos_line_format () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#11 0x00002aaaaae13f1b in symbol_table::maybe_list () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#12 0x00002aaaaae4180b in Fdocument () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#13 0x00002aaaaae45a16 in Fwhos () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#14 0x00002aaaaaf14846 in octave_builtin::do_multi_index_op () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#15 0x00002aaaaaf1415d in octave_builtin::subsref () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#16 0x00002aaaaaed3c88 in octave_value::subsref () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#17 0x00002aaaab001fca in tree_index_expression::rvalue () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#18 0x00002aaaab01df6d in tree_statement::eval () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#19 0x00002aaaab01e637 in tree_statement_list::eval () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#20 0x00002aaaaae25355 in main_loop () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#21 0x00002aaaaada8099 in octave_main () from 
/usr/lib64/octave-2.9.5/liboctinterp.so
#22 0x0000003d0511d084 in __libc_start_main () from /lib64/libc.so.6
#23 0x0000000000400759 in _start ()
#24 0x00007ffffffbcc78 in ?? ()
#25 0x0000000000000000 in ?? ()




-- 
_______________________________________________________________

  Alexander Barth

  Ocean Circulation Group
  University of South Florida
  College of Marine Science
  140 Seventh Avenue South 
  St. Petersburg, Florida  33701
  USA

  Phone: +1-727-553-3508     FAX:   +1-727-553-1189

_______________________________________________________________

[OctDev] Patch for awgn.m and further errors with 'make check'

[Thomas W. <tho...@gm...>]

Hi, 

there's a bracket missing in awgn.m. Strangely enough, 
	make check 
fails with Octave 2.9.5 without it.

But even with it, it fails with the following error:
=======================================================================
extra/testfun [tests 3 of 7 files]
warning: warning: setting state with structure not implemented
warning: warning: setting state with structure not implemented
error: regexp: missing terminating ] for character class at position 57
of expression
error: evaluating argument list element number 1
error: if: error evaluating conditional expression
error: evaluating if command near line 628, column 11
error: evaluating if command near line 604, column 7
error: evaluating if command near line 491, column 5
error: evaluating for command near line 461, column 3
error: called from `test' in file
`/tmp/octave-forge-2006.03.17/extra/testfun/test.m'
error: near line 373 of file `fntests.m'

make: *** [check] Error 1
=======================================================================

This means it fails with 
	[p,n] = test('extra/testfun/assert.m','quiet',fid);

However, if I start Octave myself and run the tests in assert.m,
everything works. In case it's important, I have compiled both Octave
and Octave-Forge with pcre support.

	Thomas

Re: [OctDev] Build problems with gcc 4.1

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

Alexander Barth wrote:
> I downloaded the 2006.03.17 release and I found a bug in the 
> configure.add script. I attached the corrected version which simply 
> replaces the version you have.
Thanks. That seems to fix the configuration problem.


> The current CVS version doesn't work with octave-2.9.4-8.fc5. I needed 
> to undo some changes ("Commit changes from JWE for 
> octave_value/octave_base_value changes in 2.9.5+") made by adb014 
> (David Bateman ?) in my local copy to make things work. But I haven't 
> had time to dig in this problem.
It doesn't work with 2.9.5 either. The problem appears to be that "which 
ov-netcdf" does not give the path to ov-netcdf.oct as expected. As far 
as I can tell, this appears to be due to the presence of the "-" 
character, which seems to be confusing the octave parser. I don't know 
if this is intended behavior in octave or not, but you could work around 
it by renaming ov-netcdf.oct to ov_netcdf.oct (and making the 
appriopriate changes to all the other things that link to it).

-Quentin

Re: [OctDev] make check fails with Octave 2.9.5 and octave-forge 2005.06.13 due to galois fields

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

Thomas Weber wrote:

>Hi, 
>
>isequal in Octave 2.9.5 can't handle galois fields, therefore 
>	comms('test')
>fails:
>
>octave:2> poly1 = gf([2,4,5,1],3);
>octave:3> isequal(poly1, poly1)
>error: find: wrong type argument `galois'
>error: evaluating assignment expression near line 139, column 11
>error: evaluating if command near line 136, column 5
>error: evaluating if command near line 52, column 3
>error: called from `__isequal__' in file
>`/usr/share/octave/2.9.5/m/general/__isequal__.m'
>error: evaluating assignment expression near line 28, column 12
>error: evaluating if command near line 27, column 3
>error: called from `isequal' in file
>`/usr/share/octave/2.9.5/m/general/isequal.m'
>
>Regards
>	Thomas
>
>  
>
Ok, I don't see a simple way of adapting __isequal__.m to work with
galois fields in a generic way. The fix will be to add an overload
function for isequal for galois fields and use dispatch to map it to
isequal. I add the attached function to octave-forge in the main/comms
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] make check fails with Octave 2.9.5 and octave-forge 2005.06.13 due to galois fields

[Thomas W. <tho...@gm...>]

Hi, 

isequal in Octave 2.9.5 can't handle galois fields, therefore 
	comms('test')
fails:

octave:2> poly1 = gf([2,4,5,1],3);
octave:3> isequal(poly1, poly1)
error: find: wrong type argument `galois'
error: evaluating assignment expression near line 139, column 11
error: evaluating if command near line 136, column 5
error: evaluating if command near line 52, column 3
error: called from `__isequal__' in file
`/usr/share/octave/2.9.5/m/general/__isequal__.m'
error: evaluating assignment expression near line 28, column 12
error: evaluating if command near line 27, column 3
error: called from `isequal' in file
`/usr/share/octave/2.9.5/m/general/isequal.m'

Regards
	Thomas

Re: [OctDev] Build problems with gcc 4.1

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

Hi Quentin,

I downloaded the 2006.03.17 release and I found a bug in the 
configure.add script. I attached the corrected version which simply 
replaces the version you have. For a built of octcdf with NetCDF, I did 
the following steps:

$ which ncdap-config
/usr/bin/which: no ncdap-config in ( ... )       # good
$ autogen.sh; CPPFLAGS=-I/usr/include/netcdf-3 
LDFLAGS=-L/usr/lib64/netcdf-3 ./configure
[...]
checking for nc-dap... no
checking for nc_open in -lnetcdf... yes
checking netcdf.h usability... yes
checking netcdf.h presence... yes
[...]
$ cd main/octcdf/
$ make
$ for i in *octlink; do ln -s ov-netcdf.oct  ${i%link}; done    # You 
have probably a better way of doing links instead of octlink files
$ octave -f
octave:1> nctest
writing test output to nctest.log
 >>>>> /home/abarth/Download/octave-forge-2006.03.17/main/octcdf/nctest.m
PASSES 17 out of 17 tests


But since OpenDAP supersedes the functionality of NetCDF, I think an 
OpenDAP built would be more useful.

$ ncdap-config --libs
-L/usr/lib64 -lnc-dap  -L/usr/lib64 -ldap  -L/usr/lib64 -lcurl 
-L/usr/kerberos/lib64 -lssl -lcrypto -ldl -lz -lgssapi_krb5 -lkrb5 
-lk5crypto -lkrb5support -lcom_err -lresolv -lidn -lssl -lcrypto -lz 
-lxml2 -lz -lm -lpthread           # good
$ autogen.sh; ./configure
[...]
checking for nc-dap... yes
[...]
$ cd main/octcdf/
$ make
$ for i in *octlink; do ln -s ov-netcdf.oct  ${i%link}; done
$ octave -f
octave:1> nctest
writing test output to nctest.log
 >>>>> /home/abarth/Download/octave-forge-2006.03.17/main/octcdf/nctest.m
PASSES 17 out of 17 tests

You probably don't need the information in all those details and you 
have your own way of doing the build. The current CVS version doesn't 
work with octave-2.9.4-8.fc5. I needed to undo some changes ("Commit 
changes from JWE for octave_value/octave_base_value changes in 2.9.5+") 
made by adb014 (David Bateman ?) in my local copy to make things work. 
But I haven't had time to dig in this problem.

Thanks,
Cheers
Alex


Quentin Spencer wrote:
> Alexander Barth wrote:
>
>> Hi Quentin,
>>
>> I'm glad to see that my octcdf toolbox is included in the Fedora Core 
>> 5 octave-forge package.
>> However, it seems that the package is not linked against the nc-dap 
>> library. Any call to the toolbox stops octave with a message like:
>>
>> octave:1> example_netcdf
>> octave: symbol lookup error: 
>> /usr/libexec/octave/site/oct/api-v17/x86_64-unknown-linux-gnu/octave-forge/ov-netcdf.oct: 
>> undefined symbol: nc_create
>>
>> Since the nc-dap library is included in FC5, I guess that this is not 
>> too difficult to fix. The configure script 
>> (main/octcdf/configure.add) should detect the the location of the 
>> nc-dap libraries using the ncdap-config script included in 
>> libnc-dap-devel.
>>
>> Alternatively, octcdf can be linked against the NetCDF library, but 
>> this would reduce its functionality since only local files can be 
>> accessed with the NetCDF library. With nc-dap, local files and data 
>> sets on a OpenDAP server can be imported in octave.
>
>
> I didn't know about nc-dap. It's currently linking to netcdf (at least 
> it finds netcdf when I run configure), but apparently there's still 
> something wrong. I've noticed you've made quite a lot of updates to 
> CVS. Do I need current CDF, or will the last release (2006.03.17) 
> work? Does nc-dap replace or supplement netcdf? I tried running 
> configure with libnc-dap-devel instaled, and it looked like it was 
> still looking for netcdf.
>
> -Quentin
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>


-- 
_______________________________________________________________

  Alexander Barth

  Ocean Circulation Group
  University of South Florida
  College of Marine Science
  140 Seventh Avenue South 
  St. Petersburg, Florida  33701
  USA

  Phone: +1-727-553-3508     FAX:   +1-727-553-1189

_______________________________________________________________

Re: [OctDev] Build problems with gcc 4.1

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

Alexander Barth wrote:

> Hi Quentin,
>
> I'm glad to see that my octcdf toolbox is included in the Fedora Core 
> 5 octave-forge package.
> However, it seems that the package is not linked against the nc-dap 
> library. Any call to the toolbox stops octave with a message like:
>
> octave:1> example_netcdf
> octave: symbol lookup error: 
> /usr/libexec/octave/site/oct/api-v17/x86_64-unknown-linux-gnu/octave-forge/ov-netcdf.oct: 
> undefined symbol: nc_create
>
> Since the nc-dap library is included in FC5, I guess that this is not 
> too difficult to fix. The configure script (main/octcdf/configure.add) 
> should detect the the location of the nc-dap libraries using the 
> ncdap-config script included in libnc-dap-devel.
>
> Alternatively, octcdf can be linked against the NetCDF library, but 
> this would reduce its functionality since only local files can be 
> accessed with the NetCDF library. With nc-dap, local files and data 
> sets on a OpenDAP server can be imported in octave.


I didn't know about nc-dap. It's currently linking to netcdf (at least 
it finds netcdf when I run configure), but apparently there's still 
something wrong. I've noticed you've made quite a lot of updates to CVS. 
Do I need current CDF, or will the last release (2006.03.17) work? Does 
nc-dap replace or supplement netcdf? I tried running configure with 
libnc-dap-devel instaled, and it looked like it was still looking for 
netcdf.

-Quentin

Re: [OctDev] Build problems with gcc 4.1

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

Hi Quentin,

I'm glad to see that my octcdf toolbox is included in the Fedora Core 5 
octave-forge package.
However, it seems that the package is not linked against the nc-dap 
library. Any call to the toolbox stops octave with a message like:

octave:1> example_netcdf
octave: symbol lookup error: 
/usr/libexec/octave/site/oct/api-v17/x86_64-unknown-linux-gnu/octave-forge/ov-netcdf.oct: 
undefined symbol: nc_create

Since the nc-dap library is included in FC5, I guess that this is not 
too difficult to fix. The configure script (main/octcdf/configure.add) 
should detect the the location of the nc-dap libraries using the 
ncdap-config script included in libnc-dap-devel.

Alternatively, octcdf can be linked against the NetCDF library, but this 
would reduce its functionality since only local files can be accessed 
with the NetCDF library. With nc-dap, local files and data sets on a 
OpenDAP server can be imported in octave.

Thanks and regards
Alex

Quentin Spencer wrote:
> I'm in the process of trying to get octave-forge to build with 2.9.4 
> for the upcoming Fedora Core 5, which will be using gcc 4.1. I finally 
> got everything patched so it will build on Fedora Core 4 (gcc 4.0), 
> but on the FC5 test release with gcc, it still fails. It appears that 
> there are quite a lot of errors in the fixed point code, but I haven't 
> had time to try debugging it. This is likely because gcc 4.1 is more 
> strict in enforcing C++ standards. Anyway, I thought I'd send out a 
> notice about this in case someone feels like figuring out what needs 
> to be fixed in the fixed point code.
>
> -Quentin
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>


-- 
_______________________________________________________________

  Alexander Barth

  Ocean Circulation Group
  University of South Florida
  College of Marine Science
  140 Seventh Avenue South 
  St. Petersburg, Florida  33701
  USA

  Phone: +1-727-553-3508     FAX:   +1-727-553-1189

_______________________________________________________________

Re: [OctDev] change to subversion

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

I think that I've voiced this opinion every time that it has come up, but=
=20
I definitely prefer svn.

Bill

On Mon, 24 Apr 2006, Stefan van der Walt wrote:

> Thanks, David.
>
> Has anyone else got an opinion on this?  Please speak up!
>
> St=E9fan
>
> On Mon, Apr 24, 2006 at 03:53:14PM +0200, David Bateman wrote:
>> Can we still use cvs on the public side? I don't imagine it is possible
>> to do so on the developers side. Are all the developers happy to convert
>> to SVN? If there are no objections I'll do it Stefan..
>>
>> D.
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

--=20
"I don't need time. What I need is a deadline."  -- Duke Ellington

Re: [OctDev] change to subversion

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

Thanks, David.

Has anyone else got an opinion on this?  Please speak up!

Stéfan

On Mon, Apr 24, 2006 at 03:53:14PM +0200, David Bateman wrote:
> Can we still use cvs on the public side? I don't imagine it is possible
> to do so on the developers side. Are all the developers happy to convert
> to SVN? If there are no objections I'll do it Stefan..
> 
> D.

Re: [OctDev] change to subversion

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

Can we still use cvs on the public side? I don't imagine it is possible
to do so on the developers side. Are all the developers happy to convert
to SVN? If there are no objections I'll do it Stefan..

D.


Stefan van der Walt wrote:

>On Sun, Apr 02, 2006 at 11:24:15AM +0200, Stefan van der Walt wrote:
> =20
>
>>Is anyone else interested in moving over to subversion?  Sourceforge
>>provides detailed documentation at
>>
>>http://sourceforge.net/docs/E09/
>>   =20
>>
>
>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/PROJEC=
TNAME).
>   4. Click on the 'Admin' link.
>   5. Click on the 'Subversion' admin page link.
>   6. Click on the 'migrate' link on the 'Migration Instructions' sectio=
n 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
>
>
>-------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security=
?
>Get stuff done quickly with pre-integrated technology to make your job e=
asier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geroni=
mo
>http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642
>_______________________________________________
>Octave-dev mailing list
>Oct...@li...
>https://lists.sourceforge.net/lists/listinfo/octave-dev
> =20
>


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

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

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