Re: [Plplot-devel] Changed from treating libcd as an external library to building libnistcd internally
Hi Werner, I have been able to build the CGM driver without a problem (the nistcd.dll was being buit before - I simply overlooked it). I can use the driver in an example and that produces a CGM file. I will use the new test facilities later to see if all is well (right now I can do little with CGM files, I will try and hunt down a viewer) Regards, Arjen n 2009-03-10 10:34, Werner Smekal wrote: Hi Arjen, I tried building PLplot with this device (and the new third-party library) turned on on bare Windows, but it fails: - The linker complains about cdImageColorClear() - it does not seem to exist. Only this function was not exported, since it is declared as private. Since it is used in the cgm driver I exported it as well. - The dll directory that is created under Windows does not contain a corresponding dll for the CD library, only an import-library that is empty as far as I can see. I can't confirm that. I have a nistcd.dll and nistcd.lib in the dll directory and the cgm driver links and works. Could you try it again, if the changes I comitted solve your problem? Thanks, Werner I have not had an opportunity yet to examine the source code, but my guess is that for Windows we need to add the proper visibility attributes (dllexport). It is probably not too difficult to add them (after all, we have already done it for other libraries), but it may take me a couple of days - real life taking quite some of my time away. Regards, Arjen On 2009-03-09 08:36, Alan W. Irwin wrote: Please give this change a thorough testing. If you don't know how to view the resulting cgm files, they should be convertable to other vector graphics formats such as svg using uniconvertor. However, Debian Lenny let me down in this case (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518816). ... After that build, the display application gave good results for our cgm plots within the current limitations of the cgm device (Hershey fonts, no antialising, etc.) Note, if you look at the cgm examples generated by running the tests in lib/nistcd, the text is done with good looking fonts, and the text and lines are nicely antialiased. Thus, it is possible in theory to overcome these current limitations for our cgm device if anybody is interested on working on this device (considering that the external libcd build is no longer a barrier to entry for using -dev cgm). Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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. -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sme...@iap.tuwien.ac.at web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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
Re: [Plplot-devel] Changed from treating libcd as an external library to building libnistcd internally
Hi Arjen, I tried building PLplot with this device (and the new third-party library) turned on on bare Windows, but it fails: - The linker complains about cdImageColorClear() - it does not seem to exist. Only this function was not exported, since it is declared as private. Since it is used in the cgm driver I exported it as well. - The dll directory that is created under Windows does not contain a corresponding dll for the CD library, only an import-library that is empty as far as I can see. I can't confirm that. I have a nistcd.dll and nistcd.lib in the dll directory and the cgm driver links and works. Could you try it again, if the changes I comitted solve your problem? Thanks, Werner I have not had an opportunity yet to examine the source code, but my guess is that for Windows we need to add the proper visibility attributes (dllexport). It is probably not too difficult to add them (after all, we have already done it for other libraries), but it may take me a couple of days - real life taking quite some of my time away. Regards, Arjen On 2009-03-09 08:36, Alan W. Irwin wrote: Please give this change a thorough testing. If you don't know how to view the resulting cgm files, they should be convertable to other vector graphics formats such as svg using uniconvertor. However, Debian Lenny let me down in this case (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518816) . ... After that build, the display application gave good results for our cgm plots within the current limitations of the cgm device (Hershey fonts, no antialising, etc.) Note, if you look at the cgm examples generated by running the tests in lib/nistcd, the text is done with good looking fonts, and the text and lines are nicely antialiased. Thus, it is possible in theory to overcome these current limitations for our cgm device if anybody is interested on working on this device (considering that the external libcd build is no longer a barrier to entry for using -dev cgm). Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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. -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sme...@iap.tuwien.ac.at web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Changed from treating libcd as an external library to building libnistcd internally
Hi Werner, On 2009-03-10 10:34, Werner Smekal wrote: Hi Arjen, I tried building PLplot with this device (and the new third-party library) turned on on bare Windows, but it fails: - The linker complains about cdImageColorClear() - it does not seem to exist. Only this function was not exported, since it is declared as private. Since it is used in the cgm driver I exported it as well. Right, that was an easy fix then. - The dll directory that is created under Windows does not contain a corresponding dll for the CD library, only an import-library that is empty as far as I can see. I can't confirm that. I have a nistcd.dll and nistcd.lib in the dll directory and the cgm driver links and works. Could you try it again, if the changes I comitted solve your problem? I will, but I can not report any results until tomorrow. Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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. -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Changed from treating libcd as an external library to building libnistcd internally
Hi Werner, good to know that :) then I won't spend time on that fix. Regards, Arjen On 2009-03-10 09:52, Werner Smekal wrote: Hi Arjen, I already fixed that, but didn't commit that so far. Will do in the next hours. Regards, Werner On 10.03.2009, at 08:43, Arjen Markus wrote: Hi Alan, I tried building PLplot with this device (and the new third-party library) turned on on bare Windows, but it fails: - The linker complains about cdImageColorClear() - it does not seem to exist. - The dll directory that is created under Windows does not contain a corresponding dll for the CD library, only an import-library that is empty as far as I can see. I have not had an opportunity yet to examine the source code, but my guess is that for Windows we need to add the proper visibility attributes (dllexport). It is probably not too difficult to add them (after all, we have already done it for other libraries), but it may take me a couple of days - real life taking quite some of my time away. Regards, Arjen On 2009-03-09 08:36, Alan W. Irwin wrote: Please give this change a thorough testing. If you don't know how to view the resulting cgm files, they should be convertable to other vector graphics formats such as svg using uniconvertor. However, Debian Lenny let me down in this case (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518816) . ... After that build, the display application gave good results for our cgm plots within the current limitations of the cgm device (Hershey fonts, no antialising, etc.) Note, if you look at the cgm examples generated by running the tests in lib/nistcd, the text is done with good looking fonts, and the text and lines are nicely antialiased. Thus, it is possible in theory to overcome these current limitations for our cgm device if anybody is interested on working on this device (considering that the external libcd build is no longer a barrier to entry for using -dev cgm). Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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. -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sme...@iap.tuwien.ac.at web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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. --
Re: [Plplot-devel] Changed from treating libcd as an external library to building libnistcd internally
Hi Alan, good idea to include the library. On Mac OS X (but only later versions, 10.4 upwards or so) malloc.h must be included with #include malloc/malloc.h and not with #include malloc.h I took the easy route and defined for Mac OS X NOMALLOCH in the corresponding CMakeLists.txt (Revision 9683) so that malloc.h is not included. But I think we shouldn't include malloc.h, since normal alloc/calloc/free calls are defined somewhere else anyway. Could you check in Linux if removing the include of malloc.h leads to problems? If not, I think we could remove it and revert CMakeLists.txt. Regards, Werner On 09.03.2009, at 08:36, Alan W. Irwin wrote: See revision 9682. I made this change because I think it is a better way to support our cgm device driver. CGM format is a long-established (since 1987) open standard for vector graphics that is supported by w3c (see http://www.w3.org/Graphics/WebCGM/). Despite its openness, CGM has never gotten much support within the free software community (probably because it was ahead of its time). But that doesn't mean we have to continue that trend. I doubt many were using our cgm device before because it depends on the public domain software library, libcd, which is difficult to find, and no longer maintained. OTOH, that library code seems to build without problems on all platforms that our developers have tried so it makes sense to do the build ourselves so it is automatically accessible for everybody who builds PLplot. I have only lightly tested these changes so far, but if I run the test executables built in lib/nistcd, I generate identical cgm files to those supplied with the libcd tarball. Please give this change a thorough testing. If you don't know how to view the resulting cgm files, they should be convertable to other vector graphics formats such as svg using uniconvertor. However, Debian Lenny let me down in this case (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518816) . Another possibility for viewing/converting cgm is ralcgm. (That is what the ImageMagick display app uses to view/convert cgm files.) However, Debian let me down there as well since nobody has packaged ralcmg for Debian. An unpatched ralcgm is impossible to build on Linux because the package's configuration is completely Linux unaware. (Yes, that happened back in the mid 90's when ralcgm was programmed). However, I took a patched source from a src rpm that filled in all the Linux configuration information properly, and I got that version to build with no issues. After that build, the display application gave good results for our cgm plots within the current limitations of the cgm device (Hershey fonts, no antialising, etc.) Note, if you look at the cgm examples generated by running the tests in lib/nistcd, the text is done with good looking fonts, and the text and lines are nicely antialiased. Thus, it is possible in theory to overcome these current limitations for our cgm device if anybody is interested on working on this device (considering that the external libcd build is no longer a barrier to entry for using -dev cgm). 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 __ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sme...@iap.tuwien.ac.at web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut
Re: [Plplot-devel] Changed from treating libcd as an external library to building libnistcd internally
From Linux man page MALLOC(3) Linux Programmer's Manual MALLOC(3) NAME calloc, malloc, free, realloc - Allocate and free dynamic memory SYNOPSIS #include stdlib.h void *calloc(size_t nmemb, size_t size); void *malloc(size_t size); void free(void *ptr); void *realloc(void *ptr, size_t size); and so the correct thing to do is include stdlib.h Andrew On Mon, Mar 09, 2009 at 04:19:29PM +0100, Werner Smekal wrote: Hi Alan, good idea to include the library. On Mac OS X (but only later versions, 10.4 upwards or so) malloc.h must be included with #include malloc/malloc.h and not with #include malloc.h I took the easy route and defined for Mac OS X NOMALLOCH in the corresponding CMakeLists.txt (Revision 9683) so that malloc.h is not included. But I think we shouldn't include malloc.h, since normal alloc/calloc/free calls are defined somewhere else anyway. Could you check in Linux if removing the include of malloc.h leads to problems? If not, I think we could remove it and revert CMakeLists.txt. Regards, Werner On 09.03.2009, at 08:36, Alan W. Irwin wrote: See revision 9682. I made this change because I think it is a better way to support our cgm device driver. CGM format is a long-established (since 1987) open standard for vector graphics that is supported by w3c (see http://www.w3.org/Graphics/WebCGM/). Despite its openness, CGM has never gotten much support within the free software community (probably because it was ahead of its time). But that doesn't mean we have to continue that trend. I doubt many were using our cgm device before because it depends on the public domain software library, libcd, which is difficult to find, and no longer maintained. OTOH, that library code seems to build without problems on all platforms that our developers have tried so it makes sense to do the build ourselves so it is automatically accessible for everybody who builds PLplot. I have only lightly tested these changes so far, but if I run the test executables built in lib/nistcd, I generate identical cgm files to those supplied with the libcd tarball. Please give this change a thorough testing. If you don't know how to view the resulting cgm files, they should be convertable to other vector graphics formats such as svg using uniconvertor. However, Debian Lenny let me down in this case (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518816) . Another possibility for viewing/converting cgm is ralcgm. (That is what the ImageMagick display app uses to view/convert cgm files.) However, Debian let me down there as well since nobody has packaged ralcmg for Debian. An unpatched ralcgm is impossible to build on Linux because the package's configuration is completely Linux unaware. (Yes, that happened back in the mid 90's when ralcgm was programmed). However, I took a patched source from a src rpm that filled in all the Linux configuration information properly, and I got that version to build with no issues. After that build, the display application gave good results for our cgm plots within the current limitations of the cgm device (Hershey fonts, no antialising, etc.) Note, if you look at the cgm examples generated by running the tests in lib/nistcd, the text is done with good looking fonts, and the text and lines are nicely antialiased. Thus, it is possible in theory to overcome these current limitations for our cgm device if anybody is interested on working on this device (considering that the external libcd build is no longer a barrier to entry for using -dev cgm). 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 __ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net
Re: [Plplot-devel] Changed from treating libcd as an external library to building libnistcd internally
On 2009-03-09 16:19+0100 Werner Smekal wrote: Hi Alan, good idea to include the library. On Mac OS X (but only later versions, 10.4 upwards or so) malloc.h must be included with #include malloc/malloc.h and not with #include malloc.h I took the easy route and defined for Mac OS X NOMALLOCH in the corresponding CMakeLists.txt (Revision 9683) so that malloc.h is not included. But I think we shouldn't include malloc.h, since normal alloc/calloc/free calls are defined somewhere else anyway. Could you check in Linux if removing the include of malloc.h leads to problems? If not, I think we could remove it and revert CMakeLists.txt. Hi Werner: Thanks for spotting this issue, and making a good first try at dealing with it. Dropping it for Linux works fine (as predicted by Andrew). However, instead of ripping out #ifndef NOMALLOCH #include malloc.h #endif from the code in the three places where that occurs, I decided to do everything from CMake, and effectively did that same thing by using a small change of what you did. This preserves the original code exactly, and already is proved to work for Linux and Mac OS X. If it works for Windows and proprietary Unix as well, that is great, but if not, this method still allows us to deal at the CMake level with platforms where #include malloc.h is actually needed in that form. 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 __ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
