octave-dev — GNU Octave developers' list

[OctDev] segfault reading netcdf file

[Muhali <mu...@us...>]

With the current octave tip and the most recent octcdf package the following
program generates a segfault. My system is Ubuntu 12.04 x86_64. debug output
is attached.

--------
pkg load octcdf
ncfile =
"http://ensemblesrt3.dmi.dk/cgi-bin/nph-dods/data/ERA40/METNO/25km/DM/METNOHIRHAM_CTR_ERA40_DM_25km_1971-1980_huss.nc.gz"
nc = netcdf(ncfile, "r") ;
x = nc{"huss"}(:) ;
--------


Program received signal SIGSEGV, Segmentation fault.
buildcachenode34 (nccomm=0xd72820, constraint=0x75d130, varlist=0xe91b50,
cachep=0x7fffffffc8b8, isprefetch=0) at cache.c:231
231		    cache->cachesize -= node->xdrsize;
(gdb) where
#0  buildcachenode34 (nccomm=0xd72820, constraint=0x75d130,
varlist=0xe91b50, cachep=0x7fffffffc8b8, isprefetch=0) at cache.c:231
#1  0x00007fffea516304 in nc3d_getvarx (ncid=<optimized out>, varid=4,
startp=<optimized out>, countp=<optimized out>, stridep=<optimized out>,
data=0x7fffc8d4a010, dsttype0=5)
    at getvara3.c:192
#2  0x00007fffea4e7596 in NC_get_vars (ncid=65536, varid=8, start=0xe91f30,
edges=0xe91f60, stride=0xe91f90, value=<optimized out>, memtype=5) at
var.c:762
#3  0x00007fffea4ed00c in nc_get_vars_float (ncid=65536, varid=8,
start=0xe91f30, edges=0xe91f60, stride=0xe91f90, value=0x7fffc8d4a010) at
var.c:2446
#4  0x00007fffea803458 in ov_nc_get_vars (ncid=65536, varid=8, ranges=...,
nctype=5) at ov-netcdf.cc:774
#5  0x00007fffea80ae1a in octave_ncvar::subsref (this=0x75d050, type=...,
idx=...) at ov-ncvar.cc:366
#6  0x00007ffff745dd5b in subsref (idx=..., type=..., this=<optimized out>)
at ./octave-value/ov.h:397
#7  octave_value::next_subsref (this=0x7fffffffd3f0, type=..., idx=...,
skip=1) at octave-value/ov.cc:1290
#8  0x00007fffea80620b in octave_ncfile::subsref (this=0xd56020, type=...,
idx=...) at ov-ncfile.cc:374
#9  0x00007ffff7457a2e in octave_value::subsref (this=<optimized out>,
type=..., idx=..., nargout=<optimized out>) at octave-value/ov.cc:1264
#10 0x00007ffff7457a85 in octave_value::subsref (this=<optimized out>,
type=..., idx=..., nargout=<optimized out>, lvalue_list=<optimized out>) at
octave-value/ov.cc:1277
#11 0x00007ffff74c219d in tree_index_expression::rvalue (this=0xc90520,
nargout=1, lvalue_list=0x0) at parse-tree/pt-idx.cc:414
#12 0x00007ffff74c292b in tree_index_expression::rvalue (this=<optimized
out>, nargout=<optimized out>) at parse-tree/pt-idx.cc:284
#13 0x00007ffff74bee14 in tree_index_expression::rvalue1 (this=0xc90520,
nargout=1) at parse-tree/pt-idx.cc:425
#14 0x00007ffff74aa502 in tree_simple_assignment::rvalue1 (this=0x770c20) at
parse-tree/pt-assign.cc:211
#15 0x00007ffff74b7ad3 in tree_evaluator::visit_statement (this=<optimized
out>, stmt=...) at parse-tree/pt-eval.cc:747
#16 0x00007ffff74b73f1 in visit_statement_list (lst=...,
this=0x7ffff7dd3958) at parse-tree/pt-eval.cc:797
#17 tree_evaluator::visit_statement_list (this=0x7ffff7dd3958, lst=...) at
parse-tree/pt-eval.cc:778
#18 0x00007ffff744e4cd in octave_user_script::do_multi_index_op
(this=0xca9b60, nargout=<optimized out>, args=...) at
octave-value/ov-usr-fcn.cc:141
#19 0x00007ffff74f8486 in source_file (file_name=..., context=...,
verbose=false, require_file=true, warn_for=...) at oct-parse.yy:4019
#20 0x00007ffff74f88b0 in Fsource (args=...) at oct-parse.yy:4126
#21 0x00007ffff73b3529 in octave_builtin::do_multi_index_op (this=0x67e2a0,
nargout=0, args=..., lvalue_list=0x0) at octave-value/ov-builtin.cc:131
#22 0x00007ffff73b2305 in octave_builtin::subsref (this=0x67e2a0, type=...,
idx=..., nargout=0, lvalue_list=0x0) at octave-value/ov-builtin.cc:64
#23 0x00007ffff73b2ffc in octave_builtin::subsref (this=<optimized out>,
type=..., idx=..., nargout=<optimized out>) at octave-value/ov-builtin.cc:47
#24 0x00007ffff7457a18 in octave_value::subsref (this=<optimized out>,
type=..., idx=..., nargout=<optimized out>) at octave-value/ov.cc:1266
#25 0x00007ffff7457a85 in octave_value::subsref (this=<optimized out>,
type=..., idx=..., nargout=<optimized out>, lvalue_list=<optimized out>) at
octave-value/ov.cc:1277
#26 0x00007ffff74c219d in tree_index_expression::rvalue (this=0x75f2a0,
nargout=0, lvalue_list=0x0) at parse-tree/pt-idx.cc:414
#27 0x00007ffff74c292b in tree_index_expression::rvalue (this=<optimized
out>, nargout=<optimized out>) at parse-tree/pt-idx.cc:284
#28 0x00007ffff74bee14 in tree_index_expression::rvalue1 (this=0x75f2a0,
nargout=0) at parse-tree/pt-idx.cc:425
#29 0x00007ffff74b7ad3 in tree_evaluator::visit_statement (this=<optimized
out>, stmt=...) at parse-tree/pt-eval.cc:747
#30 0x00007ffff74b73f1 in visit_statement_list (lst=...,
this=0x7ffff7dd3958) at parse-tree/pt-eval.cc:797
#31 tree_evaluator::visit_statement_list (this=0x7ffff7dd3958, lst=...) at
parse-tree/pt-eval.cc:778
#32 0x00007ffff77bb1f7 in main_loop () at interpfcn/toplev.cc:595
#33 0x00007ffff70c2305 in octave_execute_interpreter () at octave.cc:1021
#34 0x00007ffff677f76d in __libc_start_main (main=0x4007b0 <main(int,
char**)>, argc=1, ubp_av=0x7fffffffe9c8, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffffffe9b8) at libc-start.c:226
#35 0x0000000000400831 in _start ()




--
View this message in context: http://octave.1599824.n4.nabble.com/segfault-reading-netcdf-file-tp4646843.html
Sent from the Octave - Dev mailing list archive at Nabble.com.

[OctDev] bug in csape (part of package splines)

[Ted R. <ted...@gm...>]

csape(x, y, "cond") with a boundary condition of "periodic" will work  
for a one dimensional vector, but not for a matrix value for y. This  
is fixed by changing line 162 in csape.m from:

   c(2:n,idx) = z(:,2:end) - z(:,1) * fact;

to:

   c(2:n,:) = z(:,2:end) - z(:,1) * fact;

Re: [OctDev] complex error function

[Daniel J S. <dan...@ie...>]

On 11/20/2012 07:43 PM, Nir Krakauer wrote:
> Can the contributed functions be given names that don't conflict with
> the current Octave ones, like erf_complex? That way there should be no
> problem with putting them either in specfun or as their own Octave
> package.

That's an alternative.  Yet it might be desired to have complex error 
function family of functions:

octave-cli:3> erfc(complex(1,pi))
error: erfc: not defined for complex scalar

Will this code work for that?

If Steven's code were released as a mini C library that could be 
accessed easily and had some compile switches to use internal square 
root, sinc, etc. functions or external, that might address Jordi's 
concern about maintaining the code.

Dan

Re: [OctDev] complex error function

[Nir K. <nkr...@cc...>]

Can the contributed functions be given names that don't conflict with
the current Octave ones, like erf_complex? That way there should be no
problem with putting them either in specfun or as their own Octave
package.

Re: [OctDev] complex error function

[Michael D. G. <mic...@gm...>]

Also keep in mind that this will need to be compatible with
the Matlab complex erf(z).

Re: [OctDev] complex error function

[Daniel J S. <dan...@ie...>]

Hi Steven,

Some comments below with regards to Jordi's observations on integration.


