octaviz-help — installing and using octaviz

Re: [Octaviz-help] octaviz being abandoned [Fwd: Re: Octaviz patch for VTK 5.2 (incomplete)]

[Lukas D. <luk...@ni...>]

Just out of curiosity how good is the 64 bit support/integration of scipy ?
>From a quick look in wikipedia it looks very promising, v.0.7.1 though but
interface to R and debugging seem nice.  I'm staying with octave mainly because
the set of numerical (old, debugged and reliable) fortran libs is excellent and
64bit compatible.

greetings
Lukas

On Wed, Feb 03, 2010 at 11:20:48AM -0500, Jonathan Stickel wrote:
> I am abandoning Octaviz.  I do not see a future with Octaviz with Octave 
> developers fully committed to so-called 'native' graphics using fltk and 
> opengl.  Personally, I have switched to using python/scipy with 
> matplotlib and mayavi2, a better numerical programming language and much 
> better plotting and visualization, in my opinion.
> 
> The last activity with Octaviz that I am aware of came from Andreas 
> Potschka (see below).  He attempted to fix Octaviz to compile with 
> vtk-5.2, with limited success.  I have tried to check in his work to 
> CVS, in case anyone wants to revive the project in the future.
> 
> Regards,
> Jonathan
> 
> 
> -------- Original Message --------
> Subject: Re: Octaviz patch for VTK 5.2 (incomplete)
> Date: Sat, 7 Nov 2009 15:52:09 +0100
> From: Andreas Potschka <pot...@iw...>
> To: Jonathan Stickel <jjs...@vc...>
> CC: dr...@us..., jjs...@us...
> References: 
> <29f...@ma...>	 
> <4AF...@vc...>
> 
> Hi Jonathan,
> 
> thanks for the answer. It's a rewrite of the bison interface plus some
> changes in the lexer and the wrapper. It compiles with VTK 5.2. I am
> sorry, but I can't put more time into this. It should not be a lot of
> work for you to diff it yourself which is why I won't send you a
> patchfile.
> 
> Cheers
> Andreas
> 
> On Sat, Nov 7, 2009 at 3:29 AM, Jonathan Stickel wrote:
> > Unfortunately, Octaviz is more-or-less dead, mostly because it no longer
> > compiles with recent versions of VTK, as you have found.  A rewrite of its
> > bison interface is likely needed.  I am not sure what you did here.  If you
> > sent a patchfile showing differences, I might take a look.
> >
> > Jonathan
> >
> >
> > Andreas Potschka wrote:
> >>
> >> Hi,
> >>
> >> I send these files to you and hope they may help you.
> >>
> >> I tried for two days to get octaviz compile with VTK 5.2 and managed
> >> to get the source to compile. However, from within octave I get errors
> >> like
> >>
> >> octave:1> t = linspace(0, 1, 11);
> >> octave:2> [x,y] = meshgrid(t,t);
> >> octave:3> vtk_surf(x,y,x.*y)
> >> error: Method was found but arguments were wrong.
> >> error: called from `vtk_trisurf' in file
> >> `/usr/share/octave/3.0.5/site/m/octaviz/vtk_trisurf.m'
> >> error: evaluating assignment expression near line 91, column 6
> >> error: evaluating if command near line 88, column 3
> >> error: called from `vtk_surf' in file
> >> `/usr/share/octave/3.0.5/site/m/octaviz/vtk_surf.m'
> >>
> >> I don't have more time to work on the issue. Maybe you have.
> >>
> >> Cheers
> >> Andreas
> >
> 
> 
> 
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Octaviz-help mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octaviz-help

-- 
Lukas L. Diduch
Smartspace Laboratory
Information Access Division (IAD) 
National Institute of Standards and Technology (NIST)

web    : http://www.nist.gov/smartspace
email  : lukas (dot) diduch (at) nist (dot) gov
office : +1 (301) 975 6399
fax    : +1 (301) 975 5287 

[Octaviz-help] octaviz being abandoned [Fwd: Re: Octaviz patch for VTK 5.2 (incomplete)]

[Jonathan S. <jjs...@vc...>]

I am abandoning Octaviz.  I do not see a future with Octaviz with Octave 
developers fully committed to so-called 'native' graphics using fltk and 
opengl.  Personally, I have switched to using python/scipy with 
matplotlib and mayavi2, a better numerical programming language and much 
better plotting and visualization, in my opinion.

The last activity with Octaviz that I am aware of came from Andreas 
Potschka (see below).  He attempted to fix Octaviz to compile with 
vtk-5.2, with limited success.  I have tried to check in his work to 
CVS, in case anyone wants to revive the project in the future.

Regards,
Jonathan


-------- Original Message --------
Subject: Re: Octaviz patch for VTK 5.2 (incomplete)
Date: Sat, 7 Nov 2009 15:52:09 +0100
From: Andreas Potschka <pot...@iw...>
To: Jonathan Stickel <jjs...@vc...>
CC: dr...@us..., jjs...@us...
References: 
<29f...@ma...>	 
<4AF...@vc...>

Hi Jonathan,

thanks for the answer. It's a rewrite of the bison interface plus some
changes in the lexer and the wrapper. It compiles with VTK 5.2. I am
sorry, but I can't put more time into this. It should not be a lot of
work for you to diff it yourself which is why I won't send you a
patchfile.

Cheers
Andreas

On Sat, Nov 7, 2009 at 3:29 AM, Jonathan Stickel wrote:
> Unfortunately, Octaviz is more-or-less dead, mostly because it no longer
> compiles with recent versions of VTK, as you have found.  A rewrite of its
> bison interface is likely needed.  I am not sure what you did here.  If you
> sent a patchfile showing differences, I might take a look.
>
> Jonathan
>
>
> Andreas Potschka wrote:
>>
>> Hi,
>>
>> I send these files to you and hope they may help you.
>>
>> I tried for two days to get octaviz compile with VTK 5.2 and managed
>> to get the source to compile. However, from within octave I get errors
>> like
>>
>> octave:1> t = linspace(0, 1, 11);
>> octave:2> [x,y] = meshgrid(t,t);
>> octave:3> vtk_surf(x,y,x.*y)
>> error: Method was found but arguments were wrong.
>> error: called from `vtk_trisurf' in file
>> `/usr/share/octave/3.0.5/site/m/octaviz/vtk_trisurf.m'
>> error: evaluating assignment expression near line 91, column 6
>> error: evaluating if command near line 88, column 3
>> error: called from `vtk_surf' in file
>> `/usr/share/octave/3.0.5/site/m/octaviz/vtk_surf.m'
>>
>> I don't have more time to work on the issue. Maybe you have.
>>
>> Cheers
>> Andreas
>

Re: [Octaviz-help] More on the Octaviz segfault

[J. G. H. <jo...@gm...>]

On 30/05/2008, Thomas Weber <tho...@gm...> wrote:
> Am Freitag, den 30.05.2008, 08:29 -0500 schrieb Jordi Gutiérrez Hermoso:
>
> > My suspicion is still that the Octaviz parser is producing code
>  > that is working most of the time but that some obscure undocumented
>  > feature or bug of the VTK shipped with Debian let it slip by during
>  > compilation.
>
>
> I don't think th vtkIdType is really the problem. If my gdb skills are
>  sufficient[1], then InsertUniquePoint() is called from vtkTriangle with
>  a vector x of three elements, all of which are NaN.

Yeah, I saw that too, but I don't *think* that should cause a
segfault. When you pass other NaN's to Octaviz, you just get blank
plots, not segfaults. Ah, well. I guess we're still guessing until I
see if fixing the parser makes the segfault go away or not.

- Jordi G. H.

Re: [Octaviz-help] More on the Octaviz segfault

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

Am Freitag, den 30.05.2008, 08:29 -0500 schrieb Jordi Gutiérrez Hermoso:
> On 30/05/2008, Thomas Weber <tho...@gm...> wrote:
> > I looked into this and I think vtkIdType being int is actually correct,
> >  unless you set VTK_USE_64BIT_IDS (which seems to be unset by default).
> 
> It may work in some cases, but it didn't even compile against the cvs
> VTK. The politically correct action would be to set it to IdType in
> the parser and to let VTK itself decide if that should be an int or
> not. My suspicion is still that the Octaviz parser is producing code
> that is working most of the time but that some obscure undocumented
> feature or bug of the VTK shipped with Debian let it slip by during
> compilation.

I don't think th vtkIdType is really the problem. If my gdb skills are
sufficient[1], then InsertUniquePoint() is called from vtkTriangle with
a vector x of three elements, all of which are NaN.

I don't think that should happen. 

[1] They are quite limited.


> This involves making quite a few modifications to the Octaviz parser,
> in order to make it work with later versions of the VTK bison and flex
> grammar files. I haven't worked on this for the past couple of weeks,
> and the next few weeks involve preparing finals for my students and
> lots of bureaucracy. I still plan, however, to dust off my
> undergraduate notes on parsers and context free grammars and see how I
> can synch Octaviz's parser with the better 64-bit aware grammar. ;-)

Eh, I know basically no C++ and have zero knowledge about parsers and
lexers. Be my guest :)

	Thomas

Re: [Octaviz-help] More on the Octaviz segfault

[J. G. H. <jo...@gm...>]

