Re: [Plplot-devel] [Plplot-general] About plfill, plline, plmap and request of functionalities
On 2011-01-03 17:57-0800 Alan W. Irwin wrote: > To sum this up, the bad wingcc and qt results are probably due to > external library issues combined with issues in plfill while the bad > psc (which depends on no external library) and cairo (which depends on > a subset of the GTK+ stack of libraries) results are likely due to > issues in plfill. I have just looked at some additional results for -dev svgqt (depends on Qt4); -dev svg (which has no external library dependencies at all); and -dev svgcairo (depends on GTK+ stack). The results for -dev svgqt were bad for page 11 on up following the bad results for the other qt-related devices. There might be something obvious in the qt driver code, but I cannot see it so I ascribe this issue to something wrong for the Qt4 libraries. The svg, svgcairo (and all other cairo devices I have checked), and psc all agree in detail with each other. The consistent fill errors for page 13 and above for all of these constitutes a strong case that there is a fill bug in plfill for complicated boundaries. I also confirmed some of the above results for the npts=240 case for x27c.c, and I suggest you might find it valuable to try that case as well. That value assures all plline, plfill, and plgradient calls are below the PL_MAXPOLY limit of 256. The boundary, although much more irregular for the smaller number of points is also much easier to interpret with the odd/even rule. For this small npts case (which cannot involve the malloc version used when npts > PL_MAXPOLY-1), wxwidgets hangs at page 12 (just like for normal npts), while xcairo gives bad filling results for page 13 and above similar to those that occur for the svg, cairo, and psc devices for the normal npts case. So whatever is wrong with fills for these devices has nothing to do with the malloc versus static array PL_MAXPOLY logic that has been recently introduced. So the good news is the filling errors now shown by example 27 are not a regression. The bad news is this is a long-standing fill bug which we didn't know we had before. :-) 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 __ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] About plfill, plline, plmap and request of functionalities
On 2011-01-03 09:51+0100 Arjen Markus wrote: > Hi Alan, > > I just committed the changes: the individual curves > are now drawn both as polylines and as filled curves. > While I do not think it is all that well-defined (some > of the curves are very convoluted, in the colloquial > sense, not the geometrical one), it does give some > interesting results. The deltoid for instance, a > non-intersecting curve, is NOT filled by the wingcc > device. This may be due to a bug in the underlying Windows library that supports wingcc, and other windows users that use a different windows platform than you might have success with this fill. I get similar bad results (just the outline, no fill for pages 11-13, partial but incorrect fills above that) here for the epsqt and epspng devices. For the qtwidgets device page 11 is okay, but the following pages hang. I have looked through the qt driver and see no issues for large numbers of boundary points for fills. Everything just boils down to a call to drawPolygon (see http://pepper.troll.no/s60prereleases/doc/qpainter.html#drawPolygon) which has a default odd/even filling rule (see discussion below). These issues may be cleared up in some future release of Qt, but if we eventually get perfect results for other devices and still bad results for Qt I will send in a bug report to encourage TrollTech/Nokia to make the fix. > It is for the PostScript output. The next > one in line, a curve like the deltoid but with three > loops in stead of cusps gets partly filled - the > loops are. I don't quite follow this last sentence, but my analysis (see below) is that this figure (page 12) should have everything inside the outer boundary filled. > > I assume you will see the same sort of things with > wine. Actually it is easier for me to test your recent commits on Linux. Before getting started with the psc case, it would be good to review http://en.wikipedia.org/wiki/Point_in_polygon. We use the ray casting algorithm (also known as the even/odd rule especially when dealing with self-intersecting, i.e, complex polygons) to decide what is inside and outside a given polygon so our fill results should correspond to that rule as well. Note that http://pepper.troll.no/s60prereleases/doc/qt.html#FillRule-enum also has a good discussion of the even/odd filling rule versus the non-zero winding number filling rule. The page 2 boundary is simple so everything inside it gets filled and the corresponding psc page 11 results confirm that. The page 3 boundary is our simplest complex polygon case. The inner area AND the outward-pointing loops are all accessible with a straight line that undergoes 1 intersection with an edge of the polygon so all those areas should be filled, and the corresponding page 12 psc results confirm that. Those good page 11 and page 12 fill results indicate to me that the malloc method of dealing with large numbers of boundary points for plfill is working properly which is an important result. For more complex boundaries (corresponding to page 4 and up), we appear to run into logic issues in how plfill decides to fill the polygon. The fourth-page boundary analysis shows the inward-facing loops are accessible with two intersections with a straight line so should be _excluded_ from the fill. The page 13 psc results fill those loops which is an error. The fifth-page boundary analysis shows the outer loops and the innermost areas are accessible with a straight line with an odd number of boundary intersections so the loops and innermost area should be filled which the psc device does for the corresponding page 14 results. But in between the two there is a symmetrical patchwork that should consist of unfilled and filled areas. The page 14 psc results do something similar, but don't select the correct filled and unfilled areas in the patchwork region which is a clear fill error, and also for the right-hand-side of the figure lose the expected symmetry which is also a clear fill error. The pscairo fill results seem exactly equivalent to the psc results so that supports the idea that the fill errors noted above are due to a plfill logic issue rather than a driver issue. Another possible interpretation is something is wrong with my PostScript viewer's rendering of a long self-intersecting boundary polygon that needs to be filled, but that interpretation is shot down by the xcairo and pngcairo results which are viewed completely independently and which show the exact same (bad) fill patterns as the pscairo and psc devices. To sum this up, the bad wingcc and qt results are probably due to external library issues combined with issues in plfill while the bad psc (which depends on no external library) and cairo (which depends on a subset of the GTK+ stack of libraries) results are likely due to issues in plfill. Off list I will send you the compressed results for the psc device (which is 1.6MB despite the compression which is why I am not sending it to the list) so you c
Re: [Plplot-devel] Building on Mac OS X 10.6 (aka Snow Leopard)
On 2011-01-03 10:37-0800 David MacMahon wrote: > I'm slowly getting back to some plplot development. Since my last involvement with plplot, I have received a new computer with Mac OS X 10.6.5 (aka Snow Leopard) and a 64 bit processor (Intel Core i5). I noticed a few issues when building plplot on this new system. I'm documenting them all here for posterity, though I have a few questions mixed in. Apologies in advance for the lengthiness. Hi Dave: Thanks for your continued strong interest in PLplot. I cannot help you with specifics on the build-system issues you have brought up because I don't have access to Mac OS X myself, but my general feeling is that our developers with access to that platform (i.e., Hazen, Werner, and Jerry) all have different methods of avoiding build-system issues like you have discovered on that platform. Instead, of such a "avoidance" approach like you what I would like to see is a PLplot build system for Mac OS X that builds (or drops with an explanatory message if the environment is not right) the components of PLplot just as smoothly as it does on Linux. Therefore, I urge all of you to work together toward achieving that goal. Dave, that probably means you are going to have to learn more cmake logic, but that is pretty straightforward, and enhanced CMake logic skills are well worth having for developers these days since CMake is used to build so many different software packages. 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 __ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Broken drivers/tkwin.c?
On 2011-01-03 08:36-0800 David MacMahon wrote:
> I also noticed this when compiling tkwin.c...
>
> drivers/tkwin.c:398: warning: assignment makes pointer from integer without a
> cast
>
> This is because XOpenDisplay is not declared in any #included files. I think
> because I'm on Mac OS X and Tk is not based on X11 on that platform. I see a
> lot of "#ifdef MAC_TCL" in the source code, but I can't find that being
> #defined (or #undefed) anywhere nor any cmake files that refer to the MAC_TCL
> macro.
>
> Thanks again,
> Dave
>
> P.S. Here's the full command line that make used and the resulting output...
>
> cd /Users/davidm/local/src/plplot/tmp/drivers && /opt/local/bin/gcc
> -Dtkwin_EXPORTS -DHAVE_CONFIG_H -arch i386 -isysroot
> /Developer/SDKs/MacOSX10.6.sdk -fPIC -I/Users/davidm/local/src/plplot/include
> -I/Users/davidm/local/src/plplot/lib/qsastime
> -I/Users/davidm/local/src/plplot/lib/nistcd
> -I/Users/davidm/local/src/plplot/tmp
> -I/Users/davidm/local/src/plplot/tmp/include
> -I/System/Library/Frameworks/Tcl.framework/Headers
> -I/System/Library/Frameworks/Tk.framework/Headers -I/usr/include
> -I"/Users/davidm/local/src/plplot"/bindings/tcl
> -I"/Users/davidm/local/src/plplot/tmp"/bindings/tcl
> -I"/Users/davidm/local/src/plplot"/bindings/tk-x-plat
> -I"/Users/davidm/local/src/plplot"/bindings/tk -DUSINGDLL -o
> CMakeFiles/tkwin.dir/tkwin.c.o -c
> /Users/davidm/local/src/plplot/drivers/tkwin.c
>
> /Users/davidm/local/src/plplot/drivers/tkwin.c: In function 'plD_open_tkwin':
> /Users/davidm/local/src/plplot/drivers/tkwin.c:398: warning: assignment makes
> pointer from integer without a cast
> /Users/davidm/local/src/plplot/drivers/tkwin.c: In function 'Init':
> /Users/davidm/local/src/plplot/drivers/tkwin.c:946: warning: assignment makes
> pointer from integer without a cast
> /Users/davidm/local/src/plplot/drivers/tkwin.c:959: warning: assignment makes
> pointer from integer without a cast
> /Users/davidm/local/src/plplot/drivers/tkwin.c: In function 'CreatePixmap':
> /Users/davidm/local/src/plplot/drivers/tkwin.c:1235: warning: assignment
> makes pointer from integer without a cast
Hi Dave:
Please insert the following line
message(STATUS "tkwin_COMPILE_FLAGS = ${tkwin_COMPILE_FLAGS}")
in cmake/modules/tk.cmake right after tkwin_COMPILE_FLAGS is defined,
then rerun cmake from an empty build tree while collecting its full
output to send here as an attachment to help us to figure out what is
going wrong above.
It has been a very long time since I have looked at the tkwin "device",
but here is some background (from memory and from looking at
cmake/modules/tcl-related.cmake and cmake/modules/tk.cmake.)
The tkwin "device" is usually built by default but rarely tested. As
far as I can remember it is actually a shared object/dll that is meant
to be dynamically loaded by wish rather than a PLplot device driver
that is meant to be dynamically loaded by our core C library.
tk.cmake says tkwin won't get built unless Tk is enabled. Most
Tk-related components of PLplot use the extended Tk that depends on X.
So in general Tk won't be enabled unless X was found. Thus, since
your build system is evidently building tkwin on Mac OS X, your cmake
output requested above should report that X was found and Tk enabled.
It should also give specifics about where X was found i.e.,
X11_INCLUDE_DIR and X11_LIBRARIES.
There is the cmake command
message(STATUS "TK_INCLUDE_PATH = ${TK_INCLUDE_PATH}")
in tcl-related.cmake so you should see that result in the cmake
output. If you look a few lines up in the file, TK_INCLUDE_PATH
includes X11_INCLUDE_DIR. If you follow the logic in tk.cmake,
tkwin_COMPILE_FLAGS should depend on a transformed version of
X11_INCLUDE_DIR, that is the above build should include -I flags that
point to the X location. The modified cmake result asked for above
should show what is contained in tkwin_COMPILE_FLAGS, and thus give us
a better idea of what is going on.
If you get further puzzling results, I encourage you to scatter
"message(STATUS ..." commands around in our build-system files to help
diagnose what is going on. From my review of our build system files
it appears to me that our build-system logic should be working OK to
propagate X11_INCLUDE_DIR where it is needed for the tkwin build, but
it is possible the original value of X11_INCLUDE_DIR is screwed up.
We will see
BTW, once tkwin is built without warnings for you, I believe you can
test it by following the last paragraph (the one involving
tk-x-plat) in examples/tk/README.tkdemos.
Thanks in advance.
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 Loa
[Plplot-devel] Building on Mac OS X 10.6 (aka Snow Leopard)
I'm slowly getting back to some plplot development. Since my last involvement with plplot, I have received a new computer with Mac OS X 10.6.5 (aka Snow Leopard) and a 64 bit processor (Intel Core i5). I noticed a few issues when building plplot on this new system. I'm documenting them all here for posterity, though I have a few questions mixed in. Apologies in advance for the lengthiness. = freetype I think freetype is only for older plplot devices like the gd driver, but I'm not sure. Please correct me if I'm wrong, but as I recall, freetype is not used by the xwin driver, which I think is Hershey fonts only. In any event, I installed freetype using MacPorts so it lives under /opt/local rather than /usr/local so the FindFreetype.cmake module didn't find it. If this ends up being an issue, it is easy to solve through cmake command line options or adding suitable paths to FindFreetype.cmake. = wxwidgets Snow Leopard includes wxwidgets 2.8, which links to Apple's 32-bit-only Carbon framework rather than the 64-bit-capable Cocoa framework. Therefore anything, such as plplot, that links to the wxwidgets libraries on Snow Leopard must also be 32 bit. So apparently one must choose between 64-bit plplot without wxwidgets or 32-bit plplot with wxwidgets. wxwidgets 2.9 on Mac OS X links to the Cocoa framework so that would work with 64-bit plplot (assuming that plplot is compatible with wxwidgets 2.9). I found this out fairly late in the build when the link failed. I think the cmake tests could be updated to detect the architecture difference and disable the wxwidgets stuff if it is found to be incompatible. I chose to build plplot using the i386 architecture rather than the x86_64 architecture by running... cmake -DCMAKE_OSX_ARCHITECTURES:STRING=i386 .. This enabled the "-arch i386" compiler flag, which means that I have to use one of Apple's gcc versions since the gcc versions I installed via MacPorts seem to croak on this option. This has the side effect of eliminating Fortran since (AFAIK) Apple doesn't provide a Fortran compiler. Maybe I could use Apple's gcc and MacPorts gfortran, but I don't really need Fortran support, so I've not investigated that hybrid configuration. = qhull In the output of the above cmake command, I noticed that HAVE_QHULL is now OFF. This is because I had installed it via MacPorts as a "non-universal" binary so it had only x86_64 support in it. I reinstalled it as a universal binary. = octave I installed Octave 3.2.4 via MacPorts. The MacPorts octave "portfile" does not build or provide a way to build a universal binary, so my octave in x86_64 only so I can't use it and wxwidgets. = pthread Does anyone know if the comments in cmake/modules/xwin.cmake about pthread on Mac OS X 10.4 and 10.5 are still relevant for 10.6? I'd be happy to try this out if someone can let me know what to look for in terms of working vs not working. = agg HAVE_AGG is blank (i.e. neither ON nor OFF) even though I have it installed. It seems like this is only used by wxwidgets with freetype, but since I don't have freetype enabled (see above) it makes sense that this would be blank. It does get me wondering more about the wxwindows and freetype stuff. What is the status of the wxwidgets driver and bindings? They defaulted to ON which leads on to think they are not deprecated. If I eliminate the wxwidgets stuff I think I would be able to switch back to an x86_64 build, but I kind of like the concept of plplot inside a wxwidgets application. = cairo I also discovered that I needed to re-install cairo as a universal binary. Again, this happened part way through the build. Does cmake not try to link against libraries that it finds or does it not use the same flags (e.g. -arch i386) used to build plplot? It seems like cmake should have been able to tell me that my x86_64 cairo installation was not usable with the CMAKE_OSX_ARCHITECTURE setting I used, but I only found out part way through the build. = aquaterm I was unable to build the aquaterm driver. The output of cmake included "-- Found AQT: /opt/local/include/AquaTerm/AQTAdapter.h", but when I run "make VERBOSE=1" I get... cd /Users/davidm/local/src/plplot/tmp/drivers && /opt/local/bin/gcc -Daqt_EXPORTS -DHAVE_CONFIG_H -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk -fPIC -I/Users/davidm/local/src/plplot/include -I/Users/davidm/local/src/plplot/lib/qsastime -I/Users/davidm/local/src/plplot/lib/nistcd -I/Users/davidm/local/src/plplot/tmp -I/Users/davidm/local/src/plplot/tmp/include -ObjC -DUSINGDLL -o CMakeFiles/aqt.dir/aqt.c.o -c /Users/davidm/local/src/plplot/drivers/aqt.c /Users/davidm/local/src/plplot/drivers/aqt.c:33:32: error: AquaTerm/AQTAdapter.h: No such file or directory Why is there no "-I/opt/local/include" on the gcc command line given that cmake found the required header file "/opt/local/include/AquaTerm/AQTAdapter.h"? FWIW, the di
Re: [Plplot-devel] Broken drivers/tkwin.c?
On Jan 3, 2011, at 8:36 AM, David MacMahon wrote: > Thanks, Argen! I meant: Thanks ArJen! Sorry for the typo. Dave -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PLplot + Windows + Octave
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 -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Broken drivers/tkwin.c?
Thanks, Argen! I also noticed this when compiling tkwin.c... drivers/tkwin.c:398: warning: assignment makes pointer from integer without a cast This is because XOpenDisplay is not declared in any #included files. I think because I'm on Mac OS X and Tk is not based on X11 on that platform. I see a lot of "#ifdef MAC_TCL" in the source code, but I can't find that being #defined (or #undefed) anywhere nor any cmake files that refer to the MAC_TCL macro. Thanks again, Dave P.S. Here's the full command line that make used and the resulting output... cd /Users/davidm/local/src/plplot/tmp/drivers && /opt/local/bin/gcc -Dtkwin_EXPORTS -DHAVE_CONFIG_H -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk -fPIC -I/Users/davidm/local/src/plplot/include -I/Users/davidm/local/src/plplot/lib/qsastime -I/Users/davidm/local/src/plplot/lib/nistcd -I/Users/davidm/local/src/plplot/tmp -I/Users/davidm/local/src/plplot/tmp/include -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -I/usr/include -I"/Users/davidm/local/src/plplot"/bindings/tcl -I"/Users/davidm/local/src/plplot/tmp"/bindings/tcl -I"/Users/davidm/local/src/plplot"/bindings/tk-x-plat -I"/Users/davidm/local/src/plplot"/bindings/tk -DUSINGDLL -o CMakeFiles/tkwin.dir/tkwin.c.o -c /Users/davidm/local/src/plplot/drivers/tkwin.c /Users/davidm/local/src/plplot/drivers/tkwin.c: In function 'plD_open_tkwin': /Users/davidm/local/src/plplot/drivers/tkwin.c:398: warning: assignment makes pointer from integer without a cast /Users/davidm/local/src/plplot/drivers/tkwin.c: In function 'Init': /Users/davidm/local/src/plplot/drivers/tkwin.c:946: warning: assignment makes pointer from integer without a cast /Users/davidm/local/src/plplot/drivers/tkwin.c:959: warning: assignment makes pointer from integer without a cast /Users/davidm/local/src/plplot/drivers/tkwin.c: In function 'CreatePixmap': /Users/davidm/local/src/plplot/drivers/tkwin.c:1235: warning: assignment makes pointer from integer without a cast -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] About plfill, plline, plmap and request of functionalities
Hi Alan, I just committed the changes: the individual curves are now drawn both as polylines and as filled curves. While I do not think it is all that well-defined (some of the curves are very convoluted, in the colloquial sense, not the geometrical one), it does give some interesting results. The deltoid for instance, a non-intersecting curve, is NOT filled by the wingcc device. It is for the PostScript output. The next one in line, a curve like the deltoid but with three loops in stead of cusps gets partly filled - the loops are. I assume you will see the same sort of things with wine. I have not tried the gradients yet. That is a next step, later this week. Regards, Arjen On 2010-12-30 20:01, Alan W. Irwin wrote: > On 2010-12-30 09:04+0100 Arjen Markus wrote: > >> Also, none of the examples really use large polygons, so the >> new parts of the patch will formally go untested. > > Hi Arjen: > > What do you think of the idea of extending example 27 for this purpose > by adding pages where plline is replaced by plfill and plgradient? > > Extending most of the pages of the current example by replacing plline > with either plfill or plgradient would test our drivers' ability to > handle self-intersecting boundaries for fills and gradients. However, > I suspect that none of our drivers could properly handle that case at > the moment. If that is correct you could restrict the page extensions > just to the current page 2. That boundary does not self-intersect, > but it has sufficent points to test the present change. > > Please give me notice when you do make your commit so I can test the > new logic on all devices not accessible to you. > > 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 > __ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PLplot + Windows + Octave
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 __ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] About plfill, plline, plmap and request of functionalities
Hi José, hm, your comments were not in the patch files I used. I have added these comments now. (I also put in your name in the release notes as note 2.46). Just committed the changes. Regards, Arjen On 2010-12-30 15:33, José Luis García Pallero wrote: > El día 30 de diciembre de 2010 09:04, Arjen Markus > escribió: >> Hello, >> >> I have finished the work on the source files that use PL_MAXPOLY >> sized arrays. All now use either the statically defined arrays or >> allocated arrays if needed. >> >> I wonder about one file though: xfig.c. One function in this driver >> checked the number of points, but it gets passed an array with all >> the data in there already. Is it that the xfig format does not >> allow polygons of more than 256 points? (I never use that format >> and I am unfamiliar with its capabilities and limitations). >> In any case I have removed the check. >> >> I will run the code through the comprehensive test script before >> committing, but my system does not do anything with xwin.c, tkwin.c >> or plr.c, so there may be syntax errors in there. >> >> Also, none of the examples really use large polygons, so the >> new parts of the patch will formally go untested. >> >> Regards, >> >> Arjen > > Hello, > Thanks for your job. I hope the new features will be useful to someone > as for me. Two minor question: > 1. Could my name and email appear in the patched files as a > contributor (not in copyright owners list, of course -my contribution > was so small-)? In the sent patches for plfill.c, plgradient.c, > tkwin.c and xwin.c I put my name and a brief of my contribution, but I > don't know if this is the correct way to do that. I would like to put > my contribution in my (small) CV. > 2. In my patch for plfill.c I changed the comments at the start of > plfill() and plfill3() to: > > // Pattern fills the polygon bounded by the input points. > -// If hardware fill is used, a maximum of PL_MAXPOLY-1 vertices is allowed. > +// For a number of vertices greater than PL_MAXPOLY - 1, memory is managed > via > +// malloc/free. Otherwise static arrays of length PL_MAXPOLY are used > // The final point is explicitly added if it doesn't match up to the first, > // to prevent clipping problems. > > But in the new code of the svn I don't see that. I think that are > informative lines of the new behavior. Don't you think the same? > > Thanks > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] About plfill, plline, plmap and request of functionalities
Hi Alan, that does sound like a good idea. I am curious to see how the drivers handle such things. I can probably do that today. Regards, Arjen On 2010-12-30 20:01, Alan W. Irwin wrote: > On 2010-12-30 09:04+0100 Arjen Markus wrote: > >> Also, none of the examples really use large polygons, so the >> new parts of the patch will formally go untested. > > Hi Arjen: > > What do you think of the idea of extending example 27 for this purpose > by adding pages where plline is replaced by plfill and plgradient? > > Extending most of the pages of the current example by replacing plline > with either plfill or plgradient would test our drivers' ability to > handle self-intersecting boundaries for fills and gradients. However, > I suspect that none of our drivers could properly handle that case at > the moment. If that is correct you could restrict the page extensions > just to the current page 2. That boundary does not self-intersect, > but it has sufficent points to test the present change. > > Please give me notice when you do make your commit so I can test the > new logic on all devices not accessible to you. > > 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 > __ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Broken drivers/tkwin.c?
Hi David, that is probably my oversight - yes, found it and fixed it. It was part of a large commit having to do with the limitations José found and partially solved. To be committed today. Regards, Arjen On 2011-01-03 07:59, David MacMahon wrote: > I think drivers/tkwin.c got broken in r11405. I get this error when trying > to compile it... > > drivers/tkwin.c: In function 'FillPolygonCmd': > drivers/tkwin.c:859: error: 'npts' undeclared (first use in this function) > > Not sure how to fix it, but maybe change "npts" to "pls->dev_npts"? > > Thanks for any ideas, > Dave > > > -- > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
