Re: ATTENTION: Tcl/Tk transition
On Sat, 7 Jan 2012, Yaakov (Cygwin/X) wrote: Still outstanding are: * python[-tkinter] (Jason Tishler) * suite3270 [tcl3270] (Peter A. Castro) In order to provide a seamless transition for users, your packages must be rebuilt for the new Tcl/Tk per my original instructions[1]. Please let us know when you will be able to do this, or if you need any assistance. Jason: I don't want to break Tkinter. Can you make this a priority, please? Peter: If your update is not ready in time, I will have to remove tcl3270 from the distro. Yaakov, I don't know what your timeline is for this (did I somehow miss you posting a date for this transition?), but I'll see if I can rebuild this week. Yaakov [1] http://cygwin.com/ml/cygwin-apps/2011-10/msg00083.html -- Peter A. Castro doc...@fruitbat.org or peter.cas...@oracle.com Cats are just autistic Dogs -- Dr. Tony Attwood
Re: ATTENTION: Tcl/Tk transition
Yaakov, On Sat, Jan 07, 2012 at 09:47:05PM -0600, Yaakov (Cygwin/X) wrote: Still outstanding are: * python[-tkinter] (Jason Tishler) * suite3270 [tcl3270] (Peter A. Castro) In order to provide a seamless transition for users, your packages must be rebuilt for the new Tcl/Tk per my original instructions[1]. Please let us know when you will be able to do this, or if you need any assistance. I had hoped to find time to rebuild python[-tkinter] over the holidays... Jason: I don't want to break Tkinter. Can you make this a priority, please? Yes. Sorry for the delay. Jason
Re: ATTENTION: Tcl/Tk transition
Yaakov (Cygwin/X), le Sun 04 Dec 2011 23:32:14 -0600, a écrit : Thank you to Dr. Volker Zell for rebuilding his packages. That still leaves: * brltty [tcl-brlapi] (Samuel Thibault) * python[-tkinter] (Jason Tishler) * suite3270 [tcl3270] (Peter A. Castro) In order to provide a seamless transition for users, your packages must be rebuilt for the new Tcl/Tk per my original instructions[1]. Please let us know when you will be able to do this, or if you need any assistance. Yaakov [1] http://cygwin.com/ml/cygwin-apps/2011-10/msg00083.html Here is the updated build, sorry it took so long. http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-3-src.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/java-brlapi/java-brlapi-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/libbrlapi/libbrlapi-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/libbrlapi-devel/libbrlapi-devel-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/python-brlapi/python-brlapi-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/tcl-brlapi/tcl-brlapi-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/xbrlapi/xbrlapi-4.2-3.tar.bz2 Samuel
Re: ATTENTION: Tcl/Tk transition
On Sun, 2012-01-08 at 02:57 +0100, Samuel Thibault wrote: Here is the updated build, sorry it took so long. http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-3-src.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/brltty-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/java-brlapi/java-brlapi-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/libbrlapi/libbrlapi-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/libbrlapi-devel/libbrlapi-devel-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/python-brlapi/python-brlapi-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/tcl-brlapi/tcl-brlapi-4.2-3.tar.bz2 http://brl.thefreecat.org/brltty/cygwin/xbrlapi/xbrlapi-4.2-3.tar.bz2 Moved to staging area. Please be sure to update your master copy of tcl-brlapi/setup.hint requires: line as previously indicated; I will fix the copy on sourceware when this is moved in. Yaakov
Re: ATTENTION: Tcl/Tk transition
Still outstanding are: * python[-tkinter] (Jason Tishler) * suite3270 [tcl3270] (Peter A. Castro) In order to provide a seamless transition for users, your packages must be rebuilt for the new Tcl/Tk per my original instructions[1]. Please let us know when you will be able to do this, or if you need any assistance. Jason: I don't want to break Tkinter. Can you make this a priority, please? Peter: If your update is not ready in time, I will have to remove tcl3270 from the distro. Yaakov [1] http://cygwin.com/ml/cygwin-apps/2011-10/msg00083.html
Re: ATTENTION: Tcl/Tk transition
On Mon, Dec 05, 2011 at 01:25:16AM -0500, Charles Wilson wrote: [SNIP] msys-tcl seems ok so far but msys-tcl-tk: it's an unholy mess, really. :-( If Yaakov's packaging works correctly under Cygwin (and I'd be astonished if it didn't) that's all that we care about in Cygwin mailing lists. Discussion of mingw/msys concerns is not appropriate here. cgf
Re: ATTENTION: Tcl/Tk transition
On Sat, 2011-12-03 at 18:45 -0500, Charles Wilson wrote: Yaakov -- the installed tclConfig.sh and tkConfig.sh files include stuff like this: TCL_DEFS='-DPACKAGE_NAME=\tcl\ -DPACKAGE_TARNAME=\tcl\ -DPACKAGE_VERSION=\8.5\ -DPACKAGE_STRING=\tcl\ 8.5\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1 This causes warnings (PACKAGE_NAME redefined, etc) when building other packages. Which packages are you referring to? Yaakov
Re: ATTENTION: Tcl/Tk transition
On 12/4/2011 7:33 PM, Yaakov (Cygwin/X) wrote: On Sat, 2011-12-03 at 18:45 -0500, Charles Wilson wrote: Yaakov -- the installed tclConfig.sh and tkConfig.sh files include stuff like this: TCL_DEFS='-DPACKAGE_NAME=\tcl\ -DPACKAGE_TARNAME=\tcl\ -DPACKAGE_VERSION=\8.5\ -DPACKAGE_STRING=\tcl\ 8.5\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1 This causes warnings (PACKAGE_NAME redefined, etc) when building other packages. Which packages are you referring to? I found this while building (msys) versions of tcl and tk, (loosely) based on your cygports. However...I modified tk's configure.in to do a proper AC_INIT. So now, tk defines PACKAGE_NAME as tk -- but inherits tclConfig's setting of tcl (and etc.). It's possible that because tk doesn't, OOB, use the proper AC_INIT invocation that you don't see this problem with your builds. But...is it really right for tk to self-identify as tcl? Fix that...and then you see the warning. However, it just seems unambiguously correct, to me, that derived packages should NOT inherit tcl's settings of those particular macros. -- Chuck
Re: ATTENTION: Tcl/Tk transition
On Sun, 2011-12-04 at 21:05 -0500, Charles Wilson wrote: I found this while building (msys) versions of tcl and tk, (loosely) based on your cygports. However...I modified tk's configure.in to do a proper AC_INIT. So now, tk defines PACKAGE_NAME as tk -- but inherits tclConfig's setting of tcl (and etc.). Fix that...and then you see the warning. It is win/configure.in which doesn't AC_INIT properly, not unix/configure.in. Try building my tcl-tk and you won't see any such warnings, and PACKAGE_NAME is tk. So it would seem that your fix is incorrect. Yaakov
Re: ATTENTION: Tcl/Tk transition
On 12/4/2011 10:03 PM, Yaakov (Cygwin/X) wrote: On Sun, 2011-12-04 at 21:05 -0500, Charles Wilson wrote: I found this while building (msys) versions of tcl and tk, (loosely) based on your cygports. However...I modified tk's configure.in to do a proper AC_INIT. So now, tk defines PACKAGE_NAME as tk -- but inherits tclConfig's setting of tcl (and etc.). Fix that...and then you see the warning. It is win/configure.in which doesn't AC_INIT properly, not unix/configure.in. D'oh! You're right. Try building my tcl-tk and you won't see any such warnings, and PACKAGE_NAME is tk. So it would seem that your fix is incorrect. But...I'm going to have to figure out WHY you don't see the warnings. How can configure.in/config.status/Makefile-$(DEFS) set PACKAGE_NAME to tk, yet *also* include the DEFS settings sifted from tclConfig.sh which sets PACKAGE_NAME to tcl, and /not/ trigger the a macro redefinition warning? (Don't answer; it just strikes me as odd -- something funny is going on in the unix/ side and I probably ought to figure out what.) Aside: the win/ side of things is /severely/ bitrotted with regards to mingw and cygwin -- I think they only care for MSVC now -- so it's just as well your new cygwin implementations are strictly unix/-only. On the MSYS side I'm trying to hybridize: tcl=unix, tk=winGDI but with proper unixy path handing (which means translations when calling into, and of return values from, w32api functions). It's...slow going. And I wonder -- when I get that far -- whether the additional add-ons (itcl, itk, tix) will be workable at all, with tcl-ish headers under unix/ and tk-ish headers under win/; the TEA tcl.m4 seems to have provisions for such a separation...but will it work? TBD. msys-tcl seems ok so far but msys-tcl-tk: it's an unholy mess, really. :-( -- Chuck
Re: ATTENTION: Tcl/Tk transition
Yaakov -- the installed tclConfig.sh and tkConfig.sh files include stuff like this: TCL_DEFS='-DPACKAGE_NAME=\tcl\ -DPACKAGE_TARNAME=\tcl\ -DPACKAGE_VERSION=\8.5\ -DPACKAGE_STRING=\tcl\ 8.5\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1 This causes warnings (PACKAGE_NAME redefined, etc) when building other packages. Could you update your .cygport(5) to add a line like this: -e '/^TCL_DEFS/s|-DPACKAGE[^=]*=\\\[^]* ||g' \ to the munge the tclConfig.sh section of src_install? (Likewise TK_DEFS etc). -- Chuck
Re: ATTENTION: Tcl/Tk transition
On 10.11.2011 03:37, Yaakov (Cygwin/X) wrote: On Thu, 2011-11-10 at 03:00 +0100, Dr. Volker Zell wrote: What do you mean with arent't versioned ? The package names themselves: I see, a stupid packaging error on my side. tar -tvjf db-4.5.20.2-3/dist/db/libdb/libdb-4.5.20.2-3.tar.bz2 tar -tvjf db-4.8.30-1/dist/db/libdb/libdb-4.8.30-1.tar.bz2 The libdb packages must be libdb4.5 and libdb4.8. As for the -devel packages, perhaps we only need the latest one? tar -tvjf db-4.5.20.2-3/dist/db/tcl-db/tcl-db-4.5.20.2-3.tar.bz2 tar -tvjf db-4.8.30-1/dist/db/tcl-db/tcl-db-4.8.30-1.tar.bz2 If we need only one version of the Tcl bindings, fine (and it should come from 4.8), otherwise these need to be tcl-db4.5 and tcl-db4.8. Both are now versioned. Ciao Volker
Re: ATTENTION: Tcl/Tk transition
On Tue, 2011-11-08 at 02:18 +0100, Dr. Volker Zell wrote: I obsoleted the following packages: db-2.7.7 db-3.1.17 db-3.3.11.2 db-4.0.14 db-4.1.25.3 db-4.2.52.5 db-4.3.29.1 db-4.4.20.4 IMO there is no reason to keep these old versions, as nothing in the distro depends on them. So if there are no objections, we can just outright remove them, and use _obsolete packages only for tcl-db*.*. did a rebuild of db-4.5.20.2 and added db-4.8.30 Something is wrong with these packages; the libdb* and tcl-db* packages aren't versioned. (BTW, I think the tcl-db4.5 should also be an _obsolete package, pointing to tcl-db4.8.) 5.x will follow later when the dust settles. That will be helpful. * ming [tcl-ming] (Dr. Volker Zell) new requires: tcl notes: needs a pkgIndex.tcl file to be of any use Done. It has now a pkgIndex.tcl file. * WordNet (Dr. Volker Zell) new requires: tcl tcl-tk notes: needs patches for security vulnerabilities, patches available from all major distros, e.g.: http://pkgs.fedoraproject.org/gitweb/?p=wordnet.git;a=tree Done, with all the paches and security fixes. These look good. You will find the packages under /home/vzell on sourceware. Just copy (scp -r) them over when everybody is ready. Thank you for your prompt attention to this. Since space on /home is tight, I have copied the ming and WordNet into a staging area until we're ready for the move. Thanks, Yaakov Cygwin/X
Re: ATTENTION: Tcl/Tk transition
On 10.11.2011 00:51, Yaakov (Cygwin/X) wrote: On Tue, 2011-11-08 at 02:18 +0100, Dr. Volker Zell wrote: I obsoleted the following packages: db-2.7.7 db-3.1.17 db-3.3.11.2 db-4.0.14 db-4.1.25.3 db-4.2.52.5 db-4.3.29.1 db-4.4.20.4 IMO there is no reason to keep these old versions, as nothing in the distro depends on them. So if there are no objections, we can just outright remove them, and use _obsolete packages only for tcl-db*.*. did a rebuild of db-4.5.20.2 and added db-4.8.30 Something is wrong with these packages; the libdb* and tcl-db* packages aren't versioned. (BTW, I think the tcl-db4.5 should also be an _obsolete package, pointing to tcl-db4.8.) What do you mean with arent't versioned ? tar -tvjf db-4.5.20.2-3/dist/db/tcl-db/tcl-db-4.5.20.2-3.tar.bz2 usr/lib/tcl8.5/ usr/lib/tcl8.5/db4.5/ usr/lib/tcl8.5/db4.5/cygdb_tcl-4.5.dll usr/lib/tcl8.5/db4.5/pkgIndex.tcl tar -tvjf db-4.5.20.2-3/dist/db/libdb/libdb-4.5.20.2-3.tar.bz2 usr/bin/cygdb-4.5.dll usr/bin/cygdb_cxx-4.5.dll tar -tvjf db-4.8.30-1/dist/db/tcl-db/tcl-db-4.8.30-1.tar.bz2 usr/lib/tcl8.5/ usr/lib/tcl8.5/db4.8/ usr/lib/tcl8.5/db4.8/cygdb_tcl-4.8.dll usr/lib/tcl8.5/db4.8/pkgIndex.tcl tar -tvjf db-4.8.30-1/dist/db/libdb/libdb-4.8.30-1.tar.bz2 usr/bin/cygdb-4.8.dll usr/bin/cygdb_cxx-4.8.dll Ciao Volker
Re: ATTENTION: Tcl/Tk transition
On Thu, 2011-11-10 at 03:00 +0100, Dr. Volker Zell wrote: What do you mean with arent't versioned ? The package names themselves: tar -tvjf db-4.5.20.2-3/dist/db/libdb/libdb-4.5.20.2-3.tar.bz2 tar -tvjf db-4.8.30-1/dist/db/libdb/libdb-4.8.30-1.tar.bz2 The libdb packages must be libdb4.5 and libdb4.8. As for the -devel packages, perhaps we only need the latest one? tar -tvjf db-4.5.20.2-3/dist/db/tcl-db/tcl-db-4.5.20.2-3.tar.bz2 tar -tvjf db-4.8.30-1/dist/db/tcl-db/tcl-db-4.8.30-1.tar.bz2 If we need only one version of the Tcl bindings, fine (and it should come from 4.8), otherwise these need to be tcl-db4.5 and tcl-db4.8. Yaakov
Re: ATTENTION: Tcl/Tk transition
On 26.10.2011 23:02, Yaakov (Cygwin/X) wrote: cgf has asked me to take over tcl/tk/expect maintainership and transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5 currently in Ports. The following packages will need an IMMEDIATE rebuild: * db [tcl-dbX.Y] (Dr. Volker Zell) new requires: tcl notes: perhaps you should just build the latest db 4.x and/or 5.x with this tcl and we can drop the earlier bindings? Done. I obsoleted the following packages: db-2.7.7 db-3.1.17 db-3.3.11.2 db-4.0.14 db-4.1.25.3 db-4.2.52.5 db-4.3.29.1 db-4.4.20.4 did a rebuild of db-4.5.20.2 and added db-4.8.30 5.x will follow later when the dust settles. * ming [tcl-ming] (Dr. Volker Zell) new requires: tcl notes: needs a pkgIndex.tcl file to be of any use Done. It has now a pkgIndex.tcl file. * WordNet (Dr. Volker Zell) new requires: tcl tcl-tk notes: needs patches for security vulnerabilities, patches available from all major distros, e.g.: http://pkgs.fedoraproject.org/gitweb/?p=wordnet.git;a=tree Done, with all the paches and security fixes. You will find the packages under /home/vzell on sourceware. Just copy (scp -r) them over when everybody is ready. Thanks Volker
Re: ATTENTION: Tcl/Tk transition
On 10/30/2011 8:44 PM, Yaakov (Cygwin/X) wrote: Please don't. ... This is just the beginning. Mixing GDI and X11 just doesn't work, and since X11 is used for all other GUIs on Cygwin, so must Tk. My suggestion, for those who wanted this, was to build the entire tcl/tk(GDI) stack with a unique prefix -- that way it wouldn't BE mixed with the other clients which (will soon be) compiled to use the X11 version. And, to even use it at all, one would have to put it in the PATH ahead of /usr/bin. That's surely not standard; and if somebody does this and it breaks something -- then they get to keep both pieces. WJM, after all. -- Chuck
Re: ATTENTION: Tcl/Tk transition
On 10/31/2011 7:39 PM, Charles Wilson wrote: On 10/30/2011 8:44 PM, Yaakov (Cygwin/X) wrote: Please don't. ... This is just the beginning. Mixing GDI and X11 just doesn't work, and since X11 is used for all other GUIs on Cygwin, so must Tk. My suggestion, for those who wanted this, was to build the entire tcl/tk(GDI) stack with a unique prefix -- that way it wouldn't BE mixed with the other clients which (will soon be) compiled to use the X11 version. And, to even use it at all, one would have to put it in the PATH ahead of /usr/bin. That's surely not standard; and if somebody does this and it breaks something -- then they get to keep both pieces. WJM, after all. In case it wasn't clear, my suggestion was that if somebody did this, it should be hosted by a a third-party repository (similar to how cygwin-ports is structured), and not part of the actual cygwin distribution. -- Chuck
Re: ATTENTION: Tcl/Tk transition
On Sun, 2011-10-30 at 00:53 -0400, Christopher Faylor wrote: On Sat, Oct 29, 2011 at 06:31:59PM -0500, Reini Urban wrote: On Wed, Oct 26, 2011 at 5:33 PM, Charles Wilson wrote: in the gitk thread above, Reini Urban, the cygwin perl and parrot maintainer, was vehemently against switching tcltk from GDI to X11. ?I wonder if his opinion has changed in the past year... No, I'm still against it, but in minority. I tried to fix it, but ran out of time. Maybe later I can come up with a tk/tcl-native. I don't see why you need a tcl-native but it should be possible to use the Windows version of tk to do Windows-native GUI stuff without relying on X11. The trick is getting that + Cygwin paths, signals, etc. to play together. Please don't. The problem with a GDI Tk is not only getting it to work properly, but how it interoperates with other (X11) GUI software. Some examples from Ports: * Pidgin (a GTK2/X11 app) has a Tcl scripting plugin which also uses Tk. Mixing an X11 app with a GDI plugin is a sure recipe for disaster. * PyOpenGL is used by several Python libraries, such as PyGame, PyGtkGLExt, and wxPython, all of which are X11-based. But PyOpenGL includes a Tkinter/Togl interface as well. If Tk is GDI-based, then so will Tkinter have to be, but PyOpenGL can't bind both GLX and WGL at the same time. This is just the beginning. Mixing GDI and X11 just doesn't work, and since X11 is used for all other GUIs on Cygwin, so must Tk. Yaakov
Re: ATTENTION: Tcl/Tk transition
On Wed, Oct 26, 2011 at 5:33 PM, Charles Wilson wrote: Here are some of the previous discussions: Interest in native Tcl/Tk/Expect/Itcl/... packages? http://cygwin.com/ml/cygwin-apps/2004-10/msg00316.html Does anyone use insight on cygwin? http://www.cygwin.com/ml/cygwin/2008-08/msg00089.html tcl/tk/expect/dejagnu/gdb/insight http://cygwin.com/ml/cygwin/2009-09/msg00311.html gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app. http://cygwin.com/ml/cygwin/2010-08/msg00913.html NOTE in the gitk thread above, Reini Urban, the cygwin perl and parrot maintainer, was vehemently against switching tcltk from GDI to X11. I wonder if his opinion has changed in the past year... No, I'm still against it, but in minority. I tried to fix it, but ran out of time. Maybe later I can come up with a tk/tcl-native. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: ATTENTION: Tcl/Tk transition
On Sat, Oct 29, 2011 at 06:31:59PM -0500, Reini Urban wrote: On Wed, Oct 26, 2011 at 5:33 PM, Charles Wilson wrote: Here are some of the previous discussions: Interest in native Tcl/Tk/Expect/Itcl/... packages? http://cygwin.com/ml/cygwin-apps/2004-10/msg00316.html Does anyone use insight on cygwin? http://www.cygwin.com/ml/cygwin/2008-08/msg00089.html tcl/tk/expect/dejagnu/gdb/insight http://cygwin.com/ml/cygwin/2009-09/msg00311.html gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app. http://cygwin.com/ml/cygwin/2010-08/msg00913.html NOTE in the gitk thread above, Reini Urban, the cygwin perl and parrot maintainer, was vehemently against switching tcltk from GDI to X11. ?I wonder if his opinion has changed in the past year... No, I'm still against it, but in minority. I tried to fix it, but ran out of time. Maybe later I can come up with a tk/tcl-native. I don't see why you need a tcl-native but it should be possible to use the Windows version of tk to do Windows-native GUI stuff without relying on X11. The trick is getting that + Cygwin paths, signals, etc. to play together. cgf
Re: ATTENTION: Tcl/Tk transition
On Oct 27 23:54, Christopher Faylor wrote: On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote: On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote: Cool, thanks! You don't want to take over ruby maintainership as well, do you? :} Would your adding getgrouplist(3) be a fair price? :-) http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html I need this for an attempt to port polkit-1, and I haven't learned that part of the codebase yet. Deal? :-) Deal! I can add that tomorrow if the morning shift doesn't beat me to it. The morning shift will have a look, but here's a question, Yaakov. I assume you want the full group list, represented by the user's token if one would like to construct the token, right? If so, that requires to create a SID list by fetching the information from the local SAM and AD, quite similar to the initgroups function. On second thought, that would be practically identical to our initgroups32 function, except for the cygheap-user.groups.update_supp call, which would be replaced by filling the group list given as argument. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ATTENTION: Tcl/Tk transition
On Fri, 2011-10-28 at 09:56 +0200, Corinna Vinschen wrote: On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote: On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote: Cool, thanks! You don't want to take over ruby maintainership as well, do you? :} Would your adding getgrouplist(3) be a fair price? :-) http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html I need this for an attempt to port polkit-1, and I haven't learned that part of the codebase yet. Deal? :-) Deal! Done. ruby-1.8.7-p352 with separate ruby-tcltk package is ready. I assume you want the full group list, represented by the user's token if one would like to construct the token, right? See the spec noted above, but if ngroups is correctly sized, all groups to which the given user belongs are returned AND the given group even if the user is not a member thereof. If so, that requires to create a SID list by fetching the information from the local SAM and AD, quite similar to the initgroups function. On second thought, that would be practically identical to our initgroups32 function, except for the cygheap-user.groups.update_supp call, which would be replaced by filling the group list given as argument. That makes sense, given that on BSD[1], initgroups(3) is basically getgrouplist() followed by setgroups(). The primary difference will be adding the given group if not a member and assuring proper size of ngroups. (Yes, I did look into this myself once upon a time.) Yaakov [1] http://svnweb.FreeBSD.org/base/head/lib/libc/gen/initgroups.c?view=markup
Re: ATTENTION: Tcl/Tk transition
On Oct 28 03:20, Yaakov (Cygwin/X) wrote: On Fri, 2011-10-28 at 09:56 +0200, Corinna Vinschen wrote: On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote: On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote: Cool, thanks! You don't want to take over ruby maintainership as well, do you? :} Would your adding getgrouplist(3) be a fair price? :-) http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html I need this for an attempt to port polkit-1, and I haven't learned that part of the codebase yet. Deal? :-) Deal! Done. ruby-1.8.7-p352 with separate ruby-tcltk package is ready. Cool, thanks! I assume you want the full group list, represented by the user's token if one would like to construct the token, right? See the spec noted above, but if ngroups is correctly sized, all groups to which the given user belongs are returned AND the given group even if the user is not a member thereof. Uh, maybe I wasn't clear. I didn't talk about Linux or so, I was just refering to two possible implementations on Cygwin, one looking into /etc/groups only, the other fetching the information from the OS. But that was YA ENOCOFFEE question since I gave up on using the supplemetary groups from /etc/group anyway. Only what the OS allows should count. If so, that requires to create a SID list by fetching the information from the local SAM and AD, quite similar to the initgroups function. On second thought, that would be practically identical to our initgroups32 function, except for the cygheap-user.groups.update_supp call, which would be replaced by filling the group list given as argument. That makes sense, given that on BSD[1], initgroups(3) is basically getgrouplist() followed by setgroups(). The primary difference will be adding the given group if not a member and assuring proper size of ngroups. (Yes, I did look into this myself once upon a time.) Yup, I'm comparing the implementations of glibc and FreeBSD right now. The Linux getgrouplist man page doesn't tell anything of the handling of NULL pointers, so I had to use the source to see how they handle this. FreeBSD asserts, GLibc just crashes. FreeBSD also allows a NULL group pointer if *ngroups is 0. I like FreeBSD better here, so I'll do the same. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ATTENTION: Tcl/Tk transition
On Oct 28 10:48, Corinna Vinschen wrote:
On Oct 28 03:20, Yaakov (Cygwin/X) wrote:
On Fri, 2011-10-28 at 09:56 +0200, Corinna Vinschen wrote:
On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote:
On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote:
Cool, thanks! You don't want to take over ruby maintainership as
well,
do you? :}
Would your adding getgrouplist(3) be a fair price? :-)
http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html
I need this for an attempt to port polkit-1, and I haven't learned that
part of the codebase yet. Deal? :-)
Deal!
Done. ruby-1.8.7-p352 with separate ruby-tcltk package is ready.
Cool, thanks!
I assume you want the full group list, represented by the user's token
if one would like to construct the token, right?
See the spec noted above, but if ngroups is correctly sized, all
groups to which the given user belongs are returned AND the given group
even if the user is not a member thereof.
Uh, maybe I wasn't clear. I didn't talk about Linux or so, I was
just refering to two possible implementations on Cygwin, one looking
into /etc/groups only, the other fetching the information from the OS.
But that was YA ENOCOFFEE question since I gave up on using the
supplemetary groups from /etc/group anyway. Only what the OS allows
should count.
If so, that requires to create a SID list by fetching the information
from the local SAM and AD, quite similar to the initgroups function.
On second thought, that would be practically identical to our
initgroups32 function, except for the cygheap-user.groups.update_supp
call, which would be replaced by filling the group list given as
argument.
That makes sense, given that on BSD[1], initgroups(3) is basically
getgrouplist() followed by setgroups(). The primary difference will be
adding the given group if not a member and assuring proper size of
ngroups. (Yes, I did look into this myself once upon a time.)
Yup, I'm comparing the implementations of glibc and FreeBSD right
now. The Linux getgrouplist man page doesn't tell anything of
the handling of NULL pointers, so I had to use the source to see
how they handle this. FreeBSD asserts, GLibc just crashes. FreeBSD
also allows a NULL group pointer if *ngroups is 0. I like FreeBSD
better here, so I'll do the same.
Done. Please give it a try. I used this STC for testing:
$ cat ggl.c EOF
#include stdio.h
#include grp.h
int
main (int argc, char **argv)
{
int ret, ngroups;
gid_t groups[256];
ngroups = 0;
ret = getgrouplist (argv[1], 2, NULL, ngroups);
printf (ret = %d, ngroups = %d\n, ret, ngroups);
ngroups = 1;
ret = getgrouplist (argv[1], 2, NULL, ngroups);
printf (ret = %d, ngroups = %d\n, ret, ngroups);
ngroups = 1;
ret = getgrouplist (argv[1], 2, groups, ngroups);
printf (ret = %d, ngroups = %d\n, ret, ngroups);
ngroups = 256;
ret = getgrouplist (argv[1], 2, groups, ngroups);
printf (ret = %d, ngroups = %d\n, ret, ngroups);
for (ret = 0; ret ngroups; ++ret)
printf ( %d%s, groups[ret], ret ngroups - 1 ? , : \n);
ret = getgrouplist (argv[1], 2, groups, NULL);
printf (ret = %d, ngroups = %d\n, ret, ngroups);
return 0;
}
EOF
The last getgrouplist call should always abort due to an assertion.
The first call should abort if you don't give an argument. The group
2 is an arbitrary group in my /etc/group file which exists, but
which no user is a member of.
Please note that getgrouplist does not always add the gid to the
group list in my implementation. The requirement is that it must
exist in /etc/groups. There's no good reason to add a group to
the group list if the group isn't backed by a OS SID.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: ATTENTION: Tcl/Tk transition
On Oct 26 19:42, Yaakov (Cygwin/X) wrote: On Wed, 2011-10-26 at 16:02 -0500, Yaakov (Cygwin/X) wrote: * ruby (Corinna Vinschen) new requires: tcl tcl-tk notes: I suggest making a make separate ruby-tcltk package due to the additional deps. Patches for 1.8.7-p352 attached. Cool, thanks! You don't want to take over ruby maintainership as well, do you? :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ATTENTION: Tcl/Tk transition
On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote: On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote: Cool, thanks! You don't want to take over ruby maintainership as well, do you? :} Would your adding getgrouplist(3) be a fair price? :-) http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html I need this for an attempt to port polkit-1, and I haven't learned that part of the codebase yet. Deal? :-) I can add that tomorrow if the morning shift doesn't beat me to it. cgf
ATTENTION: Tcl/Tk transition
cgf has asked me to take over tcl/tk/expect maintainership and
transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5
currently in Ports.
ITA:
expect
tcltk (to be obsoleted)
ITP (in place of tcltk):
tcl
tcl-itcl
tcl-itk
tcl-iwidgets
tcl-tix
tcl-tk
(I have more extensions in Ports if anyone needs them.)
The packages are currently available in Ports here:
ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Tcl/
For the purpose of a smooth upgrade, affected maintainers should run the
following commands before rebuilding:
# cygcheck -l tcltk | d2u | xargs rm -f
# tar jxf tcl-8.5.10-1.tar.bz2 -C /
# tar jxf tcl-tk-8.5.10-1.tar.bz2 -C /
Once rebuilt, please respond to this email with an RFU, and I'll upload
once enough is in place to avoid breaking the distro.
The following packages will need an IMMEDIATE rebuild:
* db [tcl-dbX.Y] (Dr. Volker Zell)
new requires: tcl
notes: perhaps you should just build the latest db 4.x and/or 5.x with
this tcl and we can drop the earlier bindings?
* ming [tcl-ming] (Dr. Volker Zell)
new requires: tcl
notes: needs a pkgIndex.tcl file to be of any use
* python[-tkinter] (Jason Tishler)
new requires: tcl tcl-tk tcl-tix
notes: requires attached patch
* ruby (Corinna Vinschen)
new requires: tcl tcl-tk
notes: I suggest making a make separate ruby-tcltk package due to the
additional deps.
* suite3270 [tcl3270] (Peter A. Castro)
new requires: tcl
* WordNet (Dr. Volker Zell)
new requires: tcl tcl-tk
notes: needs patches for security vulnerabilities, patches available
from all major distros, e.g.:
http://pkgs.fedoraproject.org/gitweb/?p=wordnet.git;a=tree
The following packages do NOT require an immediate rebuild, so I'll just
change their requires on sourceware accordingly:
* catdoc (Reini Urban)
new requires: tcl tcl-tk
* gdb (cgf)
Version 7.x no longer requires tcltk.
* git [gitg/git-gui] (Eric Blake)
new requires: tcl tcl-tk
notes: need to ditch the cygpath line with the next release
Yaakov
Cygwin/X
--- origsrc/Python-2.5.2/setup.py 2008-02-04 17:41:02.0 -0600
+++ src/Python-2.5.2/setup.py 2008-07-02 02:11:28.671875000 -0500
@@ -1277,12 +1279,6 @@
include_dirs.append('/usr/X11/include')
added_lib_dirs.append('/usr/X11/lib')
-# If Cygwin, then verify that X is installed before proceeding
-if platform == 'cygwin':
-x11_inc = find_file('X11/Xlib.h', [], include_dirs)
-if x11_inc is None:
-return
-
# Check for BLT extension
if self.compiler.find_library_file(lib_dirs + added_lib_dirs,
'BLT8.0'):
@@ -1300,9 +1296,8 @@
if platform in ['aix3', 'aix4']:
libs.append('ld')
-# Finally, link with the X11 libraries (not appropriate on cygwin)
-if platform != cygwin:
-libs.append('X11')
+# Finally, link with the X11 libraries
+libs.append('X11')
ext = Extension('_tkinter', ['_tkinter.c', 'tkappinit.c'],
define_macros=[('WITH_APPINIT', 1)] + defs,
Re: ATTENTION: Tcl/Tk transition
On Wed, 2011-10-26 at 16:02 -0500, Yaakov (Cygwin/X) wrote: The following packages will need an IMMEDIATE rebuild: Oops, I missed one: * brltty [tcl-brlapi] (Samuel Thibault) new requires: tcl Yaakov
Re: ATTENTION: Tcl/Tk transition
On 10/26/2011 11:06 PM, Yaakov (Cygwin/X) wrote: On Wed, 2011-10-26 at 16:02 -0500, Yaakov (Cygwin/X) wrote: The following packages will need an IMMEDIATE rebuild: Oops, I missed one: * brltty [tcl-brlapi] (Samuel Thibault) new requires: tcl Yaakov stupid question: should not be easier for testing the new packages and upgrading the other ones that you put them in the distro as experimental ? I know that the maintainers you mentioned have no problems but eventually there are other people that need to test them in advance. Regards Marco
Re: ATTENTION: Tcl/Tk transition
On 10/26/2011 11:24 PM, Marco Atzeri wrote: stupid question: should not be easier for testing the new packages and upgrading the other ones that you put them in the distro as experimental ? I know that the maintainers you mentioned have no problems but eventually there are other people that need to test them in advance. Regards Marco it is a stupid question, setup will install in any case also the old packages so a crash is assured... Regards Marco
Re: ATTENTION: Tcl/Tk transition
Yaakov, If I'm understanding this correctly once this change has been pushed we will be required to start an X server beforerunning gitk. As someone who uses git and gitk all the time having to start the X server to run gitk is a pain. I haven't checked this recently, but in the past the X server was a bit of a resource hog so my typical pattern is toonly start it when needed and that's not very often. I understand the desire to switch to X, but I think this deserves some thought on how it will effect the general users. Cary - Original Message - From: Yaakov (Cygwin/X) Subject: ATTENTION: Tcl/Tk transition cgf has asked me to take over tcl/tk/expect maintainership and transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5 currently in Ports. SNIP * git [gitg/git-gui] (Eric Blake) new requires: tcl tcl-tk notes: need to ditch the cygpath line with the next release Yaakov Cygwin/X
Re: ATTENTION: Tcl/Tk transition
On Wed, Oct 26, 2011 at 02:53:48PM -0700, Cary R. wrote: Yaakov, If I'm understanding this correctly once this change has been pushed we will be required to start an X server beforerunning gitk. As someone who uses git and gitk all the time having to start the X server to run gitk is a pain. I haven't checked this recently, but in the past the X server was a bit of a resource hog so my typical pattern is toonly start it when needed and that's not very often. I understand the desire to switch to X, but I think this deserves some thought on how it will effect the general users. We made the decision to switch to a real X-based tk long ago. The hacked version has always been barely supported and is very out of date. Continuing to support it would require real understanding of tk and I don't think anyone wants to take on that task, unless you're volunteering. cgf
Re: ATTENTION: Tcl/Tk transition
On 10/26/2011 5:53 PM, Cary R. wrote: If I'm understanding this correctly once this change has been pushed we will be required to start an X server beforerunning gitk. Yes. As someone who uses git and gitk all the time having to start the X server to run gitk is a pain. I haven't checked this recently, but in the past the X server was a bit of a resource hog so my typical pattern is toonly start it when needed and that's not very often. Well, the cygwin-X folks have made a lot of improvements over the past year or so (and the accelerated version looks to be coming along...). However, because XWin.exe /is/ a cygwin app, it suffers all the normal posix-win32 emulation penalties that every cygwin app does. So, one solution is to just use the native win32 XMing xserver (free-as-in-beer version, or the donation-supported one). tk only depends on libX11.dll (no other X extensions), so on the client side tk is fairly light in its X-incarnation. Also, here's the cygwin-git maintainer from three years ago: http://www.cygwin.com/ml/cygwin/2008-08/msg00095.html Eric Blake wrote: According to Christopher Faylor on 8/4/2008 5:38 PM: | That opens the door to building a | real version of tcl/tk for cygwin and linking insight to it. YEAH! Among others, the git package would appreciate the availability of a modern tcl/tk. So... I understand the desire to switch to X, but I think this deserves some thought on how it will effect the general users. Well, I think it *has* been thought about, and discussed, quite a bit. The decision was pretty much adopted -- only the implementation has been delayed due to (a) lack of roundtuits of the 'cgf' denomination, (b) in the far past, we had no /modern/ (7.x) X implementation and were limping along with a very old X distro. Obviously, until (b) was fixed, it made no sense to modify tcltk. And until (a) improved -- which, apparently, it never did -- the implementation couldn't happen. Hence, cgf's decision to invite Yaakov to take over. Here are some of the previous discussions: Interest in native Tcl/Tk/Expect/Itcl/... packages? http://cygwin.com/ml/cygwin-apps/2004-10/msg00316.html Does anyone use insight on cygwin? http://www.cygwin.com/ml/cygwin/2008-08/msg00089.html tcl/tk/expect/dejagnu/gdb/insight http://cygwin.com/ml/cygwin/2009-09/msg00311.html gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app. http://cygwin.com/ml/cygwin/2010-08/msg00913.html NOTE in the gitk thread above, Reini Urban, the cygwin perl and parrot maintainer, was vehemently against switching tcltk from GDI to X11. I wonder if his opinion has changed in the past year... Tcl file separator http://cygwin.com/ml/cygwin/2011-01/msg00257.html (esp. http://cygwin.com/ml/cygwin/2011-01/msg00369.html) Re: RFC: Cygwin 64 bit? http://cygwin.com/ml/cygwin-developers/2011-06/msg00081.html -- Chuck
Re: ATTENTION: Tcl/Tk transition
I already spend most of my free time working on an open source Verilog simulator, so unfortunately, no, I'm not goingto volunteer. I understand the reason for switching,but be prepared for some serious user complaintsonce this is implemented. I don't normally have time to read the general cygwin list, but if you haven't done so already I will strongly suggest starting a thread there that discusses this changeand its ramifications. To me the ramifications are the most important for the general users. I'm sure the developers have discussed this in great detail and I vaguely remember discussions about this in the past,but I'mguessing the normal users will be quite surprised bythis change. I can adapt and Linux inside VirtualBox has softened my usage of cygwin already. gitk requiring an X server maypush me a bit further in that direction. Cary - Original Message - cfg wrote Subject: Re: ATTENTION: Tcl/Tk transition On Wed, Oct 26, 2011 at 02:53:48PM -0700, Cary R. wrote: Yaakov, If I'm understanding this correctly once this change has been pushed we will be required to start an X server beforerunning gitk. As someone who uses git and gitk all the time having to start the X server to run gitk is a pain. I haven't checked this recently, but in the past the X server was a bit of a resource hog so my typical pattern is toonly start it when needed and that's not very often. I understand the desire to switch to X, but I think this deserves some thought on how it will effect the general users. We made the decision to switch to a real X-based tk long ago. The hacked version has always been barely supported and is very out of date. Continuing to support it would require real understanding of tk and I don't think anyone wants to take on that task, unless you're volunteering. cgf
Re: ATTENTION: Tcl/Tk transition
On Wed, Oct 26, 2011 at 03:59:18PM -0700, Cary R. wrote: I already spend most of my free time working on an open source Verilog simulator, so unfortunately, no, I'm not going to volunteer. I understand the reason for switching, but be prepared for some serious user complaints once this is implemented. I've been with the Cygwin project for more than a decade. I know what to (excuse the expression) expect. And, I'm sure that Yaakov who has also been around for a while and maintains scores of important packages is also quite aware that people will be surprised by any major change, even ones that are preannounced. You don't have the inclination to work on supporting tk-on-windows-with-a-side-of-cygwin. Neither does anyone else. Keeping tcl/tk in the dark ages and potentially causing problems for programs like expect and gitk is a sure recipe for complaints since programs are drifting further and further from optimal configurations. In fact, this whole thread is prompted by a complaint/request in the cygwin list. I don't normally have time to read the general cygwin list, but if you haven't done so already I will strongly suggest starting a thread there that discusses this changeand its ramifications. To me the ramifications are the most important for the general users. I'm sure the developers have discussed this in great detail and I vaguely remember discussions about this in the past, but I'm guessing the normal users will be quite surprised bythis change. I can adapt and Linux inside VirtualBox has softened my usage of cygwin already. gitk requiring an X server may push me a bit further in that direction. If you feel the need to raise the alarm to the Cygwin list, please go ahead. It's hard for me to see what you're expecting, though. You don't want things to change but you don't seem to be proposing any solutions other than, presumably, don't update anything. If you think that running VirtualBox is really an alternative to just starting X then that's definitely something you should pursue even if it's hard to see how that jives with your concern that the X server was a bit of a resource hog. cgf
Re: ATTENTION: Tcl/Tk transition
On Wed, 2011-10-26 at 16:02 -0500, Yaakov (Cygwin/X) wrote:
* ruby (Corinna Vinschen)
new requires: tcl tcl-tk
notes: I suggest making a make separate ruby-tcltk package due to the
additional deps.
Patches for 1.8.7-p352 attached.
Yaakov
libuuid from util-linux hides the w32api libuuid.a, which serves a
completely different purpose.
--- origsrc/ruby-1.8.7-p352/ext/win32ole/extconf.rb 2010-11-22 01:22:26.0 -0600
+++ src/ruby-1.8.7-p352/ext/win32ole/extconf.rb 2011-10-26 19:21:29.696817700 -0500
@@ -35,5 +35,7 @@ end
case RUBY_PLATFORM
when /mswin32/
$CFLAGS += ' /W3'
+when /cygwin/
+ $LDFLAGS += ' -L/usr/lib/w32api'
end
create_win32ole_makefile
--- origsrc/ruby-1.8.7-p352/ext/tk/extconf.rb 2011-06-29 22:53:30.0 -0500
+++ src/ruby-1.8.7-p352/ext/tk/extconf.rb 2011-10-26 19:07:48.530860500 -0500
@@ -106,7 +106,7 @@ end
# fuctions
##
def is_win32?
- /mswin|mingw|cygwin|bccwin/ =~ RUBY_PLATFORM
+ /mswin|mingw|bccwin/ =~ RUBY_PLATFORM
end
def is_macosx?
@@ -1762,7 +1762,6 @@ unless is_win32?
print(\n) # progress
end
$CPPFLAGS ||=
-$CPPFLAGS += ' -D_WIN32' if /cygwin/ =~ RUBY_PLATFORM
# Does ruby have nativethread ?
TkLib_Config[ruby_with_thread] =
_longjmp now returns void, but they don't need to be prototyped here.
--- origsrc/ruby-1.8.7-p72/eval.c 2008-08-03 22:24:26.0 -0500
+++ src/ruby-1.8.7-p72/eval.c 2009-03-17 22:31:22.248727500 -0500
@@ -196,9 +196,6 @@ static int volatile freebsd_clear_carry_
# define ruby_setjmp(just_before_setjmp, env) \
((just_before_setjmp), RUBY_SETJMP(env))
# define ruby_longjmp(env,val) RUBY_LONGJMP(env,val)
-# ifdef __CYGWIN__
-int _setjmp(), _longjmp();
-# endif
#endif
#include sys/types.h
--- origsrc/ruby-1.8.7-p72/file.c 2008-07-10 04:47:31.0 -0500
+++ src/ruby-1.8.7-p72/file.c 2009-03-17 22:51:40.295602500 -0500
@@ -2758,7 +2758,7 @@ file_expand_path(fname, dname, result)
is_symlink = 1;
*p = '\0';
}
- if (cygwin_conv_to_win32_path((*buf ? buf : /), w32buf) == 0) {
+ if (cygwin_conv_path(CCP_POSIX_TO_WIN_A, (*buf ? buf : /), w32buf, MAXPATHLEN) == 0) {
b = w32buf;
}
if (is_symlink b == w32buf) {
--- origsrc/ruby-1.8.7-p72/gc.c 2008-08-03 22:24:26.0 -0500
+++ src/ruby-1.8.7-p72/gc.c 2009-03-17 22:52:17.420602500 -0500
@@ -39,9 +39,6 @@ void rb_io_fptr_finalize _((struct rb_io
#define rb_setjmp(env) RUBY_SETJMP(env)
#define rb_jmp_buf rb_jmpbuf_t
-#ifdef __CYGWIN__
-int _setjmp(), _longjmp();
-#endif
/* Make alloca work the best possible way. */
#ifdef __GNUC__
Re: ATTENTION: Tcl/Tk transition
And I've been using Cygwin for over a decade. While I'm at it thanks to all for making life bearable on a windows machine! FYI expect is what drew me to Tcl/Tk a very long time ago. Trust that I understand the need to be using a more modern version of Tcl/Tk. I'm just whining that we're going to loose the GDI support. Since I'm not going to do anything to help the situation thisis the last I'll post on the subject. I did some quick testing and yes the new X server is much better. All my prejudices came from Cygwin 1.5 days on a slower laptop. The combination of a newer laptop and Cygwin 1.7/newer X server makes a significant difference. The benefit I get from using VirtualBox for development is that with Cygwinour test suite takes 818 second andwith Linuxinside VirtualBox it takes 45 seconds. As you can see itdoesn'ttake too many test cycles to result in a significanttimesavings and yes this is the same version of the codeon the same machine with all the other processes idle. For me the resource cost of Virtual Box is 1G of memory and a 30-45 second startup/shutdown times. Depending on what I'm doing and how long I'm going to be doing it this is acceptable given the smaller testing times. Don't construe any of this as a slam on Cygwin. I still think it is a great setup! Cary (who understands and appreciates all that goes into working on free software) - Original Message - From: Christopher Faylor Sent: Wednesday, October 26, 2011 4:34 PM Subject: Re: ATTENTION: Tcl/Tk transition On Wed, Oct 26, 2011 at 03:59:18PM -0700, Cary R. wrote: I already spend most of my free time working on an open source Verilog simulator, so unfortunately, no, I'm not going to volunteer. I understand the reason for switching, but be prepared for some serious user complaints once this is implemented. I've been with the Cygwin project for more than a decade. I know what to (excuse the expression) expect. And, I'm sure that Yaakov who has also been around for a while and maintains scores of important packages is also quite aware that people will be surprised by any major change, even ones that are preannounced. You don't have the inclination to work on supporting tk-on-windows-with-a-side-of-cygwin. Neither does anyone else. Keeping tcl/tk in the dark ages and potentially causing problems for programs like expect and gitk is a sure recipe for complaints since programs are drifting further and further from optimal configurations. In fact, this whole thread is prompted by a complaint/request in the cygwin list. I don't normally have time to read the general cygwin list, but if you haven't done so already I will strongly suggest starting a thread there that discusses this changeand its ramifications. To me the ramifications are the most important for the general users. I'm sure the developers have discussed this in great detail and I vaguely remember discussions about this in the past, but I'm guessing the normal users will be quite surprised bythis change. I can adapt and Linux inside VirtualBox has softened my usage of cygwin already. gitk requiring an X server may push me a bit further in that direction. If you feel the need to raise the alarm to the Cygwin list, please go ahead. It's hard for me to see what you're expecting, though. You don't want things to change but you don't seem to be proposing any solutions other than, presumably, don't update anything. If you think that running VirtualBox is really an alternative to just starting X then that's definitely something you should pursue even if it's hard to see how that jives with your concern that the X server was a bit of a resource hog. cgf
Re: ATTENTION: Tcl/Tk transition
On 26/10/2011 22:02, Yaakov (Cygwin/X) wrote: cgf has asked me to take over tcl/tk/expect maintainership and transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5 currently in Ports. To anyone feeling apprehensive, I've been using the 'ports versions of tcl and expect for a long time now to test GCC and binutils, and they seem to work pretty well to me. cheers, DaveK
Re: ATTENTION: Tcl/Tk transition
On Thu, Oct 27, 2011 at 02:31:28AM +0100, Dave Korn wrote: On 26/10/2011 22:02, Yaakov (Cygwin/X) wrote: cgf has asked me to take over tcl/tk/expect maintainership and transition the distro from our Win32/GDI hybrid 8.4 to the *NIX/X11 8.5 currently in Ports. To anyone feeling apprehensive, I've been using the 'ports versions of tcl and expect for a long time now to test GCC and binutils, and they seem to work pretty well to me. tcl isn't the problem. tk is. cgf
Re: ATTENTION: Tcl/Tk transition
On Wed, Oct 26, 2011 at 06:26:34PM -0700, Cary R. wrote: FYI expect is what drew me to Tcl/Tk a very long time ago. Trust that I understand the need to be using a more modern version of Tcl/Tk. I'm just whining that we're going to loose the GDI support. Since I'm not going to do anything to help the situation thisis the last I'll post on the subject. I did some quick testing and yes the new X server is much better. All my prejudices came from Cygwin 1.5 days on a slower laptop. The combination of a newer laptop and Cygwin 1.7/newer X server makes a significant difference. The benefit I get from using VirtualBox for development? is that with Cygwinour test suite takes 818 second andwith Linuxinside VirtualBox it takes 45 seconds. As you can see itdoesn'ttake too many test cycles to result in a significanttimesavings and yes this is the same version of the codeon the same machine with all the other processes idle. For me the resource cost of Virtual Box is 1G of memory and a 30-45 second startup/shutdown times. Depending on what I'm doing and how long I'm going to be doing it this is acceptable given the smaller testing times. Don't construe any of this as a slam on Cygwin. I still think it is a great setup! I don't construe it as a slam. I construe it as continuing down the off-topic for this mailing list road. You've hijacked what should be a rebuild and packaging discussion with YA astonished observation that Cygwin is slow. Moreover, as far as I can tell you are not even a package maintainer. If you have more to say then use the Cygwin mailing list. cgf