On 30/05/2008, Thomas Weber <tho...@gm...> wrote:
> I looked into this and I think vtkIdType being int is actually correct,
>  unless you set VTK_USE_64BIT_IDS (which seems to be unset by default).

It may work in some cases, but it didn't even compile against the cvs
VTK. The politically correct action would be to set it to IdType in
the parser and to let VTK itself decide if that should be an int or
not. My suspicion is still that the Octaviz parser is producing code
that is working most of the time but that some obscure undocumented
feature or bug of the VTK shipped with Debian let it slip by during
compilation.

This involves making quite a few modifications to the Octaviz parser,
in order to make it work with later versions of the VTK bison and flex
grammar files. I haven't worked on this for the past couple of weeks,
and the next few weeks involve preparing finals for my students and
lots of bureaucracy. I still plan, however, to dust off my
undergraduate notes on parsers and context free grammars and see how I
can synch Octaviz's parser with the better 64-bit aware grammar. ;-)

Of course, I have been slow in the past complying with this sort of
thing, so feel free to do it yourself if you get impatient with me.

- Jordi G. H.

Re: [Octaviz-help] More on the Octaviz segfault

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

Am Montag, den 12.05.2008, 08:43 -0500 schrieb Jordi Gutiérrez Hermoso:
> On 12/05/2008, Jonathan Stickel <jjs...@vc...> wrote:
> > Jordi Gutiérrez Hermoso wrote:
> > > The most glaring problem I can see, at least against the cvs version
> > > of VTK, is that the parser is assuming (in Wrapping/vtkParse.l) that
> > > vtkIdType is an int, while it looks like in 64bit builds vtkIdType is
> > > actually typedeffed to a long long int.
> >
> > I would prefer that octaviz continues to work with the latest official
> > release of VTK.
> 
> Alright, I guess that makes sense. I don't get a compile time error
> when building against the latest VTK release, but there still is a
> problem of Octaviz assuming that vtkIdType is an int on a 64bit
> system.

I looked into this and I think vtkIdType being int is actually correct,
unless you set VTK_USE_64BIT_IDS (which seems to be unset by default).

	Thomas

Re: [Octaviz-help] More on the Octaviz segfault

[J. G. H. <jo...@gm...>]

On 12/05/2008, Jonathan Stickel <jjs...@vc...> wrote:
> Jordi Gutiérrez Hermoso wrote:
> > The most glaring problem I can see, at least against the cvs version
> > of VTK, is that the parser is assuming (in Wrapping/vtkParse.l) that
> > vtkIdType is an int, while it looks like in 64bit builds vtkIdType is
> > actually typedeffed to a long long int.
>
> I would prefer that octaviz continues to work with the latest official
> release of VTK.

Alright, I guess that makes sense. I don't get a compile time error
when building against the latest VTK release, but there still is a
problem of Octaviz assuming that vtkIdType is an int on a 64bit
system.

I guess you can say that the cvs build of VTK at least pointed out
what a likely problem could be.

- Jordi G. H.

Re: [Octaviz-help] More on the Octaviz segfault

[Jonathan S. <jjs...@vc...>]

Jordi Gutiérrez Hermoso wrote:
> Hello, Jonathan and Thomas
> 
> Alright, I think I'm getting an idea of what could be wrong. The
> parser that wraps the VTK classes for Octave needs to be fixed for
> 64bit types.
> 
> The most glaring problem I can see, at least against the cvs version
> of VTK, is that the parser is assuming (in Wrapping/vtkParse.l) that
> vtkIdType is an int, while it looks like in 64bit builds vtkIdType is
> actually typedeffed to a long long int. This produced a compile error
> with the cvs VTK, and my guess is that this error was only caught
> later at runtime with the version of VTK in Debian. I haven't looked
> exactly at this latter version, but if Octaviz is somehow giving int*
> when VTK expects long long*, well, that would definitely be a
> segfault.
> 
> The cvs VTK provides better Wrapping/vtkParse.* files for Flex and
> Bison which have the right 64bit types in them, but using them with
> Octaviz requires modifying Octaviz's Wrapping/vtkWrapOctave.c
> 
> I'll keep working on this...
> 
> - Jordi G. H.
> 
> 

Thank you for your efforts here.  I would prefer that octaviz continues 
to work with the latest official release of VTK.  For awhile octaviz was 
programmed against VTK-cvs, which made it very difficult to make a 
release since VTK was long delayed in releasing 5.0.

Jonathan

Re: [Octaviz-help] Help: octaviz makes octave segfault

[Lukas D. <luk...@ni...>]

On Thu, May 01, 2008 at 07:36:11AM -0600, Jonathan Stickel wrote:
> Lukas Diduch wrote:
>> On Wed, Apr 30, 2008 at 09:02:40AM -0600, Jonathan Stickel wrote:
>>> Lukas Diduch wrote:
>>>> Hi,
>>>>
>>>> This might also be interesting in regard to thread: [Octaviz-help] Re:
>>>> Octaviz installation on Mac but first need VTK, and possibly also Cmake.
>>>>
>>>> Was able to build octaviz 0.4.7 on OSX/Leopard with octave 3.0.0 and VTK
>>>> 5.0.4. Octaviz apparently needs some of the VTK X11 functions, so it
>>>> won't compile with Carbon/Cocoa support enabled in VTK. X11 support for 
>>>> VTK involves hacking around the building problems due to
>>>> the opengl/ld bug in leopard and some missing files in VTKs cmake. Same
>>>> for octaviz: cmake defs do not generate proper makefiles, esp. LDFLAGS
>>>> and CXXFLAGS. Those have to be set with the correct paths to X11, GL
>>>> by hand before running ccmake for octaviz the first time.
>>>>
>>>> VTK test works fine, octave works fine. Just the same segfault problem
>>>> when i launch vtk_* scripts from within octave. cheers
>>>> Lukas
>>>>
>>> Octaviz on Mac OS X has been a challenge, but I have had it working for 
>>> some time now on Tiger (10.4).  If you are using Fink, I recommend that 
>>> you install vtk by the available info file in unstable.  Then you can use 
>>> the info file for octaviz that I put on Fink's sourceforge tracker:
>>>
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=1922228&group_id=17203&atid=414256
>>>
>>> If you are not using Fink, you can look at the info files to see what 
>>> cmake options are used.  Perhaps this will be helpful.  If the problems 
>>> are specific to Leopard, I cannot be of much help.
>>>
>>> Regards,
>>> Jonathan
>>
>> Thanks a lot, it now works fine on Leopard (10.5.2) ! Built with octave
>> 3.0.0-4, vtk-py25 5.0.4-2 and octaviz 0.4.7-1. FYI: had just to tweak
>> the Distribution: 10.4 line as well as the fink dep > 0.28 in the
>> octaviz.info file for fink to like it.
>>
>
> Glad to hear!  It is nice to know that the info works on someone else's 
> computer, and Leopard too.  I will add 10.5 to the Distribution and change 
> the fink dependency to >0.28.
>
> Did you need to use the DYLD_FALLBACK_LIBRARY_PATH environmental variable 
> to make it work?
>
> Thanks,
> Jonathan

Works with both: DYLD_LIBRARY_PATH and the fallback path. I guess you
only can get rid of this by linking the library statically.

Regards,
Lukas

Re: [Octaviz-help] Help: octaviz makes octave segfault

[Jonathan S. <jjs...@vc...>]

Lukas Diduch wrote:
> On Wed, Apr 30, 2008 at 09:02:40AM -0600, Jonathan Stickel wrote:
>> Lukas Diduch wrote:
>>> Hi,
>>>
>>> This might also be interesting in regard to thread: [Octaviz-help] Re:
>>> Octaviz installation on Mac but first need VTK, and possibly also Cmake.
>>>
>>> Was able to build octaviz 0.4.7 on OSX/Leopard with octave 3.0.0 and VTK
>>> 5.0.4. Octaviz apparently needs some of the VTK X11 functions, so it
>>> won't compile with Carbon/Cocoa support enabled in VTK. 
>>> X11 support for VTK involves hacking around the building problems due to
>>> the opengl/ld bug in leopard and some missing files in VTKs cmake. Same
>>> for octaviz: cmake defs do not generate proper makefiles, esp. LDFLAGS
>>> and CXXFLAGS. Those have to be set with the correct paths to X11, GL
>>> by hand before running ccmake for octaviz the first time.
>>>
>>> VTK test works fine, octave works fine. Just the same segfault problem
>>> when i launch vtk_* scripts from within octave. 
>>> cheers
>>> Lukas
>>>
>> Octaviz on Mac OS X has been a challenge, but I have had it working for 
>> some time now on Tiger (10.4).  If you are using Fink, I recommend that you 
>> install vtk by the available info file in unstable.  Then you can use the 
>> info file for octaviz that I put on Fink's sourceforge tracker:
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1922228&group_id=17203&atid=414256
>>
>> If you are not using Fink, you can look at the info files to see what cmake 
>> options are used.  Perhaps this will be helpful.  If the problems are 
>> specific to Leopard, I cannot be of much help.
>>
>> Regards,
>> Jonathan
> 
> Thanks a lot, it now works fine on Leopard (10.5.2) ! Built with octave
> 3.0.0-4, vtk-py25 5.0.4-2 and octaviz 0.4.7-1. FYI: had just to tweak
> the Distribution: 10.4 line as well as the fink dep > 0.28 in the
> octaviz.info file for fink to like it.
> 

