From: Alan W. I. <ir...@be...> - 2013-10-25 07:46:04
|
Orion has done good work for us over the years testing PLplot in a pioneering way using a Linux platform (Fedora's latest version) where only cutting-edge versions of software packages are available. But now it is possible to help him out a little bit by testing PLplot against the latest versions of software that you have built yourself with build_projects. As a case in point I have just now (revision 12628) implemented a Tcl-8.6.1 build with build_projects. That is definitely a cutting-edge version of Tk because it was only released in September, and the 8.6.x series is the first version of Tcl to integrate iTcl (version 4.0.0). The build and install of Tcl and iTcl only took a few minutes. I attempted a PLplot build and test against that newly installed software, and immediately found and fixed (revision 12627) a minor build system issue (had to bump the maximum itcl version looked for to 4.0.0). But after that fix, the PLplot configuration found all appropriate locations for headers and libraries for Tcl-8.6.1 and iTcl-4.0.0, the build proceeded without issues, and the test_diff_psc target showed no differences between the Tcl and corresponding C results for all our standard examples. So I am pleased by that positive result. Note, I think the above PLplot test only tests Tcl, and not iTcl. But my agenda for tomorrow (Friday) is implementing a build_projects configuration for building and installing Tk-8.6.1. Assuming I can get that to work, then the PLplot test of that will definitely include a test of iTcl. Later I plan to try and get both Tcl and Tk to build on Wine. According to the Tcl notes for such builds, I can use a very similar build procedure under MinGW/MSYS that I do on Linux, but with one caveat; Tcl no longer supports pure 32-bit Windows. Instead, you apparently need a WoW64 Windows setup (a mixture of 32-bit and 64-bit). That's actually available for Wine, but I estimate it is going to take quite a bit of effort to build that WoW64 version of Wine and install all the necessary Windows software (MinGW/MSYS, CMake, Python, etc.) on that new version of the Wine platform. So this effort may stretch into late next week. N.B. I do expect the Linux build of Tk to be useful for testing PLplot on cutting-edge Tk. But for now the corresponding Windows build of Tk (if it works) will mostly just be a curiosity since it will be the version of Tk that just uses a subset of the X calls. But I am going to attempt that Tk build on Windows for completeness, and because it might be useful later. In fact, currently I believe there is even a few simple tests you can run against that "subset" version of Tk using PLplot (the "runAllDemos.tcl" code that can be tested using the procedure in examples/tk/README.tkdemos was originally developed on Windows and uses its own unique bindings located at binding/tk-x-plat that stay within the subset API of Tk). In sum, I have made a good start toward the goal of supplying some interesting test results for the latest versions of Tcl and Tk for both Linux and Windows. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-10-25 07:53:39
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > Later I plan to try and get both Tcl and Tk to build on Wine. > According to the Tcl notes for such builds, I can use a very similar build procedure > under MinGW/MSYS that I do on Linux, but with one caveat; Tcl no longer supports > pure 32-bit Windows. Instead, you apparently need a WoW64 Windows setup (a > mixture of 32-bit and 64-bit). That's actually available for Wine, but I estimate it is > going to take quite a bit of effort to build that WoW64 version of Wine and install all > the necessary Windows software (MinGW/MSYS, CMake, Python, etc.) on that new > version of the Wine platform. So this effort may stretch into late next week. > Where did you find that information about Tcl no longer supporting 32-bits Windows? ActiveTcl 8.6.1 comes in two flavours for Windows for instance: 32-bits and 64-bits. Or is this something specific to MinGW/MSYS? > N.B. I do expect the Linux build of Tk to be useful for testing PLplot on cutting-edge > Tk. But for now the corresponding Windows build of Tk (if it works) will mostly just be > a curiosity since it will be the version of Tk that just uses a subset of the X calls. But > I am going to attempt that Tk build on Windows for completeness, and because it > might be useful later. In fact, currently I believe there is even a few simple tests you > can run against that "subset" version of Tk using PLplot (the "runAllDemos.tcl" code > that can be tested using the procedure in examples/tk/README.tkdemos was > originally developed on Windows and uses its own unique bindings located at > binding/tk-x-plat that stay within the subset API of Tk). > > In sum, I have made a good start toward the goal of supplying some interesting test > results for the latest versions of Tcl and Tk for both Linux and Windows. > I have been able to build the Tk bindings and related drivers under Cygwin. Since there is a X11 Window server and window manager for that platform, I could run the examples on my Windows laptop. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-10-25 09:19:27
|
On 2013-10-25 07:53-0000 Arjen Markus wrote: > Where did you find that information about Tcl no longer supporting 32-bits Windows? > ActiveTcl 8.6.1 comes in two flavours for Windows for instance: 32-bits and 64-bits. > Or is this something specific to MinGW/MSYS? Hi Arjen: Thanks to your question, I investigated some more and discovered my mistake. Here is the actual quote from win/README in the Tcl-8.6.1 source tree that was confusing me: "Note: Tcl no longer provides support for Win32s." I incorrectly interpreted that "s" to be plural, i.e., referring to various kinds of Win32 systems, but I have just now realized that "Win32s" is the name of an old version of Windows, and Tcl no longer supporting that old version is not much of a concern. This implies I can continue to use a pure 32-bit version of Wine which should greatly simplify my life. So I am glad you responded above to what I said. >> N.B. I do expect the Linux build of Tk to be useful for testing PLplot on cutting-edge >> Tk. But for now the corresponding Windows build of Tk (if it works) will mostly just be >> a curiosity since it will be the version of Tk that just uses a subset of the X calls. But >> I am going to attempt that Tk build on Windows for completeness, and because it >> might be useful later. In fact, currently I believe there is even a few simple tests you >> can run against that "subset" version of Tk using PLplot (the "runAllDemos.tcl" code >> that can be tested using the procedure in examples/tk/README.tkdemos was >> originally developed on Windows and uses its own unique bindings located at >> binding/tk-x-plat that stay within the subset API of Tk). >> >> In sum, I have made a good start toward the goal of supplying some interesting test >> results for the latest versions of Tcl and Tk for both Linux and Windows. >> > > I have been able to build the Tk bindings and related drivers under Cygwin. Since there is > a X11 Window server and window manager for that platform, I could run the examples > on my Windows laptop. I remember that result, and also the slow speed for it that you reported at the time (presumably because the translation of X calls to native graphics Windows calls is inefficient). I think the responsiveness of the Tk GUI would be much quicker if the PLplot Tk bindings just used the subset Tk API which would bypass X and effectively call Windows graphics directly. And similarly, I think you would get substantial speed gains for graphical devices when the Cairo and Qt libraries are configured and built to take advantage of direct Windows graphics rather than using X. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-10-25 09:36:45
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Friday, October 25, 2013 11:19 AM > To: Arjen Markus > Cc: PLplot development list > Subject: RE: [Plplot-devel] Tcl-8.6.1 and iTcl-4.0.0 > > On 2013-10-25 07:53-0000 Arjen Markus wrote: > > > Where did you find that information about Tcl no longer supporting 32-bits > Windows? > > ActiveTcl 8.6.1 comes in two flavours for Windows for instance: 32-bits and 64-bits. > > Or is this something specific to MinGW/MSYS? > > Hi Arjen: > > Thanks to your question, I investigated some more and discovered my mistake. > > Here is the actual quote from win/README in the Tcl-8.6.1 source tree that was > confusing me: > > "Note: Tcl no longer provides support for Win32s." > > I incorrectly interpreted that "s" to be plural, i.e., referring to various kinds of Win32 > systems, but I have just now realized that "Win32s" > is the name of an old version of Windows, and Tcl no longer supporting that old > version is not much of a concern. This implies I can continue to use a pure 32-bit > version of Wine which should greatly simplify my life. So I am glad you responded > above to what I said. > Ah, I had all but forgotten about that one! If I remember correctly, "Win32s" was actually a means to use 32-bits applications on 16-bits systems. That was another era ... Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-10-28 21:23:52
|
To Maurice, Arjen, and/or James Tappin: I am primarily addressing this appeal to you guys because you are the only ones I know with some combined PLplot and Tcl/Tk expertise. In order to finish off some Tcl/Tk8.6 + itcl/itk/iwidgets version 4 testing work, I need some global way to effectively replace package require Itcl package require Itk package require Iwidgets everywhere it occurs in our code with either package require Itcl 3.0 package require Itk 3.0 package require Iwidgets 3.0 OR package require itcl 4.0.0 package require itk 4.0.0 package require iwidgets 4.0.0 I am thinking along the lines of setting some global variables such as itcl_package_name itk_package_name iwidgets_package_name with the appropriate values for version 3 or version 4, but I don't know whether that is possible with Tcl. As an experiment, I did try using set itk_package_name "itk 4.0.0" in bindings/tk/pkgIndex.tcl and I attempted to access that variable in examples/tk/tk02 using global itk_package_name puts "$itk_package_name" But the result errored out with can't read "itk_package_name": no such variable while executing "puts "$itk_package_name"" The goal here is to make it easy for the user to choose between using either version 3 of [incr Tcl_tk] or version 4. In fact, my testing of those two cases is being held up because I don't have an easy way to switch between them (without a lot of code editing). So some quick help on how to make this possible would be appreciated. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2013-10-28 21:44:55
|
On 2013-10-28 14:23-0700 Alan W. Irwin wrote: > The goal here is to make it easy for the user to choose between > using either version 3 of [incr Tcl_tk] or version 4. In fact, my > testing of those two cases is being held up because I don't have > an easy way to switch between them (without a lot of code editing). > So some quick help on how to make this possible would be appreciated. Soon after I sent the above appeal off, I discovered how our build system set the macro TCL_DIR and how bindings/tcl/tclMain.c used that macro to help determine the Tcl global variable $dir. Therefore, I will try something similar to globally set itcl_package_name, etc., (unless you guys can think of a better method). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Maurice L. <mj...@br...> - 2013-10-29 03:00:26
|
On Monday, October 28, 2013 at 14:44:48 (-0700) Alan W. Irwin writes: > On 2013-10-28 14:23-0700 Alan W. Irwin wrote: > > > The goal here is to make it easy for the user to choose between > > using either version 3 of [incr Tcl_tk] or version 4. In fact, my > > testing of those two cases is being held up because I don't have > > an easy way to switch between them (without a lot of code editing). > > So some quick help on how to make this possible would be appreciated. > > Soon after I sent the above appeal off, I discovered how our build > system set the macro TCL_DIR and how bindings/tcl/tclMain.c used that > macro to help determine the Tcl global variable $dir. Therefore, I > will try something similar to globally set itcl_package_name, etc., > (unless you guys can think of a better method). I think in order to avoid coding in package version dependencies where none should exist, make sure your desired tcl package library directories are all properly positioned in auto_path. E.g. on my Kubuntu 12.04.3 box: $ tclsh8.4 % puts $auto_path /usr/share/tcltk/tcl8.4 /usr/lib /usr/local/lib/tcltk /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk $ tclsh8.5 % puts $auto_path /usr/share/tcltk/tcl8.5 /usr/lib /usr/local/lib/tcltk /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk That first entry enables it to find the right packages. -- Maurice LeBrun |
From: Alan W. I. <ir...@be...> - 2013-10-29 08:31:19
|
On 2013-10-28 21:44-0500 Maurice LeBrun wrote: > On Monday, October 28, 2013 at 14:44:48 (-0700) Alan W. Irwin writes: > > On 2013-10-28 14:23-0700 Alan W. Irwin wrote: > > > > > The goal here is to make it easy for the user to choose between > > > using either version 3 of [incr Tcl_tk] or version 4. In fact, my > > > testing of those two cases is being held up because I don't have > > > an easy way to switch between them (without a lot of code editing). > > > So some quick help on how to make this possible would be appreciated. > > > > Soon after I sent the above appeal off, I discovered how our build > > system set the macro TCL_DIR and how bindings/tcl/tclMain.c used that > > macro to help determine the Tcl global variable $dir. Therefore, I > > will try something similar to globally set itcl_package_name, etc., > > (unless you guys can think of a better method). > > I think in order to avoid coding in package version dependencies where none > should exist, make sure your desired tcl package library directories are all > properly positioned in auto_path. E.g. on my Kubuntu 12.04.3 box: > > $ tclsh8.4 > % puts $auto_path > /usr/share/tcltk/tcl8.4 /usr/lib /usr/local/lib/tcltk /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk > > $ tclsh8.5 > % puts $auto_path > /usr/share/tcltk/tcl8.5 /usr/lib /usr/local/lib/tcltk /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk > > That first entry enables it to find the right packages. Hi Maurice, First, I think version 4 of itcl... is the wave of the future. The reason I say that is itcl version 4 is already completely integrated with Tcl-8.6 and built on top of its inherent low-level OO capabilities of that version of Tcl. (This is the first time itcl has ever been integrated with Tcl.) Furthermore, version 4 of itk and iwidgets are built on top of that integrated version of itcl-4. Second, some web comments I read imply that although version 3 of itcl... is legacy code, that code still should work fine with Tcl/Tk-8.6. So what I plan to do is build both version 3 and version 4 of itcl... as part of the Tcl/Tk-8.6 installation directory tree that is provided by build_projects, and use the method I outlined before to allow the user to choose one or the other of those versions in a consistent way. I emphasize that convenience method should be viewed as preliminary (since I am not much of a Tcl/Tk expert), and if someone can come up with a better method in our scripts of making that choice, that is fine with me. Once that preliminary method of choosing version 3 or version 4 of itcl... for Tcl/Tk8.6 is implemented, then we will be in a position to test how compatible our PLplot scripts are at a fundamental level with those two versions. I expect from previus experience with version 3 that our scripts will be fine with that version, but my preliminary tests indicate our scripts will have to be modified (more than just the package require commands) to get them to work with version 4 of itcl.... (More on that later once I marshall all the evidence.) Once our scripts work properly with both itcl.... version 3 and itcl... version 4 we may want to remove all this version choice for itcl... and simply demand that itcl... version 3 can only be used if it is installed in a Tcl/Tk8.5 directory tree while itcl... version 4 can only be used when it is installed in a Tcl/Tk8.6 directory tree. But we can cross that bridge when we come to it. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-10-29 08:49:21
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > > > I think in order to avoid coding in package version dependencies where > > none should exist, make sure your desired tcl package library > > directories are all properly positioned in auto_path. E.g. on my Kubuntu 12.04.3 > box: > > > > $ tclsh8.4 > > % puts $auto_path > > /usr/share/tcltk/tcl8.4 /usr/lib /usr/local/lib/tcltk > > /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk > > > > $ tclsh8.5 > > % puts $auto_path > > /usr/share/tcltk/tcl8.5 /usr/lib /usr/local/lib/tcltk > > /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk > > > > That first entry enables it to find the right packages. > The auto_path variable is computed from the environment variable TCLLIBPATH, which is accessed within Tcl code as $::env(TCLLIBPATH) (:: indicating the global namespace). The environment variable is only used at start-up. This provides the means to control the directories that are searched for packages, but if you want this to be decided at build/install time, then the C macro TCL_DIR may be more useful. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-10-29 19:19:16
|
On 2013-10-29 08:49-0000 Arjen Markus wrote: > Hi Alan, > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] > > >>> >>> I think in order to avoid coding in package version dependencies where >>> none should exist, make sure your desired tcl package library >>> directories are all properly positioned in auto_path. E.g. on my Kubuntu 12.04.3 >> box: >>> >>> $ tclsh8.4 >>> % puts $auto_path >>> /usr/share/tcltk/tcl8.4 /usr/lib /usr/local/lib/tcltk >>> /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk >>> >>> $ tclsh8.5 >>> % puts $auto_path >>> /usr/share/tcltk/tcl8.5 /usr/lib /usr/local/lib/tcltk >>> /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk >>> >>> That first entry enables it to find the right packages. >> > > The auto_path variable is computed from the environment variable TCLLIBPATH, which is > accessed within Tcl code as $::env(TCLLIBPATH) (:: indicating the global namespace). The > environment variable is only used at start-up. This provides the means to control the > directories that are searched for packages, but if you want this to be decided at build/install time, > then the C macro TCL_DIR may be more useful. Hi Arjen: For your information here is the current directory layout of $prefix/lib, where $prefix is the overall install prefix used by build_projects for the "buildtool" category of packages which currently includes Tcl/Tk8.6.1, and version 4 of itcl..... lib lib/tcl8.6 lib/tcl8.6/opt0.4 lib/tcl8.6/msgs lib/tcl8.6/http1.0 lib/tcl8.6/encoding lib/tcl8 lib/tcl8/8.6 lib/tcl8/8.6/tdbc lib/tcl8/8.5 lib/tcl8/8.4 lib/tcl8/8.4/platform lib/tdbc1.0.0 lib/thread2.7.0 lib/tdbcmysql1.0.0 lib/sqlite3.8.0 lib/tdbcpostgres1.0.0 lib/tk8.6 lib/tk8.6/ttk lib/tk8.6/images lib/tk8.6/msgs lib/tk8.6/demos lib/tk8.6/demos/images lib/iwidgets4.1_cp lib/pkgconfig lib/tdbcodbc1.0.0 lib/itcl4.0.0 lib/itk4.0.0 I have no clue what is contained in lib/tcl8/8.5 and lib/tcl8/8.4, but build_projects does not build or install earlier versions of Tcl so suspect they are installed by Tcl-8.6.1 to provide some sort of backwards compatibility. Note that if lappend includes lib (which is what happens automatically if you follow the build directions in http://www.linuxfromscratch.org/blfs/view/svn/general/tcl.html which is what build_projects does), then you automatically find all subdirectories, i.e. Tcl/Tk8.6, and version 4 of itcl.... Thus, I think regardless of the location of version 3 of itcl..., the only way you can exclude version 4 and use version 3 instead with Tcl/Tk8.6 is by using versioned package require itcl... commands in our scripts with the desired (configured) version numbers. So that is what I plan to implement after I have modified build_projects to also install version 3 of itcl... in the above lib tree for convenience. However, I emphasize the above argument about requiring version numbers to exclude version 4 of itcl.... does not actually depend on that 3 installation location. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2013-11-03 22:30:32
|
Here is the current build_projects status for itcl... version 4 and version 3. Version 4. itcl version 4 is integrated in as part of the Tcl install so the only added build configurations are for itk (version 4) and iwidgets (version 4.1) which build without issues and are automatically picked up in a Tk-8.6 wish environment using package require itcl (or package require Itcl) package require itk package require iwidgets (The lower case version of the names is required for itk and iwidgets.) Version 3. Version 3 requires build configurations itcl3, itk3, and iwidgets4.0. The first two of those are currently implemented and build without issues. Version 3 is currently being installed with a unique install prefix. But it turns out that doesn't buy you anything except the lappend complication. It turns out if you use a special lappend auto_path command to find that install prefix, then, "package require Itcl" _still_ finds version 4 because it is integrated with Tcl-8.6. I have already solved some filename clashes (e.g., the itcl and itk headers) with version 4 that were revealed by the separate install prefix. I shortly plan to drop the separate install prefix and use the previous plan I expressed which was to use global variables to establish the name/version of what is obtained with the package require commands in our scripts. To Do: iwidgets4.0 build configuration. This takes a bit of extra work because this has not been maintained in a decade. However, once I have this figured out, I may use the same procedure for iwidgets4.1 since in that case, the current build_projects configuration is simply to copy existing install-tree results of a minimally patched iwidgets4.0 installation. Make the install prefix for itcl... version 3 common with that of Tcl8.6. Implement global variables with versioned package names for the package require commands in the PLplot scripts. Also do anything else required so that all the version 3 itcl... aspects work for the tk02 and tk04 examples. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |