From: Joao C. <jca...@in...> - 2001-12-13 20:11:09
|
On Tuesday 11 December 2001 23:50, Alan W. Irwin wrote: | I haven't been able to spend as much time as I wanted to on Plplot so t= here | is still a lot for me to do before the release. Thus, I am backing awa= y | from a release within a few days. I won't put it off for a long time, = but | this should give all of you a chance to do a bit more before the releas= e. | | Here is my wish list for the release. Feel free to modify it, but let'= s =2E.. | (9) Get command-line parameter parsing to work for octave x examples. | (Joao). This is needed so that, for example, the -fam and -fnum parame= ters | work for the drivers that require familying, but it would also be nice = to | see this work for all parameters (like it does for the p octave example= s). I can try this, but now I'm too busy. =2E.. | (12) IMO, the most egregious bug for the plplot library shows up for x0= 8c | with the non-smooth edges (missing triangles) to the hidden parts of th= e | plot for pages 5 through 8 (the 3D shade plot demonstration). If a C ex= pert | here is wondering how they can chip in, it would be *wonderful* to fina= lly | get rid of this bug. Yes, this worries me too, but it is not a matter of C expertise. I think = that=20 Geoffrey has already tried to correct it, and if I remember correctly he = said=20 "better to write it from the begining" | | (13) dynamic tk and xwin driver. (probably Joao). My impression from | commented out parts of the code that I reviewed for the cgm driver is t= his | might be ready to go now that we understand exactly what is required in | the gd and cgm cases. Every dynamic driver requires a link to libplplo= t | and some require additional links to their own special libraries. Woul= dn't | those special libraries just be the Tk library for the tk driver and th= e X | libraries for the xwin driver? The xwin and tk drivers can't be made dynamic. There is no problem with the xwin driver alone, but the tk driver (either= =20 static or dynamic) won't work with a dynamic xwin driver. The tk driver n= eeds=20 some functions that are in the xwin driver. The only solution, which is not elegant, would be to link tk.o and xwin.o= to=20 make tk.drv. | (14) Joao also mentioned in his last e-mail that he wanted to play with | plimage a bit more. Yes, but I had not the time. | I have probably forgotten some things so feel free to add to this list = so | long as the project is reasonably short (a few days or less). This is an issue that worries me. You make a beatifull job testing plplot= =20 regularly, and you post your conclusions/bugs/requests. But we might be b= usy=20 at the time, and your conclusions/requests becomes lost. I always archive= =20 your testing requests for latter usage, but most of the time I just forgo= t to=20 use them. I think that we should start using some mechanism to correct this. A=20 possibility will be using the "tasks manager",=20 http://sourceforge.net/pm/?group_id=3D2915 , creating an entry for each d= river=20 and language binding. What do you think? Joao |
From: Alan W. I. <ir...@be...> - 2002-01-13 01:55:39
|
The release date is only 12 days away so I thought I should review where we stand. I have dropped the extended gdimage colour image example for now---there is just too much else to do. Also for similar reasons, Alessandro has dropped any additional pyqt GUI development until a later time. Also, I have made a lot of progress on the examples, and the xw09.py segfault has not come back to haunt me. Here is what I am aware is left. Above the line is my responsibility (unless I make remarks about where others can help). (1) Make consistent examples for all the various front ends. I have made a lot of progress on this, and I hope to find a good stopping point late this week. At that time I hope to have python, tcl, C, and yorick finished (aside from example 20 which I won't do this time and examples 14, 17, and 19 which I will probably never do for various reasons.) I also hope to still make a lot of progress on the Java examples. Fortran, C++, and perl will have to wait unless somebody volunteers. Joao, if you feel like bringing the "x" octave examples in line with the new extended examples (in those cases where they are different), try following what was done for x01c.c through x13c.c for now (since those are finished), and by the end of this week the extended x15c, x16c, and x18c should be ready as well. The goal is for your postscript output to be equivalent to the others for each example as a test that your front end is doing exactly what it is supposed to. (2) Get documentation to build on Debian woody. (3) README-style documentation about what I did recently for the cgm driver configuration. Hopefully, this will be the start of a new cookbook for the dynamic (and static) driver configuration. (4) README-style documentation on setting up java, python, pyqt. (5) On Monday, 21 January, I plan to start the full test process (essentially complete runs of plplot-test.sh for psc, png, jpeg, and possibly cgm drivers) for Debian woody, limited compile farm Debian potato and Solaris, and possibly RedHat 7.2 (if I can get access at UVic). Joao hopefully will be testing for the additional environments available to him at the same time. If any changes are made to CVS after the tests are completed, but before the CVS freeze time the file results from the earlier tests will be available for quick comparisons to be sure nothing essential was clobbered by the extra changes. (6) Starting at the CVS freeze time of 8:00 PST (= 16:00 UT) on 24 January, I will finish any last minute testing of changes, and all the other mechanical stuff I do for a release to make it available at our SF release area. Typically, the whole process takes several hours (although no guarantees--it could be as much as a day or so if there is a nasty bug we are chasing down) until I give the word that you can use CVS again. (7) After the file release is available at sourceforge (and downloaded again to make sure it is identical with the original), I will circulate an announcement on the plplot-general list, sourceforge, freshmeat, SAL, and Linuxburg. (8) I will try to get an RH 7.2 rpm available at SF within a day of the release. Joao had some trouble making RPM's for the distributions that were available to him last time, but I hope he tries again this time; it greatly expands our userbase if we can make rpm's for some of the major distributions. I also hope Rafael can quickly (say within a week after release) make a Debian version of the new release for exactly the same promotional reasons. Everything below this line is someone else's responsibility, but I am willing to help with testing. **************************************** (7) Finish W98 and W2000 changes. Olof is apparently satisfied with what has been checked in, but he still needs to finish some README-style documention about how to build the windows port of PLplot. (8) Java API (Geoffrey, especially the plcont, plshade, and plshades API that is necessary for examples 9, 15, and 16). (9) Some (possible?) additional changes associated with plimage from Joao, and Olof. Just be sure to leave it in a reasonably well-working state for the release. (10) Maurice's changes that he has discussed previously on list. Reviewing his e-mail about this, they include the solution for the "plgdevlst: too many devices" bug, a fix for some "configuration problems involving excluded devices", and a Tk widgets resources project Maurice hoped to complete before release. Is there anything else? Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
From: <jca...@in...> - 2002-01-14 23:18:36
|
On Sunday 13 January 2002 01:55, Alan W. Irwin wrote: =2E.. | The release date is only 12 days away so I thought I should review | where we stand. =2E.. | (1) Make consistent examples for all the various front ends. I =2E.. | Joao, if you feel like bringing | the "x" octave examples in line with the new extended examples (in | those cases where they are different), try following what was done | for x01c.c through x13c.c for now (since those are finished), and | by the end of this week the extended x15c, x16c, and x18c should be | ready as well. The goal is for your postscript output to be | equivalent to the others for each example as a test that your front | end is doing exactly what it is supposed to. Hi, In the next five weeks I don't have the time for sistematic plplot=20 development; however I will be able to make small corrections and bug=20 fixes. | (5) On Monday, 21 January, I plan to start the full test process | (essentially complete runs of plplot-test.sh for psc, png, jpeg, | and possibly cgm drivers) for Debian woody, limited compile farm | Debian potato and Solaris, and possibly RedHat 7.2 (if I can get | access at UVic). Joao hopefully will be testing for the additional | environments available to him at the same time. That's fine for me. =2E.. | (8) I will try to get an RH 7.2 rpm available at SF within a day of | the release. Joao had some trouble making RPM's for the | distributions that were available to him last time, but I hope he | tries again this time; OK, I will try it again, but I will need independent testing=20 (suse-7.2), as my system is heavely hand-tuned. | (9) Some (possible?) additional changes associated with plimage | from Joao, and Olof. Yes, but it still work in progress. | Is there anything else? Have you recently tested an installed plplot? I think to remember=20 that there was some problems left from java? Joao |
From: Alan W. I. <ir...@be...> - 2002-01-15 22:37:38
|
On Mon, 14 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > (AWI wrote) Is there anything else? > > Have you recently tested an installed plplot? I think to remember > that there was some problems left from java? Of course before installation, all java examples work fine if you are in tm= p and you set setenv CLASSPATH java setenv LD_LIBRARY_PATH . No problems here with java after installation as well. I do the following (your install location will probably differ): setenv CLASSPATH /usr/local/plplot/lib/java setenv LD_LIBRARY_PATH /usr/local/plplot/lib/ cd /tmp #to prove that your current directory doesn't matter. java plplot.examples.x01 java plplot.examples.x08 Those examples worked fine so I am sure the rest are fine as well. This brings up some other java install questions. Geoffrey, I cannot find any installed source for the java files. Shall I just change the configuration so the sources will be installed into the appropriate subdirectory of $prefix/plplot/lib/java/plplot along with their corresponding *.class files? Finally, I would like to install java/plplot/examples into the examples install area ($prefix/lib/plplot5.1.0/examples/). This requires two directories in CLASSPATH, e.g., setenv CLASSPATH \ /usr/local/plplot/lib/java:/usr/local/plplot/lib/plplot5.1.0/examples/java but so long as that change is made, e.g., java plplot.examples.x01 works fine. The reason I would like this change is it just seems more logical to me to have the java examples installed with the remainder of the plplot examples, and the java core stuff installed in $prefix/lib/java righ= t where it is now. This is just a suggestion, and if you feel the best solution is the current one with the java examples split off from the rest of the examples, then I will go along. Alan email: ir...@be... phone: 250-727-2902=09FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
From: Geoffrey F. <fu...@ga...> - 2002-01-15 23:59:14
|
Alan W. Irwin writes: > Geoffrey, I cannot find any installed source for the java files. Shall I > just change the configuration so the sources will be installed into the > appropriate subdirectory of $prefix/plplot/lib/java/plplot along with > their corresponding *.class files? > > Finally, I would like to install > java/plplot/examples into the examples install area > ($prefix/lib/plplot5.1.0/examples/). This requires two directories in > CLASSPATH, e.g., > > setenv CLASSPATH \ > /usr/local/plplot/lib/java:/usr/local/plplot/lib/plplot5.1.0/examples/java > > but so long as that change is made, e.g., > > java plplot.examples.x01 > > works fine. The reason I would like this change is it just seems more > logical to me to have the java examples installed with the remainder of the > plplot examples, and the java core stuff installed in $prefix/lib/java right > where it is now. This is just a suggestion, and if you feel the best > solution is the current one with the java examples split off from the rest > of the examples, then I will go along. Mmm. Well, I just think of it that all the PLplot java stuff lives under the plplot.* package hierarchy. Some of it is under plplot.core.*, some of it is under plplot.examples.*. I said way back in the beginning, that I am a novice in java packaging, so what is done now is surely simplistic. However, your proposal doesn't seem right to me either, since it seems kludgy to have to have two additions to classpath to use the java stuff. Maybe you could take the position that you only need the first one for normal client codes, and the second one is just to reach the PLplot Java demos, but to me it makes more sense to have one classpath component which reaches all things plplot/java. What is probably really in order, is to build a jar file. Then to enhance plplot-config to have a --classpath arg to spit out the right classpath for use as we do plplot-config --libs now in C/C++ contexts. But I haven't gotten to that yet. I am quite sure that upscale java dists use .jar files. But I don't really know how to create them fashionably, so have just put up the current hacky thing to get us through until either I learn what to really do, or until some Java guru developer graces us with some guru class configuration advice. Personally, I'd just leave it alone for now, figuring that it wil lhave to change later once we learn the ways of upscale Java packagers well enough to follow suit fashionably. -- Geoffrey Furnish fu...@ga... |
From: Alan W. I. <ir...@be...> - 2002-01-16 00:43:32
|
On Tue, 15 Jan 2002, Geoffrey Furnish wrote: > [...] However, your > proposal doesn't seem right to me either, since it seems kludgy to have > to have two additions to classpath to use the java stuff. Maybe you > could take the position that you only need the first one for normal > client codes, and the second one is just to reach the PLplot Java > demos, yes. Also, I was quite happy to see that your java package structure still worked fine if you assembled the bits and pieces from separate directory trees with the appropriate colon-separated list of directories in CLASSPATH. Of course, just because something is possible doesn't mean you have to do it so see below. > but to me it makes more sense to have one classpath component > which reaches all things plplot/java. OK. I will go along with this decision. > Personally, I'd just leave it alone for now, figuring that it wil > lhave to change later once we learn the ways of upscale Java packagers > well enough to follow suit fashionably. OK, to be revisited later when one of us knows more about jar files, etc. You didn't answer my question about the sources. Currently there are no java sources anywhere in the install directory tree. I believe at least the java example sources should be there (by analogy with the source code that is installed for the other examples). Assuming you agree on the examples, do you also want the core sources installed? Alan |
From: Maurice L. <mj...@ga...> - 2002-01-17 03:08:48
|
Alan W. Irwin writes: > (10) Maurice's changes that he has discussed previously on list. Reviewing > his e-mail about this, they include the solution for the "plgdevlst: too > many devices" bug, I will get to this. > a fix for some "configuration problems involving excluded > devices", I plan to get to this also. > and a Tk widgets resources project Maurice hoped to complete > before release. No way I can get it finished and not suck within a week. So, next time I guess. > Is there anything else? I'll have the palette tools working again, based on Vince's TEA work. Will require Itcl. Also, have had the rude awakening that on my default TrueColor visuals for 16 or 24 bit depths, I can't allocate r/w color cells, so these tools aren't nearly as cool as-is. When I switch to 8 bit display I can get back a PseudoColor display with r/w color cells and they work just as I remember them. So now I'm thinking for TrueColor displays I'll include a switch to redraw the whole plot each time a color is changed. Can be slow at times (so it will be configurable) but it's the same expense as with zoom/pan which isn't that bad on a fast system even for 256x256 resolution grids and color shading if the number of distinct colors isn't large (say 10). -- Maurice LeBrun mj...@ga... |
From: Joao C. <jc...@fe...> - 2002-01-17 11:12:01
|
Hi, I think that the main directory README, INSTALL, CHANGES and NEWS files=20 should be updated, as they are the first think that I read on (and I assu= me=20 others also do it :). The ToDo and PROBLEMS file also needs an update, as some users can have t= he=20 expertise and mood to do/solve it. WE *should* use it, also! The examples/java/README file should be in bindings/java, or its name cha= nged=20 to README.java, to follow what is done in the other examples directory. I thinks that each bindings and examples subdirs should have a README fil= e,=20 and the main README file should point to them. What is the purpose of the "new" directory and its "bogus" file? And the=20 bindings/python/1.4b3 subdir? When will be 5.1 released? What do we intend to have on it? Can we add mo= re=20 and more stuff to HEAD and always have an unstable CVS? I would like to add some things to the documentation, after english-proof= ing=20 by an English native speaker, but I found the DocBook too complex! I was=20 still not able to create the development environment (and I tried, and I=20 tried, and I tried , but I couldn't get it :-)). Is there a xml2sgml util= ity?=20 ( My system has a sgml2xml utility). Than I could convert to latex and ad= d=20 the docs. Oh well, questions, questions, Joao |
From: Alan W. I. <ir...@be...> - 2002-01-17 17:15:45
|
Joao, you have brought up a number of interesting points which I will attempt to answer in context below. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Thu, 17 Jan 2002, Joao Cardoso wrote: > > Hi, > > I think that the main directory README, INSTALL, CHANGES and NEWS files > should be updated, as they are the first think that I read on (and I assume > others also do it :). > The ToDo and PROBLEMS file also needs an update, as some users can have the > expertise and mood to do/solve it. WE *should* use it, also! I agree with both your points here. I don't have time to start any of this myself so I would encourage you (after the release, please!) to change these files any way you like. Once you start to use them, I (and perhaps the other developers) will most likely follow. Note, if there are any English problems with your changes, I would be willing to make corrections after you make your main changes. > > The examples/java/README file should be in bindings/java, or its name changed > to README.java, to follow what is done in the other examples directory. Done. > I thinks that each bindings and examples subdirs should have a README file, > and the main README file should point to them. We are gradually getting there on the first point, and on the second point I say please go ahead. I would be happy to see changes in the overall README before the release. > > What is the purpose of the "new" directory and its "bogus" file? And the > bindings/python/1.4b3 subdir? Haven't got a clue. > > When will be 5.1 released? 24 January. What do we intend to have on it? Current CVS HEAD plus any changes we do from now until then. See my wishlist. > Can we add more > and more stuff to HEAD Yes, so long as it is useful. plimage is an excellent example of such an add-on. and always have an unstable CVS? No. For example, we are in a stabilizing phase right now in preparation for the release. We have discussed release philosophy many times before so I will try to keep this short. As far as I am concerned, I never plan to make an experimental or unstable release. Instead, periodically we work hard to stabilize cvs HEAD and release that. My own view is we are too small a project to support a lot of different branches. For example, I never want to see a special stable branch (except periodically for CVS HEAD). Branches are useful for the really big changes such as dynamic drivers, but I personally lost weeks of work on the tea branch because there wasn't a critical mass of interested developers at the time. Thus, you have to be really careful about splitting development up too much. Taking the plimage example, again, I wouldn't have gotten interested in it if you hadn't put it on the HEAD. So for relatively small changes like this that don't impact a lot of other stuff, put them right on HEAD, then work to stabilize them in time for a release. Obviously, you are not quite satisfied with plimage yet ("work in progress"), but I am not personally going to worry if you change the API one more time after this release. Users of new features have to expect API changes. However, I do hope that the x20c example at least works for this release, and that you have plimage completely stabilized (including API decisions) in time for the release after this one. > > I would like to add some things to the documentation, after english-proofing > by an English native speaker, but I found the DocBook too complex! I was > still not able to create the development environment (and I tried, and I > tried, and I tried , but I couldn't get it :-)). I will be happy to help you get this sorted out, Joao. But I need specifics from you off list. (In the next few days I will be going through this for my own woody system and perhaps a RedHat 7.2 system as well so now is an excellent time to get the DocBook development environment working on your system as well.) > Is there a xml2sgml utility? > ( My system has a sgml2xml utility). Than I could convert to latex and add > the docs. > I have not heard of an xml2sgml facility. sgml is being phased out in favor of xml so I think the sgml/xml language types would view xml2sgml as a retrograde step they were unwilling to support. I think a much better solution is simply to get the DocBook-xml environment working on your system. I will help, but as I said above, I need specifics about what doesn't work. For example, how far did you get in README.developers? Alan |
From: <jca...@in...> - 2002-01-18 01:28:54
|
On Thursday 17 January 2002 17:15, Alan W. Irwin wrote: | Joao, you have brought up a number of interesting points which I | will attempt to answer in context below. | | Alan =2E.. | On Thu, 17 Jan 2002, Joao Cardoso wrote: | > Hi, | > | > I think that the main directory README, INSTALL, CHANGES and NEWS | > files should be updated, as they are the first think that I read | > on (and I assume others also do it :). | > The ToDo and PROBLEMS file also needs an update, as some users | > can have the expertise and mood to do/solve it. WE *should* use | > it, also! | | I agree with both your points here. I don't have time to start any | of this myself so I would encourage you (after the release, | please!) to change these files any way you like. Once you start to | use them, I (and perhaps the other developers) will most likely | follow. Note, if there are any English problems with your changes, | I would be willing to make corrections after you make your main | changes. As you say latter that this will be a major release, I think that=20 they should be changed now. But as nobody has the time now, I suggest=20 a 5.1.1 release to follow shortly after 5.1.0, with bug fixes and=20 improved docs. You can quickly change the the README or NEWS files by just appending=20 the announcements you made when you release 5.0.1...5.0.4. | > The examples/java/README file should be in bindings/java, or its | > name changed to README.java, to follow what is done in the other | > examples directory. | | Done. | | > I thinks that each bindings and examples subdirs should have a | > README file, and the main README file should point to them. | | We are gradually getting there on the first point, and on the | second point I say please go ahead. I would be happy to see | changes in the overall README before the release. I will try it. | | > What is the purpose of the "new" directory and its "bogus" file? | > And the bindings/python/1.4b3 subdir? | | Haven't got a clue. | | > When will be 5.1 released? | | 24 January. !?! I thought that this release would be 5.0.5! But if I were the boss we=20 would continue until reaching release 5.0.31415926 Seriously, there are too many new functionalities for this to be 5.1.=20 Java is all new, python has suffered significative modifications,=20 plimage() has still bugs on it, what else?... I can't use "plrender"=20 with device tk,.. | What do we intend to have on it? | | Current CVS HEAD plus any changes we do from now until then. See | my wishlist. | | > Can we add more | > and more stuff to HEAD | | Yes, so long as it is useful. plimage is an excellent example of | such an add-on. | | and always have an unstable CVS? | | No. For example, we are in a stabilizing phase right now in | preparation for the release. I don't agree. My not yet commited plimage() changes and related=20 functions are yet alpha. At this point I'm afraid of commiting my=20 changes, as perhaps the current cvs plimage() is more stable than=20 mine. I have just added an option to x01c to show how one can=20 programatically save a file (that is stable, I will commit it). What I mean is that 5.1 is too definitive for the current status. As you say, we are not many, and can't afford the pressure of a=20 faulty major release. | We have discussed release philosophy many times before so I will | try to keep this short. As far as I am concerned, I never plan to | make an experimental or unstable release. Instead, periodically we | work hard to stabilize cvs HEAD and release that. Yes, but I was not aware of 5.1.0 | My own view is we are too small a project to support a lot of | different branches. For example, I never want to see a special | stable branch (except periodically for CVS HEAD). I agree. | Branches are | useful for the really big changes such as dynamic drivers, but I | personally lost weeks of work on the tea branch because there | wasn't a critical mass of interested developers at the time. Thus, | you have to be really careful about splitting development up too | much. Taking the plimage example, again, I wouldn't have gotten | interested in it if you hadn't put it on the HEAD. So, it was my mistake. I would put it on a branch. | So for | relatively small changes like this that don't impact a lot of other | stuff, put them right on HEAD, then work to stabilize them in time | for a release. Obviously, you are not quite satisfied with plimage | yet ("work in progress"), but I am not personally going to worry if | you change the API one more time after this release. Users of new | features have to expect API changes. However, I do hope that the | x20c example at least works for this release, and that you have | plimage completely stabilized (including API decisions) in time for | the release after this one. Isn't the current x20c.c stable enought for you? As I said before, my=20 current changes are not so stable... I think, as I never run a clean=20 cvs HEAD again. | > I would like to add some things to the documentation, after | > english-proofing by an English native speaker, but I found the | > DocBook too complex! I was still not able to create the | > development environment (and I tried, and I tried, and I tried , | > but I couldn't get it :-)). | | I will be happy to help you get this sorted out, Joao. But I need | specifics from you off list. (In the next few days I will be going | through this for my own woody system and perhaps a RedHat 7.2 | system as well so now is an excellent time to get the DocBook | development environment working on your system as well.) | | > Is there a xml2sgml utility? | > ( My system has a sgml2xml utility). Than I could convert to | > latex and add the docs. | | I have not heard of an xml2sgml facility. sgml is being phased out | in favor of xml so I think the sgml/xml language types would view | xml2sgml as a retrograde step they were unwilling to support. It is not xml that is complicated, is all the setup needed to run it!=20 DocBook is for book writers, editors and publishers, not for a lonely=20 graphics library. I personaly don't want to spend too much time=20 writing docs, and I want to it using my usual tools. But what is done=20 is done. (And sgml was "made" because xml was too complicated for everyday=20 usage.) | I | think a much better solution is simply to get the DocBook-xml | environment working on your system. I will help, but as I said | above, I need specifics about what doesn't work. For example, how | far did you get in README.developers? Re-read it several times, installed several, possibly confliting=20 packages, looking for the tons of perl modules my system has and has=20 not... Don't worry, I will write the text, trying to use the tags=20 correctly, and I will submit it to you. Thanks, Joao |
From: Alan W. I. <ir...@be...> - 2002-01-18 02:55:03
|
On Fri, 18 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > On Thursday 17 January 2002 17:15, Alan W. Irwin wrote: > | > When will be 5.1 released? > | > | 24 January. > > !?! > > I thought that this release would be 5.0.5! But if I were the boss we > would continue until reaching release 5.0.31415926 ;-) > > Seriously, there are too many new functionalities for this to be 5.1. > Java is all new, python has suffered significative modifications, I don't care that much about version numbers except that I don't want to go through them too rapidly. My understanding is the major number should be incremented for huge changes, the minor number should be incremented for fairly large changes, and the patch number incremented for smaller changes. I absolutely agree with you there have been some fairly large changes made since 5.0.4. Thus, I assumed it was appropriate to increment the minor number and move on to 5.1.0. But if the developers here feel that 5.0.5 is more appropriate, that is certainly fine with me! For the others here, please let me know your feelings on this. > [...] what else?... I can't use "plrender" > with device tk,.. Neither can I, but this is the first I have heard of it! (I tend to do strictly non-interactive tests, and leave the interactive stuff to the rest of you.) I must have missed your bug report to the list....;-) Here is mine.... Maurice, here are the symptoms (with dynamic drivers configured if that makes a difference) There is no problem if I executed =2E/x01c -dev tk However, =2E/x01c -dev plmeta -o x01c.meta =2E/plrender -i x01c.meta -dev tk TCL command " invalid command name " Can this bug be fixed before the release? > > [....] My not yet commited plimage() changes and related > functions are yet alpha. At this point I'm afraid of commiting my > changes, as perhaps the current cvs plimage() is more stable than > mine. But the point is this does not affect anything other than x20c. It would b= e a much tougher decision if you were fiddling with the very inner core of plplot, but you are not. I hope to get out the next release within a month or two so if you make a mistake with plimage now, it will soon get corrected. So I am inclined to say that if x20c still works on your platform with all your uncommitted changes, then go ahead and commit them. However, if you are not comfortable with that, that is fine as well. Ultimately, of course, it is your decision. > I have just added an option to x01c to show how one can > programatically save a file (that is stable, I will commit it). > > What I mean is that 5.1 is too definitive for the current status. > As you say, we are not many, and can't afford the pressure of a > faulty major release. My understanding of release traditions is quite different. Patch version 0 of anything is never expected to be reliable. Compare kernel 2.4.0 with 2.4.17 or KDE 2.2.0 with 2.2.2, for example. That said, I do want the functionality that worked in 5.0.4 to continue to work in 5.0.5 (or 5.1.0., whichever the developers here prefer). I believe that is the case. It is only a small subset of the new things that have been added that are not completely stabilized yet. For example, dynamic drivers seem to work perfectly for all but xwin and tk, and our configuration scheme works around that problem so no user will be affected by it (assuming that plrender bug gets fixed.) Java is of course considered to be experimental since it is still incomplete, but for the defined API, i= t is rock solid. Python no longer segfaults. Thus, I will have no compunction about telling all our users we no longer support 5.0.4, and it is time to move to this next release (whatever version number we decide). Alan |
From: Joao C. <jc...@fe...> - 2002-01-18 14:27:47
|
On Friday 18 January 2002 2:54 am, Alan W. Irwin wrote: > On Fri, 18 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > > On Thursday 17 January 2002 17:15, Alan W. Irwin wrote: =2E.. > > [....] My not yet commited plimage() changes and related > > functions are yet alpha. At this point I'm afraid of commiting my > > changes, as perhaps the current cvs plimage() is more stable than > > mine. > > But the point is this does not affect anything other than x20c. It wou= ld > be a much tougher decision if you were fiddling with the very inner cor= e of > plplot, but you are not. I'm not sure about that. Working with plstrm.h, plcore.c, plbuf.c and xwi= n.c=20 might break others things. > I hope to get out the next release within a month > or two so if you make a mistake with plimage now, it will soon get > corrected. So I am inclined to say that if x20c still works on your > platform with all your uncommitted changes, then go ahead and commit th= em. > However, if you are not comfortable with that, that is fine as well. > Ultimately, of course, it is your decision. I have checked out a clean cvs and test x20c; it's more stable than my=20 current cvs, so I will not commit my changes for now. =2E.. > > What I mean is that 5.1 is too definitive for the current status. > > As you say, we are not many, and can't afford the pressure of a > > faulty major release. > > My understanding of release traditions is quite different. Patch versi= on 0 > of anything is never expected to be reliable. Compare kernel 2.4.0 wit= h > 2.4.17 or KDE 2.2.0 with 2.2.2, for example. But it is not "intencional". We *know* that, given the nature of things,=20 version 0 is unstable, no matter the efforts developpers made. But if you= =20 look at KDE, e.g., the 0 release is quite usable and is followed shortly = by a=20 bug correcting release. Gnome has even a shorter history release. But as Geoffrey said, you are the boss in this matter, and I'm glad you a= re=20 :-) Joao |
From: Maurice L. <mj...@ga...> - 2002-01-19 09:57:01
|
Alan W. Irwin writes: > > [...] what else?... I can't use "plrender" > > with device tk,.. > > Neither can I, but this is the first I have heard of it! (I tend to > do strictly non-interactive tests, and leave the interactive stuff to > the rest of you.) I must have missed your bug report to the list....;-) > > Here is mine.... > > Maurice, here are the symptoms (with dynamic drivers configured if that > makes a difference) > > There is no problem if I executed > > ./x01c -dev tk > > However, > > ./x01c -dev plmeta -o x01c.meta > ./plrender -i x01c.meta -dev tk > TCL command " > invalid command name " > > Can this bug be fixed before the release? With dyndrivers enabled, I don't see it. ged$ ./x01c -dev plmeta -o x01c.meta Plplot library version: 5.1.0 Opened x01c.meta ged$ ./plrender -i x01c.meta -dev tk ged$ So I'm pretty much stuck on that point. Hmm.. maybe it is related to the devlist bug. Please try again with the latest sources. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-01-19 18:23:55
|
On Sat, 19 Jan 2002, Maurice LeBrun wrote: > > ./x01c -dev plmeta -o x01c.meta > > ./plrender -i x01c.meta -dev tk > > TCL command " > > invalid command name " > > > > Can this bug be fixed before the release? > > With dyndrivers enabled, I don't see it. > So I'm pretty much stuck on that point. > Hmm.. maybe it is related to the devlist bug. You are right. The problem was still there yesterday, but now it is solved. Thanks very much for this effort! Release Status: From above, my impression is that the tk driver is now ready for the release. Yesterday, I finished all I wanted to do (the README's) in this cycle of the documentation work. Thanks to Geoffrey's recent API work we have example 9 and example 15 compatible between Java and the other front ends. That still leaves my compatibility work (probably a day or two more) for examples 16 and 18. After that I will work on coaxing the documentation to build for the first time on Debian woody. (That's probably just a matter of getting the right documentation packages installed.) Anyhow, I plan to terminate my wishlist before Tuesday. Joao, my impression from what you said is you decided to commit your plimage stuff. I haven't seen that yet, but I assume that will happen before Tuesday. Could somebody please volunteer to do a final comprehensive check that the C code is ansi-compliant? This would take some release burden off me. (I think I can recall how to check it, but if there are warnings, I wouldn't know how to fix up the problems except for the // commentary that screws up the Slowaris compiler.) Does anybody else here have work they want to get in before Tuesday? I would like to call a CVS "soft" freeze (nothing but bug fixes allowed) starting Tuesday 8 a.m. PST. I plan to start the comprehensive non-interactive testing on Tuesday for the various platforms that are available to me and Joao. This will take some time because there are a lot of images to look at, and there may still be some bugs that need squashing. Nevertheless, I believe we are still on schedule for releasing on Thursday with a hard CVS freeze starting Thursday 8.am. PST. Alan |
From: <jca...@in...> - 2002-01-20 00:38:36
|
On Saturday 19 January 2002 18:23, you wrote: | On Sat, 19 Jan 2002, Maurice LeBrun wrote: =2E.. | Joao, my impression from what you said is you decided to commit | your plimage stuff. No, I concluded that the cvs version is more stable than my current=20 version. Also, I have more than one undred examinations to correct during the=20 week-end, and I have no time for further developments. | Could somebody please volunteer to do a final comprehensive check | that the C code is ansi-compliant? This would take some release | burden off me. (I think I can recall how to check it, but if there | are warnings, I wouldn't know how to fix up the problems except for | the // commentary that screws up the Slowaris compiler.) I'm afraid that tk.c, around line 1229, uses some POSIX, non-ansi=20 system calls, such as sigemptyset(), sigaddset() and sigprocmask().=20 It's only purpose is to "Don't kill plserver on a ^C if=20 pls->server_nokill is set", and can safely be conditionaly compiled=20 within a #ifndef __STRICT_ANSI__/#endif block. I don't commit this=20 as I'm no ansi/posix expert, and it might be gcc (linux) specific. All other source files compiled OK, except for two warnings in=20 plframe.c. It looks like that fdopen() and fileno() are not ansi=20 compliant? | Does anybody else here have work they want to get in before | Tuesday? I would like to call a CVS "soft" freeze (nothing but bug | fixes allowed) starting Tuesday 8 a.m. PST. | | I plan to start the comprehensive non-interactive testing on | Tuesday for the various platforms that are available to me and | Joao. That's OK for me. Joao | This will take some time because there are a lot of images to | look at, and there may still be some bugs that need squashing.=20 | Nevertheless, I believe we are still on schedule for releasing on | Thursday with a hard CVS freeze starting Thursday 8.am. PST. | | Alan | | | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2002-01-20 03:02:43
|
On Sun, 20 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > No, I concluded that the cvs version is more stable than my current > version. OK. > > | Could somebody please volunteer to do a final comprehensive check > | that the C code is ansi-compliant? This would take some release > | burden off me. (I think I can recall how to check it, but if there > | are warnings, I wouldn't know how to fix up the problems except for > | the // commentary that screws up the Slowaris compiler.) > > I'm afraid that tk.c, around line 1229, uses some POSIX, non-ansi > system calls, such as sigemptyset(), sigaddset() and sigprocmask(). > It's only purpose is to "Don't kill plserver on a ^C if > pls->server_nokill is set", and can safely be conditionaly compiled > within a #ifndef __STRICT_ANSI__/#endif block. I don't commit this > as I'm no ansi/posix expert, and it might be gcc (linux) specific. > > All other source files compiled OK, except for two warnings in > plframe.c. It looks like that fdopen() and fileno() are not ansi > compliant? Thanks very much for that comprehensive check. I am particularly glad ther= e are no // commentary issues this time. Could a C expert here deal with the remaining non-ANSI problems that Joao has found? Alan |
From: Maurice L. <mj...@ga...> - 2002-01-20 04:01:41
|
Alan W. Irwin writes: > > > > | Could somebody please volunteer to do a final comprehensive check > > | that the C code is ansi-compliant? This would take some release > > | burden off me. (I think I can recall how to check it, but if there > > | are warnings, I wouldn't know how to fix up the problems except for > > | the // commentary that screws up the Slowaris compiler.) > > > > I'm afraid that tk.c, around line 1229, uses some POSIX, non-ansi > > system calls, such as sigemptyset(), sigaddset() and sigprocmask(). > > It's only purpose is to "Don't kill plserver on a ^C if > > pls->server_nokill is set", and can safely be conditionaly compiled > > within a #ifndef __STRICT_ANSI__/#endif block. I don't commit this > > as I'm no ansi/posix expert, and it might be gcc (linux) specific. > > > > All other source files compiled OK, except for two warnings in > > plframe.c. It looks like that fdopen() and fileno() are not ansi > > compliant? > > Thanks very much for that comprehensive check. I am particularly glad there > are no // commentary issues this time. Could a C expert here deal with the > remaining non-ANSI problems that Joao has found? There's no problem with non-ANSI, but POSIX, function calls AFAIK. -- Maurice LeBrun mj...@ga... |
From: Joao C. <jc...@fe...> - 2002-01-21 17:10:51
|
On Sunday 20 January 2002 4:00 am, Maurice LeBrun wrote: > Alan W. Irwin writes: > > > | Could somebody please volunteer to do a final comprehensive chec= k > > > | that the C code is ansi-compliant? This would take some release > > > | burden off me. (I think I can recall how to check it, but if th= ere > > > | are warnings, I wouldn't know how to fix up the problems except = for > > > | the // commentary that screws up the Slowaris compiler.) > > > > > > I'm afraid that tk.c, around line 1229, uses some POSIX, non-ansi > > > system calls, such as sigemptyset(), sigaddset() and sigprocmask()= =2E > > > It's only purpose is to "Don't kill plserver on a ^C if > > > pls->server_nokill is set", and can safely be conditionaly compile= d > > > within a #ifndef __STRICT_ANSI__/#endif block. I don't commit thi= s > > > as I'm no ansi/posix expert, and it might be gcc (linux) specific. > > > > > > All other source files compiled OK, except for two warnings in > > > plframe.c. It looks like that fdopen() and fileno() are not ansi > > > compliant? > > > > Thanks very much for that comprehensive check. I am particularly gl= ad > > there are no // commentary issues this time. Could a C expert here = deal > > with the remaining non-ANSI problems that Joao has found? > > There's no problem with non-ANSI, but POSIX, function calls AFAIK. The problem is that the compiler can't find the function prototypes, but=20 worse, the "sigset_t" type does not exists in ansi, and the compilation f= ails. Joao |
From: <jca...@in...> - 2002-01-20 01:03:24
|
On Saturday 19 January 2002 18:23, Alan W. Irwin wrote: | On Sat, 19 Jan 2002, Maurice LeBrun wrote: =2E.. | From above, my impression is that the tk driver is now ready for | the release. Yesterday, I finished all I wanted to do (the | README's) in this cycle of the documentation work. Thanks to | Geoffrey's recent API work we have example 9 and example 15 | compatible between Java and the other front ends.=20 Hi, Some problems that I detected during a pause: 1-Java (as well as Python and Octave) can't be build without shared=20 libraries. "configure" does not check for this and enables java if,=20 by accident, java exists and JAVA_HOME is defined. 2-Fortran examples x06f.f and x07f.f don't compile, eg: g77 -c -O x06f.f Line too long as of (?) [info -f g77 M LEX] x06f.f: In program `MAIN__': x06f.f:29: warning: call plmtex('b', real (1.5), real (0.1*i+0.05), 1 x06f.f:52: (continued): call plmtex('t', real (1.5), real (0.5), real (0.5), 2 Too few arguments for `plmtex' at (2) versus invocation at (1) [info=20 -f g77 M GLOBALS] x06f.f:52:=20 call plmtex('t', real (1.5), real (0.5), real (0.5), 1 2 Invalid token at (2) in expression or subexpression at (1) Sorry, I make no ideia about what's going on. Joao |
From: Alan W. I. <ir...@be...> - 2002-01-20 02:57:46
|
On Sun, 20 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > Hi, > > Some problems that I detected during a pause: > > 1-Java (as well as Python and Octave) can't be build without shared > libraries. "configure" does not check for this and enables java if, > by accident, java exists and JAVA_HOME is defined. =2E.. and if you explicitly enable java. It is not on by default because j= ava is still judged to be experimental; the API is not yet complete---although getting closer, and I am sure there are probably still a number of Java configuration issues to sort out. Thus, my judgement is these are minor configuration issues that are far from release critical, and I have higher priorities at the moment. However, if somebody else wants to tackle these issues (before Tuesday) that is fine with me. > > 2-Fortran examples x06f.f and x07f.f don't compile, eg: Fortran has worked forever for me, but I just tried again, and no problem. Thus, I cannot confirm your bug report. Did you configure with --with-double? That is required for fortran. Joao, although I don't view your first report as a particularly serious problem, and I could not confirm your second report, I very much appreciate your continued tests, and your "Devil's Advocate" attitude that there has got to be something seriously wrong with this release if you dig deeply enough. Without that attitude something serious might in fact slip by. By now, I am probably a lousy tester because I don't expect to find anything wrong because it so rarely happens in my non-interactive tests. So throw everything you got (especially interactive tests) at this latest version of PLplot! Alan |
From: Alan W. I. <ir...@be...> - 2002-01-20 16:59:46
|
On Sat, 19 Jan 2002, Alan W. Irwin wrote: > On Sun, 20 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > > 2-Fortran examples x06f.f and x07f.f don't compile, eg: > > Fortran has worked forever for me, but I just tried again, and no problem= =2E > Thus, I cannot confirm your bug report. Did you configure with > --with-double? That is required for fortran. I woke up this morning realizing that last sentence was wrong. IIRC, Maurice fixed up single precision and fortran at some point. Anyhow, Joao, please give lots more particulars about the configuration that lead to the problem. I don't see it here at all using --with-double. But you may have some different configuration that did not work as expected or there may be something wrong with the m4 pre-processing that occurs on your machine. Alan |
From: <jca...@in...> - 2002-01-21 01:23:11
|
On Sunday 20 January 2002 16:59, Alan W. Irwin wrote: | On Sat, 19 Jan 2002, Alan W. Irwin wrote: | > On Sun, 20 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: | > > 2-Fortran examples x06f.f and x07f.f don't compile, eg: | > | > Fortran has worked forever for me, but I just tried again, and no | > problem. Thus, I cannot confirm your bug report. Did you | > configure with --with-double? That is required for fortran. | | I woke up this morning realizing that last sentence was wrong.=20 | IIRC, Maurice fixed up single precision and fortran at some point.=20 | Anyhow, Joao, please give lots more particulars about the | configuration that lead to the problem. I don't see it here at all | using --with-double. But you may have some different configuration | that did not work as expected or there may be something wrong with | the m4 pre-processing that occurs on your machine. Nothing at all, almost a plain "configure" (cd ../cf; autoconf; mv configure ..); ../configure --disable-java=20 --without-shlib command: ../configure --disable-java --without-shlib system: Linux-2.2.18 prefix: /usr/local CC: gcc -c -O =20 LDC: gcc =20 CXX: g++ -c -O=20 LDCXX: g++ =20 F77: g77 -c -O=20 LDF: g77 =20 INCS: -I. LIBS: -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3 -L/usr/X11R6/lib=20 -lX11 -lgd -lpng -ljpeg -lz -ldl -lm -lg2c LIB_TAG: =20 devices: plmeta null xterm tek4010 tek4010f tek4107 tek4107f=20 mskermit conex vlt versaterm dg300 png jpeg ps psc xfig ljii hp7470=20 hp7580 lj_hpgl ljiip imp xwin tk pbm pstex Available device drivers static: plmeta null tek dg300 gd ps xfig ljii hpgl ljiip=20 impress xwin tk pbm pstex dynamic: =20 with_shlib: no with_double: no with_debug: no with_opt: yes with_warn: no with_profile: no with_gcc: yes with_rpath: yes enable_xwin: yes enable_tcl: yes enable_tk: yes enable_itcl: yes enable_cxx: yes enable_python: no enable_f77: yes enable_java: no enable_octave: no enable_gnome: no jcard@rick:~/tmp/plplot/tmp > g77 --version GNU Fortran 0.5.25 19991024 (release) jcard@rick:~/tmp/plplot/tmp > m4 --version GNU m4 1.4o configuring the same as above, but adding "--with-double " does not solve the problem. Again, it is: m4 -S2000 -B8192 x06f.fm4 >x06f.f g77 -c -O x06f.f Line too long as of (?) [info -f g77 M LEX] x06f.f: In program `MAIN__': x06f.f:29: warning: call plmtex('b', real (1.5), real (0.1*i+0.05), 1 x06f.f:52: (continued): call plmtex('t', real (1.5), real (0.5), real (0.5), 2 Too few arguments for `plmtex' at (2) versus invocation at (1) [info=20 -f g77 M GLOBALS] x06f.f:52:=20 call plmtex('t', real (1.5), real (0.5), real (0.5), 1 2 Invalid token at (2) in expression or subexpression at (1) make: *** [x06f.o] Error 1 This is in suse-7.0; in suse-7.2 the same error occurs. Sorry I can't=20 help more, Joao |
From: Alan W. I. <ir...@be...> - 2002-01-21 07:28:33
|
On Mon, 21 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > On Sunday 20 January 2002 16:59, Alan W. Irwin wrote: > | [...]But you may have some different configuration > | that did not work as expected or there may be something wrong with > | the m4 pre-processing that occurs on your machine. > > Nothing at all, almost a plain "configure" > > (cd ../cf; autoconf; mv configure ..); ../configure --disable-java > --without-shlib > > command: ../configure --disable-java --without-shlib > system: Linux-2.2.18 > prefix: /usr/local > CC: gcc -c -O > LDC: gcc > CXX: g++ -c -O > LDCXX: g++ > F77: g77 -c -O > LDF: g77 > INCS: -I. > LIBS: -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3 -L/usr/X11R6/lib > -lX11 -lgd -lpng -ljpeg -lz -ldl -lm -lg2c > LIB_TAG: > devices: plmeta null xterm tek4010 tek4010f tek4107 tek4107f > mskermit conex vlt versaterm dg300 png jpeg ps psc xfig ljii hp7470 > hp7580 lj_hpgl ljiip imp xwin tk pbm pstex > > Available device drivers > static: plmeta null tek dg300 gd ps xfig ljii hpgl ljiip > impress xwin tk pbm pstex > dynamic: > > with_shlib: no with_double: no > with_debug: no with_opt: yes > with_warn: no with_profile: no > with_gcc: yes with_rpath: yes > > enable_xwin: yes enable_tcl: yes > enable_tk: yes enable_itcl: yes > enable_cxx: yes enable_python: no > enable_f77: yes enable_java: no > enable_octave: no enable_gnome: no > > jcard@rick:~/tmp/plplot/tmp > g77 --version > GNU Fortran 0.5.25 19991024 (release) > > jcard@rick:~/tmp/plplot/tmp > m4 --version > GNU m4 1.4o > Again, I cannot reproduce the problem you have reported. I configured exactly as you above on a clean checkout. All the major flags at the end o= f config message were identical to yours. The driver lists looked the same (although that should not matter). My system found f77 rather than g77, but on Debian woody that is a symlink to g77. I get the following: f77 --version GNU Fortran 0.5.25 20010319 (prerelease) [+ lots of stuff about the lack of warranty, etc.] m4 --version GNU m4 1.4 make fdemos works like a charm, and I even tried x06f and x07f and they produced the same boring (;-) results as always. I can think of two possibilities. (1) Somehow your plplot system is confused by a mix of old and new results. Please try again with a clean checkout (if you didn't have that already). (2) I am also somewhat concerned about the two-yr old date on your g77 compiler compared to mine. Maybe there is too long a line (as mentioned in one of your error messages) for your old compiler. In that case, find the longest line in your x06f.f source, find the equivalent line in x06f.fm4 an= d split it into two lines (by using almost any character in the 6th column fo= r the continued line as you can see from other *.fm4 files that have continuations) and try again. If a line split solves the problem, go ahead and commit the modified x06f.fm4 results. And similarly for x07f.fm4 assuming that problem is due to the same cause. I don't want this to drag on so while Joao is doing further tests with clean checkouts/and or line splitting will others please take a few minutes to try to reproduce the bug? We may need more eyeballs on this one to solve it, and I am hamstrung because I cannot reproduce it. Thanks in advance. Alan |
From: Joao C. <jc...@fe...> - 2002-01-21 17:10:15
|
On Monday 21 January 2002 7:28 am, Alan W. Irwin wrote: > On Mon, 21 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > > On Sunday 20 January 2002 16:59, Alan W. Irwin wrote: > > | [...]But you may have some different configuration > > | that did not work as expected or there may be something wrong with > > | the m4 pre-processing that occurs on your machine. In the x06f.f file, after m4 processing, appears indeed a very long line = as=20 the first fortran source line: ! Displays the plotter=20 AND,CMP,COMPLEX,DREAL,FALSE,IMAG,IMPLICIT_REAL,INCLUDED_FMACS,NO,OFF,ON,O= R,REAL,REAL_FUN,SYSTEM,TRUE,YES,__file__,__gnu__,__line__,__m4_version__,= __unix__,builtin,cdefine,cexpand,changecom,changequote,changesyntax,conca= t,debugfile,debugmode,decr,define,defn,divert,divnum,dnl,dumpdef,errprint= ,esyscmd,eval,format,getstring,if_aix,if_bsd,if_dbl,if_dgux,if_false,if_h= pux,if_linux,if_sunos,if_sx,if_sysv,if_true,if_ultrix,ifdef,ifelse,ifndef= ,ignore,implicit_none,include,incr,index,indir,len,m4exit,m4wrap,macro_do= ,maketemp,patsubst,popdef,pushdef,regexp,shift,sinclude,substr,symbols,sy= ncoutput,syscmd,sysval,traceoff,traceon,translit,undef,undefine,undivert=20 for PLPOIN <--- from the comment until here is a one comment line! implicit none <--- this is another line integer i, j, k real*4 x, y character*3 text ! Full sized page for display So it seems that this is a m4 problem. But suse-7.2 is not that old, and = my=20 suse system is updated with the last changes... (rpm says that m4 was "Bu= ild=20 Date: Fri 11 May 2001") The problem seem to be the word "symbols" in the comments and in the last= =20 plmtex() arguments of file x06f.fm4; if I remove the word "symbols" from = the=20 comments, the lines will be no more expanded by m4 as above. What is the = real=20 cure for this? Joao > > jcard@rick:~/tmp/plplot/tmp > g77 --version > > GNU Fortran 0.5.25 19991024 (release) > > > > jcard@rick:~/tmp/plplot/tmp > m4 --version > > GNU m4 1.4o > > Again, I cannot reproduce the problem you have reported. I configured > exactly as you above on a clean checkout. All the major flags at the e= nd > of config message were identical to yours. The driver lists looked the > same (although that should not matter). My system found f77 rather than > g77, but on Debian woody that is a symlink to g77. > > I get the following: > > f77 --version > GNU Fortran 0.5.25 20010319 (prerelease) > [+ lots of stuff about the lack of warranty, etc.] > > m4 --version > GNU m4 1.4 > > make fdemos works like a charm, and I even tried x06f and x07f and they > produced the same boring (;-) results as always. > > I can think of two possibilities. > > (1) Somehow your plplot system is confused by > a mix of old and new results. Please try again with a clean checkout (= if > you didn't have that already). > > (2) I am also somewhat concerned about the two-yr old date on your g77 > compiler compared to mine. Maybe there is too long a line (as mentione= d in > one of your error messages) for your old compiler. In that case, find = the > longest line in your x06f.f source, find the equivalent line in x06f.fm= 4 > and split it into two lines (by using almost any character in the 6th > column for the continued line as you can see from other *.fm4 files tha= t > have continuations) and try again. If a line split solves the problem,= go > ahead and commit the modified x06f.fm4 results. And similarly for x07f= =2Efm4 > assuming that problem is due to the same cause. > > I don't want this to drag on so while Joao is doing further tests with > clean checkouts/and or line splitting will others please take a few > minutes to try to reproduce the bug? We may need more eyeballs on this > one to solve it, and I am hamstrung because I cannot reproduce it. > > Thanks in advance. > > Alan > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Joao C. <jc...@fe...> - 2002-01-21 17:37:30
|
On Monday 21 January 2002 5:09 pm, Joao Cardoso wrote: > On Monday 21 January 2002 7:28 am, Alan W. Irwin wrote: > > On Mon, 21 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > > > On Sunday 20 January 2002 16:59, Alan W. Irwin wrote: > > > | [...]But you may have some different configuration > > > | that did not work as expected or there may be something wrong wit= h > > > | the m4 pre-processing that occurs on your machine. > > In the x06f.f file, after m4 processing, appears indeed a very long lin= e as > the first fortran source line: > > ! Displays the plotter > AND,CMP,COMPLEX,DREAL,FALSE,IMAG,IMPLICIT_REAL,INCLUDED_FMACS,NO,OFF,ON= ,OR, >REAL,REAL_FUN,SYSTEM,TRUE,YES,__file__,__gnu__,__line__,__m4_version__,_= _uni >x__,builtin,cdefine,cexpand,changecom,changequote,changesyntax,concat,de= bugf >ile,debugmode,decr,define,defn,divert,divnum,dnl,dumpdef,errprint,esyscm= d,ev >al,format,getstring,if_aix,if_bsd,if_dbl,if_dgux,if_false,if_hpux,if_lin= ux,i >f_sunos,if_sx,if_sysv,if_true,if_ultrix,ifdef,ifelse,ifndef,ignore,impli= cit_ >none,include,incr,index,indir,len,m4exit,m4wrap,macro_do,maketemp,patsub= st,p >opdef,pushdef,regexp,shift,sinclude,substr,symbols,syncoutput,syscmd,sys= val, >traceoff,traceon,translit,undef,undefine,undivert for PLPOIN <--- from t= he > comment until here is a one comment line! implicit none <--- this is > another line > integer i, j, k > real*4 x, y > > character*3 text > > ! Full sized page for display > > So it seems that this is a m4 problem. But suse-7.2 is not that old, an= d my > suse system is updated with the last changes... (rpm says that m4 was > "Build Date: Fri 11 May 2001") > > The problem seem to be the word "symbols" in the comments and in the la= st > plmtex() arguments of file x06f.fm4; if I remove the word "symbols" fro= m > the comments, the lines will be no more expanded by m4 as above. What i= s > the real cure for this? > > Joao 'info m4' says that: Getting the defined macro names =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D The name of the currently defined macro can be accessed by `symbols= ': symbols which results in a sorted list of quoted strings. This contrasts w= ith `dumpdef' which output can not be accessed by `m4' programs. When given arguments, `symbols' returns the sorted subset of the symbols currently defined: symbols(`ifndef', `ifdef', `define', `undef') =3D>define,ifdef I can't however avoid "symbols" to be expanded by m4, by quoting it, as i= n=20 `symbols'. The quick cure for the release is to just remove the word--aft= er=20 all it is just a comment. Comments? Joao > > > > jcard@rick:~/tmp/plplot/tmp > g77 --version > > > GNU Fortran 0.5.25 19991024 (release) > > > > > > jcard@rick:~/tmp/plplot/tmp > m4 --version > > > GNU m4 1.4o > > > > Again, I cannot reproduce the problem you have reported. I configured > > exactly as you above on a clean checkout. All the major flags at the= end > > of config message were identical to yours. The driver lists looked t= he > > same (although that should not matter). My system found f77 rather th= an > > g77, but on Debian woody that is a symlink to g77. > > > > I get the following: > > > > f77 --version > > GNU Fortran 0.5.25 20010319 (prerelease) > > [+ lots of stuff about the lack of warranty, etc.] > > > > m4 --version > > GNU m4 1.4 > > > > make fdemos works like a charm, and I even tried x06f and x07f and th= ey > > produced the same boring (;-) results as always. > > > > I can think of two possibilities. > > > > (1) Somehow your plplot system is confused by > > a mix of old and new results. Please try again with a clean checkout= (if > > you didn't have that already). > > > > (2) I am also somewhat concerned about the two-yr old date on your g7= 7 > > compiler compared to mine. Maybe there is too long a line (as mentio= ned > > in one of your error messages) for your old compiler. In that case, = find > > the longest line in your x06f.f source, find the equivalent line in > > x06f.fm4 and split it into two lines (by using almost any character i= n > > the 6th column for the continued line as you can see from other *.fm4 > > files that have continuations) and try again. If a line split solves= the > > problem, go ahead and commit the modified x06f.fm4 results. And > > similarly for x07f.fm4 assuming that problem is due to the same cause= =2E > > > > I don't want this to drag on so while Joao is doing further tests wit= h > > clean checkouts/and or line splitting will others please take a few > > minutes to try to reproduce the bug? We may need more eyeballs on th= is > > one to solve it, and I am hamstrung because I cannot reproduce it. > > > > Thanks in advance. > > > > Alan > > > > > > _______________________________________________ > > Plplot-devel mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-devel > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |