From: Alan W. I. <ir...@be...> - 2002-01-26 20:20:04
|
Hello everybody. Since our efforts to release 5.1.0 seem to have stalled, I'm reinitiating the test/release plan. Please get all your final checkins that you want included in this release finished by the hard deadline of 8 AM PST (= 16:00 UT) Monday at which time the final release testing will commence. Here is the new plan (thanks to Geoffrey for suggesting this). On Monday 8 A.M PST I will tag CVS HEAD with v5_1_0_rc1. This will allow me to go about my testing business while you guys use CVS any way you like. It also allows any of you to obtain exactly the version I am testing (in case of an emergency where I absolutely need your help) regardless of subsequent CVS activity. Thus, with this new plan there is no CVS freeze at all, just a deadline if you want your stuff included in 5.1.0. Assuming all my tests go well ("well" here means that the results should be as good as my tests for 5.0.4 so I won't be treating any of our known bugs for 5.0.4 as release critical), I will simply ignore anything you put into CVS after 8 AM Monday and retag my non-updated local copy as v5_1_0_final after the completion of the tests and just before the 5.1.1 release. 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: Geoffrey F. <fu...@ga...> - 2002-01-27 05:48:10
|
Alan W. Irwin writes: > Hello everybody. Since our efforts to release 5.1.0 seem to have stalled, > I'm reinitiating the test/release plan. Thanks Alan for restarting the count down. I'm afraid I am writing to report some possibly discouraging news. The Tk driver is not working for me right now. I'm getting: Packet send failed: pl_PacketSend -- error writing to fifo: bad file number TCL command "plclient_link_end" failed: no application named "cplace_x86kaig" Program aborted when I run my code. The tk driver starts, the plframe is displayed, then it all vanishes in a puff of smoke, and 50% of the time or so, it prints the above message, the other times it all simply vanishes without a trace. Now, you might suspect its just my code. And that could well be. However, it runs to completion with no upset using many other devices, including xwin, ps, and plmeta. With a metafile, I can render to device tk. Also the plplot C examples work with dev tk. So I realize this is a pretty inconclusive set of data. Trying to pin the blame on my own code, I've gotten as far as running it under electric fence, but again, nothing turns up. I don't know if anybody else has experience with electric fence, but I've been using it a little here ever since I upgraded one of my machines to Red Hat 7.1, and it seems to be pretty good to me, has caught bugs in other porgrams. I don't know if I'll be able to run a purified version or not, as I don't currently have access to a purify license (but am working on it). Since the data I am providing is so inconclusive, I don't want it to hold up the release by itself. If no one but me is having troubles with the tk driver, we should press on with the release. But it would be nice if other people with substantial PLplot client codes could just give the current cvs head a whirl, and make sure the tk driver and plframe widget work for you today as well as they did a month ago. If others notice trouble, speak up on plplot-devel. If no one but me finds problems, I think Alan should proceed as planned, presuming the problem is of my own creation. But if anybody else has evidence the tk driver isn't working right, then in that case I think maybe we should find a way to dig deeper. Cheers to all, -- Geoffrey Furnish fu...@ga... |
From: Alan W. I. <ir...@be...> - 2002-01-27 15:31:18
|
On Sat, 26 Jan 2002, Geoffrey Furnish wrote: > [...]Now, you might suspect its just my code. And that could well be. > However, it runs to completion with no upset using many other devices, > including xwin, ps, and plmeta. With a metafile, I can render to > device tk. Also the plplot C examples work with dev tk. So I realize > this is a pretty inconclusive set of data. The C examples with tk driver may not be adequately exercising the code. Therefore, I think you should exercise every Tk example to see if there are any obvious problems on your system. Here is my script for doing this from plplot/tmp: #!/bin/sh #test suite of all interactive tk stuff that cannot be done by file. #tk driver (x14c), tcldemos, tkdemos. export cdir=. export tcldir=. export tkdir=. export plplotbindir=. $cdir/x14c $cdir/x17c -dev tk $tkdir/xtk01 -f tk01 $tkdir/xtk02 -f tk02 $plplotbindir/plserver -f tk03 $tkdir/xtk04 -f tk04 cd $tcldir $plplotbindir/plserver <<EOF plstdwin . plxframe .plw pack append . .plw {left expand fill} source plgrid.tcl proc 1 {} "plgrid .plw.plwin" 1 exit EOF cd $tkdir $plplotbindir/plserver <<EOF source tkdemos.tcl 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 exit EOF If all these examples work well, then I would pick the nearest to your own use of PLplot and see what is different about yours that is generating an error. I suspect it may be one of the obscure API changes that is messing you about. Recall that part of Maurice's recent work was removing those nameclashes that occurred in plframe.c between special plframe commands and Tcl-wrapped PLplot library code commands. Perhaps your code is calling some of those special plframe commands that were renamed? Finally, does your code work with PLplot 5.0.4? PLplot of September? PLplot of last week? There really haven't been that many tk/plframe changes since 5.0.4 so it should be a relatively quick task to find out which one is causing your problem. Since all the examples work (AFAIK), and there have been too many delays already, I am very much inclined to continue with the tag deadline tomorrow. Ideally, if you actually find something specifically wrong with PLplot today, you will also be able to fix it today. Good luck, and let us know how it goes. Alan |
From: Geoffrey F. <fu...@ga...> - 2002-01-28 01:52:05
|
Alan W. Irwin writes: > On Sat, 26 Jan 2002, Geoffrey Furnish wrote: > > [...]Now, you might suspect its just my code. And that could well be. > > However, it runs to completion with no upset using many other devices, > > including xwin, ps, and plmeta. With a metafile, I can render to > > device tk. Also the plplot C examples work with dev tk. So I realize > > this is a pretty inconclusive set of data. > > The C examples with tk driver may not be adequately exercising the code. > Therefore, I think you should exercise every Tk example to see if there are > any obvious problems on your system. Here is my script for doing this from > plplot/tmp: Thanks. The script was helpful, things seem to be working in the core distribution. But I agree with your suspicion that my particular client code is probably doing things wityh the API that the examples don't. However, I haven't been able to pin it down yet to a single specific problem, and realistically, do not expect to have such closure in the next 14 hours. So, unless someone else announces similar problems, I think you should just go ahead. I did manage to build my code with a completely different compiler, just to try to eliminate the "bad code gen" prospect. The same failure occurs even when the client code is built with the latst gcc, 3.0.3. So, the plot thickens. Realistically, I think its going to take a timescale of days for me to get to the bottom of this, so you should just proceed. The problem may well turn out to have nothing to do with PLplot. More when I know more. -- Geoffrey Furnish fu...@ga... |
From: Maurice L. <mj...@ga...> - 2002-01-28 00:58:39
|
Geoffrey Furnish writes: > Alan W. Irwin writes: > > Hello everybody. Since our efforts to release 5.1.0 seem to have stalled, > > I'm reinitiating the test/release plan. > > Thanks Alan for restarting the count down. Sorry my efforts have slowed, but I may yet get some more stuff sorted out in time for inclusion for tomorrow's release. > I'm afraid I am writing to report some possibly discouraging news. > The Tk driver is not working for me right now. I'm getting: > > Packet send failed: > pl_PacketSend -- error writing to fifo: bad file number > TCL command "plclient_link_end" failed: > no application named "cplace_x86kaig" > Program aborted > > when I run my code. The tk driver starts, the plframe is displayed, > then it all vanishes in a puff of smoke, and 50% of the time or so, it > prints the above message, the other times it all simply vanishes > without a trace. No idea.. I've never seen this. BTW it may be informative to run including the -debug option. Then again it may not help. -- Maurice LeBrun mj...@ga... |
From: Geoffrey F. <fu...@ga...> - 2002-01-28 16:52:36
|
Maurice LeBrun writes: > > I'm afraid I am writing to report some possibly discouraging news. > > The Tk driver is not working for me right now. I'm getting: > > > > Packet send failed: > > pl_PacketSend -- error writing to fifo: bad file number > > TCL command "plclient_link_end" failed: > > no application named "cplace_x86kaig" > > Program aborted > > > > when I run my code. The tk driver starts, the plframe is displayed, > > then it all vanishes in a puff of smoke, and 50% of the time or so, it > > prints the above message, the other times it all simply vanishes > > without a trace. > > No idea.. I've never seen this. BTW it may be informative to run including > the -debug option. Then again it may not help. I've demonstrated that the behavior is the same with snapshots from 1/1/02 and from 9/1/01. Therefore, I think it is clear that it is at least not a recently introduced bug in PLplot. Whether or not it is a bug in PLplot at all, is yet to be determined, it may still be in my code. However, I haven't been able to find the cause yet. Somehow it seems that when running the tk driver, somehow my code cores and the message is coming from plserver, saying the host app is dead. When I run the host code in the debugger, it sometimes claims to have ended with a SIGPIPE. Doesn't make any sense to me. yet. Using any other device seems to work fine. -- Geoffrey Furnish fu...@ga... |
From: Geoffrey F. <fu...@ga...> - 2002-01-28 17:45:17
|
Geoffrey Furnish writes: > > No idea.. I've never seen this. BTW it may be informative to run including > > the -debug option. Then again it may not help. > > I've demonstrated that the behavior is the same with snapshots from > 1/1/02 and from 9/1/01. Therefore, I think it is clear that it is at > least not a recently introduced bug in PLplot. Whether or not it is a > bug in PLplot at all, is yet to be determined, it may still be in my > code. However, I haven't been able to find the cause yet. Somehow it > seems that when running the tk driver, somehow my code cores and the > message is coming from plserver, saying the host app is dead. When I > run the host code in the debugger, it sometimes claims to have ended > with a SIGPIPE. Doesn't make any sense to me. yet. Using any other > device seems to work fine. No, that's wrong. It's plserver that's dieing, leaving the host app up, but unable to communicate with it. That explains why the host app gets a sigpipe. So now that makes sense. But I don't understand what's killing plserver. Is there an easy way to run an app against a seperately started plserver? I seem to remember traffic on this list about this, but I wasn't paying enough attention then to remember how to do it now. -- Geoffrey Furnish fu...@ga... |
From: Maurice L. <mj...@ga...> - 2002-01-29 07:10:55
|
Geoffrey Furnish writes: > Is there an easy way to run an app against a seperately started > plserver? I seem to remember traffic on this list about this, but I > wasn't paying enough attention then to remember how to do it now. Yeah, Joao tried it and couldn't get it to work, and I wasn't much help at the time. It certainly did work at one time, else I wouldn't have documented it in the code (scenario #3 in tk.c:init_server()). My first few tries were unsuccessful, but then.. I got it to work, yeah! (my wife's asleep & I can't get the dogs to cheer, oh well. :) OK, so here's the scoop. In one window: $ plserver -name plserver -client_name x01c and then in another: $ x01c -dev tk -server_name plserver ... ta-da! I remember doing considerable debugging in this mode b/c I had access to the Tcl shell in window #1, so I could find out lots of nice info that way. If you start up another plserver & x01c, the main window names become "plserver #2" and "x01c #2", etc. -- Maurice LeBrun mj...@ga... |
From: Maurice L. <mj...@ga...> - 2002-01-29 07:44:06
|
Maurice LeBrun writes: > If you start up another plserver & x01c, the main window names become > "plserver #2" and "x01c #2", etc. Hmm.. there is a problem with the latter right now, although there's a workaround. If I do: $ plserver -name plserver -client_name x01c $ x01c -dev tk -server_name plserver in one pair of windows, and then repeat in a second pair using the #2 main window name change, I get: $ plserver -name "plserver #2" -client_name "x01c #2" $ x01c -dev tk -server_name "plserver #2" Plplot library version: 5.1.0 TCL command "plclient_link_init" failed: no application named "{plserver #2}" TCL command "plclient_link_end" failed: can't read "plwindow": no such variable Program aborted So some problem with list-ification in the tk driver. The workaround is: $ plserver -name plserver2 -client_name "x01c #2" $ x01c -dev tk -server_name plserver2 which is nicer anyway. -- Maurice LeBrun mj...@ga... |