Glad to hear!  It is nice to know that the info works on someone else's 
computer, and Leopard too.  I will add 10.5 to the Distribution and 
change the fink dependency to >0.28.

Did you need to use the DYLD_FALLBACK_LIBRARY_PATH environmental 
variable to make it work?

Thanks,
Jonathan

Re: [Octaviz-help] Help: octaviz makes octave segfault

[Lukas D. <luk...@ni...>]

On Wed, Apr 30, 2008 at 09:02:40AM -0600, Jonathan Stickel wrote:
> Lukas Diduch wrote:
>> Hi,
>>
>> This might also be interesting in regard to thread: [Octaviz-help] Re:
>> Octaviz installation on Mac but first need VTK, and possibly also Cmake.
>>
>> Was able to build octaviz 0.4.7 on OSX/Leopard with octave 3.0.0 and VTK
>> 5.0.4. Octaviz apparently needs some of the VTK X11 functions, so it
>> won't compile with Carbon/Cocoa support enabled in VTK. 
>> X11 support for VTK involves hacking around the building problems due to
>> the opengl/ld bug in leopard and some missing files in VTKs cmake. Same
>> for octaviz: cmake defs do not generate proper makefiles, esp. LDFLAGS
>> and CXXFLAGS. Those have to be set with the correct paths to X11, GL
>> by hand before running ccmake for octaviz the first time.
>>
>> VTK test works fine, octave works fine. Just the same segfault problem
>> when i launch vtk_* scripts from within octave. 
>> cheers
>> Lukas
>>
>
> Octaviz on Mac OS X has been a challenge, but I have had it working for 
> some time now on Tiger (10.4).  If you are using Fink, I recommend that you 
> install vtk by the available info file in unstable.  Then you can use the 
> info file for octaviz that I put on Fink's sourceforge tracker:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1922228&group_id=17203&atid=414256
>
> If you are not using Fink, you can look at the info files to see what cmake 
> options are used.  Perhaps this will be helpful.  If the problems are 
> specific to Leopard, I cannot be of much help.
>
> Regards,
> Jonathan

Thanks a lot, it now works fine on Leopard (10.5.2) ! Built with octave
3.0.0-4, vtk-py25 5.0.4-2 and octaviz 0.4.7-1. FYI: had just to tweak
the Distribution: 10.4 line as well as the fink dep > 0.28 in the
octaviz.info file for fink to like it.

Cheers,
Lukas

Re: [Octaviz-help] Help: octaviz makes octave segfault

[Jonathan S. <jjs...@vc...>]

Lukas Diduch wrote:
> Hi,
> 
> This might also be interesting in regard to thread: [Octaviz-help] Re:
> Octaviz installation on Mac but first need VTK, and possibly also Cmake.
> 
> Was able to build octaviz 0.4.7 on OSX/Leopard with octave 3.0.0 and VTK
> 5.0.4. Octaviz apparently needs some of the VTK X11 functions, so it
> won't compile with Carbon/Cocoa support enabled in VTK. 
> 
> X11 support for VTK involves hacking around the building problems due to
> the opengl/ld bug in leopard and some missing files in VTKs cmake. Same
> for octaviz: cmake defs do not generate proper makefiles, esp. LDFLAGS
> and CXXFLAGS. Those have to be set with the correct paths to X11, GL
> by hand before running ccmake for octaviz the first time.
> 
> VTK test works fine, octave works fine. Just the same segfault problem
> when i launch vtk_* scripts from within octave. 
> 
> cheers
> Lukas
> 

Octaviz on Mac OS X has been a challenge, but I have had it working for 
some time now on Tiger (10.4).  If you are using Fink, I recommend that 
you install vtk by the available info file in unstable.  Then you can 
use the info file for octaviz that I put on Fink's sourceforge tracker:

http://sourceforge.net/tracker/index.php?func=detail&aid=1922228&group_id=17203&atid=414256

If you are not using Fink, you can look at the info files to see what 
cmake options are used.  Perhaps this will be helpful.  If the problems 
are specific to Leopard, I cannot be of much help.

Regards,
Jonathan

Re: [Octaviz-help] Help: octaviz makes octave segfault

[Lukas D. <luk...@ni...>]

Hi,

This might also be interesting in regard to thread: [Octaviz-help] Re:
Octaviz installation on Mac but first need VTK, and possibly also Cmake.

Was able to build octaviz 0.4.7 on OSX/Leopard with octave 3.0.0 and VTK
5.0.4. Octaviz apparently needs some of the VTK X11 functions, so it
won't compile with Carbon/Cocoa support enabled in VTK. 

