New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue 587 projected ticks #1144

Merged
merged 28 commits into from Mar 18, 2015

Conversation

Projects
None yet
3 participants
@doutriaux1
Member

doutriaux1 commented Mar 12, 2015

@williams13 @aashish24 @chaosphere2112 I think this should go in for the rlease. It's better than what's in master.

BUT: polar projection have ticks drawn behind data. @dlonie can't look at it until later, but it souldn't be a show stopper.

Also I didn't run ctst, but for sure ALL projection tests will fail because a new baseline is needed for projected plots. @chaosphere2112 or @aashish24 can generate the new baseline.

doutriaux1 added some commits Mar 9, 2015

after various tries
decided to simply add sub-point to line objects when projected so that it follows curves nicely
box1 works, need to make sure ticks do the same as well
getting closer
but polar still not drawing ticks correctly
had to increase resolution to find actual range
in fitToViewport for polar poj
ok renderers are reused correctly
no more many pass in the long loop for proj
self._renderers[(None,None,None)]=ren
else:
ren = self._renderers[(None,None,None)]
#if not (None,None,None) in self._renderers.keys():

This comment has been minimized.

@allisonvacanti

allisonvacanti Mar 12, 2015

Contributor

Is there a reason to save this?

if geo.GetDestinationProjection().GetName() in ["aeqd",]:
## These need more precision to compute actual range
Npts=250.
print "Yes doing the long one"

This comment has been minimized.

@allisonvacanti

allisonvacanti Mar 12, 2015

Contributor

Do we need this in master?

This comment has been minimized.

@doutriaux1

doutriaux1 Mar 16, 2015

Member

absolutely! 😜

#if not (None,None,None) in self._renderers.keys():
ren = self.createRenderer()
self.renWin.AddRenderer(ren)
self.setLayer(ren,1)

This comment has been minimized.

@allisonvacanti

allisonvacanti Mar 12, 2015

Contributor

It looks like this will have no effect, as the same call is made a few lines later with tt.priority for the layer. Which is correct?

This comment has been minimized.

@doutriaux1

doutriaux1 Mar 16, 2015

Member

yes we can take this one out, it's left-over from debugging stages.

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Mar 12, 2015

Re "I didn't run ctest", please run ctest locally before making a pull request. It makes things a lot easier and faster if you test and fix issues before review.

Also, please use a tool like git gui to prepare commits. It will let you omit lines that don't need to be in master (like print statements, commented code, etc) from the commits and break up large sets of changes into standalone changes with helpful commit messages, which is invaluable when searching through the history or trying to figure out why a change was made.

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 16, 2015

@dlonie I didn't run ctest because I was out sick and I didn't have time. I knew it would fail and I was merely mentioning it to let you guys know it needs a new baseline which I didn't have time to generate last week (i.e. run 'ctest' to generate the new pngs)

doutriaux1 added some commits Mar 16, 2015

renderer layer was being constantly reset
thanks to @dlonie for pointing us in the right direction
fix #1143
priority was set on Renderer after the fitToViewport which was causing Renderers' layer to be reset to possibily too high/low priorities.
now different renderers are created if they have  different priorities
@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 16, 2015

@dlonie ok it "works" the first time I build. Subsequent calls to the script do not draw the isofill anymore...
It's sort of random... WIll try a full rebuild of everything to be sure but can you please take a look at what is out there right now? Thanks

doutriaux1 added some commits Mar 16, 2015

too many layers seemed to be the issue
having up to 200 calls to plot per priority seems to be enough
ok removed print statements, but the number of layers wasn't the issue
I still randomly get no data displayed, less frequently but still happens...
ok got only switching text way for projections
all non-projected baselines seems to be good again
@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Mar 17, 2015

I'm back in today -- where is this branch at?

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Mar 17, 2015

nvm -- I see the email now.

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Mar 17, 2015

@doutriaux1 I've updated #1143 with some more info. I can't do much more at this point, as I'm not sure what this code is trying to do, but this seems to be the point of failure.

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 17, 2015

@aashish24 @dlonie I replied there. I guess VTK needs to figure out why the geo transfromreturns different values with the same inputs.... It is super worrisome... Anyhow I have a (slower) work around for now. Will push it through soon, thanks for pin-pointing the error.

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Mar 17, 2015

Have you tried using numbers smaller than +/- 100,000,000,000,000,000,000? I have a feeling that may be giving the PROJ4 backend fits.

fixed random blank of screen
I had a leftover setNumberOfPoints(1) and then using InsertNextPoint, hence I had one extra point with
random memory bits in it
also moved pts=vtk.vtkPoints() out of the nested loop
@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 17, 2015

@dlonie turns out I had a left over pt.SetNumberOfPoints(1) a few lines above, but now i the new code I switch to use InsertNextPoint that left us with 1 extra points which was probably filled with memory garbage hence the randomness.

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 17, 2015

@dlonie we are very very close... BUT no cigar.... @aashish24 please help as well...
it works "sometimes" now, look at what's in the branch right now I left the debug statements in it
notice same number of points, same rges, different output... (on a working example)
now the follwoing ctest will seg fault in geoTransform
debug statements:

BEFORE HAND: 62500 (-180.0, 178.55999755859375, -90.0, 89.27999877929688, 0.0, 0.0)
AFTER: (-19921780.0, 19921780.0, -19923352.0, 19923352.0, 0.0, 0.0)
BEFORE HAND: 62500 (-180.0, 178.55999755859375, -90.0, 89.27999877929688, 0.0, 0.0)
AFTER: (-4.932692785686428e+32, 5.848660986321e+35, -4.9326865959862316e+32, 5.8486071111704905e+35, -4.932708259936919e+32, 5.8486292950559945e+35)

bad ctest:

vcs_test_basic_isoline_-3_proj_SH

which when run as follow:

gdb --args /lgm/uvcdat/2015-03-16/bin/python "/git/uvcdat/testing/vcs/test_vcs_basic_gms.py" "--gm_type=isoline" "--projection=-3" "--lat1=-90" "--lat2=0" "--source=/home/doutriaux1/build/uvcdat-testdata/baselines/vcs/test_vcs_basic_isoline_-3_proj_SH.png"
/git/uvcdat/Packages/vcs
running install
running build
running build_py
running install_lib
running install_data
running install_egg_info
Removing /lgm/uvcdat/2015-03-16/lib/python2.7/site-packages/vcs-2.1.0_676_gf22a375-py2.7.egg-info
Writing /lgm/uvcdat/2015-03-16/lib/python2.7/site-packages/vcs-2.1.0_676_gf22a375-py2.7.egg-info
GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /lgm/uvcdat/2015-03-16/bin/python...done.
(gdb) 

gives out:

(gdb) r
Starting program: /lgm/uvcdat/2015-03-16/bin/python /git/uvcdat/testing/vcs/test_vcs_basic_gms.py --gm_type=isoline --projection=-3 --lat1=-90 --lat2=0 --source=/home/doutriaux1/build/uvcdat-testdata/baselines/vcs/test_vcs_basic_isoline_-3_proj_SH.png
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
_int_malloc (av=0x7ffff77a9760 <main_arena>, bytes=750000) at malloc.c:3775
3775    malloc.c: No such file or directory.
(gdb) bt
#0  _int_malloc (av=0x7ffff77a9760 <main_arena>, bytes=750000) at malloc.c:3775
#1  0x00007ffff746e760 in __GI___libc_malloc (bytes=750000) at malloc.c:2891
#2  0x00007fffefb751d7 in vtkDataArrayTemplate<float>::Allocate (this=0x14ca710, sz=187500) at /home/doutriaux1/build/build/VTK/Common/Core/vtkDataArrayTemplate.txx:137
#3  0x00007fffefb77e56 in vtkDataArrayTemplate<float>::SetNumberOfValues (this=0x14ca710, number=187500)
    at /home/doutriaux1/build/build/VTK/Common/Core/vtkDataArrayTemplate.txx:921
#4  0x00007fffefb75474 in vtkDataArrayTemplate<float>::SetNumberOfTuples (this=0x14ca710, number=62500)
    at /home/doutriaux1/build/build/VTK/Common/Core/vtkDataArrayTemplate.txx:355
#5  0x00007ffff04cc1e5 in vtkPoints::SetNumberOfPoints (this=0x14ca690, numPoints=62500) at /home/doutriaux1/build/build/VTK/Common/Core/vtkPoints.h:213
#6  0x00007ffff04cb447 in PyvtkPoints_SetNumberOfPoints (self=0x7fffc583d9b0, args=0x7fffc56d74d0)
    at /home/doutriaux1/build/build/VTK-build/Wrapping/Python/vtkPointsPython.cxx:1291
