Re: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
On 27 Aug 2010 19:33:36 +0100, Andy Koppe wrote: > It will be synced with the POSIX working directory again, except when > the path is too long or it's a "virtual" directory such as /proc. Thank you for summarizing the thread. I tried using the snapshot cygwin1-20100829.dll.bz2 and confirmed that gitk works okay again. One thing to note. I said in the previous mail that "gitk unusable in cygwin-1.7.6-1", but after more testing, I found I was wrong in saying that. The correct description of the problem in cygwin-1.7.6-1 was "gitk does work in a directory with only ascii characters in its path, but is unusable in a directory that contains a non-ascii character in its path." In the latter case, echo "puts [pwd]"|wish returned //?/PIPE . But I confirmed this was fixed and gitk works again in the snapshot cygwin1-20100829.dll.bz2 . I thank the developers for fixing this. -- neomjp -- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
Charles Wilson schrieb: On 8/28/2010 10:31 AM, Reini Urban wrote: 2010/8/27 Charles Wilson: Obviously git and python-idle both work with X (on linux) so it's doable to convert -- just a nuisance. A big nuisance in my eyes. Why do I have to start a xserver, when I can use native fast small GDI? Why do you have to start cygserver (for posix IPC), when you can use native fast small named pipes, or native fast small shared memory? Because we don't have posix IPC semantics in native windows. So, the right answer is a "real" port of tcl/tk. There are two ways to do this: 1) just compile it like you would on unix. Then, you get X11, not GDI -- but you also avoid all the other win32isms. This will "just work"; recompile with the "correct" options and you're golden. 2) disentagle all the assumptions in the tcl/tk code between "windowing system" and "win32ness as it relates to non-windowing code". This is a BIG job, and NOBODY wants to do it. I did it for perltk two years ago and posted the patches to the perltk tracker. It was a nobrainer, needed one day and was straightforward. Tk is very well prepared for supporting windows GDI or unix X. But I'm not interested to maintain it. And I'm not interested to have to start startxwin for a simple tk gui. pTk is essentially the same as Tk upstream, just portable, hence the name. Just two lines are problematic, using the unix event loop with /dev/windows should be replaced by using the native windows event loop. pTk/mTk/win/tkWinX.c: GetMessage() via select() on /dev/windows and callback did not work for me. http://rt.cpan.org/Public/Bug/Display.html?id=31792 I have no idea what would be involved to try out the pTk cygwin Win32 wish instead of the original tk wish. If anyone is concerned about our current tcltk path mess should try it. http://search.cpan.org/dist/Tk/ The Tk svn already has my cygwin patches in. But I have more important things to do. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
On 8/28/2010 10:31 AM, Reini Urban wrote: > 2010/8/27 Charles Wilson: >> Obviously git and >> python-idle both work with X (on linux) so it's doable to convert -- >> just a nuisance. > > A big nuisance in my eyes. > Why do I have to start a xserver, when I can use native fast small GDI? Why do you have to start cygserver (for posix IPC), when you can use native fast small named pipes, or native fast small shared memory? Either tcl/tk is actually ported to cygwin, or it isn't. When compiled as it currently is, internally tcl/tk is a hybrid monster: this is actually a bug in tcl/tk. It conflates the concept of "display technology" with "runtime support". So, when you compile for "GDI" you also get "I like C:/foo paths" and other native-win32-ness -- BUT it isn't actually a native win32 app/lib, because it ALSO uses the cygwin runtime. It just uses it wrong. But, it was always just a stop-gap, quick-n-dirty "port". It "worked" -- enough that GDB/insight DTRT, at least. When it is used by other clients, technically -- AFAIK -- it isn't actually supported. But there are sharp edges in this unhappy marriage of GDI, native win32 calls, and the cygwin runtme. So, the right answer is a "real" port of tcl/tk. There are two ways to do this: 1) just compile it like you would on unix. Then, you get X11, not GDI -- but you also avoid all the other win32isms. This will "just work"; recompile with the "correct" options and you're golden. 2) disentagle all the assumptions in the tcl/tk code between "windowing system" and "win32ness as it relates to non-windowing code". This is a BIG job, and NOBODY wants to do it. okay, so: 3) or...status quo with a mostly working, two year old pseudo port, with some sharp edges... During a previous discussion, the list consensus was that X11 /would/ have been fine, BUT at the time we didn't actually have a maintained Xserver since the previous maintainer left, and our current maintainers had not yet stepped forward. Now, though, our X server is well maintained and works very well...so that reason no longer applies. The only /technical/ barrier now is that in some security-locked-down environments, non-Admin's cannot grant permission to applications to open a networking port. Since on cygwin, even unix domain sockets are emulated using networking ports, AND because the Xserver /will not work/ without that unix socket being opened...you can't run an Xserver in those environments, which means you wouldn't be able to run insight, gitk, etc etc. Then there's the pain involved in coordinating the switch with other maintainers of tcltk clients, and the existing higher-priority demands on cgf's time, ... and it just hasn't bubbled to the top. > The PIPE problem appears elsewhere also, and will be fixed with 1.7.7. Well, I wasn't pre-cognitively suggesting, last year, that we switch from GDI to X11 to fix this PIPE problem... -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
2010/8/27 Charles Wilson: > On 8/27/2010 2:33 PM, Andy Koppe wrote: >> On 27 August 2010 19:22, neomjp wrote: >>> 2. I understand that the reason to have tcltk-20080420-1 as a win32 app is >>> to have a graphical insight that does not depend on X Window. >> >> Cygwin programs can have Win32 interfaces actually, as proven by the >> likes of rxvt, mintty, and the Xwin server itself. > > The real issue is that tcltk-20080420-1 presents the GDI (e.g. native > windows) backend implementation for tcl/tk. I was proposing that we > eventually modify our offerings so that the new (probably split up) > replacement package(s) present the X11 backend implementation instead. > > It has nothing to do with whether "tcltk" is a "win32" *application* as > opposed to a cygwin one. It's all about which interface the > application/library uses to put graphics on the screen: GDI or X11. > > So far, nothing has occurred on that line AFAIK. If it is to happen, > the current maintainer has to just pull the trigger and say "we are > going to do this". Existing maintainers of tcl/tk clients will then > adapt; until (if) that happens, nothing will change. > > I think the big hangups were (a) insight (b) git (c) python-idle. > insight might actually be dead or dying, not sure. Obviously git and > python-idle both work with X (on linux) so it's doable to convert -- > just a nuisance. A big nuisance in my eyes. Why do I have to start a xserver, when I can use native fast small GDI? The PIPE problem appears elsewhere also, and will be fixed with 1.7.7. -- Reini -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
On 8/27/2010 2:33 PM, Andy Koppe wrote: > On 27 August 2010 19:22, neomjp wrote: >> 2. I understand that the reason to have tcltk-20080420-1 as a win32 app is >> to have a graphical insight that does not depend on X Window. > > Cygwin programs can have Win32 interfaces actually, as proven by the > likes of rxvt, mintty, and the Xwin server itself. The real issue is that tcltk-20080420-1 presents the GDI (e.g. native windows) backend implementation for tcl/tk. I was proposing that we eventually modify our offerings so that the new (probably split up) replacement package(s) present the X11 backend implementation instead. It has nothing to do with whether "tcltk" is a "win32" *application* as opposed to a cygwin one. It's all about which interface the application/library uses to put graphics on the screen: GDI or X11. So far, nothing has occurred on that line AFAIK. If it is to happen, the current maintainer has to just pull the trigger and say "we are going to do this". Existing maintainers of tcl/tk clients will then adapt; until (if) that happens, nothing will change. I think the big hangups were (a) insight (b) git (c) python-idle. insight might actually be dead or dying, not sure. Obviously git and python-idle both work with X (on linux) so it's doable to convert -- just a nuisance. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
On 27 August 2010 19:22, neomjp wrote: > 1. I see a long discussion about cygwin vs. win32 CWD is taking place in > cygwin-developer. What is win32 CWD going to be in cygwin in the future? It will be synced with the POSIX working directory again, except when the path is too long or it's a "virtual" directory such as /proc. > 2. I understand that the reason to have tcltk-20080420-1 as a win32 app is > to have a graphical insight that does not depend on X Window. Cygwin programs can have Win32 interfaces actually, as proven by the likes of rxvt, mintty, and the Xwin server itself. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
When I invoke gitk like this:
#
$ cygcheck -c cygwin git gitk tcltk
Cygwin Package Information
Package VersionStatus
cygwin 1.7.6-1OK
git 1.7.1-1OK
gitk 1.7.1-1OK
tcltk20080420-1 OK
$ ls -a
. .. .git
$ git rev-parse --git-dir
.git
$ gitk
#
I got the following error:
#
"Cannot find a git repository here."
#
This error message is shown when a valid .git directory is not found.
#
$ sed -n "11441,11446p" /usr/bin/gitk
# check that we can find a .git directory somewhere...
if {[catch {set gitdir [gitdir]}]} {
show_error {} . [mc "Cannot find a git repository here."]
exit 1
}
#
But as the "ls -a" output above shows, I do have a .git directory. So this
means the procedure "gitdir" somehow failed to detect the .git directory.
The cause of this error comes down to this:
#
$ echo "puts [pwd]"|wish
//?/PIPE
#
/usr/bin/gitk is a tcl (wish) script, but tcltk-20080420-1 is a native
Win32 app. So in cygwin-1.7.6-1, the working directory of wish is set to
//?/PIPE. That is why the git command invoked from inside gitk failed
saying "Cannot find a git repository here."
A temporary workaround is to use cygwin-1.7.5-1, but,
1. I see a long discussion about cygwin vs. win32 CWD is taking place in
cygwin-developer. What is win32 CWD going to be in cygwin in the future?
2. I understand that the reason to have tcltk-20080420-1 as a win32 app is
to have a graphical insight that does not depend on X Window. (Thread
"Does anyone use insight on cygwin?" in cygwin 2008-08.) But in the thread
"gdb, insight, and tcltk" in cygwin 2009-10, Charles Wilson discussed War
and Peace of an X-based package. Is anything moving recently in this vein?
--
neomjp
--
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
