Re: [Harbour] GTXWC clipboard paste: hang
On Fri, 18 Dec 2009, Przemysław Czerpak wrote: hi, > I cannot replicate it (probably because I cannot exactly replicate your > environment settings) so I have to guess but probably you are right. > Anyhow thank you very much for your tests. Finally I've found a while > to clean the selection code in GTXWC. thank you! -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Fri, 18 Dec 2009, Tamas TEVESZ wrote: Hi, > > Can you check if problem can be resolved if you add at the end of your > > test application: > >hb_gtInfo( HB_GTI_CLIPBOARDDATA, "" ) > no, but i managed to strace the xterm that got picked by the Client > Killer Phenomenon. :-) > it's last breath was this: > X Error of failed request: BadWindow (invalid Window parameter) > Major opcode of failed request: 2 (X_ChangeWindowAttributes) > Resource id in failed request: 0x560001e > Serial number of failed request: 1107 > Current serial number in output stream: 1108 [...] > its _only_ the xterms. i have now tried having other apps killed by > this method, but it's always the xterm that dies. > ok, i have found a pattern i seem to be able to reliably reproduce. Now it seems to be a little bit different thing the one you described in previous message or maybe I didn't understood you correctly. > i am running XTerm(235) (ubuntu intrepid x64). the test app is on a > remote box, which is ubuntu karmic x64. ssh in, start the test app (it > doesn't matter whether x is via ssh or via a direct connection). I fixed stupid bug in one of last commits which was exploited on 64bit machines so if possible please check if you can still replicate the problem with current SVN code. Anyhow seems that this modification should not effect any valid 3-rd party code. > when the test app says to copy something in, copy something in from an > xterm. then push through the test app, and after it exits, give focus > to the xterm you have copied from (this may need to be done several > times). i could kill the xterm in at most 5 tries (of giving it focus, > and taking focus away from it). > i've tried other apps, xlib-based, xaw-based, gtk-based, i've even > tried rxvt, but it is invariably the xterm that dies. > i have tried XTerm(243) (this is the latest in ubuntu), same effect. > i've built myself a smokin' fresh XTerm(253), same effect. > > so thus far every finger points at either xterm or xterm-wm > interaction being somehow at fault, and we could have been chasing > ghosts... I cannot replicate it (probably because I cannot exactly replicate your environment settings) so I have to guess but probably you are right. Anyhow thank you very much for your tests. Finally I've found a while to clean the selection code in GTXWC. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Fri, 18 Dec 2009, Przemysław Czerpak wrote: hi, > Can you check if problem can be resolved if you add at the end of your > test application: > >hb_gtInfo( HB_GTI_CLIPBOARDDATA, "" ) no, but i managed to strace the xterm that got picked by the Client Killer Phenomenon. it's last breath was this: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 2 (X_ChangeWindowAttributes) Resource id in failed request: 0x560001e Serial number of failed request: 1107 Current serial number in output stream: 1108 at another try i attached xev to the victim: this is when focus leaves the client so i can push buttons in my text app (using sloppy focus): FocusOut event, serial 17, synthetic NO, window 0x5af, mode NotifyNormal, detail NotifyNonlinear this is when my test app has exited, and i focus the victim client again. all the next events happen in a very short time right after the pointer enters the client area: FocusIn event, serial 17, synthetic NO, window 0x5af, mode NotifyNormal, detail NotifyNonlinear KeymapNotify event, serial 17, synthetic NO, window 0x0, keys: 4294967177 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 these two above events happen normally when any client gets the focus. the below events are what seem to be coming unwanted: UnmapNotify event, serial 17, synthetic NO, window 0x5af, event 0x5af, window 0x5af, from_configure NO FocusOut event, serial 17, synthetic NO, window 0x5af, mode NotifyNormal, detail NotifyAncestor DestroyNotify event, serial 17, synthetic NO, window 0x5af, event 0x5af, window 0x5a0001a DestroyNotify event, serial 17, synthetic NO, window 0x5af, event 0x5af, window 0x5af i have just found that i've been running wm with logs saved all along the way, and i can confirm from those logs that xterms have been dying with the same message during all this experiment. even more interesting. its _only_ the xterms. i have now tried having other apps killed by this method, but it's always the xterm that dies. ok, i have found a pattern i seem to be able to reliably reproduce. i am running XTerm(235) (ubuntu intrepid x64). the test app is on a remote box, which is ubuntu karmic x64. ssh in, start the test app (it doesn't matter whether x is via ssh or via a direct connection). when the test app says to copy something in, copy something in from an xterm. then push through the test app, and after it exits, give focus to the xterm you have copied from (this may need to be done several times). i could kill the xterm in at most 5 tries (of giving it focus, and taking focus away from it). i've tried other apps, xlib-based, xaw-based, gtk-based, i've even tried rxvt, but it is invariably the xterm that dies. i have tried XTerm(243) (this is the latest in ubuntu), same effect. i've built myself a smokin' fresh XTerm(253), same effect. so thus far every finger points at either xterm or xterm-wm interaction being somehow at fault, and we could have been chasing ghosts... -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Thu, 17 Dec 2009, Tamas TEVESZ wrote: Hi, > this one is solved,, thank you. thank you. > > > so the guess it that *something* is there that causes clients to exit > > > unexpectedly. it is not even sure that the client that exits is the > this one is not. Can you check if problem can be resolved if you add at the end of your test application: hb_gtInfo( HB_GTI_CLIPBOARDDATA, "" ) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Thu, 17 Dec 2009, Przemysław Czerpak wrote: hi, > > the symptom is that when there is already data in the primary when > > this app is started, the first inkey(0) is immediately satisfied (and > > then it shows the correct content for the primary selection). > > > > this doesn't happen absolutely always, but it does most of the time. > > if the primary is empty at app startup, then it never happens. this one is solved,, thank you. > > so the guess it that *something* is there that causes clients to exit > > unexpectedly. it is not even sure that the client that exits is the this one is not. > Your VM crashes when selection owner does not response. I'll add code > to disable own selection in GTXWC exit phase and I hope it will help > anyhow real fix should be done in WM code because your description > suggests that it may have very serious problems and even crash if > selection owner terminates suddenly without clearing the selection > i.e. due to delivered asynchronous signal (killall myapp). thanks for the explanation. never mind about the second issue just yet, i will bring it up with wm people. thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Thu, 17 Dec 2009, Tamas TEVESZ wrote: Hi, > the symptom is that when there is already data in the primary when > this app is started, the first inkey(0) is immediately satisfied (and > then it shows the correct content for the primary selection). > > this doesn't happen absolutely always, but it does most of the time. > if the primary is empty at app startup, then it never happens. I cannot replicate it but I guess what can be source of such behavior and it's not related to selection code. If you replace in your code 'InKey(0)' with '?? InKey(0)' then we can see the keycode returned in such case. I think it's 1101 (K_RESIZE) which can be generated on some slower system if ConfigureNotify is delivered during initial window creating. It's nothing wrong but of course I'll clean it. > another artifact is that upon exit (i start it from an xterm), it > leaves some garbage someplace, which which causes my xterm to > disappear if i press middle button. it's nothing that i could catch > with careful use of xxd waiting for some binary junk, what's more, at > one occasion this even killed my windowmaker (ok, it's not the > stablest wm in the world, but for a couple of month, since > outstandings have been fixed, i've been having much less problems with > it than i used to). > even worse, this doesn't seem to be tied to middle button events. i > have had it by middle button, up arrow in shell, ^C in a shell line i > decided not to execute... > so the guess it that *something* is there that causes clients to exit > unexpectedly. it is not even sure that the client that exits is the > one that has the focus (i was just at this moment playing with other > xterms when this one that runs my mua decided it's been long since i > last saw my desktop background...) Your VM crashes when selection owner does not response. I'll add code to disable own selection in GTXWC exit phase and I hope it will help anyhow real fix should be done in WM code because your description suggests that it may have very serious problems and even crash if selection owner terminates suddenly without clearing the selection i.e. due to delivered asynchronous signal (killall myapp). I'll commit these modifications in a while. Please test if they resolve all your problems. I cannot replicate any of them in my local machine. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Thu, 17 Dec 2009, Przemysław Czerpak wrote: hi, > > I've just checked and same OS X GTXWC app picked what was > > placed to clipboard before starting the app (or even > > starting X11 for that matter). > > I'll keep an open eye to report any clipboard problems > > here. > > Please try it after: >2009-12-17 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) it is better now, in the sense that now the primary is retained and can be reliably read by hb, but a small artifact remains. i am using a test along the lines of: #include "inkey.ch" #include "hbgtinfo.ch" FUNCTION MAIN() REQUEST HB_GT_XWC, HB_GT_CRS, HB_GT_TRM hb_gtInfo( HB_GTI_CLOSABLE, .F. ) hb_gtInfo( HB_GTI_WINTITLE, "X Clipboard/PrimarySelection test" ) hb_gtInfo( HB_GTI_SELECTCOPY, .T. ) hb_gtInfo( HB_GTI_RESIZABLE, .F. ) @ 1, 1 SAY "Copy in something (key)" InKey(0) @ 2, 1 SAY "Clipboard data:" alert( hb_gtInfo( HB_GTI_CLIPBOARDDATA ) ) @ 3, 1 SAY "Copying in 'erglebergle' (key)" hb_gtInfo( HB_GTI_CLIPBOARDDATA, "erglebergle" ) InKey(0) @ 4, 1 SAY "Paste primary (key)" InKey(0) @ 5, 1 SAY "Paste clipboard (key)" InKey(0) @ 6, 1 SAY "In clipboard:" alert( HB_GTINFO( HB_GTI_CLIPBOARDDATA ) ) @ 8, 1 SAY "Exit (key)" InKey(0) RETURN NIL (that is, you are supposed to do what it says by copying from and pasting into other clients when the test app says so) the symptom is that when there is already data in the primary when this app is started, the first inkey(0) is immediately satisfied (and then it shows the correct content for the primary selection). this doesn't happen absolutely always, but it does most of the time. if the primary is empty at app startup, then it never happens. another artifact is that upon exit (i start it from an xterm), it leaves some garbage someplace, which which causes my xterm to disappear if i press middle button. it's nothing that i could catch with careful use of xxd waiting for some binary junk, what's more, at one occasion this even killed my windowmaker (ok, it's not the stablest wm in the world, but for a couple of month, since outstandings have been fixed, i've been having much less problems with it than i used to). even worse, this doesn't seem to be tied to middle button events. i have had it by middle button, up arrow in shell, ^C in a shell line i decided not to execute... so the guess it that *something* is there that causes clients to exit unexpectedly. it is not even sure that the client that exits is the one that has the focus (i was just at this moment playing with other xterms when this one that runs my mua decided it's been long since i last saw my desktop background...) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Wed, 16 Dec 2009, Szak�ts Viktor wrote: Hi, > I've just checked and same OS X GTXWC app picked what was > placed to clipboard before starting the app (or even > starting X11 for that matter). > I'll keep an open eye to report any clipboard problems > here. Please try it after: 2009-12-17 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
> First off thanks for jumping on the issue. Unfortunately (or > fortunately) this was a local problem and a pretty stupid > one. There was an infinite loop in my code in case there was > no keyable char in clipboard buffer. Empty clipboard also > triggered this. > > Probably it never came up before because in 99.99% of the > cases there is something on clipboard, but OS X was exception, > because as Tamas reported, the initial state of clipboard > under GTXWC is empty, so the chance to trigger this error > case, was much higher. > > Probably this could be fixed in Harbour to behave more > like other apps and other Gts. I've just checked and same OS X GTXWC app picked what was placed to clipboard before starting the app (or even starting X11 for that matter). I'll keep an open eye to report any clipboard problems here. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
No educated bug report, but just now I tried to coppy/paste some text from OS X Mail to my app running GTXWC, and the app just hung with 100% CPU consumption. > > this is a long shot, but. > > is this even supposed to work? i do not know the level of integration > of x11 in osx, but there could be problems (there certainly have been > in the past, according to my friend google). > > can you copy and paste between other x11 apps and native apps? say, > something like abiword and whatever-notepad-is-on-osx (but anyhow do > not use xterm and terminal.app for these tests). you should try > selecting (with the mouse, just selecting, nothing else) in abiword, > and pasting in $notepad; selecting and edit->copy in abiword, pasting > in $notepad. Yes of course. It used to work most of the time. I'm narrowing it down to my own code now and it seems Harbour is not at fault here, now I have to investigate a little bit why such didn't happen on win. More in another mail soon. > this copy-paste thing in x11 is pretty much unlike anything else. > there are two places something can end up, a "primary" selection (this > gets stuff if you select text in an xterm, for example -- this is > sort of an implicit buffer), and a "clipboard" selection (this gets > stuff if you explicitly copy in something, by means of edit->copy in > an application). far as i can tell, gtxwc plays it safe and always > updates both selections (this does seem to work well), so it could > well be an integration issue on osx? trying it with an independent x > app could reveal what might be wrong. > > there's a very condensed page about this whole business at > > http://www.jwz.org/doc/x-cut-and-paste.html > >>> anyway, if seems that XWC_DEBUG activates a whole lot of >>> clipboard-related debug stuff, do you get any clue with that? >> >> I didn't try that yet, for that I'll need to rebuild >> everything, which is not option these days. > > turns out it doesn't worth it without some more surgery. with > XWC_DEBUG, it just gets so overly verbose no way to cherrypick the > relevant piece anyway :) As it turns, problem isn't that deep anyway. >>> (how is copy-pasting w/ xwc supposed to work? just like any other x >>> app i'd like to hope but still asking, point mouse, click, hold/point >>> mouse, hit middle button?) >> >> This application use hb_gtInfo( HB_GTI_CLIPBOARDDATA ) to >> copy and paste on all platforms/GTs. It works alright in >> GTWIN and GTWVT. > > this seems to be working fine on linux, well almost. this (as far as i > can tell) seems intentional in gtxwc.c:3072, but it's as if the > selections were cleared by this as well (so anything i have in primary > when an xwc app starts, hb_gtInfo( HB_GTI_CLIPBOARDDATA ) will return > empty -- this is somewhat surprising, but its not to say this is a > huge problem or something). Hm, I didn't check this, but it'd be good behavior if a Harbour app could pick what was already placed on clipboard before its start. Could be annoying for users, since apps usually don't have such limitations. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
Hi Przemek, Tamas, First off thanks for jumping on the issue. Unfortunately (or fortunately) this was a local problem and a pretty stupid one. There was an infinite loop in my code in case there was no keyable char in clipboard buffer. Empty clipboard also triggered this. Probably it never came up before because in 99.99% of the cases there is something on clipboard, but OS X was exception, because as Tamas reported, the initial state of clipboard under GTXWC is empty, so the chance to trigger this error case, was much higher. Probably this could be fixed in Harbour to behave more like other apps and other Gts. Brgds, Viktor On 2009 Dec 16, at 19:00, Przemysław Czerpak wrote: > On Wed, 16 Dec 2009, Szak�ts Viktor wrote: > > Hi, > >> No educated bug report, but just now I tried to >> coppy/paste some text from OS X Mail to my app >> running GTXWC, and the app just hung with 100% >> CPU consumption. > > Please always try to replicate the problem in reduced example. > > In a while I'll commit small modification to tests/gtkeys.prg > which allow to retrive text from Clippard buffer by CTRL+INS > and set new text using CTRL+END. > > Just use it for tests. In my Linux box all works as expected > without any problems. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
>> No educated bug report, but just now I tried to >> coppy/paste some text from OS X Mail to my app >> running GTXWC, and the app just hung with 100% >> CPU consumption. > > Please always try to replicate the problem in reduced example. > > In a while I'll commit small modification to tests/gtkeys.prg > which allow to retrive text from Clippard buffer by CTRL+INS > and set new text using CTRL+END. > > Just use it for tests. In my Linux box all works as expected > without any problems. I'm already testing (BTW Ctrl+Ins and/or Ctrl+End doesn't work in OS X terminal in gtrm and/or GTWXC GTs, I didn't make exact notes, just changed them to simple chars). I've also found a cycle in my pasted text processing loop which may go infinite, but I have to check what exactly happens there which doesn't happen on win. After that point I use hb_keyput( ) to push the content to the keyboard. Anyway I'll get back with the results ASAP. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Wed, 16 Dec 2009, Viktor Szakáts wrote: > >> No educated bug report, but just now I tried to > >> coppy/paste some text from OS X Mail to my app > >> running GTXWC, and the app just hung with 100% > >> CPU consumption. this is a long shot, but. is this even supposed to work? i do not know the level of integration of x11 in osx, but there could be problems (there certainly have been in the past, according to my friend google). can you copy and paste between other x11 apps and native apps? say, something like abiword and whatever-notepad-is-on-osx (but anyhow do not use xterm and terminal.app for these tests). you should try selecting (with the mouse, just selecting, nothing else) in abiword, and pasting in $notepad; selecting and edit->copy in abiword, pasting in $notepad. this copy-paste thing in x11 is pretty much unlike anything else. there are two places something can end up, a "primary" selection (this gets stuff if you select text in an xterm, for example -- this is sort of an implicit buffer), and a "clipboard" selection (this gets stuff if you explicitly copy in something, by means of edit->copy in an application). far as i can tell, gtxwc plays it safe and always updates both selections (this does seem to work well), so it could well be an integration issue on osx? trying it with an independent x app could reveal what might be wrong. there's a very condensed page about this whole business at http://www.jwz.org/doc/x-cut-and-paste.html > > anyway, if seems that XWC_DEBUG activates a whole lot of > > clipboard-related debug stuff, do you get any clue with that? > > I didn't try that yet, for that I'll need to rebuild > everything, which is not option these days. turns out it doesn't worth it without some more surgery. with XWC_DEBUG, it just gets so overly verbose no way to cherrypick the relevant piece anyway :) > > (how is copy-pasting w/ xwc supposed to work? just like any other x > > app i'd like to hope but still asking, point mouse, click, hold/point > > mouse, hit middle button?) > > This application use hb_gtInfo( HB_GTI_CLIPBOARDDATA ) to > copy and paste on all platforms/GTs. It works alright in > GTWIN and GTWVT. this seems to be working fine on linux, well almost. this (as far as i can tell) seems intentional in gtxwc.c:3072, but it's as if the selections were cleared by this as well (so anything i have in primary when an xwc app starts, hb_gtInfo( HB_GTI_CLIPBOARDDATA ) will return empty -- this is somewhat surprising, but its not to say this is a huge problem or something). -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Wed, 16 Dec 2009, Szak�ts Viktor wrote: Hi, > No educated bug report, but just now I tried to > coppy/paste some text from OS X Mail to my app > running GTXWC, and the app just hung with 100% > CPU consumption. Please always try to replicate the problem in reduced example. In a while I'll commit small modification to tests/gtkeys.prg which allow to retrive text from Clippard buffer by CTRL+INS and set new text using CTRL+END. Just use it for tests. In my Linux box all works as expected without any problems. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
>> No educated bug report, but just now I tried to >> coppy/paste some text from OS X Mail to my app >> running GTXWC, and the app just hung with 100% >> CPU consumption. > > i notice i cannot paste (nor copy) to/from xwc at all ;) > > anyway, if seems that XWC_DEBUG activates a whole lot of > clipboard-related debug stuff, do you get any clue with that? I didn't try that yet, for that I'll need to rebuild everything, which is not option these days. > (how is copy-pasting w/ xwc supposed to work? just like any other x > app i'd like to hope but still asking, point mouse, click, hold/point > mouse, hit middle button?) This application use hb_gtInfo( HB_GTI_CLIPBOARDDATA ) to copy and paste on all platforms/GTs. It works alright in GTWIN and GTWVT. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Wed, 16 Dec 2009, Viktor Szakáts wrote: hi, > No educated bug report, but just now I tried to > coppy/paste some text from OS X Mail to my app > running GTXWC, and the app just hung with 100% > CPU consumption. i notice i cannot paste (nor copy) to/from xwc at all ;) anyway, if seems that XWC_DEBUG activates a whole lot of clipboard-related debug stuff, do you get any clue with that? (how is copy-pasting w/ xwc supposed to work? just like any other x app i'd like to hope but still asking, point mouse, click, hold/point mouse, hit middle button?) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] GTXWC clipboard paste: hang
Hi All, No educated bug report, but just now I tried to coppy/paste some text from OS X Mail to my app running GTXWC, and the app just hung with 100% CPU consumption. OS: OS X Snow Leopard (all updates) X11: XQuartz 2.3.4 (xorg-server 1.4.2-apple45) C compiler: clang 4.2.1 Harbour: r12817, Intel 64-bit build. I've noticed this effect also in the past. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
