Re: tclsh83.exe should be cygtclsh83.exe
Chuck, I do consider this thread is closed, but, [...] > > ftp://ftp.nanotech.wisc.edu/pub/khan/tcl/tcltk-8.3.4-cygwin/ > > [...] [...] > > But that tk is X-based, isn't it? There is no way that the default [...] just for the records: it's not. SLao -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tclsh83.exe should be cygtclsh83.exe
No, it is windows based. -Bill At 11:39 PM 1/29/2003 -0500, Charles Wilson wrote: >William A. Hoffman wrote: > >>There is a complete tcl that can be found here: >>ftp://ftp.nanotech.wisc.edu/pub/khan/tcl/tcltk-8.3.4-cygwin/ >>It would be great if this was used. It is a complete tcl that works under cygwin. > >But that tk is X-based, isn't it? There is no way that the default cygwin tk will be >an X-dependent one; none of Red Hat's commercial customers want to fire up an Xserver >just to run the GNUpro debugger (that is, gdb/insight). And as a non-commercial >free-as-in-beer user of cygwin, I *agree* with that. Those commercial customers >provide the money that keeps Corinna and cgf employed, supporting cygwin (even tho >it's not part of cgf's job description), and cranking out the new goodies for us. > >There have been discussions about a "tk-X" and "tk"(native "MS" windowing, cygwin >runtime) version -- but nobody, not even me, has stepped up to the plate to provide >it, and work out the issues related to both versions coexisting on the same user's >machine. I do *not* want to restart that thread again here -- but check the ml list >archives for more info; I think the most recent discussion was back in early >September/late August 2002. > >--Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tclsh83.exe should be cygtclsh83.exe
William A. Hoffman wrote: There is a complete tcl that can be found here: ftp://ftp.nanotech.wisc.edu/pub/khan/tcl/tcltk-8.3.4-cygwin/ It would be great if this was used. It is a complete tcl that works under cygwin. But that tk is X-based, isn't it? There is no way that the default cygwin tk will be an X-dependent one; none of Red Hat's commercial customers want to fire up an Xserver just to run the GNUpro debugger (that is, gdb/insight). And as a non-commercial free-as-in-beer user of cygwin, I *agree* with that. Those commercial customers provide the money that keeps Corinna and cgf employed, supporting cygwin (even tho it's not part of cgf's job description), and cranking out the new goodies for us. There have been discussions about a "tk-X" and "tk"(native "MS" windowing, cygwin runtime) version -- but nobody, not even me, has stepped up to the plate to provide it, and work out the issues related to both versions coexisting on the same user's machine. I do *not* want to restart that thread again here -- but check the ml list archives for more info; I think the most recent discussion was back in early September/late August 2002. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tclsh83.exe should be cygtclsh83.exe
Chuck, On Tue, Jan 28, 2003 at 08:54:19PM -0500, Charles Wilson wrote: > Charles Wilson wrote: > /usr/lib/libtcl8.3.a -> libcygtcl83.a > > I forgot to mention, I created the libtcl8.3.a file as a symlink; The above will no longer be necessary for Python 2.3. Plus, the "cyg" prefixes has been removed in the Cygwin Tcl/Tk 8.4 package anyway. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tclsh83.exe should be cygtclsh83.exe
> > >As far as the libraries for tcl, I dunno. That's a decision made by the tcl/tk folks >over on the insight list. For the record, I have these in my /usr/lib dir: >/usr/lib/libcygitcl32.a >/usr/lib/libcygtcl83.a >/usr/lib/libtcl8.3.a <<<-- >/usr/lib/libcygitclstub32.a >/usr/lib/libcygtclstub83.a >/usr/lib/tclConfig.sh > >But I haven't yet updated to the version that was released today. Apparently a lot of >hard work has gone on in this area recently; take a look at the new packages. If >they aren't satisfactory, I'm sure the folks over on the insight list would love some >help -- but don't hold your breath on the tcl executable being renamed... There is a complete tcl that can be found here: ftp://ftp.nanotech.wisc.edu/pub/khan/tcl/tcltk-8.3.4-cygwin/ It would be great if this was used. It is a complete tcl that works under cygwin. -Bill -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tclsh83.exe should be cygtclsh83.exe
Charles Wilson wrote: tcl/tk folks over on the insight list. For the record, I have these in my /usr/lib dir: /usr/lib/libcygitcl32.a /usr/lib/libcygtcl83.a /usr/lib/libtcl8.3.a <<<-- /usr/lib/libcygitclstub32.a /usr/lib/libcygtclstub83.a /usr/lib/tclConfig.sh /usr/lib/libtcl8.3.a -> libcygtcl83.a I forgot to mention, I created the libtcl8.3.a file as a symlink; this allowed me to build a working Python Imaging Library (the fileviewer, viewer.py, uses the tk/tcl extensions...so a working tcl and tk is a must: but a few symlinks, and some additional header files snarfed from the tcltk sources and I was up and running. Search the cygwin ml archives for "PIL". --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tclsh83.exe should be cygtclsh83.exe
Peter A. Castro wrote: If that is NOT what you are suggestion -- e.g. that only tclsh83 should be renamed -- why? Why is tclsh83 special? By that same token, why do the tcl libraries have "cyg" in their name? Eg: libtcl83.a is named libcygtcl83.a. Why? It's still tcl. Why are the libraries name different for this platform? I've had to hack some autoconf generated configure scripts because they wanted 'libtcl83' not 'libcygtcl83'. I know. In general, import and static libs are "libfoo", but the DLLs are cygfoo. This is to avoid hard-to-diagnose problems related to DLL loading, platform mismatch, and in-memory caching. (similar to .exe conflicts -- but much harder to diagnose, since DLL loading is a black art for most users, while "make sure the .exe you want is in front of your PATH" is fairly easy) As far as the libraries for tcl, I dunno. That's a decision made by the tcl/tk folks over on the insight list. For the record, I have these in my /usr/lib dir: /usr/lib/libcygitcl32.a /usr/lib/libcygtcl83.a /usr/lib/libtcl8.3.a <<<-- /usr/lib/libcygitclstub32.a /usr/lib/libcygtclstub83.a /usr/lib/tclConfig.sh But I haven't yet updated to the version that was released today. Apparently a lot of hard work has gone on in this area recently; take a look at the new packages. If they aren't satisfactory, I'm sure the folks over on the insight list would love some help -- but don't hold your breath on the tcl executable being renamed... P.S. Now, we *do* name all DLL's with a special 'cyg' prefix, but that is because DLLs are a much more complicated problem than EXEs (memory resident, etc etc) For DLLs, I can see why they are tagged with 'cyg' (this *is* still Windows under the hood), but what about static linklibs? That is controlled by the compiler/linker's lookup path (builtin, plus -L arguments). Thus, no need to worry about conflicts unless you do something silly. And linktime issues are the domain of developers, who are assumed to be somewhat more clueful than your average bear. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tclsh83.exe should be cygtclsh83.exe
If this was REALLY a full tclsh83.exe, I would have less of a problem with it. However, this is some small sub-set of tclsh83 that replaces a FULL cygtclsh80.exe. Perhaps this one should be called cyg-gdb-tclsh.If you have programs like cmake or configure scripts that look for tclsh, they find this one, and mistakenly think it is a working tcl which it is not. The comment in setup.exe says it is only for use with gdb. -Bill At 08:26 AM 1/28/2003 +0100, S. L. wrote: >[...] >> If that is NOT what you are suggestion -- e.g. that only tclsh83 should >> be renamed -- why? Why is tclsh83 special? >[...] > > >[cough, ough!] >Yes, yes, why?! Why is it the one and only cygwin app (except the specific >applications, e.g. cygcheck, cygpath) that cannot do a "$ /bin/tclsh83.exe >/usr/share/tcl8.3/tcltest1.0/tcltest.tcl" returning a "couldn't read file >"/usr/share/tcl8.3/tcltest1.0/tcltest.tcl": no such file or directory" message ?! >:)) > > >No joke, now, actually it IS special, but this is it. To quote, "any patches >...", 'right ?! :)) > >SLao > >-- >+++ GMX - Mail, Messaging & more http://www.gmx.net +++ >NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tclsh83.exe should be cygtclsh83.exe
[...] > If that is NOT what you are suggestion -- e.g. that only tclsh83 should > be renamed -- why? Why is tclsh83 special? [...] [cough, ough!] Yes, yes, why?! Why is it the one and only cygwin app (except the specific applications, e.g. cygcheck, cygpath) that cannot do a "$ /bin/tclsh83.exe /usr/share/tcl8.3/tcltest1.0/tcltest.tcl" returning a "couldn't read file "/usr/share/tcl8.3/tcltest1.0/tcltest.tcl": no such file or directory" message ?! :)) No joke, now, actually it IS special, but this is it. To quote, "any patches ...", 'right ?! :)) SLao -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tclsh83.exe should be cygtclsh83.exe
On Mon, 27 Jan 2003, Charles Wilson wrote: > William A. Hoffman wrote: > > I recently ran setup, and one of the new packages, I think gdb, caused > > a tclsh83.exe to be installed into /usr/bin. It would be nice if > > this were a full working tclsh83.exe, but it is not.However, it conflicted > > with the working tclsh83.exe I already had in my path. Shouldn't the > > name of this by cygtclsh83.exe? > > No. Are you suggesting that all 508 of the .exe's in my /bin should > really be named "cyg*.exe"? "cyglynx" "cygman" "cygless" just because > they MIGHT conflict with a mingw or native version of less.exe or man.exe? > > If that is NOT what you are suggestion -- e.g. that only tclsh83 should > be renamed -- why? Why is tclsh83 special? By that same token, why do the tcl libraries have "cyg" in their name? Eg: libtcl83.a is named libcygtcl83.a. Why? It's still tcl. Why are the libraries name different for this platform? I've had to hack some autoconf generated configure scripts because they wanted 'libtcl83' not 'libcygtcl83'. > It's easy to avoid executable PATH conflicts -- just make sure the tclsh > you want appears in the PATH before the one you don't like. End of problem. > > --Chuck > > P.S. Now, we *do* name all DLL's with a special 'cyg' prefix, but that > is because DLLs are a much more complicated problem than EXEs (memory > resident, etc etc) For DLLs, I can see why they are tagged with 'cyg' (this *is* still Windows under the hood), but what about static linklibs? -- Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> "Cats are just autistic Dogs" -- Dr. Tony Attwood -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tclsh83.exe should be cygtclsh83.exe
William A. Hoffman wrote: I recently ran setup, and one of the new packages, I think gdb, caused a tclsh83.exe to be installed into /usr/bin. It would be nice if this were a full working tclsh83.exe, but it is not.However, it conflicted with the working tclsh83.exe I already had in my path. Shouldn't the name of this by cygtclsh83.exe? No. Are you suggesting that all 508 of the .exe's in my /bin should really be named "cyg*.exe"? "cyglynx" "cygman" "cygless" just because they MIGHT conflict with a mingw or native version of less.exe or man.exe? If that is NOT what you are suggestion -- e.g. that only tclsh83 should be renamed -- why? Why is tclsh83 special? It's easy to avoid executable PATH conflicts -- just make sure the tclsh you want appears in the PATH before the one you don't like. End of problem. --Chuck P.S. Now, we *do* name all DLL's with a special 'cyg' prefix, but that is because DLLs are a much more complicated problem than EXEs (memory resident, etc etc) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