X11 support for VTK involves hacking around the building problems due to
the opengl/ld bug in leopard and some missing files in VTKs cmake. Same
for octaviz: cmake defs do not generate proper makefiles, esp. LDFLAGS
and CXXFLAGS. Those have to be set with the correct paths to X11, GL
by hand before running ccmake for octaviz the first time.

VTK test works fine, octave works fine. Just the same segfault problem
when i launch vtk_* scripts from within octave. 

cheers
Lukas

-- 
Lukas L. Diduch
Array Signal Processing / Multisensor Data Fusion
National Institute of Standards and Technology
Information Access Division - Smartspace Laboratory

Re: [Octaviz-help] rpath flag

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

Am Sonntag, den 30.12.2007, 15:24 -0700 schrieb Jonathan Stickel:
> Thomas Weber wrote:
> > Am Sonntag, den 30.12.2007, 13:11 -0700 schrieb Jonathan Stickel:
> >> I get the following error with the newly implemented rpath flag:
> >>
> >> /usr/bin/ld: unknown flag: 
> >> -rpath=/sw/lob/octave/3.0.0/site/oct/i386-apple-darwin8.11.1/octaviz
> >> collect2: ld returned 1 exit status
> >> make[2]: *** [Common/vtk_init.oct] Error 1
> >> make[1]: *** [Common/CMakeFiles/OctavizCommonFiles.dir/all] Error 2
> >> make: *** [all] Error 2
> > 
> > Can you look into ld's manpage and search for "rpath" on Mac? Sorry, I
> > don't have any access to such a system, but there must be a way to get
> > this working on Mac.
> 
> A search of the ld manpage shows no mention of "rpath".  I am not very 
> knowledgeable about dynamic libraries, but it seems to me that Mac puts 
> some path information directly in the library files.

Okay, how about the following call:

=========================================================================
 cmake								\
	    -DCMAKE_SKIP_RPATH:BOOL=YES 			\
	    -DVTK_DIR:PATH=/usr/lib/vtk-5.0			\
	    -DVTK_DATA_ROOT:PATH=/usr/share/VTKData		\
	    -DOCTAVIZ_LIBRARY_DIR:PATH=/usr/lib/octaviz		\
            -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON                    \
	    .. 

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

If you call cmake directly in the source directory, you need only one
point at the end. I usually create a subdirectory build/, though.
If it doesn't work, try leaving the "-DOCTAVIZ_LIBRARY_DIR:PATH" out.

	Thomas

Re: [Octaviz-help] rpath flag

[Jonathan S. <jjs...@vc...>]

Thomas Weber wrote:
> Am Sonntag, den 30.12.2007, 13:11 -0700 schrieb Jonathan Stickel:
>> I get the following error with the newly implemented rpath flag:
>>
>> /usr/bin/ld: unknown flag: 
>> -rpath=/sw/lob/octave/3.0.0/site/oct/i386-apple-darwin8.11.1/octaviz
>> collect2: ld returned 1 exit status
>> make[2]: *** [Common/vtk_init.oct] Error 1
>> make[1]: *** [Common/CMakeFiles/OctavizCommonFiles.dir/all] Error 2
>> make: *** [all] Error 2
> 
> Can you look into ld's manpage and search for "rpath" on Mac? Sorry, I
> don't have any access to such a system, but there must be a way to get
> this working on Mac.

A search of the ld manpage shows no mention of "rpath".  I am not very 
knowledgeable about dynamic libraries, but it seems to me that Mac puts 
some path information directly in the library files.

> 
>> It doesn't seem to matter what I enter for the rpath when running 
>> ccmake.  I am on on Mac OS X 10.4.
> 
> You can't set this arbitrarily! It must be the path where octaviz.so
> (shared library under Linux) is finally found.
> 

OK, sure.  That is what I thought.

Jonathan

Re: [Octaviz-help] rpath flag

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

Am Sonntag, den 30.12.2007, 13:11 -0700 schrieb Jonathan Stickel:
> I get the following error with the newly implemented rpath flag:
> 
> /usr/bin/ld: unknown flag: 
> -rpath=/sw/lob/octave/3.0.0/site/oct/i386-apple-darwin8.11.1/octaviz
> collect2: ld returned 1 exit status
> make[2]: *** [Common/vtk_init.oct] Error 1
> make[1]: *** [Common/CMakeFiles/OctavizCommonFiles.dir/all] Error 2
> make: *** [all] Error 2

Can you look into ld's manpage and search for "rpath" on Mac? Sorry, I
don't have any access to such a system, but there must be a way to get
this working on Mac.

> It doesn't seem to matter what I enter for the rpath when running 
> ccmake.  I am on on Mac OS X 10.4.

You can't set this arbitrarily! It must be the path where octaviz.so
(shared library under Linux) is finally found.

	Thomas

[Octaviz-help] rpath flag

[Jonathan S. <jjs...@vc...>]

I get the following error with the newly implemented rpath flag:

/usr/bin/ld: unknown flag: 
-rpath=/sw/lob/octave/3.0.0/site/oct/i386-apple-darwin8.11.1/octaviz
collect2: ld returned 1 exit status
make[2]: *** [Common/vtk_init.oct] Error 1
make[1]: *** [Common/CMakeFiles/OctavizCommonFiles.dir/all] Error 2
make: *** [all] Error 2

It doesn't seem to matter what I enter for the rpath when running 
ccmake.  I am on on Mac OS X 10.4.

Jonathan

Re: [Octaviz-help] Segmentation fault running vtk_*

[Jonathan S. <jjs...@vc...>]

Octaviz requires octave-2.9.9 or greater.  I recommend using 
octave-2.9.15 from the science overlay.  If you are not familiar with 
overlays, emerge layman and read the help.

Jonathan


Paulo Jnkml wrote:
> Hi
> as another gentoo user also posted last year, I also have seg fault 
> problems when running vtk stuff.
> I'm using sabayon linux, gentoo based distro, gcc 4.1.1, octave 2.1.73, 
> vtk 5.0.3, octaviz 0.4.6.
> I'm also using qt 4.3.2 and 3.3.8-r4 and apparently vtk got configured 
> to use qt4, although it required 3.3.8-r4.
> Probably something related with it's ebuild.
> 
> I'm guessing that it is some binary incompatibility, can anyone give me 
> a suggestion?
> Thank you.
> 
> As for ebuilds I modified the ebuild that cames with the source.
> It just needs the name modified, and the command:
> 
>        cd ${WORKDIR}/${PN}     #heck it's a hack
> 
> added to the begining of both src_compile and src_install functions.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Octaviz-help mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octaviz-help

[Octaviz-help] Segmentation fault running vtk_*

[Paulo J. <pau...@gm...>]

Maybe it would be helpful if I show an example. Here it goes.



user@patino ~ $ octave
GNU Octave, version 2.1.73 (i686-pc-linux-gnu).
Copyright (C) 2006 John W. Eaton.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html

