From: Ali M. <so...@sy...> - 2004-09-01 02:07:40
|
Hi, Sometime ago I created the dll file for java binding on XP based on = 5.3.0. Recently, I tried to do the same thing using version 5.3.1 but = had some problems with compiling the lib file. Then the development team = made the changes on my request and committed the changes to cvs and I = was able to create lib file. Since cvs does not contain the java files = generated by swig, I am unable to compile dll. I do not know how to run = swig on XP.=20 Can somebody kindly send me the swig generated java files based on = current code in CVS. It will save me a lot of time. Thank you -Ali |
From: Alan W. I. <ir...@be...> - 2004-09-01 03:44:56
|
On 2004-08-31 22:07-0400 Ali Muhammad wrote: > Hi, > > Sometime ago I created the dll file for java binding on XP based on 5.3.0. Recently, I tried to do the same thing using version 5.3.1 but had some problems with compiling the lib file. Then the development team made the changes on my request and committed the changes to cvs and I was able to create lib file. Since cvs does not contain the java files generated by swig, I am unable to compile dll. I do not know how to run swig on XP. > > Can somebody kindly send me the swig generated java files based on current code in CVS. It will save me a lot of time. > There are cvs tarball snapshots (which include the swig-generated files) available at http://plplot.sourceforge.net/cvs-tarball/. The current tarball there was generated on 2004-08-22. If we made the cvs change you require earlier than that date, then I suggest trying that tarball. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Ali M. <so...@sy...> - 2004-09-02 00:32:04
|
Hi Alan, I did try the tarball and I got the folowing error. Please advise -Ali D:\plplot\core>cl /IC:\j2sdk1.4.2_01\include /IC:\j2sdk1.4.2_01\include\win32 /I d:\plplot\include /LD plplotjavac_wrap.c /Fejplplot.dll /link D:\plplot\sys\win3 2\msdev\plplib\plplot.lib /NOD USER32.lib GDI32.lib KERNEL32.LIB MSVCRT.LIB Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8141 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. plplotjavac_wrap.c Microsoft (R) Incremental Linker Version 6.00.8141 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. /dll /implib:jplplot.lib /out:jplplot.dll D:\plplot\sys\win32\msdev\plplib\plplot.lib /NOD USER32.lib GDI32.lib KERNEL32.LIB MSVCRT.LIB plplotjavac_wrap.obj Creating library jplplot.lib and object jplplot.exp LINK : warning LNK4049: locally defined symbol "_w32_tmpfile" imported plplotjavac_wrap.obj : error LNK2001: unresolved external symbol _c_plsvect plplotjavac_wrap.obj : error LNK2001: unresolved external symbol _c_plvect plplot.lib(plcore.obj) : error LNK2001: unresolved external symbol _plsvect plplot.lib(plcore.obj) : error LNK2001: unresolved external symbol _getcwd jplplot.dll : fatal error LNK1120: 4 unresolved externals ----- Original Message ----- From: "Alan W. Irwin" <ir...@be...> To: "PLplot development list" <plp...@li...> Sent: Tuesday, August 31, 2004 11:36 PM Subject: Re: [Plplot-devel] plplot java binding > On 2004-08-31 22:07-0400 Ali Muhammad wrote: > > > Hi, > > > > Sometime ago I created the dll file for java binding on XP based on 5.3.0. Recently, I tried to do the same thing using version 5.3.1 but had some problems with compiling the lib file. Then the development team made the changes on my request and committed the changes to cvs and I was able to create lib file. Since cvs does not contain the java files generated by swig, I am unable to compile dll. I do not know how to run swig on XP. > > > > Can somebody kindly send me the swig generated java files based on current code in CVS. It will save me a lot of time. > > > > There are cvs tarball snapshots (which include the swig-generated files) > available at http://plplot.sourceforge.net/cvs-tarball/. The current > tarball there was generated on 2004-08-22. If we made the cvs change you > require earlier than that date, then I suggest trying that tarball. > > Alan > __________________________ > Alan W. Irwin > email: ir...@be... > phone: 250-727-2902 > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the PLplot scientific plotting software > package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the > Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2004-09-02 03:49:29
|
On 2004-09-01 20:31-0400 Ali Muhammad wrote: > Hi Alan, > > I did try the tarball and I got the folowing error. > > Please advise > > -Ali [...] > plplotjavac_wrap.obj : error LNK2001: unresolved external symbol _c_plsvect Sorry, Ali. I completely forgot that Arjen made a cvs fix for that error in the windows part of the tree after the cvs snapshot tarball was created. Arjen, would you be willing to do a complete windows build now to make sure everything is okay with the cvs version? Thanks to Andrew Roach's efforts we now have a new gif device embedded as part of the gd.c device driver. That new code may have no effect on the windows side of things, but it should be checked. Once Arjen determines that the cvs version is okay for windows, it will be a good opportunity to make another cvs snapshot tarball for Ali to try. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Ali M. <so...@sy...> - 2004-09-02 10:40:16
|
Thank you, I appreciate your help. Regards, -Ali ----- Original Message ----- From: "Alan W. Irwin" <ir...@be...> To: "PLplot development list" <plp...@li...> Sent: Wednesday, September 01, 2004 10:21 PM Subject: Re: [Plplot-devel] plplot java binding > On 2004-09-01 20:31-0400 Ali Muhammad wrote: > > > Hi Alan, > > > > I did try the tarball and I got the folowing error. > > > > Please advise > > > > -Ali > [...] > > plplotjavac_wrap.obj : error LNK2001: unresolved external symbol _c_plsvect > > Sorry, Ali. I completely forgot that Arjen made a cvs fix for that error in > the windows part of the tree after the cvs snapshot tarball was created. > > Arjen, would you be willing to do a complete windows build now to make sure > everything is okay with the cvs version? Thanks to Andrew Roach's efforts > we now have a new gif device embedded as part of the gd.c device driver. > That new code may have no effect on the windows side of things, but it should > be checked. > > Once Arjen determines that the cvs version is okay for windows, it will be a > good opportunity to make another cvs snapshot tarball for Ali to try. > > Alan > __________________________ > Alan W. Irwin > email: ir...@be... > phone: 250-727-2902 > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the PLplot scientific plotting software > package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the > Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <arj...@wl...> - 2004-09-03 11:14:03
|
"Alan W. Irwin" wrote: > > On 2004-09-01 20:31-0400 Ali Muhammad wrote: > > > Hi Alan, > > > > I did try the tarball and I got the folowing error. > > > > Please advise > > > > -Ali > [...] > > plplotjavac_wrap.obj : error LNK2001: unresolved external symbol _c_plsvect > > Sorry, Ali. I completely forgot that Arjen made a cvs fix for that error in > the windows part of the tree after the cvs snapshot tarball was created. > Okay, CVS has a version of plstubs.cpp that has a stupid typo (I should have rebuilt both the static and the dynamic library!). This was easy to fix and I will commit the thing today. > Arjen, would you be willing to do a complete windows build now to make sure > everything is okay with the cvs version? Thanks to Andrew Roach's efforts > we now have a new gif device embedded as part of the gd.c device driver. > That new code may have no effect on the windows side of things, but it should > be checked. > > Once Arjen determines that the cvs version is okay for windows, it will be a > good opportunity to make another cvs snapshot tarball for Ali to try. > To check that plvect() and plsvect() are indeed nicely useable, I tried to compile example x22c. This uses however the constant M_PI (not defined apparently under Windows - with MS Visual C/C++ 6.0 anyway) and, worse, it uses "const int" to define the array sizes. This is not supported either! I have temporarily fixed this (and a few omissions in the Windows version of plplot.h - in CVS shortly), but now I get errors about function pointers with different attributes (this concerns pltr2). I am trying to make it work properly ... More later Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-09-03 11:55:36
|
Arjen Markus wrote: > > To check that plvect() and plsvect() are indeed nicely useable, I tried > to > compile example x22c. This uses however the constant M_PI (not defined > apparently under Windows - with MS Visual C/C++ 6.0 anyway) and, > worse, it uses "const int" to define the array sizes. This is not > supported either! > > I have temporarily fixed this (and a few omissions in the Windows > version of > plplot.h - in CVS shortly), but now I get errors about function pointers > with different > attributes (this concerns pltr2). I am trying to make it work properly > ... > More later > I have just ran into a problem that I need to solve properly but which requires some careful thinking: the functions plAlloc2dGrid and plFree2dGrid are posing problems - they should ideally be named just as most other functions (i.e. some uncuth magic concerning the prefix c_), but this is in conflict with their actual definition. Oh, I know I am not expressing myself very clearly, but the DLL on Windows requires the proper attributes for all public functions, which is done a.o. via the c_ stuff). In short: these two functions must behave as public functions, therefore they should have names like c_plAlloc.... but that requires a gratuitous change to pdfutils.c, unless I work out the magic incantation that ... -- argh, I need a drink! No time now, grrrrr Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2004-09-04 16:26:24
|
On 2004-09-03 13:55+0200 Arjen Markus wrote: > I have just ran into a problem that I need to solve properly but which > requires some careful thinking: the functions plAlloc2dGrid and > plFree2dGrid > are posing problems - they should ideally be named just as most other > functions (i.e. some uncuth magic concerning the prefix c_), but this is > in conflict with their actual definition. > > Oh, I know I am not expressing myself very clearly, but the DLL on > Windows > requires the proper attributes for all public functions, which is done > a.o. > via the c_ stuff). > > In short: these two functions must behave as public functions, therefore > they should have names like c_plAlloc.... No. The "c" prefix stands for the common _subset_ of the public API. It originally meant the API subset that was interfaced by fortran, but eventually it came to mean that part of the public API that was essential and common to all interfaces. So to get back to your example, plAlloc2dGrid and plFree2dGrid are definitely part of the public API, but they will never be part of the common API subset since they are memory management functions which are specific to C (and probably C++) alone. For example, note that these function are protected by an #if 0 ....#endif block in bindings/swig-support/plplotcapi.i so they are not part of the python or java interface, and I assume they are similarly ignored for other interfaces as well. So on the windows side of things do not rely on the "c" prefix to help decide whether something is in the public API or not. Instead, look at the total contents of plplot.h to find out what is in the public API. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-09-04 16:46:09
|
* Alan W. Irwin <ir...@be...> [2004-09-04 08:43]: > The "c" prefix stands for the common _subset_ of the public API. It > originally meant the API subset that was interfaced by fortran, but > eventually it came to mean that part of the public API that was essential > and common to all interfaces. So to get back to your example, plAlloc2dGrid > and plFree2dGrid are definitely part of the public API, but they will never > be part of the common API subset since they are memory management functions > which are specific to C (and probably C++) alone. For example, note that > these function are protected by an #if 0 ....#endif block in > bindings/swig-support/plplotcapi.i so they are not part of the python or > java interface, and I assume they are similarly ignored for other interfaces > as well. This is not true. plAllocGrid, plFreeGrid, plAlloc2dGrid, and plFree2dGrid are implemented in the PDL binding. See the examples x09.pl, x16.pl, and x22.pl. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-09-04 18:22:45
|
On 2004-09-04 18:46+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-09-04 08:43]: > >> The "c" prefix stands for the common _subset_ of the public API. It >> originally meant the API subset that was interfaced by fortran, but >> eventually it came to mean that part of the public API that was essential >> and common to all interfaces. So to get back to your example, plAlloc2dGrid >> and plFree2dGrid are definitely part of the public API, but they will never >> be part of the common API subset since they are memory management functions >> which are specific to C (and probably C++) alone. For example, note that >> these function are protected by an #if 0 ....#endif block in >> bindings/swig-support/plplotcapi.i so they are not part of the python or >> java interface, and I assume they are similarly ignored for other interfaces >> as well. > > This is not true. plAllocGrid, plFreeGrid, plAlloc2dGrid, and plFree2dGrid > are implemented in the PDL binding. See the examples x09.pl, x16.pl, and > x22.pl. That of course does not invalidate the original point which is common API is only a subset of the public API so that Arjen should not rely on the "c" prefix to denote public API. But beyond that it is interesting that you use these functions in perl/PDL. Is there some problem allocating array space using methods native to perl/PDL? In Python/numeric I far prefer the native method. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-09-04 21:45:28
|
* Alan W. Irwin <ir...@be...> [2004-09-04 10:29]: > But beyond that it is interesting that you use these functions in perl/PDL. > Is there some problem allocating array space using methods native to > perl/PDL? In Python/numeric I far prefer the native method. It is not a matter of native array allocation, but a design option I took for the PDL binding. Let us compare the Python and PDL binding with the C API for the x09 example: /////////// x09c.c ////////////////////////////////////////////////// plAlloc2dGrid(&cgrid2.xg, RPTS, THETAPTS); plAlloc2dGrid(&cgrid2.yg, RPTS, THETAPTS); cgrid2.nx = RPTS; cgrid2.ny = THETAPTS; for (i = 0; i < RPTS; i++) { r = i/(double)(RPTS-1); for (j = 0; j < THETAPTS; j++) { theta = (2.*PI/(double)(THETAPTS-1))*(double)j; cgrid2.xg[i][j] = r*cos(theta); cgrid2.yg[i][j] = r*sin(theta); } } plcont(z, RPTS, THETAPTS, 1, RPTS, 1, THETAPTS, lev, 10, pltr2, (void *) &cgrid2); ///////////////////////////////////////////////////////////////////// ########### xw09.py ################################################# xg = r*cos(theta) yg = r*sin(theta) plcont(zg, lev, pltr2, xg, yg, 2) ##################################################################### ########### x09.pl ################################################## my $cgrid2 = plAlloc2dGrid ($r * cos ($theta), $r * sin ($theta)); plcont ($z, 1, RPTS, 1, THETAPTS, $lev, \&pltr2, $cgrid2); ##################################################################### The first thing to notice is that the plcont implementation in PDL matches much closer the C API than that in Python. However, beyond this nice feature of similarity to the C API, the PDL binding has a generic implementation of the pltr* family of functions. Regardless of the use of pltr1, pltr2, or whichever, the call of plcont is always the same. In Python, the arguments of plcont vary accordingly to the pltr function used, for instance (from x09w.py): plcont(z, clevel, mypltr, tr) plcont(z, clevel, pltr1, xg1, yg1) plcont(zg, lev, pltr2, xg, yg, 2) The equivalent in PDL is: plcont ($z, 1, XPTS, 1, YPTS, $clevel, \&mypltr, 0); plcont ($w, 1, XPTS, 1, YPTS, $clevel, \&pltr1, $cgrid1); plcont ($w, 1, XPTS, 1, YPTS, $clevel, \&pltr2, $cgrid2); I could have implemented the pltr-related interface in PDL similarly to the Python one, but I still prefer my scheme, because of its generality and similarity to the C API. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-09-04 22:54:25
|
On 2004-09-04 23:45+0200 Rafael Laboissiere wrote: > ########### xw09.py ################################################# > xg = r*cos(theta) > yg = r*sin(theta) > plcont(zg, lev, pltr2, xg, yg, 2) > ##################################################################### > > ########### x09.pl ################################################## > my $cgrid2 = plAlloc2dGrid ($r * cos ($theta), $r * sin ($theta)); > plcont ($z, 1, RPTS, 1, THETAPTS, $lev, \&pltr2, $cgrid2); > ##################################################################### I think we just have to agree to differ here about what is aesthetically pleasing to our eyes. The python/numeric syntax above appeals to me much more than the second form. For you it is the opposite, and I accept that. > In > Python, the arguments of plcont vary accordingly to the pltr function used, > for instance (from x09w.py): > > plcont(z, clevel, mypltr, tr) > plcont(z, clevel, pltr1, xg1, yg1) > plcont(zg, lev, pltr2, xg, yg, 2) > > The equivalent in PDL is: > > plcont ($z, 1, XPTS, 1, YPTS, $clevel, \&mypltr, 0); > plcont ($w, 1, XPTS, 1, YPTS, $clevel, \&pltr1, $cgrid1); > plcont ($w, 1, XPTS, 1, YPTS, $clevel, \&pltr2, $cgrid2); Again, it is a matter of personal taste. I prefer the first version with input arguments reduced to essentials. Our python interface has always (even in the hand-crafted days) overloaded plcont (and some of the other API) this way. With the swig-generated interface, this overloading now occurs in plplot.py, but of course you always have the long version of the argument list available to you if you don't want to accept the default arguments for the overloaded versions. I still hope we can eventually have user-friendly extensions to both our java and C++ API's to have overloaded versions of plcont, etc. which shorten some of the argument lists down to their essentials similar to what is now available for the python interface. You might want to consider doing the same for the perl/pdl interface if overloading is available for that interface. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-09-05 07:08:32
|
* Alan W. Irwin <ir...@be...> [2004-09-04 15:29]: > On 2004-09-04 23:45+0200 Rafael Laboissiere wrote: > > >########### xw09.py ################################################# > > xg = r*cos(theta) > > yg = r*sin(theta) > > plcont(zg, lev, pltr2, xg, yg, 2) > >##################################################################### > > > >########### x09.pl ################################################## > > my $cgrid2 = plAlloc2dGrid ($r * cos ($theta), $r * sin ($theta)); > > plcont ($z, 1, RPTS, 1, THETAPTS, $lev, \&pltr2, $cgrid2); > >##################################################################### > > I think we just have to agree to differ here about what is aesthetically > pleasing to our eyes. The python/numeric syntax above appeals to me much > more than the second form. For you it is the opposite, and I accept that. I understand that, for Python people, the syntax constraints of Perl requiring "$" and "\&" prefixing the variables may be unpleasant to their eyes. Are you talking about that or about the extra arguments "1, RPTS, 1, THETAPTS" in the PDL implementation of plcont? These arguments are present in the C API (kx, lx, ky, ly) and cannot be automatically deduced from the input arguments, for the generic case. I think that the Python binding defaults to the dimensions of the matirx zg when the ky, lx, ky, and ly arguments are absent. Is that what you are suggesting by this: > I still hope we can eventually have user-friendly extensions to both our > java and C++ API's to have overloaded versions of plcont, etc. which shorten > some of the argument lists down to their essentials similar to what is now > available for the python interface. ? -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-09-05 20:26:43
|
On 2004-09-05 09:08+0200 Rafael Laboissiere wrote: >> I still hope we can eventually have user-friendly extensions to both our >> java and C++ API's to have overloaded versions of plcont, etc. which shorten >> some of the argument lists down to their essentials similar to what is now >> available for the python interface. > > ? I am sorry you didn't understand this remark. To be more explicit, all these languages allow function overloading where the same function name can be used for multiple functions provided each differs in the number or type of its parameters. These languages also allow default arguments for the same function. See http://cplus.about.com/library/weekly/aa061602a.htm for a short tutorial on these possibilities for the C++ case. We take advantage of these possibilities in the python interface to provide user convenience (a variety of ways to call plcont, plvect, plshade, and plshades depending on the needs of the user), and I hope we eventually provide that same user-friendliness for the C++ and Java (and perl/pdl?) interfaces as well. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-09-06 06:50:50
|
* Alan W. Irwin <ir...@be...> [2004-09-05 08:16]: > On 2004-09-05 09:08+0200 Rafael Laboissiere wrote: > > >>I still hope we can eventually have user-friendly extensions to both our > >>java and C++ API's to have overloaded versions of plcont, etc. which > >>shorten > >>some of the argument lists down to their essentials similar to what is now > >>available for the python interface. > > > >? > > I am sorry you didn't understand this remark. To be more explicit, all > these languages allow function overloading where the same function name can > be used for multiple functions provided each differs in the number or type > of its parameters. These languages also allow default arguments for the > same function. See http://cplus.about.com/library/weekly/aa061602a.htm for a > short tutorial on these possibilities for the C++ case. > > We take advantage of these possibilities in the python interface to provide > user convenience (a variety of ways to call plcont, plvect, plshade, and > plshades depending on the needs of the user), and I hope we eventually > provide that same user-friendliness for the C++ and Java (and perl/pdl?) > interfaces as well. Thanks for the clarifications, I see what you are meaning now. However, you should notice that Python has no proper function overloading as in C++, where the ambiguities are resolved at compile time. This is radically different of the approach in Python, which can only decide at run time which type of call function was used by the user. This arises from the fact that Python is an interpreted language and that its variables are untyped. Indeed, if you look at bindings/python/plplot.py, you will see that the plcont function is defined with: def plcont(z, *args): where the args array is parsed *_at run time_* to decided what type of call was intended by the user, essentially by checking the number and types of the arguments passed. The same trick could be implemented in the PDL binding, of course, but it would imply a significant amount of work. I will keep the idea in a corner in my mind. -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-09-08 10:49:28
|
Hello, I have committed new versions of the three files involved in the problem of the plvect and plsvect functions not being visible in the Java binding. With these versions I can make example x22c work properly (this example uses said functions, as well as two others that gave me a bit of a headache - see previous postings). As I do not have a Java development environment ready, I would like to ask Ali to test this as soon as the new tarball is ready. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-09-16 08:28:28
|
Arjen Markus wrote: > > Hello, > > I have committed new versions of the three files involved in the problem > of the plvect and plsvect functions not being visible in the Java > binding. > > With these versions I can make example x22c work properly (this example > uses said functions, as well as two others that gave me a bit of > a headache - see previous postings). > > As I do not have a Java development environment ready, I would like to > ask Ali to test this as soon as the new tarball is ready. > I have received a message from Ali Mohammed, that with these new versions the Java bindings can be correctly created on Windows. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-09-02 06:21:42
|
"Alan W. Irwin" wrote: > > Sorry, Ali. I completely forgot that Arjen made a cvs fix for that error in > the windows part of the tree after the cvs snapshot tarball was created. > > Arjen, would you be willing to do a complete windows build now to make sure > everything is okay with the cvs version? Thanks to Andrew Roach's efforts > we now have a new gif device embedded as part of the gd.c device driver. > That new code may have no effect on the windows side of things, but it should > be checked. > > Once Arjen determines that the cvs version is okay for windows, it will be a > good opportunity to make another cvs snapshot tarball for Ali to try. > Yes, I will do that - I hope I can make it today, otherwise it will have to wait until tomorrow (an urgent little task awaits me today ;)) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-09-03 12:28:56
|
Arjen Markus wrote: > > Arjen Markus wrote: > > > > > To check that plvect() and plsvect() are indeed nicely useable, I tried > > to > > compile example x22c. This uses however the constant M_PI (not defined > > apparently under Windows - with MS Visual C/C++ 6.0 anyway) and, > > worse, it uses "const int" to define the array sizes. This is not > > supported either! > > > > I have temporarily fixed this (and a few omissions in the Windows > > version of > > plplot.h - in CVS shortly), but now I get errors about function pointers > > with different > > attributes (this concerns pltr2). I am trying to make it work properly > > ... > > More later > > > > I have just ran into a problem that I need to solve properly but which > requires some careful thinking: the functions plAlloc2dGrid and > plFree2dGrid > are posing problems - they should ideally be named just as most other > functions (i.e. some uncuth magic concerning the prefix c_), but this is > in conflict with their actual definition. > > Oh, I know I am not expressing myself very clearly, but the DLL on > Windows > requires the proper attributes for all public functions, which is done > a.o. > via the c_ stuff). > > In short: these two functions must behave as public functions, therefore > they should have names like c_plAlloc.... but that requires a gratuitous > change to pdfutils.c, unless I work out the magic incantation that ... > -- argh, I need a drink! > > No time now, grrrrr > Perhaps I should have added: this is for the DLL version only! The static version compiles and links and the examples work fine Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-09-08 08:49:27
|
"Alan W. Irwin" wrote: > > So on the windows side of things do not rely on the "c" prefix to help decide > whether something is in the public API or not. Instead, look at the total > contents of plplot.h to find out what is in the public API. > I think I was making my life a bit more miserable than was actually necessary: I had solved this issue with other functions already - now to find the right magical combination... Regards, Arjen |