On 11/20/2012 03:33 PM, Jordi Gutiérrez Hermoso wrote:
> On 4 November 2012 00:34, Steven G. Johnson<st...@al...>  wrote:
>> There is an updated version of my package
>> (http://ab-initio.mit.edu/Faddeeva) which computes not only the Faddeeva
>> function (the scaled complex error function) but also the ordinary erf
>> and erfc functions of complex arguments, as well as the erfcx and erfi
>> variants and the Dawson function (a scaled erfi).
>>
>> This should make it relatively painless to drop it in as a replacement
>> for the Octave erf and erfc functions in order to support complex arguments.
>
> I'm still not sure what to do with this code... It sounds useful,
> sure, but you didn't write it for Octave except for a small wrapper.
> Since you're trying to overwrite Octave functions, it should go in
> Octave core but you also want to provide a bunch of other special
> functions, so those should go in the specfun package in OF.

How much of this is the Faddeeva function and how much of it is 
supporting code?  One concern I would have, just looking at the code for 
a few minutes, is all the repetitive routines for square root, sinc, 
etc.  I would think the preference should be to utilize such algorithms 
from Octave's core or utilize the library that Octave is using.  That 
way things remain consistent.

The issue for integration is then what hunks to integrate and how.  The 
package can certainly remain in the current form.

For reference, the current erf and erfc appear to come from the standard 
math library:

# gl_COMMON_DOUBLE_MATHFUNC(FUNC)
# -------------------------------
# tests whether the function FUNC is available in libc or libm.
# It sets FUNC_LIBM to empty or "-lm" accordingly.
# FUNC must be one of the following functions, that are present on all 
systems
# and provided by libm on all systems except Mac OS X, BeOS, Haiku:
#   acos asin atan atan2 cbrt cos cosh erf erfc exp fmod hypot j0 j1 jn 
lgamma
#   log log10 log1p pow remainder sin sinh sqrt tan tanh y0 y1 yn


> I'm also not sure how committed you are to maintaining this code for
> Octave. If this is a one-time code dump and it's up to us to maintain
> this code in the future, I'm less inclined to accept it into Octave
> core, since it's a relatively rare request. I have never heard of our
> users clamouring for the Faddeeva function or its relatives.

Certainly error function and complimentary error function find general 
use, but Faddeeva function seems like something particular to wave 
theory or Fourier analysis.  Whether that belongs in the special 
functions category or a wave-theory (or similar) package, I don't know.

This has an MIT license, correct?  Is that compatible with GPL?  From my 
brief browsing of the code, it does seem to be original and reference 
up-to-date papers on the algorithm and its limitations.

It seems to me the first question is whether to replace erf/erfc in the 
core source with something that handles complex inputs.  I'm not sure 
Faddeeva function on its own warrants core code.  But there might be a 
better way to put Faddeeva function in a package, script code being one 
possibility if that turns out to not be too slow.

Dan

Re: [OctDev] complex error function

[Jordi G. H. <jo...@oc...>]

On 4 November 2012 00:34, Steven G. Johnson <st...@al...> wrote:
> There is an updated version of my package
> (http://ab-initio.mit.edu/Faddeeva) which computes not only the Faddeeva
> function (the scaled complex error function) but also the ordinary erf
> and erfc functions of complex arguments, as well as the erfcx and erfi
> variants and the Dawson function (a scaled erfi).
>
> This should make it relatively painless to drop it in as a replacement
> for the Octave erf and erfc functions in order to support complex arguments.

I'm still not sure what to do with this code... It sounds useful,
sure, but you didn't write it for Octave except for a small wrapper.
Since you're trying to overwrite Octave functions, it should go in
Octave core but you also want to provide a bunch of other special
functions, so those should go in the specfun package in OF.

I'm also not sure how committed you are to maintaining this code for
Octave. If this is a one-time code dump and it's up to us to maintain
this code in the future, I'm less inclined to accept it into Octave
core, since it's a relatively rare request. I have never heard of our
users clamouring for the Faddeeva function or its relatives.

What do you think, how committed are you feeling?

- Jordi G. H.

[OctDev] cgi 0.1.0 released

[Carnë D. <car...@gm...>]

Hi everyone

a new package cgi has been released, version 0.1.0, by Alexander Barth.
Enjoy Octave responsibly.

Carnë

Re: [OctDev] ncread (octcdf) strange

[Muhali <mu...@us...>]

Alexander Barth-3 wrote
> ncread from matlab adopted a different ordering convention than octcdf

thanks. A hint in the ncread help text is probably helpful.

M.



--
View this message in context: http://octave.1599824.n4.nabble.com/ncread-octcdf-strange-tp4646809p4646818.html
Sent from the Octave - Dev mailing list archive at Nabble.com.

[OctDev] Common Gatway Interface (CGI) for Octave

[Alexander B. <bar...@gm...>]

Hi
Here is a new package with a Common Gatway Interface (CGI) for Octave.

svn checkout svn://svn.code.sf.net/p/octave/code/trunk/octave-forge/extra/cgi
cgi

Some documentation is available here:
http://modb.oce.ulg.ac.be/mediawiki/index.php/CGI_programming_with_Octave

The code and the html-doc are uploaded in the package-release forum.

md5sums

cb7c54c543cd318bc44a44738802ae2a  cgi-0.1.0.tar.gz
3893097ae20ef796d29d9e54e6287b08  cgi-html.tar.gz

Best regards,
Alex

Re: [OctDev] ncread (octcdf) strange

[Alexander B. <bar...@gm...>]

On Tue, Nov 20, 2012 at 1:16 PM, Muhali <mu...@us...> wrote:
> Adapting example_opendap.m as follows
>
> ----
> pkg load octcdf
> nc = netcdf(ncfile='http://hycom.coaps.fsu.edu/thredds/dodsC/atl_ops','r');
> N=size(nc{'ssh'})
> ssh = ncread(ncfile, 'ssh', [1 1 1], [1 1 N(3)])
> ----
>
> I get
>
> N =
>
>     730   1609   1678
>
> error: Error while retrieving variable: NetCDF: Index exceeds dimension
> bound.
> error: called from:
> error:   /usr/local/octave-dev/share/octave/packages/octcdf-1.1.5/ncread.m
> at line 51, column 3
> error:   foo.m at line 5, column 5
>
> The 4th argument of ncread is the 'count' vector, so it should be able read
> N(3) variables. Or am I missing something?
>
>
ncread from matlab adopted a different ordering convention than octcdf
(which follows the original matlab toolbox from USGS). The order of
dimensions are reversed. For example octcdf would report a file as
time,lat,lon while ncread lon,lat,time. It is better not to mix ncread
which direct calls to octcdf (it ends up to be confusing). If you want
to use ncread and need to know the size of a variable, it is better to
use ncinfo:

>> vinfo = ncinfo('http://hycom.coaps.fsu.edu/thredds/dodsC/atl_ops','ssh');
>> vinfo.Size
ans =

   1678   1609    730

Cheers,
Alex

[OctDev] ncread (octcdf) strange

[Muhali <mu...@us...>]

Adapting example_opendap.m as follows

----
pkg load octcdf
nc = netcdf(ncfile='http://hycom.coaps.fsu.edu/thredds/dodsC/atl_ops','r');
N=size(nc{'ssh'})
ssh = ncread(ncfile, 'ssh', [1 1 1], [1 1 N(3)])
----

I get

N =

    730   1609   1678

error: Error while retrieving variable: NetCDF: Index exceeds dimension
bound.
error: called from:
error:   /usr/local/octave-dev/share/octave/packages/octcdf-1.1.5/ncread.m
at line 51, column 3
error:   foo.m at line 5, column 5

The 4th argument of ncread is the 'count' vector, so it should be able read
N(3) variables. Or am I missing something? 



--
View this message in context: http://octave.1599824.n4.nabble.com/ncread-octcdf-strange-tp4646809.html
Sent from the Octave - Dev mailing list archive at Nabble.com.

[OctDev] ncread (octcdf) strange

[Muhali <mu...@us...>]

Adapting example_opendap.m as follows

----
pkg load octcdf
nc = netcdf(ncfile='http://hycom.coaps.fsu.edu/thredds/dodsC/atl_ops','r');
N=size(nc{'ssh'})
ssh = ncread(ncfile, 'ssh', [1 1 1], [1 1 N(3)])
----

I get 

N =

    730   1609   1678

error: Error while retrieving variable: NetCDF: Index exceeds dimension
bound.
error: called from:
error:   /usr/local/octave-dev/share/octave/packages/octcdf-1.1.5/ncread.m
at line 51, column 3
error:   foo.m at line 5, column 5

The 4th argument of ncread is the 'count' vector, so it should be able read
N(3) variables. Or am I missing something?



--
View this message in context: http://octave.1599824.n4.nabble.com/ncread-octcdf-strange-tp4646807.html
Sent from the Octave - Dev mailing list archive at Nabble.com.

Re: [OctDev] Octave-3.6.4-rc0 Mingw gcc4.7.2 panics

[nitnit <ni...@gm...>]

Jordi Gutiérrez Hermoso-2 wrote
> Not from scratch! Have you seen jwe's recent post to the maintainers'
> list about MXE?

Yes I have seen that, but currently I do not have any linux machine to try
it.

I wonder whether cross-compiling may be done by cygwin where the target is
mingw. I have used that technique to cross compile openblas on cygwin for
mingw (recent version now supports mingw directly).

For now, I have found (on octaveforge svn) Benjamin Lindner scripts for
mingw octave-3.2.4 and all respective dependencies and I will use that as a
starting point.





--
View this message in context: http://octave.1599824.n4.nabble.com/Octave-3-6-4-rc0-Mingw-gcc4-7-2-panics-tp4646723p4646747.html
Sent from the Octave - Dev mailing list archive at Nabble.com.

Re: [OctDev] Octave-3.6.4-rc0 Mingw gcc4.7.2 panics

[Jordi G. H. <jo...@oc...>]

On 16 November 2012 14:11, nitnit <ni...@gm...> wrote:
> I will have to rebuild all libs but since I do not have any scripts and/or
> envoronment settings (it has all been done by Tatsuro) I will have to start
> from scratch and that will take time.
>

Not from scratch! Have you seen jwe's recent post to the maintainers'
list about MXE?

- Jordi G. H.

Re: [OctDev] Octave-3.6.4-rc0 Mingw gcc4.7.2 panics

[nitnit <ni...@gm...>]

Michael Goffioul wrote
> For the record, such problems are easily triggered. Consider a piece of
> fortran code, compiled with 4.6.x, making a call to EXP with a complex
> number. This is translated by gcc/gfortran into a call to cexp, which is
> provided by libgcc, hence 4.7.x. This function returns a double complex
> structure (> 8 bytes), so the fortran code and libgcc will use different
> calling conventions, leading to stack corruption.

You are probably right, I have recompiled arpack, eigs.cc passed but now
qr.cc it panics !

I will have to rebuild all libs but since I do not have any scripts and/or
envoronment settings (it has all been done by Tatsuro) I will have to start
from scratch and that will take time.

Philipe, I will report and share everything when I will get some better
results.

Nitzan



--
View this message in context: http://octave.1599824.n4.nabble.com/Octave-3-6-4-rc0-Mingw-gcc4-7-2-panics-tp4646723p4646733.html
Sent from the Octave - Dev mailing list archive at Nabble.com.

Re: [OctDev] [Pkg-octave-devel] [RFU] octave-image 2.0.0-1

[Carnë D. <car...@gm...>]

On 12 November 2012 21:21, Jordi Gutiérrez Hermoso <jo...@oc...> wrote:
> OF list: fftconv2's vector-vector-matrix three-arg call seems
> incorrect and seems to have been incorrect for some time. Can anyone
> please confirm? These two calls should both be equal:
>
>     octave:1> conv2(1:3, 1:2, [1 2; 3 4; 5 6])
>     ans =
>
>         1    4    4
>         5   18   16
>        14   48   40
>        19   62   48
>        15   48   36
>
>     octave:2> fftconv2(1:3, 1:2, [1 2; 3 4; 5 6])
>     ans =
>
>         1    4    7    6
>         5   18   31   24
>        11   36   61   42
>        10   32   54   36
>
>
> The upper result is correct. You can nobtain this result with
> fftconv2(fftconv2([1 2; 3 4; 5 6,1:2),1:3), so I think this should be
> fairly easy to fix.

You can't. Your alternative gives a syntax error, I believe you meant
what I tried below which still does not give the same result. See:

octave> conv2(1:3, 1:2, [1 2; 3 4; 5 6])
ans =

    1    4    4
    5   18   16
   14   48   40
   19   62   48
   15   48   36

octave> fftconv2(fftconv2([1 2; 3 4; 5 6], 1:2), 1:3)
ans =

    1    6   15   20   12
    3   16   37   46   24
    5   26   59   72   36

Carnë

Re: [OctDev] error: __getlegenddata__

[Surandokht N. <sur...@gm...>]

Thanks, I do try them.

On 12-11-16 6:52 PM, "Daniel J Sebald" <dan...@ie...> wrote:

>On 11/16/2012 11:10 AM, Surandokht Nikzad wrote:
>> Hi there;
>>
>>
>> I think there is bug/error while I am plotting:
>>
>> error: __getlegenddata__: subscript indices must be either positive
>> integers or logicals
>> error: called from:
>> error:
>> 
>>/Applications/Octave.app/Contents/Resources/share/octave/3.4.0/m/plot/pri
>>vate/__getlegenddata__.m
>> at line 38, column 11
>> error:
>> 
>>/Applications/Octave.app/Contents/Resources/share/octave/3.4.0/m/plot/pri
>>vate/__plt__.m
>> at line 57, column 23
>> error:
>> 
>>/Applications/Octave.app/Contents/Resources/share/octave/3.4.0/m/plot/plo
>>t.m
>> at line 194, column 9
>>
>> Here is the script:
>>
>> a=[];
>>
>> [files]=dir('*.txt');
>>
>> for i=1:length(files)
>>
>> a=vertcat(a,dlmread(files(i).name,'',1,0));
>>
>> end;
>>
>>
>> d=0.01;
>>
>> doc_ef=a(:,2);
>>
>> run_doc=0:d:20;
>>
>> dens_est_doc_ef=kernel_dens(ones(size(run_doc)),doc_ef+5,run_doc);
>>
>> plot(run_doc,dens_est_doc_ef,'color',[0.9100 0.4100
>>0.1700],'linewidth',2);
>>
>> xlabel('a',"fontsize",16);
>>
>> ylabel('b',"fontsize",16);
>>
>> a=legend('{\fontsize{16} screen}','{\fontsize{16} screen}');
>>
>> text(10,0.5,'No_o_b_s screen=101',"fontsize",12)
>>
>> grid on
>>
>>
>> I have to use this again to dauble plotting in one graph.
>> The fist time use of this script is fine. No error.
>> However, when I use for the second time for the second data set, I do
>> have the above error!
>>
>> Is there any way to solve this problem?
>
>It's difficult to debug such a thing.  Developers typically work with
>the development version or the most recent stable release.  To go back
>to 3.4 is a bit of guess work without re-installing that version and
>rebuilding.  But often these things get fixed along the way so to go
>back to 3.4 without knowledge the bug still exists in the development
>version is repeating work.
>
>Also, try to isolate the problem to as parsimonious code as possible so
>that others may reproduce on their setups.  We don't know what data
>files you are using, and kernel_dens is not a routine in the standard
>Octave package.  If it were code I could easily run here I could try
>this on Octave 3.6+ series and tell you whether that works.
>
>As for specific error in your case, I don't know what the legend code is
>doing with subscripts.  Maybe the underscore '_' in your variables is
>confusing the code.  Try removing the underscores in the variables, or
>maybe change the translation setting of "latex" on or off.  It's hard to
>say.
>
>Dan
>
>
>>
>> Your help and advice greatly appreciated.
>> Sue
>>
>>
>>
>> 
>>-------------------------------------------------------------------------
>>-----
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>>
>>
>>
>> _______________________________________________
>> Octave-dev mailing list
>> Oct...@li...
>> https://lists.sourceforge.net/lists/listinfo/octave-dev
>
>-- 
>
>Dan Sebald
>email: daniel(DOT)sebald(AT)ieee(DOT)org
>URL: http://www(DOT)dansebald(DOT)com

Re: [OctDev] error: __getlegenddata__

[Daniel J S. <dan...@ie...>]

On 11/16/2012 11:10 AM, Surandokht Nikzad wrote:
> Hi there;
>
>
> I think there is bug/error while I am plotting:
>
> error: __getlegenddata__: subscript indices must be either positive
> integers or logicals
> error: called from:
> error:
> /Applications/Octave.app/Contents/Resources/share/octave/3.4.0/m/plot/private/__getlegenddata__.m
> at line 38, column 11
> error:
> /Applications/Octave.app/Contents/Resources/share/octave/3.4.0/m/plot/private/__plt__.m
> at line 57, column 23
> error:
> /Applications/Octave.app/Contents/Resources/share/octave/3.4.0/m/plot/plot.m
> at line 194, column 9
>
> Here is the script:
>
> a=[];
>
> [files]=dir('*.txt');
>
> for i=1:length(files)
>
> a=vertcat(a,dlmread(files(i).name,'',1,0));
>
> end;
>
>
> d=0.01;
>
> doc_ef=a(:,2);
>
> run_doc=0:d:20;
>
> dens_est_doc_ef=kernel_dens(ones(size(run_doc)),doc_ef+5,run_doc);
>
> plot(run_doc,dens_est_doc_ef,'color',[0.9100 0.4100 0.1700],'linewidth',2);
>
> xlabel('a',"fontsize",16);
>
> ylabel('b',"fontsize",16);
>
> a=legend('{\fontsize{16} screen}','{\fontsize{16} screen}');
>
> text(10,0.5,'No_o_b_s screen=101',"fontsize",12)
>
> grid on
>
>
> I have to use this again to dauble plotting in one graph.
> The fist time use of this script is fine. No error.
> However, when I use for the second time for the second data set, I do
> have the above error!
>
> Is there any way to solve this problem?

It's difficult to debug such a thing.  Developers typically work with 
the development version or the most recent stable release.  To go back 
to 3.4 is a bit of guess work without re-installing that version and 
rebuilding.  But often these things get fixed along the way so to go 
back to 3.4 without knowledge the bug still exists in the development 
version is repeating work.

Also, try to isolate the problem to as parsimonious code as possible so 
that others may reproduce on their setups.  We don't know what data 
files you are using, and kernel_dens is not a routine in the standard 
Octave package.  If it were code I could easily run here I could try 
this on Octave 3.6+ series and tell you whether that works.

As for specific error in your case, I don't know what the legend code is 
doing with subscripts.  Maybe the underscore '_' in your variables is 
confusing the code.  Try removing the underscores in the variables, or 
maybe change the translation setting of "latex" on or off.  It's hard to 
say.

Dan


>
> Your help and advice greatly appreciated.
> Sue
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
>
>
>
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

[OctDev] error: __getlegenddata__

[Surandokht N. <sur...@gm...>]

Hi there;


I think there is  bug/error while I am plotting:

error: __getlegenddata__: subscript indices must be either positive integers
or logicals
error: called from:
error:   
/Applications/Octave.app/Contents/Resources/share/octave/3.4.0/m/plot/privat
e/__getlegenddata__.m at line 38, column 11
error:   
/Applications/Octave.app/Contents/Resources/share/octave/3.4.0/m/plot/privat
e/__plt__.m at line 57, column 23
error:   
/Applications/Octave.app/Contents/Resources/share/octave/3.4.0/m/plot/plot.m
at line 194, column 9

Here is the script:
a=[];

[files]=dir('*.txt');

for i=1:length(files)

a=vertcat(a,dlmread(files(i).name,'',1,0));

 

 end; 



d=0.01;

doc_ef=a(:,2);

run_doc=0:d:20;

dens_est_doc_ef=kernel_dens(ones(size(run_doc)),doc_ef+5,run_doc);

plot(run_doc,dens_est_doc_ef,'color',[0.9100    0.4100
0.1700],'linewidth',2);

xlabel('a',"fontsize",16);

ylabel('b',"fontsize",16);

a=legend('{\fontsize{16} screen}','{\fontsize{16} screen}');

 text(10,0.5,'No_o_b_s screen=101',"fontsize",12)

grid on


I have to use this again to dauble plotting  in one graph.
The fist time use of this script is fine. No error.
However, when I use for the second time for the second data set, I do have
the above error!

Is there any way to solve this problem?

Your help and advice greatly appreciated.
Sue

Re: [OctDev] Octave-3.6.4-rc0 Mingw gcc4.7.2 panics

[Michael G. <mic...@gm...>]

On Fri, Nov 16, 2012 at 11:52 AM, Philip Nienhuis <pr....@hc...>wrote:

> nitnit wrote:
> > Hello all,
> >
> > I have tried to re-build Octave-3.6.4-rc0 with an updated mingw/msys
> > environment (recent repository with gcc-4.7.2).
> >
> > I have used Tatsuros libraries which have been built with gcc-4.6.2.
> >
> > I had to rebuild lapack and reference blas in order for the configure
> script
> > to succeed. All other libs are those which have been pre-compiled by
> Tatsuro
> > with gcc-4.6.2.
> >
> > I could build octave successfully but with make -check, I am getting a
> seg.
> > fault in eigs.cc:
> >
> >    ...
> >    src\DLD-FUNCTIONS\dot.cc ............................... PASS    3/3
> >    src\DLD-FUNCTIONS\eig.cc ............................... PASS   20/20
> >    src\DLD-FUNCTIONS\eigs.cc ..............................panic:
> > Segmentation violation -- stopping myself...
> > make[1]: [check] Error 3 (ignored)
> > make[1]: Leaving directory `/c/OctaveB/octave-3.6.4-rc0/test'
> >
> > Any ideas about cab cause it ?
>
> In principle I'd agree with Michael's suggestion to rebuild ALL deps
> with gcc 4.7.2. Who knows what other hidden problems pop up with a mixed
> build chain. In this respect the various BLAS<->arch segfaults come to
> mind.
>

For the record, such problems are easily triggered. Consider a piece of
fortran code, compiled with 4.6.x, making a call to EXP with a complex
number. This is translated by gcc/gfortran into a call to cexp, which is
provided by libgcc, hence 4.7.x. This function returns a double complex
structure (> 8 bytes), so the fortran code and libgcc will use different
calling conventions, leading to stack corruption.

Michael.

Re: [OctDev] Octave-3.6.4-rc0 Mingw gcc4.7.2 panics

[Philip N. <pr....@hc...>]

nitnit wrote:
> Hello all,
>
> I have tried to re-build Octave-3.6.4-rc0 with an updated mingw/msys
> environment (recent repository with gcc-4.7.2).
>
> I have used Tatsuros libraries which have been built with gcc-4.6.2.
>
> I had to rebuild lapack and reference blas in order for the configure script
> to succeed. All other libs are those which have been pre-compiled by Tatsuro
> with gcc-4.6.2.
>
> I could build octave successfully but with make -check, I am getting a seg.
> fault in eigs.cc:
>
>    ...
>    src\DLD-FUNCTIONS\dot.cc ............................... PASS    3/3
>    src\DLD-FUNCTIONS\eig.cc ............................... PASS   20/20
>    src\DLD-FUNCTIONS\eigs.cc ..............................panic:
> Segmentation violation -- stopping myself...
> make[1]: [check] Error 3 (ignored)
> make[1]: Leaving directory `/c/OctaveB/octave-3.6.4-rc0/test'
>
> Any ideas about cab cause it ?

In principle I'd agree with Michael's suggestion to rebuild ALL deps 
with gcc 4.7.2. Who knows what other hidden problems pop up with a mixed 
build chain. In this respect the various BLAS<->arch segfaults come to mind.

But it's also true that arpack is a particularly sensitive beast, on 
Linux as well, so I'd first try to build just that and try again.

On a related note, would you share your build stuff? I'd also like to 
switch to 4.7.x but had no time yet (and I wanted to rebuild all 
dependencies anyway. I'd also like to have a first go at building a 64 
bit Win version). Sharing the burden of rebuilding all can save both of 
us time.

Philip

Re: [OctDev] Octave-3.6.4-rc0 Mingw gcc4.7.2 panics

[Michael G. <mic...@gm...>]

On Fri, Nov 16, 2012 at 9:52 AM, nitnit <ni...@gm...> wrote:

> Hello all,
>
> I have tried to re-build Octave-3.6.4-rc0 with an updated mingw/msys
> environment (recent repository with gcc-4.7.2).
>
> I have used Tatsuros libraries which have been built with gcc-4.6.2.
>
> I had to rebuild lapack and reference blas in order for the configure
> script
> to succeed. All other libs are those which have been pre-compiled by
> Tatsuro
> with gcc-4.6.2.
>
> I could build octave successfully but with make -check, I am getting a seg.
> fault in eigs.cc:
>
>   ...
>   src\DLD-FUNCTIONS\dot.cc ............................... PASS    3/3
>   src\DLD-FUNCTIONS\eig.cc ............................... PASS   20/20
>   src\DLD-FUNCTIONS\eigs.cc ..............................panic:
> Segmentation violation -- stopping myself...
> make[1]: [check] Error 3 (ignored)
> make[1]: Leaving directory `/c/OctaveB/octave-3.6.4-rc0/test'
>
> Any ideas about cab cause it ?
>


There are differences in default calling conventions between 4.6.x and
4.7.x versions under Windows. The 4.7.x calling conventions is more
compatible with MSVC (in fine, this is to be compatible with MSVC-compiled
DLL's). For instance, one of the change is about who's popping up the
hidden pointer from the stack when returning an aggregate object larger
than 8 bytes.

So I'd definitely recompile everything with the same compiler.

Michael.

Re: [OctDev] Octave-3.6.4-rc0 Mingw gcc4.7.2 panics

[Jordi G. H. <jo...@oc...>]

On 16 November 2012 09:52, nitnit <ni...@gm...> wrote:
> Hello all,
>
> I have tried to re-build Octave-3.6.4-rc0 with an updated mingw/msys
> environment (recent repository with gcc-4.7.2).
>
> I have used Tatsuros libraries which have been built with gcc-4.6.2.
>
> I had to rebuild lapack and reference blas in order for the configure script
> to succeed. All other libs are those which have been pre-compiled by Tatsuro
> with gcc-4.6.2.
>
> I could build octave successfully but with make -check, I am getting a seg.
> fault in eigs.cc:
>
>   ...
>   src\DLD-FUNCTIONS\dot.cc ............................... PASS    3/3
>   src\DLD-FUNCTIONS\eig.cc ............................... PASS   20/20
>   src\DLD-FUNCTIONS\eigs.cc ..............................panic:
> Segmentation violation -- stopping myself...
> make[1]: [check] Error 3 (ignored)
> make[1]: Leaving directory `/c/OctaveB/octave-3.6.4-rc0/test'
>
> Any ideas about cab cause it ?

Possible problem with Arpack. Can you get a stack trace?

- Jordi G. H.

[OctDev] Octave-3.6.4-rc0 Mingw gcc4.7.2 panics

[nitnit <ni...@gm...>]

Hello all,

I have tried to re-build Octave-3.6.4-rc0 with an updated mingw/msys
environment (recent repository with gcc-4.7.2).

I have used Tatsuros libraries which have been built with gcc-4.6.2.

I had to rebuild lapack and reference blas in order for the configure script
to succeed. All other libs are those which have been pre-compiled by Tatsuro
with gcc-4.6.2.

I could build octave successfully but with make -check, I am getting a seg.
fault in eigs.cc:

  ...
  src\DLD-FUNCTIONS\dot.cc ............................... PASS    3/3
  src\DLD-FUNCTIONS\eig.cc ............................... PASS   20/20
  src\DLD-FUNCTIONS\eigs.cc ..............................panic:
Segmentation violation -- stopping myself...
make[1]: [check] Error 3 (ignored)
make[1]: Leaving directory `/c/OctaveB/octave-3.6.4-rc0/test'

Any ideas about cab cause it ?

Nitzan



--
View this message in context: http://octave.1599824.n4.nabble.com/Octave-3-6-4-rc0-Mingw-gcc4-7-2-panics-tp4646723.html
Sent from the Octave - Dev mailing list archive at Nabble.com.