Report bugs to <bu...@oc...> (but first, please read
http://www.octave.org/bugs.html to learn how to write a helpful report).

octave:1> vtk_demo
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
error: octave_base_value::save_binary(): wrong type argument `vtk_object'
save to `octave-core' complete
Segmentation fault

[Octaviz-help] Segmentation fault running vtk_*

[Paulo J. <pau...@gm...>]

Hi
as another gentoo user also posted last year, I also have seg fault 
problems when running vtk stuff.
I'm using sabayon linux, gentoo based distro, gcc 4.1.1, octave 2.1.73, 
vtk 5.0.3, octaviz 0.4.6.
I'm also using qt 4.3.2 and 3.3.8-r4 and apparently vtk got configured 
to use qt4, although it required 3.3.8-r4.
Probably something related with it's ebuild.

I'm guessing that it is some binary incompatibility, can anyone give me 
a suggestion?
Thank you.

As for ebuilds I modified the ebuild that cames with the source.
It just needs the name modified, and the command:

        cd ${WORKDIR}/${PN}     #heck it's a hack

added to the begining of both src_compile and src_install functions.

[Octaviz-help] Switch to Subversion?

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

Hi, 

octave-forge migrated away from CVS to Subversion over the weekend.
Should we do this for Octaviz as well?

	Thomas

Re: [Octaviz-help] octaviz on Mac OS X

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

Am Donnerstag, den 11.10.2007, 11:06 -0600 schrieb Jonathan Stickel:
> Thomas Weber wrote:
> > Am Freitag, den 05.10.2007, 09:02 -0600 schrieb Jonathan Stickel:
> >> Thomas Weber wrote:
> >>> Am Freitag, den 05.10.2007, 08:16 -0600 schrieb Jonathan Stickel:
> >>>> Thomas Weber wrote:
> >>>>> Am Donnerstag, den 04.10.2007, 07:55 -0600 schrieb Jonathan Stickel:
> 
> >>>>>> Problem 2:
> >>>>>> Linking of libraries does not work automatically.  As a workaround, I added
> >>>>>>
> >>>>>> -L/sw/lib/octave-2.9.14 -loctinterp -loctave -lcruft -lvtkCommon
>  >>>>>>
>  >>>>>>to Common/CMakeFiles/octaviz.dir/link.txt
> 
> Thomas
> 
> I updated with your additions to CVS and added a couple of my own.  The 
> only compiling trouble that I still have is the library linking for 
> liboctaviz.dylib, for which I use the workaround above.  Do you know how 
> the that link.txt file is generated with cmake and how to modify it?  If 
> you give me some hints, maybe I figure out how to make it all work in 
> Mac OS X.

Sorry for not answering for so long. But the problem is that I don't
have a clue.

Sorry, 
	Thomas

Re: [Octaviz-help] Specify view from the command line or script.

[Jonathan S. <jjs...@vc...>]

Peter A. Gustafson wrote:
> On Thursday 11 October 2007 13:01:45 you wrote:
>> Peter A. Gustafson wrote:
>>
>> This is an issue with the postscript/pdf converter (GL2PS).  I get the
>> same behavior (the zzzz label not showing) if I just print straight to
>> pdf without the -tex flag.  The suggestion I have at the moment is to
>> change the aspect ratio of the window like this:
>>
>> f.window.SetSize(500,400);
>>
> 
> Yes, I had just tried this and found it to work OK.  However I don't really 
> consider it to be a general solution.  No complaints though... it works and 
> I'm gladly using it.
> 
>> This solves the problem for your particular example.  It should also be
>> possible to use SetFocalPoint, SetDistance, etc., to adjust the
>> placement of the figure in the window, but I haven't yet figured out how
>> to then update the rendering without resetting all of these...  Let me
>> know if you have any success with those commands.
>>
>>> Another question, can fon't sizing be turned off.  I want identical font
>>> sizes managed by tex.
>> At the moment I can only suggest that you post-process your .tex file.
>> Perhaps something like:
>>
>> sed -i -e /fontsize/d test.tex
>>
> 
> It appears we think alike.  I've got a local vtp_printlatex file which does 
> basically that.  (actually grep -v fontsize)  Ideally this would all be 
> controlled within octaviz, but like I said I'm not complaining, it works.  
> I'm sure there are more important things to work on.
> 
> 

As you know, we are all volunteers here.  Sometimes the "best" solution 
gives way to the "easy" solution due to contributors' interest and time. 
  I'd love to see more people using and contributing to Octaviz.

Jonathan

Re: [Octaviz-help] Specify view from the command line or script.

[Peter A. G. <pe...@sp...>]

On Thursday 11 October 2007 13:01:45 you wrote:
> Peter A. Gustafson wrote:
>
> This is an issue with the postscript/pdf converter (GL2PS).  I get the
> same behavior (the zzzz label not showing) if I just print straight to
> pdf without the -tex flag.  The suggestion I have at the moment is to
> change the aspect ratio of the window like this:
>
> f.window.SetSize(500,400);
>

Yes, I had just tried this and found it to work OK.  However I don't really 
consider it to be a general solution.  No complaints though... it works and 
I'm gladly using it.

> This solves the problem for your particular example.  It should also be
> possible to use SetFocalPoint, SetDistance, etc., to adjust the
> placement of the figure in the window, but I haven't yet figured out how
> to then update the rendering without resetting all of these...  Let me
> know if you have any success with those commands.
>
> > Another question, can fon't sizing be turned off.  I want identical font
> > sizes managed by tex.
>
> At the moment I can only suggest that you post-process your .tex file.
> Perhaps something like:
>
> sed -i -e /fontsize/d test.tex
>

It appears we think alike.  I've got a local vtp_printlatex file which does 
basically that.  (actually grep -v fontsize)  Ideally this would all be 
controlled within octaviz, but like I said I'm not complaining, it works.  
I'm sure there are more important things to work on.


Pete

Re: [Octaviz-help] octaviz on Mac OS X

[Jonathan S. <jjs...@vc...>]

Thomas Weber wrote:
> Am Freitag, den 05.10.2007, 09:02 -0600 schrieb Jonathan Stickel:
>> Thomas Weber wrote:
>>> Am Freitag, den 05.10.2007, 08:16 -0600 schrieb Jonathan Stickel:
>>>> Thomas Weber wrote:
>>>>> Am Donnerstag, den 04.10.2007, 07:55 -0600 schrieb Jonathan Stickel:

>>>>>> Problem 2:
>>>>>> Linking of libraries does not work automatically.  As a workaround, I added
>>>>>>
>>>>>> -L/sw/lib/octave-2.9.14 -loctinterp -loctave -lcruft -lvtkCommon
 >>>>>>
 >>>>>>to Common/CMakeFiles/octaviz.dir/link.txt

Thomas

I updated with your additions to CVS and added a couple of my own.  The 
only compiling trouble that I still have is the library linking for 
liboctaviz.dylib, for which I use the workaround above.  Do you know how 
the that link.txt file is generated with cmake and how to modify it?  If 
you give me some hints, maybe I figure out how to make it all work in 
Mac OS X.

Thanks,
Jonathan