Menu
▾
▴
plplot-devel
|
From: Maurice L. <mj...@ga...> - 2002-07-28 22:51:36
|
I've been following this discussion but been too busy to comment until now. I agree Joao that the best design would be to NOT put xwin_common.o in libpltcltk, that it should go in a separate library e.g. libplxwin. OTOH Alan's argument that it should go in libpltcltk as a pragmatic issue (to save work, simplify, etc) is compelling. So I can be happy with Alan's choice. One possibility that might satisfy everyone, if it could work, is to use an escape function in the xwin driver for the missing commands. Then there is separation without significant increase in work. Has anyone looked into this approach? -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Maurice L. <mj...@ga...> - 2002-07-29 02:23:19
|
Maurice LeBrun writes:
> One possibility that might satisfy everyone, if it could work, is to use
> an escape function in the xwin driver for the missing commands. Then there
> is separation without significant increase in work. Has anyone looked into
> this approach?
OK, I just did. The three functions needed by plframe.c:
| jcard:~/tmp/plplot/tmp > for i in `nm -p libpltcl.so | fgrep " U "| awk
| '{print $2}'`; do nm -p drivers/xwin_drv.so | fgrep $i | fgrep " T ";
| done
| 00004900 T plX_setBGFG
| 00005550 T PLColor_from_XColor
| 00001d40 T plD_open_xw
can without too much trouble be called via the escape function approach, thus
removing them from consideration as external functions. plX_setBGFG and
plD_open_xw don't even need to pass any data, just the stream pointer and an
operator index. For PLColor_from_XColor, a pointer to a temporary structure
would have to be passed. In each case, we're talking about only one call from
plframe.c, so the escape function approach seems reasonable to me. Then the
whole issue with where to put these functions is avoided, and the xwin related
logic remains in xwin.c, very simple and effective. So I'd like to go back
to the way it was but with these functions turned into escape functions.
Presumably this can be done with the tkwin_common.c stuff too.
--
Maurice LeBrun mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)
|
|
From: Alan W. I. <ir...@be...> - 2002-07-29 16:48:04
|
Maurice,
I just checked the current dependencies of xwin on libplplottcltk (the
reverse of the check that was done before) to make sure only those 3
functions were required.
for i in `nm -p drivers/xwind_drv.so | fgrep " U "| awk '{print $2}'`; do nm
-p libplplottcltkd.so | fgrep $i | fgrep " T "; done
00017abc T plX_setBGFG
00017bc4 T PLColor_to_XColor
0001747c T plD_open_xw
So indeed your change would mean xwin could link to libplplot rather than
libplplottcltk. So it satisfies Joao's and your design concerns about what
the xwin driver links to and also slims down the libplplottcktk library
without causing any reverse linking or cross dependencies. So it all sounds
good to me.
In the tkwin case, doing the escape function solution for
PLColor_to_TkColor, plD_open_tkwin, and pltkwin_setBGFG would allow putting
tkwin_common back together with tkwin and slimming the libplplottcktk
library some more without reverse linking or cross dependencies. Of course
tkwin would still depend on other functions in libplplottcltk, (just like tk
now depends on libplplottcltk) but I believe that is fine from a design
perspective. So that all sounds good to me as well.
Maurice, the escape function implementations are beyond my expertise so I am
going to have to depend on you (and Vince) for those. Once they are done, I
think the configuration issues are trivial, but if you run into any trouble
with those I could certainly help at that point.
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 Sun, 28 Jul 2002, Maurice LeBrun wrote:
> Maurice LeBrun writes:
> > One possibility that might satisfy everyone, if it could work, is to use
> > an escape function in the xwin driver for the missing commands. Then there
> > is separation without significant increase in work. Has anyone looked into
> > this approach?
>
> OK, I just did. The three functions needed by plframe.c:
>
> | jcard:~/tmp/plplot/tmp > for i in `nm -p libpltcl.so | fgrep " U "| awk
> | '{print $2}'`; do nm -p drivers/xwin_drv.so | fgrep $i | fgrep " T ";
> | done
> | 00004900 T plX_setBGFG
> | 00005550 T PLColor_from_XColor
> | 00001d40 T plD_open_xw
>
> can without too much trouble be called via the escape function approach, thus
> removing them from consideration as external functions. plX_setBGFG and
> plD_open_xw don't even need to pass any data, just the stream pointer and an
> operator index. For PLColor_from_XColor, a pointer to a temporary structure
> would have to be passed. In each case, we're talking about only one call from
> plframe.c, so the escape function approach seems reasonable to me. Then the
> whole issue with where to put these functions is avoided, and the xwin related
> logic remains in xwin.c, very simple and effective. So I'd like to go back
> to the way it was but with these functions turned into escape functions.
>
> Presumably this can be done with the tkwin_common.c stuff too.
>
> --
> Maurice LeBrun mj...@ga...
> Research Organization for Information Science and Technology of Japan (RIST)
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
|
|
From: Maurice L. <mj...@ga...> - 2002-07-29 19:08:37
|
Alan W. Irwin writes: > Maurice, the escape function implementations are beyond my expertise so I am > going to have to depend on you (and Vince) for those. Once they are done, I > think the configuration issues are trivial, but if you run into any trouble > with those I could certainly help at that point. OK, no problem, I'll get to it in the next day or so. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: <jc...@fe...> - 2002-07-26 05:02:46
|
On Thursday 25 July 2002 09:34, Vince Darley wrote: | > | As far as I know, no driver depends on anything in other | > | drivers so that should not be an issue. | | This is untrue of the 'tk' driver. While I am sure it is possible | to remove any link-time dependencies through use of appropriate | stubs, dispatch tables etc, actually using the tk driver uses the | 'plframe' widget which in turn *requires* the xwin driver to | operate. Therefore it is meaningless to talk about the 'tk' driver | unless the 'xwin' driver is available... Yes. And this fully justifies what you say in another mail: |> already have a tk driver and a xwin driver. As the tkwin driver main=20 |> purpose is to be cross platform capable, couldn't it be called tkx?=20 |or xtk? or tkall? The directory name in the bindings directory is=20 |already called tk-x-plat... | | I don't like anything like 'tkx' because that sounds like it is 'tk | on X windows' which it is explicitly *not* (that is what the old 'tk'=20 | driver is). If anything we should rename 'tk' to 'tkx' and take=20 | 'tk' for the new driver *grin*. I agree, but historical considerations... if/when the tkwin driver=20 becomes a standalone driver, the old tk driver could disappear, but=20 I'm sure that many people would be against this... | (at least that's how I understand it). | | In this respect the new 'tkwin' driver is better -- it just depends | on external things (availability of tcl/tk). | | -- Vince | | <http://www.santafe.edu/~vince> | | | | | | ------------------------------------------------------- | This sf.net email is sponsored by: Jabber - The world's fastest | growing real-time communications platform! Don't just IM. Build it | in! http://www.jabber.com/osdn/xim | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
Thanks for helping keep SourceForge clean.
X