[bug #51113] No in-window menu bar with the Gtk theme

Update of bug #51113 (project gnustep): Summary: No menu bar in Gtk theme broken => No in-window menu bar with the Gtk theme ___ Reply to this item at:

[bug #51113] No menu bar in Gtk theme broken

URL: Summary: No menu bar in Gtk theme broken Project: GNUstep Submitted by: thebeing Submitted on: Thu 25 May 2017 09:11:48 AM UTC Category: Libraries Severity: 3 -

[bug #48882] Recent Gnustep-Base seems to have broken the build.

Update of bug #48882 (project gnustep): Status:None => Fixed Open/Closed:Open => In Test ___ Follow-up Comment #1: Hi Vincent!

[bug #48348] gnustep-config doesn't do what I want

Follow-up Comment #6, bug #48348 (project gnustep): A first iteration is now available in GNUstep make: * GNUstep.sh sets PKG_CONFIG_PATH for all installation domains * in makefiles for libraries and frameworks, you can use $(GNUSTEP_INSTANCE)_PKGCONFIG_FILES to specify the files to install

[bug #48348] gnustep-config doesn't do what I want

Follow-up Comment #5, bug #48348 (project gnustep): That looks like a good start! Getting gnustep-make to install pkgconfig files in the correct place shouldn't be too hard. In theory it would be nice to have them *generated* by gnustep-make as well. That would take away the hassle with the

[bug #48348] gnustep-config doesn't do what I want

Follow-up Comment #3, bug #48348 (project gnustep): I think I share Stefan sentiments here. I needed to jump through hoops at least twice when trying to integrate GNUstep stuff into a non-gnumake build process (specifically CMake and Rust's gcc-rs build helper) and ended up either mangling the

[bug #42778] Frameworks with different SONAME cannot coexist

Follow-up Comment #3, bug #42778 (project gnustep): The patch as been applied to gnustep-make in the meantime, but this part causes problems: @@ -389,10 +389,6 @@ build-framework-dirs: $(DERIVED_SOURCES_DIR) \ $(UPDATE_CURRENT_SYMLINK_RULE) ifeq

[bug #47619] NSPredicate: aggregate function expressions implemented incorrectly

Update of bug #47619 (project gnustep): Status: Ready For Test => Fixed Open/Closed: In Test => Closed ___ Follow-up Comment #2: It seems to work

[bug #47619] NSPredicate: aggregate function expressions implemented incorrectly

URL: Summary: NSPredicate: aggregate function expressions implemented incorrectly Project: GNUstep Submitted by: thebeing Submitted on: Mo 04 Apr 2016 15:04:40 GMT Category:

[bug #47618] NSPredicate: SELF implemented incorrectly

URL: Summary: NSPredicate: SELF implemented incorrectly Project: GNUstep Submitted by: thebeing Submitted on: Mo 04 Apr 2016 14:56:49 GMT Category: Base/Foundation

[bug #46418] NSPredicate is missing a predicateWithBlock implementation

Follow-up Comment #5, bug #46418 (project gnustep): > But ... the second one doesn't pass in OSX-10.11.3 :-( A bug in the OS X implement IMHO (I'm in the process of preparing the bug report): On OS X [predicate evaluateWithObject: o substituationVariables: v] works. It is supposed to be a

[bug #46418] NSPredicate is missing a predicateWithBlock implementation

Update of bug #46418 (project gnustep): Status:None => Ready For Test ___ Reply to this item at: ___

[bug #46418] NSPredicate is missing a predicateWithBlock implementation

Update of bug #46418 (project gnustep): Assigned to:thebeing => None Open/Closed:Open => In Test ___ Follow-up Comment #3: A fun little lunch

[bug #46418] NSPredicate is missing a predicateWithBlock implementation

Update of bug #46418 (project gnustep): Assigned to:None => thebeing ___ Follow-up Comment #2: I guess I can do this ___ Reply to

[bug #47178] JDBC backend in SQLClient does not compile

Update of bug #47178 (project gnustep): Open/Closed: In Test => Closed ___ Follow-up Comment #2: Thanks! It works fine for me as well now.

[bug #47178] JDBC backend in SQLClient does not compile

URL: Summary: JDBC backend in SQLClient does not compile Project: GNUstep Submitted by: thebeing Submitted on: Mi 17 Feb 2016 13:48:14 GMT Category: Libraries

[bug #46939] -Werror set for GSSpeechServer

URL: Summary: -Werror set for GSSpeechServer Project: GNUstep Submitted by: thebeing Submitted on: Mi 20 Jan 2016 21:23:15 GMT Category: Gui/AppKit Severity: 2 - Minor

[bug #43915] Simple bug in NSCountedSet comparsons

Update of bug #43915 (project gnustep): Status:None = Ready For Test Open/Closed:Open = In Test ___ Follow-up Comment #2: Thanks Vincent for

[bug #40620] Deserialising property lists in arguments can lead to an infinite loop

URL: http://savannah.gnu.org/bugs/?40620 Summary: Deserialising property lists in arguments can lead to an infinite loop Project: GNUstep Submitted by: thebeing Submitted on: Mo 18 Nov 2013 09:19:08 GMT Category:

[bug #38017] Date formatting inconsistent with Cocoa when calling -description on a NSDictionary containing NSCalendarDate objects

URL: http://savannah.gnu.org/bugs/?38017 Summary: Date formatting inconsistent with Cocoa when calling -description on a NSDictionary containing NSCalendarDate objects Project: GNUstep Submitted by: thebeing Submitted on: Mi 02 Jan 2013

[bug #37706] SQLClient links explicitly against -lobjc

Update of bug #37706 (project gnustep): Status:None = Ready For Test Open/Closed:Open = In Test ___ Follow-up Comment #1: Hi, I replaced all

[bug #37706] SQLClient links explicitly against -lobjc

Update of bug #37706 (project gnustep): Status: Ready For Test = Fixed Open/Closed: In Test = Closed ___ Reply to this item at:

[bug #37130] NSArray does not implement sorting and insertion assuming sorted

Follow-up Comment #9, bug #37130 (project gnustep): Well, actually, the documentation states that sorting is only required to be stable if you actually request it (though Apple might actually always do stable sorting and just doesn't want to make any guarantees for the general case, I didn't

[bug #37130] NSArray does not implement sorting and insertion assuming sorted

Update of bug #37130 (project gnustep): Item Group: Bug = Change Request Assigned to:None = thebeing ___ Follow-up Comment #1: Nice! Thanks alot

[patch #7822] [GNUstep Make] Bad code generator in Makefiles/Instance/framework.make, causes compiler errors

Follow-up Comment #3, patch #7822 (project gnustep): Hi Stanislav, Thanks alot for the pointer! I've updated gnustep-base to use the attribute for its root classes (when compiling with clang, that is). Cheers, Niels ___ Reply to this

[patch #7822] [GNUstep Make] Bad code generator in Makefiles/Instance/framework.make, causes compiler errors

Update of patch #7822 (project gnustep): Status:None = Ready For Test ___ Follow-up Comment #1: Please note that clang doesn't strictly emit an error here, but a warning which is then

[bug #36706] performSelector: not working with message fowarding

Follow-up Comment #6, bug #36706 (project gnustep): Hi, Just a quick follow-up on this: The attached patch changes the -performSelector:... family of methods to use objc_msg_lookup(), which fixes the issue described by Michael for me. Unfortunately, I don't have much time and only did some quick

[bug #35802] Linking Problems [libobjc2 1.6 + clang trunk (152539) + Ubuntu 11.10]

Update of bug #35802 (project gnustep): Status: Ready For Test = Fixed Open/Closed: In Test = Closed ___ Reply to this item at:

[bug #34764] XIB loading: Custom class set in Interface Builder ignored

Follow-up Comment #7, bug #34764 (project gnustep): That is an rather interesting puzzle, and somehow I cannot restrain myself from adding my very own two cents to this: Maybe we could make -[IBObjectRecord initWithCoder:] do a partial decoding by default, keep the coder around and then (ab)use

[bug #35802] Linking Problems [libobjc2 1.6 + clang trunk (152539) + Ubuntu 11.10]

Update of bug #35802 (project gnustep): Status:None = Ready For Test Open/Closed:Open = In Test ___ Follow-up Comment #1: Hi, when building

[bug #35816] When using clang getting NSInvalidRecievePortException: invalidated while awaiting reply. for all apps...

Follow-up Comment #1, bug #35816 (project gnustep): Hello Greg, I just tried reproducing this on my x86_64 Linux machine with clang, libobjc2, base, gui, back (cairo) and Gorm from last night. In my case, things seem to work fine. But I remember that a few years back I was having a very similar

[bug #35340] dbuskit fails in configure when using clang and --non-fragile-abi

Follow-up Comment #1, bug #35340 (project gnustep): Hi Sebastian, I modified the configure script to override OBJC with CC if the later but not the former is set. This should fix the problem. Cheers, Niels PS @all: It would be nice if somebody could tell me how to update bug-metadata on

[bug #35263] libobjc2 can enter a deadlock during dtable initialization

Follow-up Comment #7, bug #35263 (project gnustep): Hi guys, Just some thoughts on this: Having per class locks for +initialize is not only the Apple compatible behaviour, but imho also a contract that is easier to honour: You just have to keep the set of classes being initialized in thread A

[bug #33392] Multi-thread bug in NSObject retain and release

Follow-up Comment #5, bug #33392 (project gnustep): What Nicola is saying is perfectly accurate, but I think binary compatibility is only an issue for packagers who want their package to work, e.g., on all i[3-7]86 machines. People who build gnustep from source for their personal machine probably

[bug #33392] Multi-thread bug in NSObject retain and release

Follow-up Comment #8, bug #33392 (project gnustep): I just (r33134) added a check to base that performs the following checks before enabling USE_ATOMIC_BUILTINS: (a) Whether the compiler understands the Itanium style __sync_* intrinsics. (b) Whether we are targeting an i586 or later processor

[bug #29291] The configure script doesn't play nice with non-flattened namespaces

Follow-up Comment #8, bug #29291 (project gnustep): Thanks! Now that I know where to look, I have devised a workaround myself (diff attached). Of course this is not the correct fix because it uses GNUSTEP_HOST_* variables. One probably would want a way to specify that stuff based on the target

[bug #29291] The configure script doesn't play nice with non-flattened namespaces

Follow-up Comment #5, bug #29291 (project gnustep): No, I don't think I ever configured gnustep-base before installing gnustep-make and since I did a lot of reconfiguring during the last week or so, I'm positive that that's not the problem. But if you say gets header and library locations from

[bug #29291] The configure script doesn't play nice with non-flattened namespaces

URL: http://savannah.gnu.org/bugs/?29291 Summary: The configure script doesn't play nice with non-flattened namespaces Project: GNUstep Submitted by: thebeing Submitted on: So 21 Mär 2010 21:19:28 GMT Category:

[bug #29291] The configure script doesn't play nice with non-flattened namespaces

Follow-up Comment #3, bug #29291 (project gnustep): You're right, I was being imprecise: It's the configure script in -base that's causing the problems. Sorry for the confusion! Niels ___ Reply to this item at:

[bug #27446] Failure to obtain a rootProxy for NSMessagePort

URL: http://savannah.gnu.org/bugs/?27446 Summary: Failure to obtain a rootProxy for NSMessagePort Project: GNUstep Submitted by: thebeing Submitted on: Mo 14 Sep 2009 18:06:58 GMT Category: Base/Foundation

[bug #27233] GSFFIInvocations share _retval ivar while in -forwardInvocation:

Follow-up Comment #2, bug #27233 (project gnustep): Setting the return value seems to have nothing to do with the problem, but I have amended the test case to reflect your concerns, although I don't know how to expose the problem without using an invocation with a non-object return

[bug #27233] GSFFIInvocations share _retval ivar while in -forwardInvocation:

URL: http://savannah.gnu.org/bugs/?27233 Summary: GSFFIInvocations share _retval ivar while in -forwardInvocation: Project: GNUstep Submitted by: thebeing Submitted on: Mi 12 Aug 2009 11:55:38 GMT Category:

[bug #27008] NSNextMapEnumeratorPair() in NSConcreteMapTable treats C-types as objects

Follow-up Comment #2, bug #27008 (project gnustep): Additionally, NSEndMapTableEnumeration() will do something similar at line #493. ___ Reply to this item at: http://savannah.gnu.org/bugs/?27008

[bug #27008] NSNextMapEnumeratorPair() in NSConcreteMapTable treats C-types as objects

Follow-up Comment #4, bug #27008 (project gnustep): Thank you for adding the comments, it's actually much clearer now why that code is there. It turns out that the code in gnustep-base wasn't responsible for my problem after all. The enumerator was initialized correctly, but the subsequent code

[bug #27008] NSNextMapEnumeratorPair() in NSConcreteMapTable treats C-types as objects

URL: http://savannah.gnu.org/bugs/?27008 Summary: NSNextMapEnumeratorPair() in NSConcreteMapTable treats C-types as objects Project: GNUstep Submitted by: thebeing Submitted on: Fr 10 Jul 2009 22:28:03 GMT Category: None

[bug #27008] NSNextMapEnumeratorPair() in NSConcreteMapTable treats C-types as objects

Follow-up Comment #1, bug #27008 (project gnustep): I'm sorry, I meant to say that this happens with svn r28389. Somehow missed that... ___ Reply to this item at: http://savannah.gnu.org/bugs/?27008

[bug #24200] NSSavePanel crashes apps

Follow-up Comment #3, bug #24200 (project gnustep): I just compiled and can confirm that the change fixed the issue for me, both with GSX11HandlesWindowDecorations set to Yes and No. Besides, I can't really see any use of setting GSSavePanelShowProgress to yes on my machine since it neither has

[bug #24200] NSSavePanel crashes apps

URL: http://savannah.gnu.org/bugs/?24200 Summary: NSSavePanel crashes apps Project: GNUstep Submitted by: thebeing Submitted on: Do 04 Sep 2008 10:04:10 GMT Category: Gui/AppKit Severity: 3 - Normal

[bug #24083] Offset issues with the xmonad WM; blank windows with the cairo backend

Follow-up Comment #5, bug #24083 (project gnustep): Hello, I'm also using GNUstep on Debian unstable (that means cairo v1.6.4, base 1.16.3 and back 0.14.0) and am experiencing the exact same problems with the cairo backend (art works like a charm), both when using GNUstep from the Debian

[bug #24083] Offset issues with the xmonad WM; blank windows with the cairo backend

Follow-up Comment #8, bug #24083 (project gnustep): I investigated the matter further and found the cairo backend to be broken with gui = rev 26815 on 64bit machines, since 26816 rendering is okay for me again. So apparently the change in NSBezierPath.m did the trick. I guess I've just been