Re: cygwin, tcl/tk, and native [Was: Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?]
On Sat, Oct 16, 2004 at 03:46:45AM -0400, Jean-Sebastien Trottier wrote: I like the third option... I'm not going to use gdb as much as Chris so I think he is in a better position to maintain it. However, I agree to take care of cutting the first stable gdb + Cygwin, W11 Tcl/Tk version. I would also agree to co-maintain gdb with Chris and to fix any Tcl/Tk-related issues. As for fully taking over maintenance of gdb, I'm not totally against it but I guess we could discuss the details later... If you can come up with a workable plan for making sure that releasing tcl/tk does not impact insight and, if there are changes necessary for insight, you are willing to promote them in the insight mailing list, I'll continute to grudgingly support insight. I support gdb and used to support gcc because the previous maintainer vanished without a trace (although he has petulantly resurfaced occasionally). I'd be happy to give up supporting insight but the only other person who makes sense to pass it off to would be Corinna and she's already supporting more than her share. cgf
Re: Cygwin, tcl/tk, and native [Was: Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?]
On Fri, Oct 15, 2004 at 05:02:32PM -0400, Charles Wilson wrote:
Jean-Sebastien Trottier wrote:
I would say that what we already have is:
Tcl/Tk: half-Windows/half-Cygwin, GDI
Err...ok. If by this you mean
tcl: cygwin (no GUI), but it doesn't do cygwin paths correctly in all
cases
tk: cygwin, X11
You're right about the Tcl path issue... but I said we already have
GDI, not X11, for Tk.
You did also snip the piece that said Read on... Which basically meant
let me explain in greater boring details...
[...snip...]
Contrary to Jean-Sebastien Trottier's assertion, replacing the current
cygwin, GDI implementation with the native, GDI ActiveState version
will NOT satisfy the current requirements of insight/gdb and other
existing cygwin packages.
I never (did|meant to) assert that people should switch to using
ActiveState's Tcl.
Err...what was this, then: Apart from getting Tk to work without X, I
don't see any... If you want Tk for Windows, might as well get it from
ActiveState.
To me, that says: there is no need for non-X tk on cygwin. If you want
non-X, what you really want is windows (GDI). So go get ActiveStates'.
My point is that THAT is not true, given the distinction between
windowsGDI and windowsRUNTIME. If I misunderstood your point, I apologize.
I guess I wasn't clear then... I was referring to the fact that with
Tcl's current path issue and Tk using GDI, it's not very far from
ActiveState's version.
But enough of that...
Although (I think) it would be possible to have 2 Tk DLL's (Cygwin, X
vs Cygwin, GDI), I like Charles Wilson's idea to try and use W11:
Not my idea -- it was Igor's. ('tis a good one, tho, if you can make it
work.) However, SteveO packages libW11 together with rxvt; it is not a
separate package. (and his build technique to get it to work
is...unique) So, if you need to add stuff to libW11 and need specific
header files, there may be issues. You'll need to work with SteveO and
perhaps split libW11 to a separate project and package.
Sorry for misquoting... I keep notes to track who said what... sometimes
I copy/paste the wrong thing/person... My bad.
I've studied the rxvt/W11 source... the only unique build technique I
can find in there is the fake libX11.a wrapper.
Linking my cygtk8.4.dll against it uncovers 50 unresolved functions...
So, there will be substantial work involved to expand W11 to support
these 50 new functions. Will take some time, but I'm up to the challenge!
Maybe SteveO can lend some time...?
[...snip...]
BTW, I interpret cgf's statement
If someone wants to take over gdb + tcl/tk maintainership that's fine,
though. That is gold-star worthy.
to mean that cgf is willing to relinquish maintaining gdb/insight AND
tcl/tk -- but not just tcl/tk alone. It's a package deal; you'd need to
accept gdb maintainership too. Is that a correct interpretation, cgf,
or is there a third choice: you'd give up maintaining tcl/tk but
continue maintaining gdb SO LONG AS the tcl/tk maintainer's changes
don't force you to do more than minimal work to keep gdb up-to-snuff?
I like the third option... I'm not going to use gdb as much as Chris so
I think he is in a better position to maintain it.
However, I agree to take care of cutting the first stable gdb +
Cygwin, W11 Tcl/Tk version.
I would also agree to co-maintain gdb with Chris and to fix any
Tcl/Tk-related issues.
As for fully taking over maintenance of gdb, I'm not totally against it
but I guess we could discuss the details later...
Cheers,
Sebastien
Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?
Jean-Sebastien Trottier writes: Hi All (and Chris in particular), I've already been successful in getting the following to compile as native Cygwin packages with minimal patches: Tcl v8.4.7 (without registry and DDE) Tk v8.4.7 Itcl v3.2.1 with Iwidgets v4.0.1 expect v5.42.1 I also intend to add Tclx and Tcllib and try to port the registry and DDE libraries (part of Tcl) that are normally only for straight Windows platform. Of course, I don't mind becoming maintainer for these packages... I just want to know if there's actual interest for this, or else I'll stop wasting my time... Let me know what you think. +1*10^10 These are great news, I think cgf is already dreaming about a gold star, if you follow your way through the end. Some questions: - Did you manage to compile the libs as shared libs - Is wish working for you, last time I tried, it started up but was not response to any input Cheers, Sebastien Ciao Volker
Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?
Jean-Sebastien schrieb: Of course, I don't mind becoming maintainer for these packages... I just want to know if there's actual interest for this, or else I'll stop wasting my time... Let me know what you think. Yes, +1 from me. There are packages out there depending on Cygwin and non Cygwin TCL/TK versins, would be really great to have this as official version. Gerrit -- =^..^=
Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?
On Fri, Oct 15, 2004 at 10:09:28AM +0200, Dr. Volker Zell wrote: Jean-Sebastien Trottier writes: Hi All (and Chris in particular), I've already been successful in getting the following to compile as native Cygwin packages with minimal patches: Tcl v8.4.7 (without registry and DDE) Tk v8.4.7 Itcl v3.2.1 with Iwidgets v4.0.1 expect v5.42.1 I also intend to add Tclx and Tcllib and try to port the registry and DDE libraries (part of Tcl) that are normally only for straight Windows platform. Of course, I don't mind becoming maintainer for these packages... I just want to know if there's actual interest for this, or else I'll stop wasting my time... Let me know what you think. +1*10^10 TNATTYHWTFI (There's no acronym to tell you how warm the feeling is!) These are great news, I think cgf is already dreaming about a gold star, if you follow your way through the end. Some questions: - Did you manage to compile the libs as shared libs Have a look at my current test directory: [EMAIL PROTECTED] (0) ~] ll test/bin total 2822 -rwxr-xr-x1 jst None 158383 Oct 15 03:17 cygMpexpr10.dll* -rwxr-xr-x1 jst None 215695 Oct 14 21:16 cygexpect5.42.dll* -rwxr-x---1 jst None 123114 Oct 14 22:59 cygitcl3.2.dll* -rwxr-x---1 jst None57251 Oct 14 22:59 cygitk3.2.dll* -r-xr-xr-x1 jst None 735489 Oct 14 21:07 cygtcl8.4.dll* -r-xr-xr-x1 jst None 930546 Oct 14 21:12 cygtk8.4.dll* -rwxr-xr-x1 jst None 177866 Oct 14 21:16 expect.exe* -rwxr-xr-x1 jst None 182994 Oct 14 21:16 expectk.exe* -rw-r--r--1 jst None 223444 Oct 14 21:16 libexpect5.42.a -rw-r-1 jst None 886 Oct 14 22:59 libitclstub3.2.a -rw-r-1 jst None 770 Oct 14 22:59 libitkstub3.2.a -rw-r-1 jst None 1194 Oct 14 21:07 libtclstub8.4.a -rw-r-1 jst None 2308 Oct 14 21:12 libtkstub8.4.a -rwxr-xr-x1 jst None34010 Oct 15 03:17 mpksc* -rw-r--r--1 jst None 7088 Oct 14 21:07 tclConfig.sh -rwxr-x---1 jst None13309 Oct 14 21:07 tclsh8.4.exe* -rw-r--r--1 jst None 3469 Oct 14 21:12 tkConfig.sh -rwxr-x---1 jst None14132 Oct 14 21:12 wish8.4.exe* [EMAIL PROTECTED] (0) ~] ll test/lib total 0 drwxr-x---+ 2 jst None0 Oct 15 03:17 Mpexpr10/ drwxr-x---+ 2 jst None0 Oct 14 21:16 expect5.42/ drwxr-x---+ 2 jst None0 Oct 14 23:00 itcl3.2/ drwxr-x---+ 2 jst None0 Oct 14 23:00 itk3.2/ lrwxrwxrwx1 jst None 32 Oct 14 23:00 iwidgets - /home/jst/test/lib/iwidgets4.0.1/ drwxr-x---+ 4 jst None0 Oct 14 23:00 iwidgets4.0.1/ drwxr-xr-x+ 8 jst None0 Oct 14 21:07 tcl8.4/ drwxr-xr-x+ 5 jst None0 Oct 14 21:13 tk8.4/ I'm not sure yet if I should keep the .a's within bin or lib and if I should also use the cyg prefix on them... Still some housekeeping to work out... - Is wish working for you, last time I tried, it started up but was not response to any input Yes it does... After sending the email last night, I added Mpexpr 1.0... and I tried mpksc (Tk-based multi-precision calculator) and it works fine. Cheers, Sebastien
Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?
On Oct 15 09:31, Jean-Sebastien Trottier wrote: On Fri, Oct 15, 2004 at 01:06:10PM +0200, Gerrit P. Haase wrote: Jean-Sebastien schrieb: Of course, I don't mind becoming maintainer for these packages... I just want to know if there's actual interest for this, or else I'll stop wasting my time... Let me know what you think. Yes, +1 from me. There are packages out there depending on Cygwin and non Cygwin TCL/TK versins, would be really great to have this as official version. A quick list would be great... we'll need to figure out if we need both the Cygwin and non-Cygwin versions... The Tcl GUI version of GDB, insight, relies on Tcl/Tk for Cygwin with the native GUI. Not everybody who wants to debug using insight wants to install X. It makes sense to me to have both Tcl/Tk versions available. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Cygwin, tcl/tk, and native [Was: Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?]
In the interests of clarity, let's agree on some terminology: a cygwin version -- uses the cygwin1.dll for runtime services (like printf etc) a native windows version uses msvcrt.dll for runtime services an X version uses xlib calls to draw stuff on a display this requires a xserver of some kind And here's the tricky one: a GDI version uses the Windows Graphics Device Interface calls to draw stuff on a display -- WITHOUT using an Xlib emulator. no Xserver needed. -- Using these terms, what we already have is cygwin, GDI ActiveState provides a native, GDI What is being proposed is cygwin, X Contrary to Jean-Sebastien Trottier's assertion, replacing the current cygwin, GDI implementation with the native, GDI ActiveState version will NOT satisfy the current requirements of insight/gdb and other existing cygwin packages. Somehow, a way must be found to have both a cygwin, GDI version of tcl/tk/etc and a cygwin, X version -- where both can coexist on the same machine seamlessly, making it easy to use for the end user and develop against for the developer. This is a hard problem, since it requires proper installation and handling of DLLs, import libs, configure scripts (/usr/lib/tclConfig.sh and /usr/lib/tkConfig.sh), and include files. I am overjoyed to see someone interested in tackling the issue. -- Chuck
Re: Cygwin, tcl/tk, and native [Was: Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?]
Charles Wilson wrote: Using these terms, what we already have is cygwin, GDI ActiveState provides a native, GDI What is being proposed is cygwin, X Note that tcl and itcl do not, themselves, do any display-oriented processing. So GDI vs. X is meaningless for them. They could be released in a separate, cygwin tcl package. It's only because we package tcl + tk + itcl + itk all together in one install that we worry about X tcl and X itcl. AFAICT, expect is the same way; it depends only on tcl, not tk (and thus, not X or GDI). The real bone of contention is tk and itk alone. How can we have a cygwin-X tk and a cygwin-GDI tk on the same machine. -- Chuck
Re: Cygwin, tcl/tk, and native [Was: Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?]
On Fri, Oct 15, 2004 at 01:35:16PM -0400, Charles Wilson wrote: In the interests of clarity, let's agree on some terminology: a cygwin version -- uses the cygwin1.dll for runtime services (like printf etc) a native windows version uses msvcrt.dll for runtime services an X version uses xlib calls to draw stuff on a display this requires a xserver of some kind And here's the tricky one: a GDI version uses the Windows Graphics Device Interface calls to draw stuff on a display -- WITHOUT using an Xlib emulator. no Xserver needed. I'm OK with these... thanks for clarifying. -- Using these terms, what we already have is cygwin, GDI ActiveState provides a native, GDI What is being proposed is cygwin, X I would say that what we already have is: Tcl/Tk: half-Windows/half-Cygwin, GDI Expect: Cygwin, no GUI Putting aside the GUI part, let me explain the Tcl/Tk case with an example: [EMAIL PROTECTED] (0) ~/test] ln -s /non-existant bad-link [EMAIL PROTECTED] (0) ~/test] ln -s /home/jst/ good-link -- what we already have: half-Windows/half-Cygwin [EMAIL PROTECTED] (0) ~/test] /usr/bin/tclsh84 % parray tcl_platform tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = intel tcl_platform(os)= Windows NT tcl_platform(osVersion) = 5.1 tcl_platform(platform) = windows tcl_platform(user) = jst tcl_platform(wordSize) = 4 % pwd C:/cygwin/home/jst/test % file type bad-link could not read bad-link: no such file or directory % file type good-link directory % file readlink bad-link could not readlink bad-link: no such file or directory % file readlink good-link could not readlink good-link: invalid argument -- what I'm proposing: Cygwin [EMAIL PROTECTED] (1) ~/test] /home/jst/test/bin/tclsh8.4.exe % parray tcl_platform tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = i686 tcl_platform(os)= CYGWIN_NT-5.1 tcl_platform(osVersion) = 1.5.11(0.116/4/2) tcl_platform(platform) = unix tcl_platform(user) = jst tcl_platform(wordSize) = 4 % pwd /home/jst/test % file type bad-link link % file type good-link link % file readlink bad-link /non-existant % file readlink good-link /home/jst/ -- For comparison: linux [EMAIL PROTECTED] (0) ~/test] tclsh8.4.4.0 % parray tcl_platform tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = i686 tcl_platform(os)= Linux tcl_platform(osVersion) = 2.4.27-rc3-smp-gw tcl_platform(platform) = unix tcl_platform(user) = jst tcl_platform(wordSize) = 4 % pwd /home/jst/test % file type bad-link link % file type good-link link % file readlink bad-link /non-existant % file readlink good-link /home/jst As you can see above, the current Tcl version uses windows APIs to access the filesystem. So, I would consider it as a mixed half-Windows/half-Cygwin version... Thus, I would say the Tk GUI is not the only problem in the current version... Contrary to Jean-Sebastien Trottier's assertion, replacing the current cygwin, GDI implementation with the native, GDI ActiveState version will NOT satisfy the current requirements of insight/gdb and other existing cygwin packages. I never (did|meant to) assert that people should switch to using ActiveState's Tcl. Thanks to the list, the requirements are getting clearer now... Read on... Somehow, a way must be found to have both a cygwin, GDI version of tcl/tk/etc and a cygwin, X version -- where both can coexist on the same machine seamlessly, making it easy to use for the end user and develop against for the developer. This is a hard problem, since it requires proper installation and handling of DLLs, import libs, configure scripts (/usr/lib/tclConfig.sh and /usr/lib/tkConfig.sh), and include files. I am overjoyed to see someone interested in tackling the issue. Although (I think) it would be possible to have 2 Tk DLL's (Cygwin, X vs Cygwin, GDI), I like Charles Wilson's idea to try and use W11: On Fri, 15 Oct 2004 14:22:02 -0400 (EDT), Charles Wilson wrote: Rxvt already does this. Do tk/itk make GDI calls that aren't covered by rxvt's W11 library? If so, wouldn't a more worthwhile investment of effort be to extend the W11 library with the implementation of the appropriate X11 calls (by plundering the tk/itk GDI implementation as needed), and then use the W11 library in the same way as rxvt does. So, let's extend the terminology: a Cygwin, W11 version uses xlib calls to draw stuff on a display using the W11 library this works with or without a xserver running With this Cygwin, W11 Tk version, this would cover the insight/gdb requirements without the need for 2 distinct Tk DLL's or majorly hacking the
Re: Cygwin, tcl/tk, and native [Was: Re: Interest in native Tcl/Tk/Expect/Itcl/... packages?]
Jean-Sebastien Trottier wrote:
I would say that what we already have is:
Tcl/Tk: half-Windows/half-Cygwin, GDI
Err...ok. If by this you mean
tcl: cygwin (no GUI), but it doesn't do cygwin paths correctly in all
cases
tk: cygwin, X11
As you can see above, the current Tcl version uses windows APIs to
access the filesystem. So, I would consider it as a mixed
half-Windows/half-Cygwin version...
Thus, I would say the Tk GUI is not the only problem in the current
version...
Granted, given your examples.
Contrary to Jean-Sebastien Trottier's assertion, replacing the current
cygwin, GDI implementation with the native, GDI ActiveState version
will NOT satisfy the current requirements of insight/gdb and other
existing cygwin packages.
I never (did|meant to) assert that people should switch to using
ActiveState's Tcl.
Err...what was this, then: Apart from getting Tk to work without X, I
don't see any... If you want Tk for Windows, might as well get it from
ActiveState.
To me, that says: there is no need for non-X tk on cygwin. If you want
non-X, what you really want is windows (GDI). So go get ActiveStates'.
My point is that THAT is not true, given the distinction between
windowsGDI and windowsRUNTIME. If I misunderstood your point, I apologize.
Although (I think) it would be possible to have 2 Tk DLL's (Cygwin, X
vs Cygwin, GDI), I like Charles Wilson's idea to try and use W11:
Not my idea -- it was Igor's. ('tis a good one, tho, if you can make it
work.) However, SteveO packages libW11 together with rxvt; it is not a
separate package. (and his build technique to get it to work
is...unique) So, if you need to add stuff to libW11 and need specific
header files, there may be issues. You'll need to work with SteveO and
perhaps split libW11 to a separate project and package.
On Fri, 15 Oct 2004 14:22:02 -0400 (EDT), Charles Wilson wrote:
Rxvt already does this. Do tk/itk make GDI calls that aren't
covered by rxvt's W11 library? If so, wouldn't a more worthwhile
investment of effort be to extend the W11 library with the
implementation of the appropriate X11 calls (by plundering the
tk/itk GDI implementation as needed), and then use the W11 library
in the same way as rxvt does.
So, let's extend the terminology:
a Cygwin, W11 version
uses xlib calls to draw stuff on a display using the W11 library
this works with or without a xserver running
With this Cygwin, W11 Tk version, this would cover the insight/gdb
requirements without the need for 2 distinct Tk DLL's or majorly hacking
the code.
I will try and have a proof of concept working ASAP...
Cool!
BTW, I interpret cgf's statement
If someone wants to take over gdb + tcl/tk maintainership that's fine,
though. That is gold-star worthy.
to mean that cgf is willing to relinquish maintaining gdb/insight AND
tcl/tk -- but not just tcl/tk alone. It's a package deal; you'd need to
accept gdb maintainership too. Is that a correct interpretation, cgf,
or is there a third choice: you'd give up maintaining tcl/tk but
continue maintaining gdb SO LONG AS the tcl/tk maintainer's changes
don't force you to do more than minimal work to keep gdb up-to-snuff?
--
Chuck
