From: Arjen M. <arj...@wl...> - 2005-11-18 14:09:26
|
Hello all, just a quick question about the support of UNICODE in PLplot: I have built PLplot on the Cygwin platform with freetype support. I want to check that UNICODE characters are fully supported (well, within the limits of the available fonts). How do I do that? Is it enough to run x23c and x24c to check that they display the right kind of non-latin characters? Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-11-21 07:35:48
|
"Alan W. Irwin" wrote: > > On 2005-11-18 15:09+0100 Arjen Markus wrote: > > > Hello all, > > > > just a quick question about the support of UNICODE in PLplot: > > > > I have built PLplot on the Cygwin platform with freetype support. > > That's excellent news, Arjen. > > > I want to check that UNICODE characters are fully supported > > (well, within the limits of the available fonts). How do I > > do that? Is it enough to run x23c and x24c to check that > > they display the right kind of non-latin characters? > > If for -dev png (or some other unicode aware device) you can get results > similar to http://plplot.sourceforge.net/examples/demo23.php you probably > have unicode fonts working fine. That example evaluates font results for > unicode blocks that are useful for mathematical needs, but with small coding > changes you could use it to evaluate fonts for other unicode blocks as well. > The results at the above URL were generated using the default (on Linux) > Freefont font package which has quite complete coverage of these unicode > blocks compared to other fonts I have evaluated. That Linux default font > set is specified at cf/freetype.ac. In that file you will also see logic > that gives a different default font set for Cygwin and MinGW which Andrew > (Roach) recommends for those platforms (because those fonts tend to be > preinstalled on those platforms). > I have in fact seen quite a few, but not all of these characters in my Cygwin environment. I suppose that the missing ones (many of the mathematically oriented symbols) are due to a lack of glyphs in the standard Windows fonts. To check that it works with FORTRAN 77 too, I have implemented example 23 in FORTRAN. That will be in CVS soon. The only thing that makes it a bit cumbersome at the moment to use these "special" symbols with FORTRAN 77 in the Cygwin environment is some trouble with the iargc() and getarg() routines, used to obtain the command-line arguments. I therefore forced wingcc to use Freefont text by using plsetopt() directly. > Reproducing the results at http://plplot.sourceforge.net/examples/demo24.php > is more challenging than reproducing the example 23 results because of the > variety of non-default language fonts required, but it's a worthwhile > challenge because it shows the fonts on the platform you are testing support > languages other than those of western Europe. Andrew, have you ever got > example 24 to work on MinGW? If so, what fonts do you recommend for that > case that should be easy to obtain for MinGW and Cygwin? > I have not looked yet at example 24. I know that the Cyberbit font that used to be available for free on Windows, but not be anymore, but I need to check that, has a very nice support for many non-latin alphabets and writing systems. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2005-11-21 17:32:12
|
On 2005-11-21 08:35+0100 Arjen Markus wrote: > ...Cygwin > ...trouble > with the iargc() and getarg() routines, used to obtain the (fortran) command-line > arguments.... That brings us to a new subject. Could you demonstrate with the short example below under what conditions iargc and getarg do not work for the Cygwin environment? ********** example to test iargc and getarg capability implicit none character*4 argument integer i write(*,*) 'number of arguments = ', iargc() do i = 1,5 call getarg(i,argument) write(*,'(i5,x,a4)') i, argument enddo end ********** On my system I obtain the following results: irwin@chickadee> g77 test_command_line_parse.f -o test_command_line_parse irwin@chickadee> ./test_command_line_parse a b c number of arguments = 3 1 a 2 b 3 c 4 5 Do you get a similar result? If that simple demonstration succeeds for you, will you please turn it into the form similar to the PLplot form that fails? That is, make the above fortran a separate routine in a one-routine shared library which is called from a main routine? That would allow you to make some easy experiments (such as trying the -fPIC option or not that we discussed before) to see what is the root of the shared library problem. If you do find a way to get the shared library version to work (such as using the -fPIC option), then I will take your solution to the libtool list so they can use it for a permanent solution. I found them to be most helpful and responsive when earlier this year we could demonstrate a clear MinGW libtool problem and solution. On the other hand, if there is no way you can find to make the shared library version work, then we should take that simple demonstration of the problem to the Cygwin development list so they can fix it. 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 FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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: Arjen M. <arj...@wl...> - 2005-11-22 14:06:54
|
"Alan W. Irwin" wrote: > > On 2005-11-21 08:35+0100 Arjen Markus wrote: > > > ...Cygwin > > ...trouble > > with the iargc() and getarg() routines, used to obtain the (fortran) command-line > > arguments.... > > That brings us to a new subject. > > Could you demonstrate with the short example below under what conditions > iargc and getarg do not work for the Cygwin environment? > > ********** example to test iargc and getarg capability > implicit none > character*4 argument > integer i > write(*,*) 'number of arguments = ', iargc() > do i = 1,5 > call getarg(i,argument) > write(*,'(i5,x,a4)') i, argument > enddo > end > ********** > > On my system I obtain the following results: > > irwin@chickadee> g77 test_command_line_parse.f -o test_command_line_parse > irwin@chickadee> ./test_command_line_parse a b c > number of arguments = 3 > 1 a > 2 b > 3 c > 4 > 5 > > Do you get a similar result? > > If that simple demonstration succeeds for you, will you please turn it into > the form similar to the PLplot form that fails? That is, make the above > fortran a separate routine in a one-routine shared library which is called > from a main routine? That would allow you to make some easy experiments > (such as trying the -fPIC option or not that we discussed before) to see > what is the root of the shared library problem. > > If you do find a way to get the shared library version to work (such as > using the -fPIC option), then I will take your solution to the libtool list > so they can use it for a permanent solution. I found them to be most > helpful and responsive when earlier this year we could demonstrate a clear > MinGW libtool problem and solution. On the other hand, if there is no way > you can find to make the shared library version work, then we should take > that simple demonstration of the problem to the Cygwin development list so > they can fix it. > Hello Alan, I will give it a try - my hunch is that calling the functions directly from a DLL is the culprit. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-11-23 07:41:04
|
Hello Alan, here are the results of my experiment: main program (tstarg.f): program tstarg call chkargs end subroutine (chkargs.f): subroutine chkargs integer i integer iargc external iargc, getarg character*20 arg write(*,*) 'Number arguments:', iargc() do i = 0,5 call getarg(i,arg) write(*,*) i, arg enddo return end This works as expected if I do: g77 -o tstarg tstarg.f chkargs.f ./tstarg a b c Result: Number arguments: 3 0./tstarg.exe 1a 2b 3c 4 5 This gives a coredump or rather an error message with the invitation to send an email to MicroSoft about the problem, when I put the subroutine in a shared library: HP_Eigenaar@souterrain /cygdrive/c/arjen/plplot/plplot-5.5.3/examples/f90 $ g77 -o chkargs.so -shared chkargs.f -fPIC chkargs.f:0: warning: -fPIC ignored for target (all code is position independent ) HP_Eigenaar@souterrain /cygdrive/c/arjen/plplot/plplot-5.5.3/examples/f90 $ g77 -o tstarg tstarg.f chkargs.so -fPIC tstarg.f:0: warning: -fPIC ignored for target (all code is position independent) HP_Eigenaar@souterrain /cygdrive/c/arjen/plplot/plplot-5.5.3/examples/f90 $ ./tstarg a b c <<Error message>> HP_Eigenaar@souterrain /cygdrive/c/arjen/plplot/plplot-5.5.3/examples/f90 $ The -fPIC is not relevant on the Cygwin platform it seems, but to my surprise, the program also fails when I pass the iargc and getarg routines as arguments (I thought I might be able to bypass the snake pit of memory issues that way). I tried several other variations, but the result was the same: only when I use iargc() and getarg() from a static library will the program work as expected. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2005-11-23 10:46:16
|
On 2005-11-23 08:40+0100 Arjen Markus wrote: > Hello Alan, > > here are the results of my experiment: > > main program (tstarg.f): > > program tstarg > call chkargs > end > > subroutine (chkargs.f): > > subroutine chkargs > integer i > integer iargc > external iargc, getarg > character*20 arg > > write(*,*) 'Number arguments:', iargc() > do i = 0,5 > call getarg(i,arg) > write(*,*) i, arg > enddo > return > end > > This works as expected if I do: > > g77 -o tstarg tstarg.f chkargs.f > ./tstarg a b c > > Result: > Number arguments: 3 > 0./tstarg.exe > 1a > 2b > 3c > 4 > 5 > > This gives a coredump or rather an error message with the > invitation to send an email to MicroSoft about the problem, > when I put the subroutine in a shared library: > > HP_Eigenaar@souterrain > /cygdrive/c/arjen/plplot/plplot-5.5.3/examples/f90 > $ g77 -o chkargs.so -shared chkargs.f -fPIC > chkargs.f:0: warning: -fPIC ignored for target (all code is position > independent > ) > > HP_Eigenaar@souterrain > /cygdrive/c/arjen/plplot/plplot-5.5.3/examples/f90 > $ g77 -o tstarg tstarg.f chkargs.so -fPIC > tstarg.f:0: warning: -fPIC ignored for target (all code is position > independent) > > > HP_Eigenaar@souterrain > /cygdrive/c/arjen/plplot/plplot-5.5.3/examples/f90 > $ ./tstarg a b c > > <<Error message>> > > HP_Eigenaar@souterrain > /cygdrive/c/arjen/plplot/plplot-5.5.3/examples/f90 > $ > > The -fPIC is not relevant on the Cygwin platform it seems, but to my > surprise, the program also fails when I pass the iargc and getarg > routines as arguments (I thought I might be able to bypass the snake pit > of memory issues that way). I tried several other variations, but the > result was the same: only when I use iargc() and getarg() from a > static library will the program work as expected. > Hi Arjen, Thanks for your experiments so far. However, I am not sure your above compile step is actually going to create a shared library for Cygwin. From your previous shared library compile runs for the PLplot build, here is the equivalent of how libtool would do it on Cygwin (assuming you ignore -fPIC which I agree with you seems irrelevant from the above messages). #Create compiled object. This step appears to be the same as required for #the static case on Cygwin. g77 chkargs.f -o chkargs.o #Create shared library from that compiled object g77 -shared chkargs.o -o cygplplotf77d-9.dll \ -Wl,--enable-auto-image-base \ -Wl,--out-implib,libplplotf77d.dll.a #Create main programme which uses the shared library g77 tstarg.f -o tstarg libplplotf77d.dll.a I don't know the purpose of creating both the cyg*-9.dll form and lib*.dll.a form of the shared library, but I notice lots of Cygwin shared libraries seem to be organized that way. Could you try this 3-part shared build method, please? If there is some obvious improvement to this scheme that you prefer, please let me know your exact 3-part shared build steps so that I can report them to the Cygwin list along with the rest of the bug report (see below). Here are some more semi-random experiments I suggest you try. Most of these experiments assume there is some sort of error that exists for both static and shared linking, but which has no visible symptoms (by accident) for static linking. Did you try dropping the external statement? It is not needed on Linux, and in fact I don't see the point of it at all. Would you use external for any other library function such as cos? It might cause an error on Cygwin (which is only visible for shared linking). I would also drop the type statement for iargc since that is an intrinsic function. The Cygwin fortran library may have the wrong intrinsic type for iargc implemented by mistake so I suggest your best bet is to let it figure out the intrinsic type for iargc itself rather than forcing a type that may not agree with the implementation. Again, I am going by the way an invocation of the cos function should be handled. What happens if you only have the iargc call and comment out the getchar call and vice versa? I would like to know which fails or whether they both fail. What happens if you comment out the getchar call and replace the iargc call by calculating cos(1.0)? The linking and memory issues should be similar to iargc and getarg so if cos works and iargc and/or getarg do not, then that eliminates some possible explanations for the problem. Once you tell me the exact 3-part commands you used to compile and link the shared library and compile and link the main routine, and also once you have the results of the second round of simple experiments and exact error messages, then I would be happy to write up the bug report for the Cygwin list unless you want to do that yourself. I expect once they get such a detailed bug report with a simple example where they can verify the error for themselves, they will give us some quick action. 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 FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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: Geoffrey F. <fu...@li...> - 2005-11-23 15:56:19
|
Hi guys, I hate to barge in on a discussion where I am obviously deeply lacking in context. However, I did have a thought or two here: Alan W. Irwin writes: > On 2005-11-23 08:40+0100 Arjen Markus wrote: > > > Hello Alan, > > > > here are the results of my experiment: > > > > main program (tstarg.f): > > > > program tstarg > > call chkargs > > end > > > > subroutine (chkargs.f): > > > > subroutine chkargs > > integer i > > integer iargc > > external iargc, getarg > > character*20 arg > > > > write(*,*) 'Number arguments:', iargc() > > do i = 0,5 > > call getarg(i,arg) > > write(*,*) i, arg > > enddo > > return > > end > > > > This works as expected if I do: > > > > g77 -o tstarg tstarg.f chkargs.f > > ./tstarg a b c > > > > Result: > > Number arguments: 3 > > 0./tstarg.exe > > 1a > > 2b > > 3c > > 4 > > 5 > > > > This gives a coredump or rather an error message with the > > invitation to send an email to MicroSoft about the problem, As well it should. I would expect that to issue a coredump on any operating system in any compilation environment. You're probably just "lucky" in the non dll case. If this: > > subroutine chkargs > > integer i > > integer iargc > > external iargc, getarg > > character*20 arg > > > > write(*,*) 'Number arguments:', iargc() > > do i = 0,iargc() > > call getarg(i,arg) > > write(*,*) i, arg > > enddo > > return > > end were to coredump, now that would be more of a mystery. > Did you try dropping the external statement? It is not needed on Linux, and external declarations are required in Fortran. > in fact I don't see the point of it at all. Would you use external for any > other library function such as cos? It might cause an error on Cygwin No. cos and friends are "intrinsic" functions. Callling COS is /not/ like calling myfunc(). In fortran, the external keyword is here for this purpose. > (which is only visible for shared linking). I would also drop the type > statement for iargc since that is an intrinsic function. The Cygwin fortran > library may have the wrong intrinsic type for iargc implemented by mistake > so I suggest your best bet is to let it figure out the intrinsic type for > iargc itself rather than forcing a type that may not agree with the There is no "intrnsic type of iargc" in Fortran. It's not a part of Fortran, per se, just an external provision in the overall operating environment. > implementation. Again, I am going by the way an invocation > of the cos function should be handled. COS is intrinsic, Fortran "knows" about it because its specified in the Fortran standard. > What happens if you only have the iargc call and comment out the getchar > call and vice versa? I would like to know which fails or whether they > both fail. Me too. I bet iargc() by itself will be fine, and that the problem is the getarg call which is inducing a coredump through specification of out of range parameters. Hope this is helpful, and not just sending you off into the weeds. |
From: Arjen M. <arj...@wl...> - 2005-11-23 11:11:50
|
"Alan W. Irwin" wrote: > > > Thanks for your experiments so far. > > However, I am not sure your above compile step is actually going to create a > shared library for Cygwin. From your previous shared library compile runs > for the PLplot build, here is the equivalent of how libtool would do it on > Cygwin (assuming you ignore -fPIC which I agree with you seems irrelevant > from the above messages). > > #Create compiled object. This step appears to be the same as required for > #the static case on Cygwin. > g77 chkargs.f -o chkargs.o > #Create shared library from that compiled object > g77 -shared chkargs.o -o cygplplotf77d-9.dll \ > -Wl,--enable-auto-image-base \ > -Wl,--out-implib,libplplotf77d.dll.a > #Create main programme which uses the shared library > g77 tstarg.f -o tstarg libplplotf77d.dll.a > > I don't know the purpose of creating both the cyg*-9.dll form and lib*.dll.a > form of the shared library, but I notice lots of Cygwin shared libraries > seem to be organized that way. > It is worth a try. I am not sure whether I will have time the coming few days, but I will try. > Could you try this 3-part shared build method, please? If there is some > obvious improvement to this scheme that you prefer, please let me know your > exact 3-part shared build steps so that I can report them to the Cygwin list > along with the rest of the bug report (see below). > > Here are some more semi-random experiments I suggest you try. Most of these > experiments assume there is some sort of error that exists for both static > and shared linking, but which has no visible symptoms (by accident) for > static linking. > > Did you try dropping the external statement? It is not needed on Linux, and > in fact I don't see the point of it at all. Would you use external for any > other library function such as cos? It might cause an error on Cygwin > (which is only visible for shared linking). I would also drop the type > statement for iargc since that is an intrinsic function. The Cygwin fortran > library may have the wrong intrinsic type for iargc implemented by mistake > so I suggest your best bet is to let it figure out the intrinsic type for > iargc itself rather than forcing a type that may not agree with the > implementation. Again, I am going by the way an invocation > of the cos function should be handled. > > What happens if you only have the iargc call and comment out the getchar > call and vice versa? I would like to know which fails or whether they > both fail. > > What happens if you comment out the getchar call and replace the iargc call > by calculating cos(1.0)? The linking and memory issues should be similar to > iargc and getarg so if cos works and iargc and/or getarg do not, then that > eliminates some possible explanations for the problem. > > Once you tell me the exact 3-part commands you used to compile and link the > shared library and compile and link the main routine, and also once you have > the results of the second round of simple experiments and exact error > messages, then I would be happy to write up the bug report for the Cygwin > list unless you want to do that yourself. I expect once they get such a > detailed bug report with a simple example where they can verify the error > for themselves, they will give us some quick action. > I added the EXTERNAL statement merely to be accurate. For functions like cos() and log10() this is not necessary, they are defined by the standard. But iargc and getarg are not. Oh well, these variations you suggest seem worth looking into (or perhaps I should say: seem worth poking around with ... as I am completely at a loss when it comes to the inner regions of the compilation and linking process) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2005-11-23 19:57:18
|
On 2005-11-23 09:55-0600 Geoffrey Furnish wrote: > If this: > > > > subroutine chkargs > > > integer i > > > integer iargc > > > external iargc, getarg > > > character*20 arg > > > > > > write(*,*) 'Number arguments:', iargc() > > > do i = 0,iargc() > > > call getarg(i,arg) > > > write(*,*) i, arg > > > enddo > > > return > > > end > > were to coredump, now that would be more of a mystery. The point of the first form (with a fixed limit of 5 rather than iargc()) is to isolate the use of the two functions from each other (so you can comment one out and vice versa to find which is giving the trouble). It turns out (see below) that the g77 form of getarg returns blanks if you ask for an argument outside the range. However, the question about such implementation details is a distraction which I should have avoided in my original post by using an example which always does the test with 5 arguments, and I think that would be a good idea for Arjen to do that from now on as well. > > > Did you try dropping the external statement? It is not needed on Linux, and > > external declarations are required in Fortran. > > > in fact I don't see the point of it at all. Would you use external for any > > other library function such as cos? It might cause an error on Cygwin > > No. cos and friends are "intrinsic" functions. Callling COS is /not/ like > calling myfunc(). In fortran, the external keyword is here for this > purpose. > > > (which is only visible for shared linking). I would also drop the type > > statement for iargc since that is an intrinsic function. The Cygwin fortran > > library may have the wrong intrinsic type for iargc implemented by mistake > > so I suggest your best bet is to let it figure out the intrinsic type for > > iargc itself rather than forcing a type that may not agree with the > > There is no "intrnsic type of iargc" in Fortran. It's not a part of Fortran, > per se, just an external provision in the overall operating environment. > > > implementation. Again, I am going by the way an invocation > > of the cos function should be handled. > > COS is intrinsic, Fortran "knows" about it because its specified in the > Fortran standard. > > > What happens if you only have the iargc call and comment out the getchar > > call and vice versa? I would like to know which fails or whether they > > both fail. > > Me too. I bet iargc() by itself will be fine, and that the problem is the > getarg call which is inducing a coredump through specification of out of > range parameters. Geoffrey, it turns out your external/intrinsic comments were not correct at least for g77, but they were still useful because they lead me to dig deeper in the g77 documentation to get the definitive answer. It turns out that "info g77" says both iargc and getarg are intrinsic library routines associated with g77. I quote the relevant sections of documentation later, but there is a lot of general intrinsic information supplied by "info g77" which I want to quote first to develop this response to your remarks in a logical order. "Note that a name is not treated as that of an intrinsic if it is specified in an `EXTERNAL' statement in the same program unit; if a command-line option is used to disable the groups to which the intrinsic belongs; or if the intrinsic is not named in an `INTRINSIC' statement and a command-line option is used to hide the groups to which the intrinsic belongs. "So, it is recommended that any reference in a program unit to an intrinsic procedure that is not a standard FORTRAN 77 intrinsic be accompanied by an appropriate `INTRINSIC' statement in that program unit. This sort of defensive programming makes it more likely that an implementation will issue a diagnostic rather than generate incorrect code for such a reference." So, Arjen, you definitely should not use external. Furthermore, to force the issue so that the compiler/linker will issue a diagnostic if there is an implementation problem on Cygwin for these intrinsics you should be using the intrinsic iargc, getarc statement for your test case. I just tested that statement for g77 on my Linux system without problems. If the g77 compiler or associated linker on Cygwin issues a diagnostic for that, then that would help us pin down what is wrong. "A given specific intrinsic belongs in one or more groups. Each group is deleted, disabled, hidden, or enabled by default or a command-line option." [...] " The groups are: [skipped the irrelevant ones to this discussion] `unix' UNIX intrinsics (`IARGC', `EXIT', `ERF', and so on)." Note, there is no mention on this list of a "standard Fortran 77" intrinsic group (see cos documentation below). I think those standard intrinsics are just on by default so that is why they are not mentioned in the above list (and probably why it is not necessary to ever use intrinsic statements with standard fortran intrinsics such as cos). Finally here is the documentation for iargc, getarg, and cos (for comparison). *** IArgC() IArgC: `INTEGER(KIND=1)' function. Intrinsic groups: `unix'. Description: Returns the number of command-line arguments. This count does not include the specification of the program name itself. *** CALL GetArg(POS, VALUE) POS: `INTEGER' not wider than the default kind; scalar; INTENT(IN). VALUE: `CHARACTER'; scalar; INTENT(OUT). Intrinsic groups: `unix'. Description: Sets VALUE to the POS-th command-line argument (or to all blanks if there are fewer than VALUE command-line arguments); `CALL GETARG(0, VALUE)' sets VALUE to the name of the program (on systems that support this feature). *Note IArgC Intrinsic::, for information on how to get the number of arguments. *** Cos(X) Cos: `REAL' or `COMPLEX' function, the exact type being that of argument X. X: `REAL' or `COMPLEX'; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description: Returns the cosine of X, an angle measured in radians. *** So these routines are all intrinsic functions for g77 with the important distinction that iargc and getarg are in the unix intrinsic group while cos is in the (standard FORTRAN 77) intrinsic group. It is because of this distinction that the above intrinsic iargc, getarg line should always be in Arjen's test code. Furthermore, "info g77" also says to enable the unix intrinsics use the -funix-intrinsics-enable g77 option, but it also says that option is the default. Nevertheless, Arjen, I would always use -funix-intrinsics-enable to see if it makes any difference on Cygwin. (You might get a special message about that intrinsic group not being implemented on that platform which would be extremely helpful in its own right.) I am looking forward to the results of your further experimentation, Arjen. It is important when reporting your tests here to give your final source code version in its entirety (including the above intrinsic statement) and also give every exact command-line step that you used to compile the library code with the -funix-intrinsics-enable option, link the shared library, compile and link the main programme and execute the main programme (with 5 arguments so as not to distract discussion into getarg implementation details on g77). Also, do exactly the same thing for your static case. Finally, give full diagnostic messages. In short, give *all* the details rather than just summarizing. My prediction is you will get consistent results out of the shared and static cases when you make the intrinsic and -funix-intrinsics-enable changes. What I cannot predict, of course, is whether those consistent results will be bad (perhaps with some specific useful diagnostics) or good so I am very much looking forward to your next report to find out. I also think it is important to try variations of your full source code with either the iargc and getarg calls commented out to see whether both fail or just one fails, and also replace iargc with cos(1.) to show what happens in that case as a benchmark comparison for the standard fortran 77 intrinsic group. Exact and comprehensive reporting of these variations as well as your "full" test for both the shared and static cases will substantially improve our chances of getting a quick fix out of the Cygwin group for this problem. 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 FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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: Arjen M. <arj...@wl...> - 2005-11-24 07:22:59
|
Geoffrey Furnish wrote: > > Hi guys, > > I hate to barge in on a discussion where I am obviously deeply lacking in > context. However, I did have a thought or two here: > > > > Result: > > > Number arguments: 3 > > > 0./tstarg.exe > > > 1a > > > 2b > > > 3c > > > 4 > > > 5 > > > > > > This gives a coredump or rather an error message with the > > > invitation to send an email to MicroSoft about the problem, > > As well it should. I would expect that to issue a coredump on any operating > system in any compilation environment. You're probably just "lucky" in the > non dll case. > I have some suspicion about this myself (accessing command-line arguments that are obviously not there). But there is no output at all to the screen, not even a print of the number of arguments. I thought screen output was not buffered. > Me too. I bet iargc() by itself will be fine, and that the problem is the > getarg call which is inducing a coredump through specification of out of > range parameters. > Well, just another experiment to look into :). I should have time tomorrow, it is an intriguing problem, as the examples in PLplot fail on iargc() returning -1. So, maybe indeed trying to access arguments beyond those present is the cause of the coredump. But that leaves us with iargc() returning -1 ... Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-11-24 07:33:54
|
"Alan W. Irwin" wrote: > > > The point of the first form (with a fixed limit of 5 rather than iargc()) is > to isolate the use of the two functions from each other (so you can comment > one out and vice versa to find which is giving the trouble). It turns out > (see below) that the g77 form of getarg returns blanks if you ask for an > argument outside the range. However, the question about such implementation > details is a distraction which I should have avoided in my original post by > using an example which always does the test with 5 arguments, and I think > that would be a good idea for Arjen to do that from now on as well. > Will do :) > > > > Geoffrey, it turns out your external/intrinsic comments were not correct at > least for g77, but they were still useful because they lead me to dig deeper > in the g77 documentation to get the definitive answer. It turns out that > "info g77" says both iargc and getarg are intrinsic library routines > associated with g77. I quote the relevant sections of documentation later, > but there is a lot of general intrinsic information supplied by "info g77" > which I want to quote first to develop this response to your remarks in a > logical order. > I must admit that my knowledge of the FORTRAN 77 standard (and the variant adopted by g77) is a bit hazy on stuff like EXTERNAL and INTRINSIC. It appears there is much more to it than I thought. Finally here is the documentation for iargc, getarg, and cos (for comparison). > > *** > IArgC() > > IArgC: `INTEGER(KIND=1)' function. > Curious: KIND= is a Fortran 90 feature! > > I also think it is important to try variations of your full source code with > either the iargc and getarg calls commented out to see whether both fail or > just one fails, and also replace iargc with cos(1.) to show what happens in > that case as a benchmark comparison for the standard fortran 77 intrinsic > group. Exact and comprehensive reporting of these variations as well as your > "full" test for both the shared and static cases will substantially improve > our chances of getting a quick fix out of the Cygwin group for this problem. > Thanks for digging all this up. I will try to be systematic in my experiments and keep the source code rather than simply change the source files for the next one. Given the number of avenues to explore, this is the only way to make clear what is going on/wrong. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2005-11-18 17:43:30
|
On 2005-11-18 15:09+0100 Arjen Markus wrote: > Hello all, > > just a quick question about the support of UNICODE in PLplot: > > I have built PLplot on the Cygwin platform with freetype support. That's excellent news, Arjen. > I want to check that UNICODE characters are fully supported > (well, within the limits of the available fonts). How do I > do that? Is it enough to run x23c and x24c to check that > they display the right kind of non-latin characters? If for -dev png (or some other unicode aware device) you can get results similar to http://plplot.sourceforge.net/examples/demo23.php you probably have unicode fonts working fine. That example evaluates font results for unicode blocks that are useful for mathematical needs, but with small coding changes you could use it to evaluate fonts for other unicode blocks as well. The results at the above URL were generated using the default (on Linux) Freefont font package which has quite complete coverage of these unicode blocks compared to other fonts I have evaluated. That Linux default font set is specified at cf/freetype.ac. In that file you will also see logic that gives a different default font set for Cygwin and MinGW which Andrew (Roach) recommends for those platforms (because those fonts tend to be preinstalled on those platforms). Reproducing the results at http://plplot.sourceforge.net/examples/demo24.php is more challenging than reproducing the example 23 results because of the variety of non-default language fonts required, but it's a worthwhile challenge because it shows the fonts on the platform you are testing support languages other than those of western Europe. Andrew, have you ever got example 24 to work on MinGW? If so, what fonts do you recommend for that case that should be easy to obtain for MinGW and Cygwin? 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 FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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: Andrew R. <aro...@ya...> - 2005-11-19 00:39:24
|
At 09:43 AM 18/11/2005 -0800, you wrote: >Reproducing the results at http://plplot.sourceforge.net/examples/demo24.php >is more challenging than reproducing the example 23 results because of the >variety of non-default language fonts required, but it's a worthwhile >challenge because it shows the fonts on the platform you are testing support >languages other than those of western Europe. Andrew, have you ever got >example 24 to work on MinGW? If so, what fonts do you recommend for that >case that should be easy to obtain for MinGW and Cygwin? Parts of it, but not all. I am just using the pre-installed fonts that come with windows. -Andrew |