#7  0x00007ffff7adabf8 in call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4033
#8  PyEval_EvalFrameEx (f=0x1, throwflag=-982558816) at Python/ceval.c:2679
#9  0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7fffc5a28930, globals=0xb4fff82, locals=0x1971320, args=0x3, argcount=-1, kws=0x7e, kwcount=3, defs=0x7fffc59f64c8, 
    defcount=3, closure=0x0) at Python/ceval.c:3265
#10 0x00007ffff7adaef5 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4129
#11 call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4054
#12 PyEval_EvalFrameEx (f=0x3, throwflag=-979356536) at Python/ceval.c:2679
#13 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7fffc5a21730, globals=0xb4fff82, locals=0x1971320, args=0x5, argcount=-1, kws=0x7e, kwcount=2, defs=0x7fffc59d04e8, 
    defcount=2, closure=0x0) at Python/ceval.c:3265
#14 0x00007ffff7adaef5 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4129
#15 call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4054
#16 PyEval_EvalFrameEx (f=0x5, throwflag=-979359672) at Python/ceval.c:2679
#17 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7fffc5a21330, globals=0xb4fff82, locals=0x1971320, locals@entry=0x0, args=0x7fffc5814068, argcount=-1, kws=0x7e, 
    kws@entry=0x7ffff7f84068, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265
#18 0x00007ffff7a5447d in function_call (func=0x7fffc5a02578, arg=0x7fffc5814050, kw=0x7fffc52de4b0) at Objects/funcobject.c:526
#19 0x00007ffff7a21913 in PyObject_Call (func=0x7fffc5a02578, arg=<optimized out>, kw=<optimized out>) at Objects/abstract.c:2529
#20 0x00007ffff7ad86b8 in ext_do_call (nk=<optimized out>, na=<optimized out>, flags=<optimized out>, pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4346
#21 PyEval_EvalFrameEx (f=0xffffffff, throwflag=-979360392) at Python/ceval.c:2718
#22 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7fffc9c331b0, globals=0xb4fff82, locals=0x1971320, args=0x2, argcount=-1, kws=0x7e, kwcount=3, defs=0x0, defcount=0, 
    closure=0x0) at Python/ceval.c:3265
#23 0x00007ffff7adaef5 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4129
#24 call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4054
#25 PyEval_EvalFrameEx (f=0x3, throwflag=-979851432) at Python/ceval.c:2679
#26 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7fffc9c2beb0, globals=0xb4fff82, locals=0x1971320, args=0x0, argcount=-1, kws=0x7e, kwcount=1, defs=0x0, defcount=0, 
    closure=0x0) at Python/ceval.c:3265
#27 0x00007ffff7adaef5 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4129
#28 call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4054
---Type <return> to continue, or q <return> to quit---
#29 PyEval_EvalFrameEx (f=0x3, throwflag=-979851672) at Python/ceval.c:2679
#30 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7ffff7ec3b30, globals=0xb4fff82, locals=0x1971320, args=0x0, argcount=-1, argcount@entry=0, kws=0x7e, kws@entry=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265
#31 0x00007ffff7adc719 in PyEval_EvalCode (co=<optimized out>, globals=<optimized out>, locals=<optimized out>) at Python/ceval.c:667
#32 0x00007ffff7b00c4a in run_mod (arena=<optimized out>, flags=<optimized out>, locals=<optimized out>, globals=<optimized out>, filename=<optimized out>, 
    mod=<optimized out>) at Python/pythonrun.c:1371
#33 PyRun_FileExFlags (fp=0x65ee90, filename=0x7ffff7ec3b30 "\002", start=26678048, globals=0x7ffff7f59168, locals=0x7ffff7f59168, closeit=1, flags=0x7fffffffdcc0)
    at Python/pythonrun.c:1357
#34 0x00007ffff7b02327 in PyRun_SimpleFileExFlags (fp=0x3, filename=0x7fffffffe2e2 "/git/uvcdat/testing/vcs/test_vcs_basic_gms.py", closeit=1, flags=0x1)
    at Python/pythonrun.c:949
#35 0x00007ffff7b189aa in Py_Main (argc=-135477840, argv=0x0) at Modules/main.c:640
#36 0x00007ffff740dec5 in __libc_start_main (main=0x400710 <main>, argc=7, argv=0x7fffffffde88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffffffde78) at libc-start.c:287
#37 0x000000000040073e in _start ()
@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 17, 2015

use to backtrace somewhere in geotranform. Not quite sure what's going on.

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 17, 2015

earlier traceback (before the prints and setting pts number of points

Starting program: /lgm/uvcdat/2015-03-16/bin/python /git/uvcdat/testing/vcs/test_vcs_basic_gms.py --gm_type=isoline --projection=-3 --lat1=-90 --lat2=0 --source=/home/doutriaux1/build/uvcdat-testdata/baselines/vcs/test_vcs_basic_isoline_-3_proj_SH.png
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
*** Error in `/lgm/uvcdat/2015-03-16/bin/python': realloc(): invalid next size: 0x00000000018d9d90 ***

Program received signal SIGABRT, Aborted.
0x00007ffff7422e37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7422e37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff7424528 in __GI_abort () at abort.c:89
#2  0x00007ffff7463f74 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7ffff756cf00 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff7469ff7 in malloc_printerr (action=<optimized out>, str=0x7ffff75690dd "realloc(): invalid next size", ptr=<optimized out>) at malloc.c:4996
#4  0x00007ffff746e107 in _int_realloc (av=<optimized out>, oldp=0x18d9d80, oldsize=<optimized out>, nb=<optimized out>) at malloc.c:4234
#5  0x00007ffff746ef79 in __GI___libc_realloc (oldmem=0x18d9d90, bytes=196596) at malloc.c:3029
#6  0x00007fffefb7956b in vtkDataArrayTemplate<float>::ResizeAndExtend (this=0x1359ca0, sz=24576) at /home/doutriaux1/build/build/VTK/Common/Core/vtkDataArrayTemplate.txx:303
#7  0x00007fffefb784b6 in vtkDataArrayTemplate<float>::WritePointer (this=0x1359ca0, id=24573, number=3)
    at /home/doutriaux1/build/build/VTK/Common/Core/vtkDataArrayTemplate.txx:935
#8  0x00007fffefb77a1d in vtkDataArrayTemplate<float>::InsertNextTuple (this=0x1359ca0, tuple=0x7fffffffcdc0)
    at /home/doutriaux1/build/build/VTK/Common/Core/vtkDataArrayTemplate.txx:812
#9  0x00007fffed9189b6 in vtkPoints::InsertNextPoint (this=0x135b450, x=0x7fffffffcdc0) at /home/doutriaux1/build/build/VTK/Common/Core/vtkPoints.h:161
#10 0x00007fffed914c88 in vtkAbstractTransform::TransformPoints (this=0x149ac30, in=0x135b3d0, out=0x135b450)
    at /home/doutriaux1/build/build/VTK/Common/Transforms/vtkAbstractTransform.cxx:142
#11 0x00007fffd36f5818 in vtkGeoTransform::TransformPoints (this=0x149ac30, srcPts=0x135b3d0, dstPts=0x135b450)
    at /home/doutriaux1/build/build/VTK/Geovis/Core/vtkGeoTransform.cxx:71
#12 0x00007fffd396a299 in PyvtkGeoTransform_TransformPoints (self=0x7fffc583fef0, args=0x7fffd0b4a2d8)
    at /home/doutriaux1/build/build/VTK-build/Wrapping/Python/vtkGeoTransformPython.cxx:267
#13 0x00007ffff7adabf8 in call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4033
#14 PyEval_EvalFrameEx (f=0x2, throwflag=-982538336) at Python/ceval.c:2679
#15 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7fffc5a28930, globals=0x4500, locals=0x6, args=0x3, argcount=1681404208, kws=0x622f36312d33302d, kwcount=3, 
    defs=0x7fffc59f64c8, defcount=3, closure=0x0) at Python/ceval.c:3265
#16 0x00007ffff7adaef5 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4129
#17 call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4054
#18 PyEval_EvalFrameEx (f=0x3, throwflag=-979360632) at Python/ceval.c:2679
#19 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7fffc5a21730, globals=0x4500, locals=0x6, args=0x5, argcount=1681404208, kws=0x622f36312d33302d, kwcount=2, 
    defs=0x7fffc59d04e8, defcount=2, closure=0x0) at Python/ceval.c:3265
#20 0x00007ffff7adaef5 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4129
#21 call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4054
#22 PyEval_EvalFrameEx (f=0x5, throwflag=-979363768) at Python/ceval.c:2679
#23 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7fffc5a21330, globals=0x4500, locals=0x6, locals@entry=0x0, args=0x7fffc5815068, argcount=1681404208, 
    kws=0x622f36312d33302d, kws@entry=0x7ffff7f84068, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265
#24 0x00007ffff7a5447d in function_call (func=0x7fffc5a01578, arg=0x7fffc5815050, kw=0x7fffc52de398) at Objects/funcobject.c:526
#25 0x00007ffff7a21913 in PyObject_Call (func=0x7fffc5a01578, arg=<optimized out>, kw=<optimized out>) at Objects/abstract.c:2529
#26 0x00007ffff7ad86b8 in ext_do_call (nk=<optimized out>, na=<optimized out>, flags=<optimized out>, pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4346
#27 PyEval_EvalFrameEx (f=0xffffffff, throwflag=-979364488) at Python/ceval.c:2718
#28 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7fffc9c331b0, globals=0x4500, locals=0x6, args=0x2, argcount=1681404208, kws=0x622f36312d33302d, kwcount=3, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, closure=0x0) at Python/ceval.c:3265
#29 0x00007ffff7adaef5 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4129
#30 call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4054
#31 PyEval_EvalFrameEx (f=0x3, throwflag=-979855528) at Python/ceval.c:2679
#32 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7fffc9c2beb0, globals=0x4500, locals=0x6, args=0x0, argcount=1681404208, kws=0x622f36312d33302d, kwcount=1, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:3265
#33 0x00007ffff7adaef5 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, func=<optimized out>) at Python/ceval.c:4129
#34 call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:4054
#35 PyEval_EvalFrameEx (f=0x3, throwflag=-979855768) at Python/ceval.c:2679
#36 0x00007ffff7adc5f0 in PyEval_EvalCodeEx (co=0x7ffff7ec3b30, globals=0x4500, locals=0x6, args=0x0, argcount=1681404208, argcount@entry=0, kws=0x622f36312d33302d, 
    kws@entry=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265
#37 0x00007ffff7adc719 in PyEval_EvalCode (co=<optimized out>, globals=<optimized out>, locals=<optimized out>) at Python/ceval.c:667
#38 0x00007ffff7b00c4a in run_mod (arena=<optimized out>, flags=<optimized out>, locals=<optimized out>, globals=<optimized out>, filename=<optimized out>, 
    mod=<optimized out>) at Python/pythonrun.c:1371
#39 PyRun_FileExFlags (fp=0x65ee90, filename=0x7ffff7ec3b30 "\002", start=6, globals=0x7ffff7f59168, locals=0x7ffff7f59168, closeit=1, flags=0x7fffffffdcc0)
    at Python/pythonrun.c:1357
#40 0x00007ffff7b02327 in PyRun_SimpleFileExFlags (fp=0x4500, filename=0x7fffffffe2e2 "/git/uvcdat/testing/vcs/test_vcs_basic_gms.py", closeit=1, flags=0xffffffffffffffff)
    at Python/pythonrun.c:949
#41 0x00007ffff7b189aa in Py_Main (argc=-135477840, argv=0x0) at Modules/main.c:640
#42 0x00007ffff740dec5 in __libc_start_main (main=0x400710 <main>, argc=7, argv=0x7fffffffde88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffffffde78) at libc-start.c:287
#43 0x000000000040073e in _start ()
(gdb) quit
A debugging session is active.

    Inferior 1 [process 17664] will be killed.

Quit anyway? (y or n) y
@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 18, 2015

hum... using InsertPoint(n,x,y,z) rather than SetPoint(n,x,y,z) seems to actually fix the issue... odd...

doutriaux1 added some commits Mar 18, 2015

some proj were not actually round ones
it showed it baselines
ratio needed to be set to none for ticks/box otherwise would be stretched in bg mode
@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 18, 2015

@dlonie @aashish24 I think this is ready to to go now, please review
goes with:
CDAT/uvcdat-testdata#26

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Mar 18, 2015

SetPoint assumes that memory is already allocated. InsertPoint allocates the memory for you. It should be noted that InsertPoint is slow.

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Mar 18, 2015

Works here.

allisonvacanti added a commit that referenced this pull request Mar 18, 2015

@allisonvacanti allisonvacanti merged commit 14f9225 into CDAT:master Mar 18, 2015

1 check failed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Mar 18, 2015

@aashish24 that was my understanding doesn't setNumberOfPoints allocate the memory?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment