Menu
▾
▴
plplot-devel — Technical discussion about PLplot development
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(58) |
Nov
(95) |
Dec
(55) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(205) |
Feb
(106) |
Mar
(36) |
Apr
(25) |
May
(34) |
Jun
(36) |
Jul
(161) |
Aug
(66) |
Sep
(100) |
Oct
(62) |
Nov
(77) |
Dec
(172) |
| 2003 |
Jan
(101) |
Feb
(202) |
Mar
(191) |
Apr
(97) |
May
(27) |
Jun
(21) |
Jul
(16) |
Aug
(55) |
Sep
(155) |
Oct
(166) |
Nov
(19) |
Dec
(134) |
| 2004 |
Jan
(569) |
Feb
(367) |
Mar
(81) |
Apr
(62) |
May
(124) |
Jun
(77) |
Jul
(85) |
Aug
(80) |
Sep
(66) |
Oct
(42) |
Nov
(20) |
Dec
(133) |
| 2005 |
Jan
(192) |
Feb
(143) |
Mar
(183) |
Apr
(128) |
May
(136) |
Jun
(18) |
Jul
(22) |
Aug
(33) |
Sep
(20) |
Oct
(12) |
Nov
(80) |
Dec
(44) |
| 2006 |
Jan
(42) |
Feb
(38) |
Mar
(17) |
Apr
(112) |
May
(220) |
Jun
(67) |
Jul
(96) |
Aug
(214) |
Sep
(104) |
Oct
(67) |
Nov
(150) |
Dec
(103) |
| 2007 |
Jan
(111) |
Feb
(50) |
Mar
(113) |
Apr
(19) |
May
(32) |
Jun
(34) |
Jul
(61) |
Aug
(103) |
Sep
(75) |
Oct
(99) |
Nov
(102) |
Dec
(40) |
| 2008 |
Jan
(86) |
Feb
(56) |
Mar
(104) |
Apr
(50) |
May
(45) |
Jun
(64) |
Jul
(71) |
Aug
(147) |
Sep
(132) |
Oct
(176) |
Nov
(46) |
Dec
(136) |
| 2009 |
Jan
(159) |
Feb
(136) |
Mar
(188) |
Apr
(189) |
May
(166) |
Jun
(97) |
Jul
(160) |
Aug
(235) |
Sep
(163) |
Oct
(46) |
Nov
(99) |
Dec
(54) |
| 2010 |
Jan
(104) |
Feb
(121) |
Mar
(153) |
Apr
(75) |
May
(138) |
Jun
(63) |
Jul
(61) |
Aug
(27) |
Sep
(93) |
Oct
(63) |
Nov
(40) |
Dec
(102) |
| 2011 |
Jan
(52) |
Feb
(26) |
Mar
(61) |
Apr
(27) |
May
(33) |
Jun
(43) |
Jul
(37) |
Aug
(53) |
Sep
(58) |
Oct
(63) |
Nov
(67) |
Dec
(16) |
| 2012 |
Jan
(97) |
Feb
(34) |
Mar
(6) |
Apr
(18) |
May
(32) |
Jun
(9) |
Jul
(17) |
Aug
(78) |
Sep
(24) |
Oct
(101) |
Nov
(31) |
Dec
(7) |
| 2013 |
Jan
(44) |
Feb
(35) |
Mar
(59) |
Apr
(17) |
May
(29) |
Jun
(38) |
Jul
(48) |
Aug
(46) |
Sep
(74) |
Oct
(140) |
Nov
(94) |
Dec
(177) |
| 2014 |
Jan
(94) |
Feb
(74) |
Mar
(75) |
Apr
(63) |
May
(24) |
Jun
(1) |
Jul
(30) |
Aug
(112) |
Sep
(78) |
Oct
(137) |
Nov
(60) |
Dec
(17) |
| 2015 |
Jan
(128) |
Feb
(254) |
Mar
(273) |
Apr
(137) |
May
(181) |
Jun
(157) |
Jul
(83) |
Aug
(34) |
Sep
(26) |
Oct
(9) |
Nov
(24) |
Dec
(43) |
| 2016 |
Jan
(94) |
Feb
(77) |
Mar
(83) |
Apr
(19) |
May
(39) |
Jun
(1) |
Jul
(5) |
Aug
(10) |
Sep
(28) |
Oct
(34) |
Nov
(82) |
Dec
(301) |
| 2017 |
Jan
(53) |
Feb
(50) |
Mar
(11) |
Apr
(15) |
May
(23) |
Jun
(36) |
Jul
(84) |
Aug
(90) |
Sep
(35) |
Oct
(81) |
Nov
(13) |
Dec
(11) |
| 2018 |
Jan
(15) |
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(6) |
Jul
(4) |
Aug
(13) |
Sep
(31) |
Oct
(4) |
Nov
(25) |
Dec
(64) |
| 2019 |
Jan
(7) |
Feb
(4) |
Mar
|
Apr
|
May
(13) |
Jun
(8) |
Jul
(16) |
Aug
(7) |
Sep
(27) |
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(3) |
| 2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
(9) |
Aug
(3) |
Sep
|
Oct
(8) |
Nov
(4) |
Dec
|
| 2022 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(8) |
| 2023 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(10) |
Jun
(7) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
|
From: Christian S. <c.s...@au...> - 2002-01-24 21:09:45
|
Rafael Laboissiere wrote: > > What drivers does PLPLOT have? > > Look at http://plplot.sf.net. Hm, it is not obvious where to find a list of supported devices on that site. Hints??? Christian |
|
From: Alan W. I. <ir...@be...> - 2002-01-24 20:45:51
|
That is an interesting list Joao. I have divided them into two groups: (1) Does not appear in plplot.h. I assume these are all internal to plplot_octave. plplot_octave_txt/plclabel_format.txt not found, using plplot.doc plplot_octave_txt/plclabel_param.txt not found, using plplot.doc plplot_octave_txt/plcont0.txt not found, using plplot.doc plplot_octave_txt/plcont1.txt not found, using plplot.doc plplot_octave_txt/plcont2.txt not found, using plplot.doc plplot_octave_txt/plcont2p.txt not found, using plplot.doc plplot_octave_txt/pplimage.txt not found, using plplot.doc plplot_octave_txt/plshade2.txt not found, using plplot.doc (2) Does appear in plplot.h, but not with a "c_" prefix. So these are all public API, but not common API. Of course it is a judgement call which subset of the public API is the common API, i.e, that part of the public API that is considered to be useful enough so that all front ends should have wrappers for the common API. In future we may take certain functions out of the common API or put certain functions into the common API. For example, plarrows below is a possible candidate for being put into the common API. BTW, the chapter where we document C specific public API that is not part of the common API is called api-c.xml. It is totally incomplete because I have been concentrating on the common API chapter, api.xml. Another complication is just because a front end should have wrappers for all the common API doesn't mean it does at the moment. For example, Geoffrey is still working on the Java wrappers, and there are still a few common API functions I need to add to both the tcl and python wrappers. If anybody cares to extend the fortran and C++ examples to be the same as the C, python, tcl, and Java examples, I am sure they will find plenty of common API that needs wrappers for fortran and C++. Octave is an exception to this rule of missing common API. Apparently you have implemented not only wrappers for the common API, but also parts of the public API that are not common. Here is the public API list that you wrap, but which is not part of the common API. plplot_octave_txt/plGetCursor.txt not found, using plplot.doc plplot_octave_txt/plTranslateCursor.txt not found, using plplot.doc plplot_octave_txt/plClearOpts.txt not found, using plplot.doc plplot_octave_txt/plGetFlt.txt not found, using plplot.doc plplot_octave_txt/plGetInt.txt not found, using plplot.doc plplot_octave_txt/plHLS_RGB.txt not found, using plplot.doc plplot_octave_txt/plOptUsage.txt not found, using plplot.doc plplot_octave_txt/plParseOpts.txt not found, using plplot.doc plplot_octave_txt/plRGB_HLS.txt not found, using plplot.doc plplot_octave_txt/plResetOpts.txt not found, using plplot.doc plplot_octave_txt/plSetOpt.txt not found, using plplot.doc plplot_octave_txt/plSetUsage.txt not found, using plplot.doc plplot_octave_txt/plarrows.txt not found, using plplot.doc plplot_octave_txt/pldid2pc.txt not found, using plplot.doc plplot_octave_txt/pldip2dc.txt not found, using plplot.doc plplot_octave_txt/plsError.txt not found, using plplot.doc plplot_octave_txt/plsxwin.txt not found, using plplot.doc Alan |
|
From: Geoffrey F. <fu...@ga...> - 2002-01-24 20:33:25
|
Well, I have never personally used that driver, but I think I still know roughly what the issue is. The issue is that taking over the console and switching VT's requires privilege. The X server enjoys this privilege, which is why it can switch to VT 7 when you type startx, for example. The library that the vga driver calls, must effectively do the same thing, so the invoking executable has to be endowed with root privilege. Joao Cardoso writes: > On Thursday 24 January 2002 7:44 pm, Joao Cardoso wrote: > > I have commited changes to enable the linuxvga driver to be a dyndriver, as > > it was only partially configured (it appears only in > > PL_DYNAMIC_DRIVER_LIST). > > > > But I can't use the driver as anormal user, I get: > ^ > Neither as a normal nor as an anormal user :-S |
|
From: Joao C. <jc...@fe...> - 2002-01-24 20:14:09
|
On Thursday 24 January 2002 7:44 pm, Joao Cardoso wrote:
> Hi,
>
> I have commited changes to enable the linuxvga driver to be a dyndriver=
, as
> it was only partially configured (it appears only in
> PL_DYNAMIC_DRIVER_LIST).
>
> But I can't use the driver as anormal user, I get:
^
Neither as a normal nor as an anormal user :-S
Joao
>
> =09svgalib: Cannot get I/O permissions.
>
> As root I can however use it.
> I make no ideia of what is going on. Any clues?
>
> Joao
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
|
|
From: Joao C. <jc...@fe...> - 2002-01-24 19:48:15
|
Hi, I have commited changes to enable the linuxvga driver to be a dyndriver, = as=20 it was only partially configured (it appears only in PL_DYNAMIC_DRIVER_LI= ST). But I can't use the driver as anormal user, I get: =09svgalib: Cannot get I/O permissions. As root I can however use it. I make no ideia of what is going on. Any clues? Joao |
|
From: Joao C. <jc...@fe...> - 2002-01-24 18:16:52
|
On Thursday 24 January 2002 3:00 am, Alan W. Irwin wrote: > While waiting for the plframe bugs to get sorted out, I decided to do > something constructive today. Have a look at > http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0= =2E4.3 >/api.html to see the results. All further changes in this chapter will = be > tweaks, and nothing major unless there are new common API functions suc= h as > plimage. BTW, I decided not to do plimage documentation today because m= y > understanding is that API is still not finalized. > > Alan > Hi, Good work. Also the README files are now up to date. When Octave support is compiled, a "missing_help" file is generated in th= e=20 tmp subdir, and contains the names of functions for which man pages could= n't=20 be found (as generated by api2man.pl). Although some of these functions a= re=20 Octave specific, others are not; also, plplot_octave does not implement a= ll=20 API entry points. Currently, "more missing_help" gives: plplot_octave_txt/plclabel_format.txt not found, using plplot.doc plplot_octave_txt/plclabel_param.txt not found, using plplot.doc plplot_octave_txt/plGetCursor.txt not found, using plplot.doc plplot_octave_txt/plTranslateCursor.txt not found, using plplot.doc plplot_octave_txt/plcont0.txt not found, using plplot.doc plplot_octave_txt/plcont1.txt not found, using plplot.doc plplot_octave_txt/plcont2.txt not found, using plplot.doc plplot_octave_txt/plcont2p.txt not found, using plplot.doc plplot_octave_txt/pplimage.txt not found, using plplot.doc plplot_octave_txt/plshade2.txt not found, using plplot.doc plplot_octave_txt/plClearOpts.txt not found, using plplot.doc plplot_octave_txt/plGetFlt.txt not found, using plplot.doc plplot_octave_txt/plGetInt.txt not found, using plplot.doc plplot_octave_txt/plHLS_RGB.txt not found, using plplot.doc plplot_octave_txt/plOptUsage.txt not found, using plplot.doc plplot_octave_txt/plParseOpts.txt not found, using plplot.doc plplot_octave_txt/plRGB_HLS.txt not found, using plplot.doc plplot_octave_txt/plResetOpts.txt not found, using plplot.doc plplot_octave_txt/plSetOpt.txt not found, using plplot.doc plplot_octave_txt/plSetUsage.txt not found, using plplot.doc plplot_octave_txt/plarrows.txt not found, using plplot.doc plplot_octave_txt/pldid2pc.txt not found, using plplot.doc plplot_octave_txt/pldip2dc.txt not found, using plplot.doc plplot_octave_txt/plsError.txt not found, using plplot.doc plplot_octave_txt/plsxwin.txt not found, using plplot.doc Joao |
|
From: Maurice L. <mj...@ga...> - 2002-01-24 08:03:24
|
Alan W. Irwin writes: > While waiting for the plframe bugs to get sorted out, I decided to do > something constructive today. Have a look at > http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/api.html > to see the results. All further changes in this chapter will be tweaks, and > nothing major unless there are new common API functions such as plimage. > BTW, I decided not to do plimage documentation today because my > understanding is that API is still not finalized. Looks great. Glad to see the documentation (sorely neglected in the past) coming along so well. -- Maurice LeBrun mj...@ga... |
|
From: Maurice L. <mj...@ga...> - 2002-01-24 07:55:34
|
Alan W. Irwin writes: > (3) I also did a preliminary test of tkdemos.tcl, and found some bad > problems with the colour map handling. > > To generate the problem simply do the following: > > ./plserver > % source tkdemos.tcl > 8 > ... This part is fixed. I'm now working on the other plframe enhancement now. -- Maurice LeBrun mj...@ga... |
|
From: Alan W. I. <ir...@be...> - 2002-01-24 03:00:59
|
While waiting for the plframe bugs to get sorted out, I decided to do something constructive today. Have a look at http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/api.html to see the results. All further changes in this chapter will be tweaks, and nothing major unless there are new common API functions such as plimage. BTW, I decided not to do plimage documentation today because my understanding is that API is still not finalized. 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: Robert S. <ro...@sc...> - 2002-01-23 08:44:02
|
On Tue, 22 Jan 2002, Maurice LeBrun wrote: > Just can't seem to put this problem down and go to bed. It all checks > out under 2.13, give it a try.. Works now! Thanks! Robert -- +--------------------------------------------------------+ | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de | | Pengutronix - Linux Solutions for Science and Industry | | Braunschweiger Str. 79, 31134 Hildesheim, Germany | | Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 | +--------------------------------------------------------+ |
|
From: Robert S. <ro...@sc...> - 2002-01-23 08:44:00
|
On Tue, 22 Jan 2002, Maurice LeBrun wrote: > Not bona fide bugs, but compatibility bugs. If 2.13 is in the default > distro, then I won't worry too much about it. Of course, 2.52 > compatibility will be an issue eventually, and I'd like to fix these > problems, but it's starting to look iffy for a quick fix (i.e. before > the release). Ok - could you place a hint to the documentation in cf/ which version of the autotools have been tested? Robert -- +--------------------------------------------------------+ | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de | | Pengutronix - Linux Solutions for Science and Industry | | Braunschweiger Str. 79, 31134 Hildesheim, Germany | | Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 | +--------------------------------------------------------+ |
|
From: Alan W. I. <ir...@be...> - 2002-01-22 20:40:55
|
Geoffrey and I have jointly decided we are going to have to wait for Maurice to evaluate the plframe situation. So the start of testing will be on hold at least several more hours and perhaps even a day or two from now. We'll see. 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: Alan W. I. <ir...@be...> - 2002-01-22 20:33:21
|
On Tue, 22 Jan 2002, Geoffrey Furnish wrote: > Alan, can you change it back? Done. To be revisited post-release with a better solution, I hope. Alan |
|
From: Geoffrey F. <fu...@ga...> - 2002-01-22 19:44:58
|
Joao Cardoso writes: > On Tuesday 22 January 2002 8:38 am, Alan W. Irwin wrote: > > Grab bag of topics here. The 3rd one is the nasty bug. > > > > (1) Maurice brought up turning on dynamic drivers by default earlier. > > Since nobody has objected, and I think this will be of some benefit to our > > users, I have just committed the change. > > Shouldn't "configure" disable dyndrivers if we don't know how to make shared > libraries on that system? Otherwise we get errors. Great/important point. I totally missed that. I just configured cvs head on Solaris (which worked fine yesterday, although I wasn't using dyndrivers in yesterday's testing)--a noteworthy system whose shared libs PLplot does not currently support--and obtained this: > ../configure No defaults file found, performing full configure. system is: SunOS-5.7 checking for prefix by location of plrender... not found -- using default checking for KCC... yes Found KAI C++, using that! checking for f77... no checking for g77... yes checking how to run the C preprocessor... cc -E checking for X... libraries , headers checking for main in -lX11... yes warning: gd header files not found checking for main in -lgd... no warning: gd library not found warning: cd header files not found checking for main in -lcd... no warning: cd library not found checking for tcl.h... /usr/local/include/tcl.h checking for libtcl... /usr/local/lib/libtcl8.2.so checking for itcl.h... no warning: can't find itcl.h, setting enable_itcl to no checking for tk.h... /usr/local/include/tk.h checking for libtk... /usr/local/lib/libtk8.2.so checking for matwrap... no warning: 'matwrap' not found, disabling Octave support. checking for Python.h... no warning: can't find Python.h, setting enable_python to no checking for main in -lXbsd... no checking for main in -lsocket... yes checking for main in -lnsl... yes checking for main in -lieee... no checking for main in -lm... yes checking how to make shared libraries... unknown checking how to make archive libraries... done checking for dynamic drivers... -n plmeta -n null -n tek -n dg300 -n ps -n xfig -n ljii -n hpgl -n ljiip -n impress -n pbm -n pstex checking for ANSI C header files... yes checking for unistd.h... yes checking for termios.h... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for ranlib... ranlib checking for pid_t... yes checking for vfork.h... no checking for working vfork... yes checking for popen... yes checking for usleep... yes checking for caddr_t... yes creating Makefile.in creating Makedemo.in creating drivers/drivers.db ../configure: test: argument expected > Whic is pretty bad. I think it is clear we have to leave dyndrivers off by default at this point in time. Alan, can you change it back? Joao Cardoso writes: > This implies that the shared libraries detection in sysloc.in should be moved > to the top of the file, and enable_dyndrivers should be set to no if shared > libs build is not supported in that system. This has to be done this > way, as other drivers configured afterwards depends on enable_dyndrivers. > > But this does not fully solve the problem, and as such I think that in the > RELEASE NOTES users should be warned that, is their systems shared libs are > not supported, they should configure without dyndrivers. |
|
From: Joao C. <jc...@fe...> - 2002-01-22 19:36:36
|
On Tuesday 22 January 2002 8:38 am, Alan W. Irwin wrote: > Grab bag of topics here. The 3rd one is the nasty bug. > > (1) Maurice brought up turning on dynamic drivers by default earlier.=20 > Since nobody has objected, and I think this will be of some benefit to = our > users, I have just committed the change. Shouldn't "configure" disable dyndrivers if we don't know how to make sha= red=20 libraries on that system? Otherwise we get errors. This implies that the shared libraries detection in sysloc.in should be m= oved=20 to the top of the file, and enable_dyndrivers should be set to no if shar= ed=20 libs build is not supported in that system. This has to be done this=20 way, as other drivers configured afterwards depends on enable_dyndrivers. But this does not fully solve the problem, and as such I think that in th= e=20 RELEASE NOTES users should be warned that, is their systems shared libs a= re=20 not supported, they should configure without dyndrivers. Joao |
|
From: Alan W. I. <ir...@be...> - 2002-01-22 16:17:09
|
The reason I am putting off the start of comprehensive testing is there is still some nasty bugs in plframe that I discovered late last night, and I am not sure whether the fix will be isolated strictly to plframe.c or not. Maurice was unable to deal with it because he worked until 6:00 this morning finalizing his autoconf changes. That work is much appreciated BTW because it will make our life easier as we all individually make the jump to autoconf 2.5.2 from the old version. However, Maurice is presumably sleeping now so somebody else has to deal with the plframe bugs unless we want to put off testing for quite a while. Geoffrey, could you take a shot at solving the plframe bugs, please? There is a long errand I want to run so I will be out of e-mail contact from 9 - 12 today, but I will be most interested in reading my e-mail when I get back in hopes that the plframe bugs are solved and we can start the testing only a few hours late. 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-22 16:06:13
|
Yes, we should state plainly that GNU make is a requirement. Besides the stuff that is in there now, for which creative people may or may not be able to find workarounds in vendor makes of various strains, there is also the issue of future embellishments to the makefiles that I aim to do, one of these days. Requiring GNU make means, for one thing, that testing on one platform provides assurance about functionality on other platforms. One problem I see with Joao's proposed solution for that one line, is that I don't know what it means without researching, and thus I cannot possibly know with confidence that it will work on /other vendor/ make's (Sun, Data General, IRIX, HP/UX, etc). By using GNU make, we can author on Linux (or whatever each developers personal preferred platfrom is), and be confident that the makefiles will also work on other systems if they just use GNU make. I view that as a significant enablement for continued improvement to the build system. Alan W. Irwin writes: > On Tue, 22 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: >=20 > > No, if using gnu make-3.74 (in my home bin dir) everything runs OK= . >=20 > Good. That is all that is required. >=20 > As I understand Geoff and Maurice's posts on this issue, we no longe= r > accomodate our Makefiles to account for everybody's different variat= ions of > the make command. Instead, our policy (which I will state in the re= lease > notes so everybody is clear about this ) is we demand our users use = Gnu > make. So each of our non-Linux users will be faced with exactly your= > situation on OSF1, and the solution for them is to download Gnu make= and > install and use it. I am glad it seems to be working well on OSF1. >=20 > Alan >=20 >=20 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
|
From: Maurice L. <mj...@ga...> - 2002-01-22 12:20:00
|
Maurice LeBrun writes: > Maurice LeBrun writes: > > Robert Schwebel writes: > > > Alan, > > > > > > On Tue, 22 Jan 2002, Alan W. Irwin wrote: > > > > Robert, one possible workaround is your SuSe distribution may have a > > > > compatibility mode for autoconf version 2.1.3. > > > > > > Argh, this comes from every package wanting another version of the > > > autotools. I've had a more detailed look at it again and the distro has > > > originally 2.13 installed (2.52 came from /usr/local). With this version > > > it works. But fine if I've discovered a bug, anyway :-) > > > > Not bona fide bugs, but compatibility bugs. If 2.13 is in the default distro, > > then I won't worry too much about it. Of course, 2.52 compatibility will be > > an issue eventually, and I'd like to fix these problems, but it's starting to > > look iffy for a quick fix (i.e. before the release). > > I take it back! I just fixed the 3rd problem and it was the last. I've about > had it for tonight but tomorrow will see if these fixes work under 2.31.. I > think they probably will. Just can't seem to put this problem down and go to bed. It all checks out under 2.13, give it a try.. -- Maurice LeBrun mj...@ga... |
|
From: Maurice L. <mj...@ga...> - 2002-01-22 12:06:25
|
Maurice LeBrun writes: > Robert Schwebel writes: > > Alan, > > > > On Tue, 22 Jan 2002, Alan W. Irwin wrote: > > > Robert, one possible workaround is your SuSe distribution may have a > > > compatibility mode for autoconf version 2.1.3. > > > > Argh, this comes from every package wanting another version of the > > autotools. I've had a more detailed look at it again and the distro has > > originally 2.13 installed (2.52 came from /usr/local). With this version > > it works. But fine if I've discovered a bug, anyway :-) > > Not bona fide bugs, but compatibility bugs. If 2.13 is in the default distro, > then I won't worry too much about it. Of course, 2.52 compatibility will be > an issue eventually, and I'd like to fix these problems, but it's starting to > look iffy for a quick fix (i.e. before the release). I take it back! I just fixed the 3rd problem and it was the last. I've about had it for tonight but tomorrow will see if these fixes work under 2.31.. I think they probably will. -- Maurice LeBrun mj...@ga... |
|
From: Maurice L. <mj...@ga...> - 2002-01-22 11:39:55
|
Robert Schwebel writes: > Alan, > > On Tue, 22 Jan 2002, Alan W. Irwin wrote: > > Robert, one possible workaround is your SuSe distribution may have a > > compatibility mode for autoconf version 2.1.3. > > Argh, this comes from every package wanting another version of the > autotools. I've had a more detailed look at it again and the distro has > originally 2.13 installed (2.52 came from /usr/local). With this version > it works. But fine if I've discovered a bug, anyway :-) Not bona fide bugs, but compatibility bugs. If 2.13 is in the default distro, then I won't worry too much about it. Of course, 2.52 compatibility will be an issue eventually, and I'd like to fix these problems, but it's starting to look iffy for a quick fix (i.e. before the release). -- Maurice LeBrun mj...@ga... |
|
From: Robert S. <ro...@sc...> - 2002-01-22 10:11:27
|
Alan, On Tue, 22 Jan 2002, Alan W. Irwin wrote: > Robert, one possible workaround is your SuSe distribution may have a > compatibility mode for autoconf version 2.1.3. Argh, this comes from every package wanting another version of the autotools. I've had a more detailed look at it again and the distro has originally 2.13 installed (2.52 came from /usr/local). With this version it works. But fine if I've discovered a bug, anyway :-) Robert -- +--------------------------------------------------------+ | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de | | Pengutronix - Linux Solutions for Science and Industry | | Braunschweiger Str. 79, 31134 Hildesheim, Germany | | Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 | +--------------------------------------------------------+ |
|
From: Maurice L. <mj...@ga...> - 2002-01-22 09:21:45
|
Alan W. Irwin writes: > On Tue, 22 Jan 2002, Robert Schwebel wrote: > > > automake: Version 1.5 > > autoconf: Version 2.52 > > aclocal: Version 1.5 > > m4: Version 1.4o > > Robert, one possible workaround is your SuSe distribution may have a > compatibility mode for autoconf version 2.1.3. My distribution, Debian > woody, is in the middle of a transition from 2.1.3 to 2.5.2. Apparently it > is a quite large transition, and it appears I am getting a compatibility > mode 2.1.3 if I just specify autoconf on the command line. Obviously SuSe > will have some different arrangement, but if there is a compatibility mode > for autoconf 2.1.3 please give that a try (especially if Maurice has problems > finding a quick fix for 2.5.2). Well so far I've: found and fixed the original bug found and fixed a second bug found the third and if I don't reach the end soon I'm quitting.. -- Maurice LeBrun mj...@ga... |
|
From: Alan W. I. <ir...@be...> - 2002-01-22 09:03:17
|
On Tue, 22 Jan 2002, Robert Schwebel wrote: > automake: Version 1.5 > autoconf: Version 2.52 > aclocal: Version 1.5 > m4: Version 1.4o Robert, one possible workaround is your SuSe distribution may have a compatibility mode for autoconf version 2.1.3. My distribution, Debian woody, is in the middle of a transition from 2.1.3 to 2.5.2. Apparently it is a quite large transition, and it appears I am getting a compatibility mode 2.1.3 if I just specify autoconf on the command line. Obviously SuSe will have some different arrangement, but if there is a compatibility mode for autoconf 2.1.3 please give that a try (especially if Maurice has problems finding a quick fix for 2.5.2). Alan |
|
From: Alan W. I. <ir...@be...> - 2002-01-22 08:39:14
|
Grab bag of topics here. The 3rd one is the nasty bug. (1) Maurice brought up turning on dynamic drivers by default earlier. Since nobody has objected, and I think this will be of some benefit to our users, I have just committed the change. (2) I have also done some preliminary runs of plplot-test.sh, and all the many changes today seem to be working well together. (3) I also did a preliminary test of tkdemos.tcl, and found some bad problems with the colour map handling. To generate the problem simply do the following: ./plserver % source tkdemos.tcl 8 the $w cmd plscmap1 rr gg bb $n_col command in x08.tcl (where n_col is been set to 256) is completely incompatible with plframe although this command works fine for tcldemos.tcl (1) plframe.c assumes the incorrect order of arguments. (2) Once the arguments are rearranged, then the limit on n_col must be raised to at least 256. (3) After those changes it still doesn't work. I don't really understand the scol1 programme logic, but to me it looks unsuitable for what is meant by plscmap1 which should just set the colours in cmap1 without worrying about interpolation. Anyhow, I am beyond my depth, and I have backed out without committing anything. Maurice, could you have a look at this? The reason why this was never noticed in 5.0.4 is the x08.tcl example there had no 3D shaded plot. All my testing of the x08.tcl, etc. changes has been under tcldemos.tcl which has absolutely no problems. I didn't really twig to the fact that some of the API calls were intercepted by plframe.c until tonight so I never worried about a tkdemos.tcl test. BTW, all the other tckdemos.tcl tests go through fine except for example 8. 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: Robert S. <ro...@sc...> - 2002-01-22 08:28:12
|
On Tue, 22 Jan 2002, Maurice LeBrun wrote: > Please let me know what you get back from "m4 --version". E.g. on my system: > > $ m4 --version > GNU m4 1.4.1 callisto:/usr/local/rrdtool-1.0.33 # m4 --version GNU m4 1.4o Robert -- +--------------------------------------------------------+ | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de | | Pengutronix - Linux Solutions for Science and Industry | | Braunschweiger Str. 79, 31134 Hildesheim, Germany | | Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 | +--------------------------------------------------------+ |
76 messages has been excluded from this view by a project administrator.
