From: Daniel S. <da...@sa...> - 2009-08-18 15:29:47
|
Hi all, I've sent this question as a Support Request on SFnet and was referred to this mailing list (not without some good initial help, thanks smekal). The case is this: I'm trying to get PLplot to work together with Octave on a (urks) Windows machine. PLplot compiles (and runs) fine for GCC but as soon as I enable the Octave binding, I get this: > mingw32-make [..] [ 43%] Generating plplot_octave.cc, tmp_stub '-' is not recognized as an internal or external command, operable program or batch file. matwrap: C preprocessor exited with error status mingw32-make[2]: *** [bindings/octave/plplot_octave.cc] Error 2 mingw32-make[1]: *** [bindings/octave/CMakeFiles/plplot_octave.dir/all] Error 2 mingw32-make: *** [all] Error 2 The "is not recognized" expression is a Windows command line error message when it tries to open/run something that does not exist. I have traced the error to the perl script matwrap, line ~211 (plus/minus) where it seems that the program wants to try and fork - which, in Windows, leads to problems. What can I do? Greetings from Oslo, Daniel Huge fan of Open Source, but unfortunately bound to Windows. |
From: Andrew R. <and...@us...> - 2009-08-18 18:40:35
|
On Tue, Aug 18, 2009 at 05:03:39PM +0200, Daniel Sachse wrote: > Hi all, > > I've sent this question as a Support Request on SFnet and was referred > to this mailing list (not without some good initial help, thanks smekal). > > The case is this: > > I'm trying to get PLplot to work together with Octave on a (urks) > Windows machine. PLplot compiles (and runs) fine for GCC but as soon as > I enable the Octave binding, I get this: > > > mingw32-make > [..] > [ 43%] Generating plplot_octave.cc, tmp_stub > '-' is not recognized as an internal or external command, > operable program or batch file. > matwrap: C preprocessor exited with error status > mingw32-make[2]: *** [bindings/octave/plplot_octave.cc] Error 2 > mingw32-make[1]: *** [bindings/octave/CMakeFiles/plplot_octave.dir/all] > Error 2 > mingw32-make: *** [all] Error 2 > > > The "is not recognized" expression is a Windows command line error > message when it tries to open/run something that does not exist. > > I have traced the error to the perl script matwrap, line ~211 > (plus/minus) where it seems that the program wants to try and fork - > which, in Windows, leads to problems. What can I do? > > Greetings from Oslo, > Daniel > Huge fan of Open Source, but unfortunately bound to Windows. Daniel, Thank you for your bug report. I don't know whether anyone has tried octave support for windows before - others can better advise on that. The octave support uses matwrap to automatically generate the bindings. Unfortunately this no longer seems to be supported, and this is at least part of the reason that example 19 is not implemented - function callbacks are not supported. I have been considering trying using swig instead. We already use swig for generating the java, python and lua bindings. This might require a bit of work to set up but should in the long run be more flexible and maintainable since we already have some swig experience amongst the developers. It should (?) also be portable to windows. Anyway, back to your current problem. I suspect if you had access to a Linux / Unix box you could generate the necessary files from matwrap there and then copy them to the build tree on your windows box. Unless the plplot octave API changes (relatively uncommon) this will not need to be repeated. Whilst not a perfect solution, it would be interesting to see if this is enough to get a working octave binding. If you would like to try this, but don't have acccess to a linux box then let us know and we can probably send you the files off list. Andrew |
From: Daniel S. <da...@sa...> - 2009-08-18 21:30:54
|
Hi Andrew, Andrew Ross wrote: > I have been considering trying using swig instead. We already use > swig for generating the java, python and lua bindings. This might > require a bit of work to set up but should in the long run be more > flexible and maintainable since we already have some swig > experience amongst the developers. It should (?) also be portable > to windows. I've seen the swig dependencies, ja. I will have a look at it tomorrow, as to the Windows portability. Otherwise I believe it might be possible to replace the forks in the perl program by some other means of recursion, but I haven't checked yet what it does in detail. > > [Use a Linux box and paste the results] Sounds like a good plan to me, I'll give it a try and tell you guys how it worked out. However, a slightly more permanent version would be much appreciated. :-) Greetings from Oslo, Daniel |
From: Daniel S. <da...@sa...> - 2009-08-21 09:06:17
|
I've come a bit further with my Octave/Windows/PLplot problem. For test purposes I replaced the fork in "matwrap" with a simple open. (As far as I understand the fork is supposed to prevent problems with quotes, which I don't have in my calls.) This worked fine, but I'm running into new difficulties: The "matwrap" script now dies like this: unrecognized type 'FI' plplot_octave.h:0: fatal error: when writing output to : Invalid argument compilation terminated. Through extensive debug output I traced this problem to the "parse_str" function, which seems unable to interpret MinGW's stdio.h / stdlib.h and possibly others as well. The garbled call comes in the section "# Look for variable definitions:" around line ~480, where a regexp replacement seems to fail. The following call to "canonicalize_type" consequently fails. When in stdio.h, the regular expression tries to match to, for example $_= typedef struct _iobuf 0 FILE; extern ; FILE* ; FILE* ; int ; int ; int ; int ; FILE* ; char* ; ... and comes up with $1=[](\06, i guess), $2=FI and $3=LE. The catch is probably the typedef ...{...} FILE; , since there is no variable name following. Ideas, anyone? It is annoying that the build fails on a collector/preparation script. ;-) Daniel > On Tue, Aug 18, 2009 at 05:03:39PM +0200, Daniel Sachse wrote: >> Hi all, >> >> I've sent this question as a Support Request on SFnet and was referred >> to this mailing list (not without some good initial help, thanks smekal). >> >> The case is this: >> >> I'm trying to get PLplot to work together with Octave on a (urks) >> Windows machine. PLplot compiles (and runs) fine for GCC but as soon as >> I enable the Octave binding, I get this: >> >> > mingw32-make >> [..] >> [ 43%] Generating plplot_octave.cc, tmp_stub >> '-' is not recognized as an internal or external command, >> operable program or batch file. >> matwrap: C preprocessor exited with error status >> mingw32-make[2]: *** [bindings/octave/plplot_octave.cc] Error 2 >> mingw32-make[1]: *** [bindings/octave/CMakeFiles/plplot_octave.dir/all] >> Error 2 >> mingw32-make: *** [all] Error 2 >> >> >> The "is not recognized" expression is a Windows command line error >> message when it tries to open/run something that does not exist. >> >> I have traced the error to the perl script matwrap, line ~211 >> (plus/minus) where it seems that the program wants to try and fork - >> which, in Windows, leads to problems. What can I do? >> >> Greetings from Oslo, >> Daniel >> Huge fan of Open Source, but unfortunately bound to Windows. |
From: Daniel S. <da...@sa...> - 2009-08-20 12:09:36
|
I've read some more about perl and forking and the problem seems to be here: http://perldoc.perl.org/perlfork.html "The open(FOO, "|-") and open(BAR, "-|") constructs are not yet implemented." Unfortunately, of the workarounds offered in that document, only the "pipe_to_fork" works in Windows (tested on ActivePerl 5.8.0 and Strawberry 5.10.0), "pipe_from_fork" does not. I am wondering, though, why forking is used at all - couldn't one use the backtick operator to capture the output from the C preprocessor? The source code im "matwrap" (lines ~170) mentions that this is "likely to get fouled up if any of the arguments had to be quoted[..]. Instead, we want to use exec() with a list argument." But why not backticks? I tried it and it is at least unaffected by quotes. Alternatively, if the "memory penalty" of reading all that output before parsing it is considered a problem, why not in fact use the simple OPEN open command, but quote the execution string with q{}? Thoughts anyone? Daniel On 18.08.2009 20:40, Andrew Ross wrote: > On Tue, Aug 18, 2009 at 05:03:39PM +0200, Daniel Sachse wrote: >> Hi all, >> >> I've sent this question as a Support Request on SFnet and was referred >> to this mailing list (not without some good initial help, thanks smekal). >> >> The case is this: >> >> I'm trying to get PLplot to work together with Octave on a (urks) >> Windows machine. PLplot compiles (and runs) fine for GCC but as soon as >> I enable the Octave binding, I get this: >> >> > mingw32-make >> [..] >> [ 43%] Generating plplot_octave.cc, tmp_stub >> '-' is not recognized as an internal or external command, >> operable program or batch file. >> matwrap: C preprocessor exited with error status >> mingw32-make[2]: *** [bindings/octave/plplot_octave.cc] Error 2 >> mingw32-make[1]: *** [bindings/octave/CMakeFiles/plplot_octave.dir/all] >> Error 2 >> mingw32-make: *** [all] Error 2 >> >> >> The "is not recognized" expression is a Windows command line error >> message when it tries to open/run something that does not exist. >> >> I have traced the error to the perl script matwrap, line ~211 >> (plus/minus) where it seems that the program wants to try and fork - >> which, in Windows, leads to problems. What can I do? >> >> Greetings from Oslo, >> Daniel >> Huge fan of Open Source, but unfortunately bound to Windows. > > Daniel, > > Thank you for your bug report. I don't know whether anyone has tried > octave support for windows before - others can better advise on that. > The octave support uses matwrap to automatically generate the > bindings. Unfortunately this no longer seems to be supported, and > this is at least part of the reason that example 19 is not > implemented - function callbacks are not supported. > > I have been considering trying using swig instead. We already use > swig for generating the java, python and lua bindings. This might > require a bit of work to set up but should in the long run be more > flexible and maintainable since we already have some swig > experience amongst the developers. It should (?) also be portable > to windows. > > Anyway, back to your current problem. I suspect if you had access to > a Linux / Unix box you could generate the necessary files from > matwrap there and then copy them to the build tree on your windows > box. Unless the plplot octave API changes (relatively uncommon) > this will not need to be repeated. Whilst not a perfect solution, > it would be interesting to see if this is enough to get a working > octave binding. > > If you would like to try this, but don't have acccess to a linux > box then let us know and we can probably send you the files > off list. > > Andrew |
From: Alan W. I. <ir...@be...> - 2010-12-23 02:59:12
|
For testing under wine I have installed octave for Windows following the instructions at http://www.miscdebris.net/plplot_wiki/index.php?title=Install_Octave. A simple test of octave under wine worked fine if I did that directly on a machine where the X-server was located. (This is the configuration that most X users use.) However, wine has X network transparency issues just for the case of octave so I cannot use octave or build its bindings from my normal X-terminal. (I have posted questions about this issue on the wine-devel list and will probably end up writing up a wine bug report about this situation.) So because my simple octave tests worked fine on the "direct X" box, I tried building the octave bindings under MinGW/MSYS/wine on that box, but I ran into the following matwrap error: unrecognized type 'FI' When I googled for that I found the plplot-devel post at http://www.mail-archive.com/plp...@li.../msg03402.html which shows it is a general issue with PLplot + Windows + Octave Apparently the source of the problem is the matwrap perl script is failing to parse MinGW's version of stdlib.h and stdio.h. I can only concur with Daniel's conclusion: <quote> Ideas, anyone? It is annoying that the build fails on a collector/preparation script. ;-) </quote> I presume he has given up by now on PLplot + Windows + Wine, but there was one good idea earlier in that thread from Andrew. <quote> The octave support uses matwrap to automatically generate the bindings. Unfortunately this no longer seems to be supported, and this is at least part of the reason that example 19 is not implemented - function callbacks are not supported. I have been considering trying using swig instead. We already use swig for generating the java, python and lua bindings. This might require a bit of work to set up but should in the long run be more flexible and maintainable since we already have some swig experience amongst the developers. It should (?) also be portable to windows. </quote> Certainly the swig-generated Python and Lua bindings work on the wine version of Windows (and I presume on the Microsoft version of Windows as well). I also assume our swig-generated Java bindings work on Windows although modern MinGW does not support Java (yet) so I haven't tried Java under wine (yet). Anyhow, I think switching to generating our Octave bindings using swig is well worth a try and is much more likely to work on Windows (and deal with the example 19 situation) than attempting to fiddle with the unsupported matwrap approach to try and get it to work on Windows and for example 19. Andrew, the next chance you have to work on PLplot would you be willing to at least start swig-generated octave bindings? I don't really understand octave that well, but if you put together some typemaps for octave for input PLINT, PLFLT, and input strings, that should cover everything you need for example 10. Once example 10 (our simplest example) worked on Linux for you with swig-generated bindings, then I could test that also worked under wine as well. Furthermore, I would be willing to attempt following your octave templates to fill in some of the more difficult typemaps to expand which examples worked. Anyhow, the essential point is to make a start by getting the limited swig-generated octave bindings required for (say) example 10 to work. Once that limited goal is completed, it should be straightforward to gradually expand that typemap support with the ultimate goal of supporting the full PLplot API. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-12-23 20:09:44
|
On 2010-12-22 18:59-0800 Alan W. Irwin wrote: > Andrew, the next chance you have to work on PLplot would you be > willing to at least start swig-generated octave bindings? I don't > really understand octave that well, but if you put together some > typemaps for octave for input PLINT, PLFLT, and input strings, that > should cover everything you need for example 10. Once example 10 (our > simplest example) worked on Linux for you with swig-generated > bindings, then I could test that also worked under wine as well. > Furthermore, I would be willing to attempt following your octave > templates to fill in some of the more difficult typemaps to expand > which examples worked. > > Anyhow, the essential point is to make a start by getting the limited > swig-generated octave bindings required for (say) example 10 to work. > Once that limited goal is completed, it should be straightforward to > gradually expand that typemap support with the ultimate goal of > supporting the full PLplot API. Hi Andrew: Actually, numerical arrays, matrices, and other special constructs need typemaps, but input PLINT, PLFLT, and strings apparently do not. Therefore, I am going to spend a few hours on this project immediately with a no-typemaps plplot_octave.i, and the necessary CMake support (including an option for choosing the swig-based Octave bindings which simultanously limits the examples tested) to see how far I can get (on Linux but also on wine if Linux works) with examples such as example 10 that do not use arrays. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-12-26 09:35:18
|
On 2010-12-23 12:09-0800 Alan W. Irwin wrote: > Hi Andrew: > > Actually, numerical arrays, matrices, and other special constructs > need typemaps, but input PLINT, PLFLT, and strings apparently do not. > Therefore, I am going to spend a few hours on this project immediately > with a no-typemaps plplot_octave.i, and the necessary CMake support > (including an option for choosing the swig-based Octave bindings which > simultanously limits the examples tested) to see how far I can get (on > Linux but also on wine if Linux works) with examples such as example > 10 that do not use arrays. I have gotten a lot farther with this. For example, with a few changes I got the gcd example at http://www.swig.org/Doc1.3/Octave.html#Octave_nn3 to work perfectly which verified for me that swig generates good octave interfaces. I then had similar success with plplot_octave (see below). But now I need some simple octave help to achieve my goal of getting octave example 10 to work on Linux (and wine???) with the swig-generated approach. The current issue is I am making some stupid mistake in how I wrap functions in octave. Can somebody quickly give me a few minutes of octave advice about that issue? With the swig-based approach, I have gotten to the point where I can load the plplot_octave dll from within octave, and successfully initiate PLplot using the following two commands. plplot_octave plplot_octave.plinit() Which agains verifies the swig-generated approach is working (at least on Linux). However, all our octave examples currently drop the plplot_octave namespace so I would like to do that as well (at least as a temporary measure). So instead of the above I am trying to get plplot_octave plplot_stub_hand_crafted plinit() to work where plplot_stub_hand_crafted.m (revision 11388) attempts to drop the plplot_octave namespace using wrappers of the following form: function plinit() plplot_octave.plinit(); endfunction But that doesn't work. I get the following error message: error: can't perform indexing operations for <unknown type> type error: called from: error: plinit at line 189, column 3 (Line 189 of plplot_stub_hand_crafted.m corresponds to " plplot_octave.plinit();" This is how the matrap-generated plplot_stub.m does this instead: function plinit() % plinit() % % Original PLplot call documentation: % % % plinit: Initialize PLplot % % DESCRIPTION: % % This function is used in all of the examples. % % SYNOPSIS: % % plinit() plplot_octave(59); endfunction The 59 means plinit is the 59th PLplot function to be wrapped by matwrap. This way of doing things is a peculiarity of how matwrap interfaces functions (and an indication of the fragile manner that interfacing is done by matwrap). Since plplot_octave.plinit() works when I execute that command by hand for the swig-generated interface, I thought to copy from the matwrap version of plplot_stub.m to the hand-crafted version using plplot_octave.plinit(); while dropping all the % stuff which appears just to be comments. What am I missing? BTW, here is the Linux cookbook of how I am doing my testing of the swig-generated approach. run cmake in an initially empty build tree as normal except you also specify the -DENABLE_swig_octave=ON option. # Build the octave interface to PLplot. make plplot_octave # Change to the correct directory (in anticipation of running x10c.m eventually like plplot_test/test_octave.sh does) and make dependencies of # plplot_octave accessible. cd examples TOPDIR=pwd/.. export LD_LIBRARY_PATH="$TOPDIR"/src:"$TOPDIR"/lib/csa:"$TOPDIR"/lib/nn octave -f -q -p \ /home/software/plplot_svn/HEAD/build_dir/examples/../bindings/octave:/home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/../bindings/octave/PLplot:/home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/../bindings/octave/PLplot/support:/home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/../bindings/octave/misc:/home/software/plplot_svn/HEAD/plplot_cmake_qt/examples:/home/software/plplot_svn/HEAD/plplot_cmake_qt/examples/../bindings/octave I am a bit frustrated at the moment that the wrapping in plplot_stub_hand_crafted.m isn't working quite correctly to drop the plplot_octave namespace because once that namespace dropping works, then all indications are that at least example 10 should just work with the swig-generated approach on Linux (and wine???). Anyhow, quick octave help from anybody with octave experience that is paying attention to this list during these Christmas holidays would be much appreciated. Happy Boxing Day to all. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-12-26 23:40:19
|
On 2010-12-26 01:35-0800 Alan W. Irwin wrote: > I have gotten a lot farther with this. For example, with a few > changes I got the gcd example at > http://www.swig.org/Doc1.3/Octave.html#Octave_nn3 to work perfectly > which verified for me that swig generates good octave interfaces. > > But now I need some simple octave help to achieve my goal of getting > octave example 10 to work on Linux (and wine???) with the > swig-generated approach. The current issue is I am making some stupid > mistake in how I wrap functions in octave. Can somebody quickly > give me a few minutes of octave advice about that issue? Never mind. Although I still don't know how to wrap functions properly in octave, it turns out that the above gcd example lead me astray, and _both_ the specific namespace (e.g., plplot_octave.plinit()) and dropped namespace (e.g., plinit()) are available with the swig-generated octave bindings so function wrapping is not required (for this purpose). Once I understood that accessing the dropped namespace was not an issue, two additional real issues had to be sorted out (revisions 11389 and 11390) and the result is x10c.m "just works" on Linux with the swig-generated interface. That good result fundamentally validates this whole idea. The current status is I am expanding the list of octave examples to be tested to include the few more beyond standard example 10 which do not use array arguments. Once those additional examples give good results on Linux, then I will try a wine test, and assuming that works, the next step is to introduce more typemaps dealing with arrays, etc., so that the tested examples can be expanded to the full list of both "x" and "p" octave examples. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-12-27 10:58:02
|
On 2010-12-26 15:40-0800 Alan W. Irwin wrote: > The current status is I am expanding the list of octave examples to be > tested to include the few more beyond standard example 10 which do not > use array arguments. It turns out every example other than 10 has some call to a PLplot function that has an argument that uses one of the current placeholder typemaps for octave. So expansion to more examples will have to wait until those placeholder typemaps get defined properly. I have also streamlined and corrected the build-system logic for the -DENABLE_swig_octave=ON case. The result is to use swig-generated octave bindings rather than matwrap-generated ones, all you need to do is specify -DENABLE_swig_octave=ON, and the build system does the rest. Here are the current results on the Linux platform for the test_diff_psc target in that case: octave Missing examples : 01 02 03 04 05 06 07 08 09 11 12 13 14 14a 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 33 Differing postscript output : Missing stdout : Differing stdout : which shows that all but 10 is missing (as expected since only example 10 is currently run for this case), but the results for that example are perfect (no diffs). There are three issues I am aware of for the swig-generated octave bindings as a result of my Linux platform tests. 1. An extremely minor issue is that the plplot_octave command needs to be wrapped as "plplot_stub" so those using the swig bindings (once those are completed) will still be able to use the plplot_stub command to gain access to plplot from octave. (I currently avoid this issue via configuration of test_octave.sh. That takes care of the issue for the automated testing environment, but such configuration does not help interactive users.) 2. A less minor issue, is you cannot use the gcc option -fvisibility=hidden on Linux (I don't use this option in any case for MinGW/MSYS/wine) because that hides plplot_octave completely (and silently except for a puzzling plplot_octave undefined error which took me quite a while to track down). I believe this must be due to a bug in swig octave support because we have no visibility issues like this in our swig-generated Python, Java, and Lua bindings. 3. The important issue is that the placeholder typemaps need to be worked on in bindings/octave/plplot_octave.i so that the entire PLplot API becomes accessible to the swig-generated octave bindings which will allow running all the examples. These typemaps should be straightforward to fix since the code generated by matwrap is available as a template of what to do for each kind of PLplot API argument. I have ignored these issues for now and have moved on to the wine build and test of our swig-generated octave bindings. That is looking quite promising. The build got quite far before an issue was encountered concerning finding the hdf5.h header file. I will deal with the necessary build-system tweak after I get some sleep. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-12-28 07:01:40
|
On 2010-12-27 02:57-0800 Alan W. Irwin wrote: > That [build and test of our swig-generated octave bindings on wine] is looking > quite promising. I got plplot_octave.oct built on wine, but there were conflicting library issues. For example, octave wanted one version of libstdc++-6.dll in Octave/3.2.4_gcc-4.4.0/bin (note that is for MinGW-4.4) that was part of the octave binary download while plplot_octave.oct wanted another version of that file that was part of the MinGW-4.5 download. The result was that octave errored out with a missing symbol (in the MinGW version but not in the octave version of libstdc++-6.dll according to "objdump -p") whenever I tried to dynamically load plplot_octave. I "sort of" solved that by renaming the octave version of libstdc++-6.dll to something else which forced octave to use the MinGW version. That allowed a successful load of plplot_octave, then further plplot commands (such as plinit()) just hung which is a symptom of further library conflict issues between the two MinGW versions of the libraries or possibly other issues as well. This is not a Windows problem. You would get similar issues on Linux if you tried to use, say, RedHat libraries on Debian. I think the only reliable away around library version conflict issues is to build octave with the same compiler version used to build plplot_octave. But octave itself has a huge number of dependencies which would have to be built as well with that same MinGW compiler version. So ultimately what is needed here is a coherent MingGW-based distribution of software. We actually have the start of that with the octave binary distribution; Octave/3.2.4_gcc-4.4.0/bin contains 80 (!) dll's because of the huge number of external dependencies of Octave. But that "distribution" is not complete. So I am giving up on octave for Windows for now until the Octave-forge developers provide a version compatible with MinGW-4.5. (I could also fall back to MinGW-4.4 myself, but then I would lose the huge convenience of the automatic installer that is available for MinGW-4.5 (and the latest version of MSYS). In fact, I think that huge convenience factor is going to motivate a lot of Windows packagers to move from earlier MinGW versions to MinGW-4.5 so I don't think my wait for octave (and also the Qt4 suite of libraries which have similar issues) to move to MinGW-4.5 will be too long. Note, although my Octave on Windows efforts are temporarily suspended the primary motivation (i.e., our group knows how to deal with swig typemap issues but not matwrap issues) remains for implementing swig-generated octave binding. For example, with swig-generated octave bindings Andrew tells us there is a chance of dealing with the API issues for example 19 in octave. Anyhow, for the next few days I plan to see how far I can get with implementing correct swig/octave typemaps using the matwrap-generated interface code as a guide for what to do with the typemaps. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-12-29 06:47:24
|
Here is the current status of the swig bindings for octave as of revision 11398. I completed all vector-related typemaps today, and the result is roughly half the octave examples now work which is excellent progress if I do say so myself. :-) To try these experimental bindings for yourself, all you have to do is specify -DENABLE_swig_octave=ON as one of your cmake options. Here are the results you should currently get with the test_noninteractive target. octave Missing examples : 01 02 08 09 11 14 14a 15 16 17 19 20 21 22 23 28 29 31 33 Differing postscript output : 04 18 26 Missing stdout : Differing stdout : The list of 14 examples that work are i=[3 4 5 06 07 10 12 13 18 24:27 30] The missing 33 and differing 4, 18, and 26 are all propagation issues which I will leave until later. The remaining 18 "missing" examples are that way because I deliberately avoided them with the above "i=" line in test_octave.sh so that the test would complete without errors. Known issues at the moment are the typemaps for the 2D matrices, values returned from PLplot to the octave environment, and callbacks. I hope to deal with first of those issues tomorrow (Wednesday). That should be the last of the low-hanging fruit and progress should be slower after that, but I am confident that the full list of examples available under the matwrap-wrapped bindings, i.e., i=[1:18 20:31] will become available fairly soon with the swig-wrapped octave bindings. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-12-31 22:19:10
|
On 2010-12-28 22:47-0800 Alan W. Irwin wrote: > Here is the current status of the swig bindings for octave as of > revision 11398. > > [...]Here are the results you should currently get with the > test_noninteractive target. > > octave > Missing examples : 01 02 08 09 11 14 14a 15 16 17 19 20 21 22 23 28 29 31 33 > Differing postscript output : 04 18 26 > Missing stdout : > Differing stdout : As of revision 11407 the results look substantially better; octave Missing examples : 08 09 11 14 14a 15 16 19 20 21 22 28 29 33 Differing postscript output : 04 18 26 Missing stdout : Differing stdout : The missing 33 and differing 4, 18, and 26 are all propagation issues and Example 19 is a long-standing issue. These issues will be left until later. The remaining 11 "missing" examples are that way because I deliberately avoided them mostly because of known issues with 2D matrices and callbacks which I am currently working on. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2011-01-02 03:00:38
|
On 2010-12-31 14:18-0800 Alan W. Irwin wrote: > As of revision 11407 the results look substantially better; > > octave > Missing examples : 08 09 11 14 14a 15 16 19 20 21 22 28 29 33 > Differing postscript output : 04 18 26 > Missing stdout : > Differing stdout : > > The missing 33 and differing 4, 18, and 26 are all propagation issues > and Example 19 is a long-standing issue. These issues will be left > until later. > > The remaining 11 "missing" examples are that way because I > deliberately avoided them mostly because of known issues with 2D > matrices and callbacks which I am currently working on. As of revision 11427 the results look even better; octave Missing examples : 19 20 21 22 33 Differing postscript output : 04 18 26 Missing stdout : Differing stdout : There are three to go (20, 21, and 22) before the swig-generated octave bindings produce as good diff results as the matwrapped bindings. I hope to finish this off tomorrow. Happy New Year! Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2011-01-03 08:34:02
|
Hi Andrew: Here are the swig-generated octave bindings diff results as of revision 11431: octave Missing examples : 19 33 Differing postscript output : 04 18 26 Missing stdout : Differing stdout : That is, I now obtain the same diff diagnostic results with the new swig-generated octave bindings as I do with the original matwrapped ones. Despite my fundamental lack of octave knowledge, I was able to achieve this success quite rapidly because swig allowed me to borrow (somewhat blindly) from the previous matwrap work by Joao Cardoso, Rafael Laboissiere, and you in an efficient manner. Could you take a look at what I have done with swig? In particular, I felt my copying of some of the wrappers (especially the laborious transformation of matrix results) used in matwrap was not really taking full advantage of swig capabilities. Also from some of the machinations done in plplot_octave.i it is clear there are some unnecessary differences between the PLplot octave and C API's which I have continued to preserve so as not to introduce octave PLplot API breakage (except in not vectorizing some of the scalar PLplot functions for the reasons explained in plplot_octave.i). At this point you might wish to declare a PLplot octave bindings API break and change plplot_octave.i to reduce or eliminate those gratuitous differences, but I leave that judgement call to you. There are still some issues to work out with this new set of bindings for octave, and I hope you will be able to help with those. 1. You cannot use the gcc option -fvisibility=hidden on Linux. No such issue occurs for our Python, Java, and Lua bindings so I may have forgotten something obvious that is done for those other bindings or there may be some bug in swig octave support that needs to be addressed by the swig developers. 2. The octave help command does not work for PLplot functions. The way this is implemented for the matwrapped approach is the help files generated by the make_documentation target are integrated into plplot_stub.m by the "massage" programme by wrapping each raw octave bindings call with a documented version. So massage.c has to be changed to do this same integration for the swig-generated octave bindings as well. Despite these issues, my feeling is that we should use the swig-generated bindings from here on out. The advantages are that addition of new API usually comes automatically and simultaneously for Python, Java, Lua, and now Octave, through a single simple change to bindings/swig-support/plplotcapi.i, and the maintenance of the swig-generated bindings for octave should be straightforward. Therefore, I have enabled (revision 11432) the swig-generated bindings by default which means that to obtain the old matwrapped bindings you must now specify -DENABLE_swig_octave=OFF. The only other octave plans I have at the moment are to get rid of the propagation issues that affect examples 04, 18, 26, and 33 using the swig-generated bindings approach. That should leave Example 19 still unimplemented because I don't believe I have the octave skill to deal with it. As you indicated before there is at least some chance of dealing with it using swig-generated bindings (as opposed to the matwrapped bindings where there was little chance) so I hope you will take it on. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: David M. <da...@as...> - 2011-01-03 16:39:34
|
Hi, Alan, On Jan 3, 2011, at 12:33 AM, Alan W. Irwin wrote: > Could you take a look at what I have done with swig? In particular, I > felt my copying of some of the wrappers (especially the laborious > transformation of matrix results) used in matwrap was not really > taking full advantage of swig capabilities. I'm no expert on Octave internals, but I assume they have a certain structure for representing matrices, so maybe it would be worthwhile to create a set of "plf2ops" functions to allow use of their matrix format without any copying/rearranging of data. Just an idea, Dave |
From: Alan W. I. <ir...@be...> - 2011-01-08 19:01:08
|
On 2011-01-03 00:33-0800 Alan W. Irwin wrote: > Here are the swig-generated octave bindings diff results as of revision > 11431: > > octave > Missing examples : 19 33 > Differing postscript output : 04 18 26 > Missing stdout : > Differing stdout : Here are the same diff test results as of revision 11456 octave Missing examples : 19 Differing postscript output : 04 26 Missing stdout : Differing stdout : In particular note that example 33 (full of pllegend calls) has been implemented (starting from the python template for example 33) in octave and gives (with the swig-generated results since the matwrapped ones are unable to deal with the pllegend argument list) identical results to the corresponding C results. I plan to update octave examples 4 and 26 today (those updates also involve pllegend so I will be removing those examples from the matrapped list of examples to test) to eliminate the above differences for those examples. One octave issue I had to solve before I could produce the above results was the global symbol problem. Our octave examples currently contain some statements setting up variables to mimic the PLplot constants such as PL_NOTSET = -42.0 in x31c.m. The reason for such statements was the previous version of plplot_octave_def was much too limited and only set up a small subset of the global PLplot constants. I now generate plplot_octave_def from the #define's in bindings/swig-support/plplotcapi.i using a sed script which means, for example, the above statement can be replaced by global PL_NOTSET without having to refer to any specific value in the example. (This improvement should also work for the matwrapped case). This change made the implementation of example 33 much less error-prone because a large number of global PLplot constants are used in that example. Some concern has been expressed here before about how to interface the array of strings (const char **) arguments in pllegend for each language. When working on this question for octave, I realized this is an easy issue for most languages. All you have to do is copy a lot of what is done for that similar sort of argument for plstripc (which specifically has 4 elements rather than nlegend elements but otherwise is the same). So don't let that concern discourage you from creating pllegend API and updating examples 4 and 26 and creating example 33 to test and demonstrate pllegend for your favorite language. :-) Ironically, it turns out for the octave case that interfacing const char ** arguments was a new issue that had to be solved largely from scratch. For that language, plstripc has a different API which uses 4 character string arguments rather than the array of 4. Thus, I was breaking into new territory with pllegend. I started out with little familiarity with octave so it took me a while to figure out what to do, but I finally solved the issue as you can see above. There is still one more variation that needs doing with interfacing the const char ** arguments for octave. I got the above good result for example 33 using a charMatrix type of octave argument. Those type of chacter string arrays are the ones which most octave users are familiar with. However, such string arrays are clumsy to handle from the octave side (as you can see from x33c.m, where there is a lot of fooling around with the text and symbols matrices to get them to behave properly). The fundamental issue with this approach is unsigned char attributes have been imposed on what are considered to be numerical matrices with a uniform number of columns corresponding to the characters in the strings. So, for example, all character strings in the array are padded with blanks to equal the length of the longest character string in the array. An alternative, much more natural approach to using character string arrays from octave is to store the character strings as elements of an octave cell array. So implementing the char ** alternative for that style of string array storage is on my near-term octave agenda. familiar with octave. The final octave concern of interest to me is the lack of help results I mentioned previously for the swig-generated case. Andrew has kindly found a swig-based method of dealing with that issue which I hope to implement in the next few days. So in sum, I am going to be busy with the swig-generated bindings for octave for something like another week, but at least the end is finally in sight (except for the implementation of example 19 which I will be leaving for someone else to do). I also want to comment that through my experiments with octave, I now realize just what a powerful and useful platform it is which obviously deserves an absolutely first-class PLplot implementation. I feel we are well along toward that goal now. The Octave PLplot bindings and low-level (x??c.m) standard example fundamentals are obviously rounding into shape using a swig-based approach which has already gone substantially beyond what is possible with the matwrapped approach. Furthermore, Andrew has expressed interest off-list in making the high-level octave interface first class as well once he gets a breathing space to work on PLplot again, and that is an extremely encouraging sign for the future of PLplot on octave. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |