GWorkspace crash
Hi, the recent changes, make GWorkspace crash or hang. I get a crash on FreeBSD if I try to close one of the viewer windows: #0 0x288e3a64 in objc_msg_lookup () from /usr/lib/libobjc.so.3 #1 0x282a231f in -[NSApplication(Private) _targetForAction:keyWindow:mainWindow:] (self=0x29046948, _cmd=0x284d2ab8, aSelector=0x290adde8, keyWindow=0x0, mainWindow=0x2c4f9908) at NSApplication.m:3814 #2 0x282a22e2 in -[NSApplication(Private) _targetForAction:keyWindow:mainWindow:] (self=0x29046948, _cmd=0x284d2ab8, aSelector=0x290adde8, keyWindow=0x2c4fa008, mainWindow=0x2c4f9908) at NSApplication.m:3841 #3 0x282a1833 in -[NSApplication targetForAction:] (self=0x29046948, _cmd=0x284d2ac0, aSelector=0x290adde8) at NSApplication.m:2251 #4 0x282a3708 in -[NSApplication targetForAction:to:from:] (self=0x29046948, _cmd=0x285203d0, theAction=0x290adde8, theTarget=0x0, sender=0x29b79ce8) at NSApplication.m:2236 #5 0x283614d5 in -[NSMenu update] (self=0x299cae88, _cmd=0x285202e0) at NSMenu.m:1150 #6 0x283617a2 in -[NSMenu update] (self=0x2998a548, _cmd=0x284d2988) at NSMenu.m:1145 #7 0x282a50c2 in -[NSApplication(Private) _windowDidBecomeKey:] ( self=0x29046948, _cmd=0x284d2838, notification=0x293a19e8) at NSApplication.m:3890 #8 0x287181ce in -[NSNotificationCenter _postAndRelease:] (self=0x29075fc8, _cmd=0x28881968, notification=0x293a19e8) at NSNotificationCenter.m:1161 #9 0x287173f8 in -[NSNotificationCenter postNotificationName:object:userInfo:] (self=0x29075fc8, _cmd=0x28881970, name=0x28581804, object=0x2c4fa008, at NSControl.m:713 #10 0x2871726e in -[NSNotificationCenter postNotificationName:object:] ( self=0x29075fc8, _cmd=0x28572908, name=0x28581804, object=0x2c4fa008) at NSNotificationCenter.m:1200 #11 0x2841e3df in -[NSWindow becomeKeyWindow] (self=0x2c4fa008, _cmd=0x28572948) at NSWindow.m:1486 #12 0x28418764 in -[NSWindow makeKeyWindow] (self=0x2c4fa008, _cmd=0x28572438) at NSWindow.m:1600 #13 0x284200a8 in -[NSWindow(GNUstepPrivate) _lossOfKeyOrMainWindow] ( self=0x2c4f9908, _cmd=0x28572988) at NSWindow.m:294 #14 0x2841b149 in -[NSWindow orderWindow:relativeTo:] (self=0x2c4f9908, _cmd=0x28572978, place=NSWindowOut, otherWin=0) at NSWindow.m:1701 #15 0x28418498 in -[NSWindow orderOut:] (self=0x2c4f9908, _cmd=0x28572b10, sender=0x2c4f9908) at NSWindow.m:1655 #16 0x2842031a in -[NSWindow close] (self=0x2c4f9908, _cmd=0x28572ba0) at NSWindow.m:2689 #17 0x28426ef8 in -[NSWindow performClose:] (self=0x2c4f9908, _cmd=0x28572bf8, sender=0x2c4c9038) at NSWindow.m:2911 #18 0x282a18d2 in -[NSApplication sendAction:to:from:] (self=0x29046948, _cmd=0x284f5848, aSelector=0x28572bf8, aTarget=0x2c4f9908, sender=0x2c4c9038) at NSApplication.m:2193 #19 0x283028f4 in -[NSControl sendAction:to:] (self=0x2c4c9038, _cmd=0x284e7100, theAction=0x28572bf8, theTarget=0x2c4f9908) #20 0x282dc3e4 in -[NSCell _sendActionFrom:] (self=0x2c4ecb88, _cmd=0x284e7150, sender=0x2c4c9038) at NSCell.m:1437 #21 0x282e1f6a in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] ( self=0x2c4ecb88, _cmd=0x284f58e8, theEvent=Variable "theEvent" is not available. ) at NSCell.m:1755 #22 0x283025c0 in -[NSControl mouseDown:] (self=0x2c4c9038, _cmd=0x28572dc8, theEvent=0x2936eba8) at NSControl.m:869 #23 0x28425f28 in -[NSWindow sendEvent:] (self=0x2c4f9908, _cmd=0x284d2a60, theEvent=0x2936eba8) at NSWindow.m:3675 #24 0x282a51b2 in -[NSApplication sendEvent:] (self=0x29046948, _cmd=0x284d2990, theEvent=0x2936eba8) at NSApplication.m:2068 #25 0x282a6e8e in -[NSApplication run] (self=0x29046948, _cmd=0x80f4cd0) at NSApplication.m:1530 #26 0x0804d50b in main () at main.m:37 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
On 26 Mar 2010, at 19:55, Fred Kiefer wrote: > moving on to non fragile ivars will happen later I currently count 6 instances of @defs in -gui, which is all that is preventing it from compiling with the non-fragile ABI. David -- Sent from my brain ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Next GNUstep release?
Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, or so it seems from the outside and gui had to play catch up. Then I toyed around with the NIB loading and broke a few things. Now things are rather stable again and we should come back to our original plan. For gui this would be an intermediate release not the 1.0 release I am hoping to see later this year. What still needs to be done in gui is finishing the switch to #import, moving on to non fragile ivars will happen later. I first want to see the results base gets with its approach to that topic. Adam, could you once more take up the task of releasing GNUstep? We should give it another week or two so that people can complain about existing bugs that need to be fixed before the release. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [PATCH] A NSNetService implementation using Avahi
Hullo, yes, I'm still alive :-) On Fri, Mar 26, 2010 at 9:26 AM, Fred Kiefer wrote: [...] > for doing it differently here? Even the delegate handling methods are > duplicated, with the mDNS ones having an additional tracing call. The tracing calls are a left-over from when I originally wrote that stuff. I hate debugging, but I like to know where I am when something goes wrong. It's only compiled in when VERBOSE is set and can safely be deleted. > Apart from that your patch makes perfectly sense to me. Yup. Though back when, Avahi was pretty buggy and did implement a lot of Bonjour in quite a wrong way, and blaming Apple for Avahi not playing nicely with the real deal on Macs... No idea if they ever got around to fix it. -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [PATCH] A NSNetService implementation using Avahi
Hi Niels, Le 26 mars 2010 à 13:44, Niels Grewe a écrit : Okay. I guess just piping it through 'indent' won't be sufficient to get it cleaned up? Do we have any coding-style documentation (apart from the "GNU Coding Standards", obviously). You can find the GNUstep coding standards at the bottom of this page: http://www.gnustep.org/developers/documentation.html Cheers, Quentin. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [PATCH] A NSNetService implementation using Avahi
On Fri, Mar 26, 2010 at 09:26:14AM +0100, Fred Kiefer wrote: > I only had a short look at this patch and was a bit surprised to see how > little these two implementations share. In a normal class cluster you > would expect that most of the code is in the common super class and only > the primitive methods get implemented separately. What was the reason > for doing it differently here? The "reason" (apart from general laziness) is that the Avahi-based implementation started its life as a local out-of-tree workaround for me. Of course that's not a good reason. I will move stuff up to NSNetService where possible, though that will require shuffling around the class layouts bit, because the avahi subclasses make use of behaviours. > Even the delegate handling methods are duplicated, with the mDNS ones > having an additional tracing call. I left the mDNS implementation mostly untouched (except where it was retaining delegates…), the tracing calls where already there. > PS: You seem to be using tabs to indent your code. Spaces (two of them > actually) are prefered. Okay. I guess just piping it through 'indent' won't be sufficient to get it cleaned up? Do we have any coding-style documentation (apart from the "GNU Coding Standards", obviously). Thanks for having a look! Niels signature.asc Description: Digital signature ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [PATCH] A NSNetService implementation using Avahi
I only had a short look at this patch and was a bit surprised to see how little these two implementations share. In a normal class cluster you would expect that most of the code is in the common super class and only the primitive methods get implemented separately. What was the reason for doing it differently here? Even the delegate handling methods are duplicated, with the mDNS ones having an additional tracing call. Apart from that your patch makes perfectly sense to me. Fred PS: You seem to be using tabs to indent your code. Spaces (two of them actually) are prefered. Am 26.03.2010 02:58, schrieb Niels Grewe: > Hello guys, > > here [0] you will find a patch (slighly to large for attachment) that > I've been cooking up for some time now. It augements the present > implementation of NSNetService and NSNetServiceBrowser in gnustep-base > with a second implementation using the Avahi API. Some words on why that > seems to be a good idea to me: > > Our present implementation of NSNetServices makes use of the API that > Apple implemented in mDNSResponder [1] to provide zeroconf (=Bonjour) > services. That is, in principle, a good idea, because we can bet that > Apple also used it to implement NSNetServices on Mac OS X. The problem > is only that (way back) mDNSResponder was APSL licensed [2], which was > hindering adoption by some Linux distributions, so it is not available > on many Linux systems. > Fortunately, the Avahi project provides a compatibility layer for the > mDNSResponder API that can be used instead. Unfortunately, that > compatibility layer is only partitially implemented and (apparently) not > very well maintained. This means that presently our NSNetServices code > will run on most Linux distributions where avahi is available, but most > of the shiny stuff you would want in an useful application (e.g. > monitoring TXT records) wont work. > > Since Avahi is probably going to stick on the Linux desktop (it provides > a DBUS interface that seems to be quite popular for reasons unknown to > me), I decided not to waste my time on fixing the Avahi compatability > layer, but to reimplement NSNetServices on top of the native Avahi API. > This was actually quite easy, because avahi provides some hooks that > allowed hooking the event-handling into NSRunLoop quite transparently. > This has the following ramifications: > > 1. NSNetService and NSNetServiceBrowser are now abstract superclasses >that return concrete subclasses for the configured implementation. > > 2. The zeroconf API to use is now configurable by the >--with-zeroconf-api configure switch. It can take the values "mdns", >"avahi" and "any" (with "any" being the default). If both are >installed, it will always use avahi, since the mDNS implementation is >most certainly the broken compatibility-layer. > > 3. The new avahi-based implementation has some shiny additional features >that make it more flexible then the Apple one. I.e. it allows you not >only to browse for (or register) services and TXT records, but also >arbitrary records. This is nice for use-cases like serverless >XMPP-messaging, where you are supposed to publish a buddy-icon as a >NULL record. While these features are not yet available with our >mDNSResponder-based implementation, they are certainly possible, and >I would be adding them eventually if there is sufficient interest. > > I'm now soliciting feedback on this patch. It still has some > non-critical FIXMEs strewn over it that I plan to resolve, but in > general it seems to be quite usable. So if you have any code that uses > NSNetService and friends, please try it out and tell me when it breaks > and where it doesn't behave as expected. To this purpose, I have also > uploaded the patch to the Étoilé reviewboard [3]. > > Thanks, > > > Niels > -- > [0] http://www.halbordnung.de/~thebeing/gnustep/NSNetServices+avahi.patch > [1] http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-214/ > [2] It's Apache-licensed now. > [3] http://review.etoileos.com/r/137/ > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
