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

[Niels Grewe]

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:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

I've just been playing around with the Gtk.theme (on an Ubuntu 17.04
installation with gtk 2.24.31) and it seems that it fails to render the
in-window menu bar. There is the following warning printed from Gtk:

(Ink:28940): Gtk-WARNING **: Attempting to add a widget with type GtkMenuBar
to a container of type GtkFixed, but the widget is already inside a container
of type GtkFixed, the GTK+ FAQ at
http://library.gnome.org/devel/gtk-faq/stable/ explains how to reparent a
widget.

I think this would be for someone with some actual knowledge of gtk to look
at.

Thanks!

Niels




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

Update of bug #48882 (project gnustep):

  Status:None => Fixed  
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

Hi Vincent!

Thanks for the report. it looks like this was broken for configurations with a
flattened filesystem layout. It should be fixed in r40063.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 installation domains and such.  Unfortunately that would require
gnustep-make to have a better model of the code that it is building (e.g.
public vs. private cflags, dependencies, etc.) 

But we can start with the simple thing.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 output of gnustep-config or just hardcoding things for a
quick and dirty solution. Thinking about it, I've come to believe that maybe
we don't want to use gnustep-config for this at all. Instead, it might be
preferable to have the GNUstep libraries to install pkg-config files for
themselves. I'd be willing to look into, but only if I don't end up being the
only person using it ;-)

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42778] Frameworks with different SONAME cannot coexist

[Niels Grewe]

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 ($(FRAMEWORK_VERSION_SUPPORT), yes)
$(ECHO_NOTHING)cd $(FRAMEWORK_DIR); \
- if [ ! -h "Resources" ]; then \
-   $(RM_LN_S) Resources; \
-   $(LN_S_RECURSIVE) Versions/Current/Resources Resources; \
- fi; \
  if [ ! -h "Headers" ]; then \
$(RM_LN_S) Headers; \
$(LN_S_RECURSIVE) Versions/Current/Headers Headers; \

It breaks resource lookups and prevents proper dynamic loading of frameworks.
I'm pretty sure that this is accidental and will revert that part.



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

Update of bug #47619 (project gnustep):

  Status:  Ready For Test => Fixed  
 Open/Closed: In Test => Closed 

___

Follow-up Comment #2:

It seems to work for me (and matches the Cocoa behaviour). The test case was a
tad glitchy because we still support count instead of @count, so it would in
fact not test the right thing, but I fixed that.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

URL:
  

 Summary: NSPredicate: aggregate function expressions
implemented incorrectly
 Project: GNUstep
Submitted by: thebeing
Submitted on: Mo 04 Apr 2016 15:04:40 GMT
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The aggregate function expressions (sum, min, max, avg) in base are
implemented as vararg functions. This is incorrect with respect to the Cocoa
implementation. There they are implemented as single argument functions that
take collections as arguments. 

In particular, the following evaluates truthy:

NSArray *a = @[ @{ @"count": @1 }, @{ @"count": @1 } ];
NSPredicate *p = [NSPredicate predicateWithFormat: @"sum(count) == 2"];
[p evaluateWithObject: a];

(sorry, literal notation for compactness). On GNUstep it raises an
NSInvalidArgumentException (because the array of NSNumbers does not implement
-doubleValue).




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #47618] NSPredicate: SELF implemented incorrectly

[Niels Grewe]

URL:
  

 Summary: NSPredicate: SELF implemented incorrectly
 Project: GNUstep
Submitted by: thebeing
Submitted on: Mo 04 Apr 2016 14:56:49 GMT
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The SELF expression in NSPredicate is implemented in a way that only allows it
to be used as LHS or RHS expression in an NSComparison predicate. 

In particular, the following is legal under Cocoa:

  NSDictionary *a = [NSDictionary dictionaryWithObjectsAndKeys: 
@"2", @"foo", nil];
  NSPredicate *p = [NSPredicate predicateWithFormat: @"SELF.foo <= 2"];
  [p evaluateWithObject: a];

The base implementation gives you:

Uncaught exception NSInvalidArgumentException, reason:
[GSEvaluatedObjectExpression-keyPath] should be overridden by subclass

You can even do more complicated expressions such as "bar[SELF.foo]", where
SELF is not a top-level expression in Cocoa.

The reason is that GSEvaluatedObjectExpression is created as a singleton, and
always returns itself from expressionValueWithObject:context:, and there is
some pointer equality checking in NSComparisonPredicate  to make it work for
the really simple case (self == 'foo'). That totally sounds like premature
optimisation to me, btw.





___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #46418] NSPredicate is missing a predicateWithBlock implementation

[Niels Grewe]

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 shorthand for [[predicate
predicateWithSubstitutionVariables: v] evaluateWithObject: o] (optimising away
the allocation of the intermediary object). 

It looks like they didn't implement that for block predicates, but we need it
to work because we don't have -evaluateWithObject:substitutionVariables: yet.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #46418] NSPredicate is missing a predicateWithBlock implementation

[Niels Grewe]

Update of bug #46418 (project gnustep):

  Status:None => Ready For Test 


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #46418] NSPredicate is missing a predicateWithBlock implementation

[Niels Grewe]

Update of bug #46418 (project gnustep):

 Assigned to:thebeing => None   
 Open/Closed:Open => In Test

___

Follow-up Comment #3:

A fun little lunch break project. Now ready for test in trunk. It needs
libobjc2 and clang for testing, though.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #46418] NSPredicate is missing a predicateWithBlock implementation

[Niels Grewe]

Update of bug #46418 (project gnustep):

 Assigned to:None => thebeing   

___

Follow-up Comment #2:

I guess I can do this

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

Update of bug #47178 (project gnustep):

 Open/Closed: In Test => Closed 

___

Follow-up Comment #2:

Thanks! It works fine for me as well now.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The JDBC backend in SQLClient will not compile because it wasn't updated
properly after the inception of the SQLClientPool code:

 Compiling file JDBC.m ...
JDBC.m: In function '+[SQLClientJVM defaultClassPath]':
JDBC.m:251:3: warning: @interface of class 'NSDictionary' not found [enabled
by default]
   return [environment objectForKey: @"CLASSPATH"];
   ^
JDBC.m: In function '+[SQLClientJVM defaultLibraryPath]':
JDBC.m:258:3: warning: @interface of class 'NSDictionary' not found [enabled
by default]
   return [environment objectForKey: @"LD_LIBRARY_PATH"];
   ^
JDBC.m: In function '-[SQLClientJDBC backendQuery:recordType:listType:]':
JDBC.m:1310:14: warning: variable 'getBinaryStream' set but not used
[-Wunused-but-set-variable]
jmethodID getBinaryStream;
  ^
JDBC.m: In function '-[SQLClientJDBC batch:]':
JDBC.m:1524:14: error: 'struct _JDBCTransaction' has no member named '_db'
   transaction->_db = [self retain];
  ^
JDBC.m: In function '-[SQLClientJDBC transaction]':
JDBC.m:1683:14: error: 'struct _JDBCTransaction' has no member named '_db'
   transaction->_db = [self retain];
  ^
JDBC.m: In function '-[_JDBCTransaction execute]':
JDBC.m:1739:12: error: '_db' undeclared (first use in this function)
   if ([_db connect] == NO)
^
JDBC.m:1739:12: note: each undeclared identifier is reported only once for
each function it appears in
JDBC.m:1789:13: warning: variable 'js' set but not used
[-Wunused-but-set-variable]
 jobject js;
 ^
make[3]: *** [obj/JDBC.obj/JDBC.m.o] Error 1

As you can see, it tries to access the _db ivar on SQLTransaction, which is
now gone and replaced with a _owner ivar that holds either an SQLClient or an
SQLClientPool.




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #46939] -Werror set for GSSpeechServer

[Niels Grewe]

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
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Currently, the GSSpeechServer tool is really difficult to get to build because
it sets the -Werror flag on all source files. I stumbled upon this recently
when I wrote my VM build scripts, but see also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811928.
 
Philosophically speaking, I'm quite in favour of -Werror (no warnings means no
petty little problems to obscure big ones), but we don't do it anywhere else
(as far as I'm aware), so it might make sense to remove it?

Cheers,

Niels




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #43915] Simple bug in NSCountedSet comparsons

[Niels Grewe]

Update of bug #43915 (project gnustep):

  Status:None => Ready For Test 
 Open/Closed:Open => In Test

___

Follow-up Comment #2:

Thanks Vincent for the bug report and Oleg for the suggested fix!
Unfortunately, things are slightly more complicated since some subclasses
implemented optimisations for the equality checking, so I decided to do things
a bit differently (among other things to avoid having to check which subclass
we're dealing with). This should now be fixed in trunk (r38470) 

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

URL:
  

 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: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

At some places, property list deserialisation queries some information about
the format using the GSPrivateDefaultsFlag() function. That function depends
on the user defaults being properly initialised.

 It turns out that this is a bit unsafe is we are deserialising the plist as
part of initialisation of the defaults system. You can easily reproduce this
if you add a `-Foo "{ Foo = Bar }"' (note how the semicolon is missing
after`Bar') to the invocation of any GNUstep app or tool. The plist parser
then queries the GSMacOSXCompatible flag to find to whether it should just
warn about the error or reject the plist. There are a couple of other places
where we are using the function, so I think we should review them and change
the code to adopt a sensible default when the user defaults are not yet set
up.




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

URL:
  

 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 15:50:24 GMT
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

On Mac OS X, when you call -description on a dictionary that contains
NSCalendarDate objects, it respects the calendar format set for the object.
When you do the same with gnustep-base, you get a standard timestamp instead.
The reason is that we have proper support for NSDate in ASCII property lists
:-) So I'm not quite sure whether we want to modify our behaviour to match the
OS X implementation, since it would mean that we'd have to have a special case
in GSPropertyListMake() just for this. (Also, when writing XML plists, Cocoa
will disregard the calendar format set for the object as well).




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #37706] SQLClient links explicitly against -lobjc

[Niels Grewe]

Update of bug #37706 (project gnustep):

  Status:  Ready For Test => Fixed  
 Open/Closed: In Test => Closed 


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #37706] SQLClient links explicitly against -lobjc

[Niels Grewe]

Update of bug #37706 (project gnustep):

  Status:None => Ready For Test 
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

Hi,

I replaced all occurrences of -lobjc and -lgnustep-base with gnustep-make's
$(FND_LIBS) and $(OBJC_LIBS) variables, which should do the right thing.
Please test...

Cheers,

Niels

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

Update of bug #37130 (project gnustep):

  Status:   Confirmed => Ready For Test 
 Open/Closed:Open => In Test

___

Follow-up Comment #11:

Hi,

as it turns out, the sorting stuff in -base needed a little love in general 
(for instance, -sortUsingFunction: and -sortUsingSortDescriptors: were
implemented without resusing any code, one implemeting shellsort, the other
quicksort). I consolidated all this stuff into an API that can be used with
blocks, functions, or sort descriptors and also has plugable sort algorithms.
I implemented the NSComparator related sorting/insertion point searching
methods using this. 

For the stable sort algorithm (actually, I made it the default for all
sorting) we now have timsort. It seems to work well in my tests, but it is a
complex beast and could definitely use some more testing and a few pairs of
eyes looking at it.

Cheers,


Niels

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 check.) 

As far as the choice of sort algorithm is concerned, I highly suspect that
Apple has actually implemented their sorting stuff with mergesort, because it
is inherently easy to do it in parallel and they seem to like that :-) (by the
way: while Thomas' mergesort implementation is stable, you can also do
mergesort in an unstable way, depending on how you slice the array).

Another alternative that we could consider is timsort, which is the default
sorting algorithm in Python, Android and Java 7 and is said to be marvellously
fast for partially pre-sorted inputs as they occur in real-world settings. It
is stable, but I didn't see any obvious avenues for parallel execution.
(Anyways, I suspect that you'd need to throw a lot of cores at a parallel
mergesort to beat timsort in something other than a contrived
micro-benchmark).

(Actually, you can read that as an endorsement that I might consider it a fun
project to implement timsort in -base…)

Cheers,

Niels 


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

Update of bug #37130 (project gnustep):

  Item Group: Bug => Change Request 
 Assigned to:None => thebeing   

___

Follow-up Comment #1:

Nice! 

Thanks alot for the patch, especially since it removes one item from my todo
list :-). I have one remark, though: If you want to call blocks in
gnustep-base, you need to use the CALL_BLOCK macro, which ensures that we can
compile gnustep-base with GCC and still use blocks properly.

Since this is clearly a substantial patch: Have you signed a copyright
assignment with the FSF? -- We'd require that before incorporating the patch.

Many thanks,

Niels

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 escalated using -Werror, so gnustep-make is not generating
invalid code here (there are perfectly sensible reasons for implementing root
classes, after all). But there seems to be no valid reason why the framework
dummy-classes should be root-classes, so I went ahead applied your patch.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 tests with libobjc2 trunk.

Cheers,

Niels 

(file #26124)
___

Additional Item Attachment:

File name: performSel.patch   Size:1 KB


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

Follow-up Comment #5, bug #36706 (project gnustep):

Hi Fred,

It seems like you're correct. At least, Apple runtime reference documentation
explicitly states that class_getMessageImplementation() might return a pointer
to `a part of the runtime's message forwarding machinery'. So we technically
would need to modify the behaviour of our runtime to be compatible with the
Apple implementation. 

Since that is a bit tedious (since it means juggling around with varargs and
various places where the return value might end up), my is a take on this
issue is that we should, in the meantime, do two things:

a) Don't raise an exception in gs_objc_msg_forward2(), just return NULL if we
cannot get a signature to construct a cframe for. The function is a hook for
the runtime, which should tolerate if the forwarding mechanism doesn't come up
with a sensible match.

b) Amend our implementation of `-performSelector:' to just use
objc_msg_lookup() and call the returned IMP. This is what a message send
compiles to anyways, which (I think) should be more robust than the present
code that calls class_getMethodImplementation(). But then again I might be
missing the reason why we did it that way in the first place...

Cheers,

Niels

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

Update of bug #35802 (project gnustep):

  Status:  Ready For Test => Fixed  
 Open/Closed: In Test => Closed 


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 the -unarchiverDidFinish:
delegate method on the IBObjectContainer to trigger a complete decoding of the
IBObjectRecords. But here I'm assuming that IBObjectRecords only ever occur in
IBObjectContainers...

But then on the other hand, I might be way off here.

Cheers,

Niels

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #35934] -[GormViewEditor editedObjectFrameDidChange: infinite loop

[Niels Grewe]

URL:
  

 Summary: -[GormViewEditor editedObjectFrameDidChange:
infinite loop
 Project: GNUstep
Submitted by: thebeing
Submitted on: Mi 21 Mär 2012 14:33:55 GMT
Category: Gorm
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hi guys,

I'm not quite familiar with the Gorm internals but I just experienced a
situation where Gorm was doing an infinite resize loop when creating a window
upon "Document"->"New Application". I Could track this down to the fact that
GormViewEditor tracks the frame of the edited object and, sometimes, seems to
be the edited object itself (?). Consequently, you get a nice little infinite
loop via the NSViewFrameDidChangeNotification:

 #6  0x77a86791 in -[GormViewEditor editedObjectFrameDidChange:]
(self=0x17632c8, _cmd=0x77d39780, sender=0x1774138) at
GormViewEditor.m:328
#7  0x75d90097 in -[NSNotificationCenter _postAndRelease:] ()
   from
/usr/GNUstep/System/Library/Libraries/x86_64/linux-gnu/gnu-gnu-gnu/libgnustep-base.so.1.24
#8  0x75d90cff in -[NSNotificationCenter
postNotificationName:object:userInfo:] ()
   from
/usr/GNUstep/System/Library/Libraries/x86_64/linux-gnu/gnu-gnu-gnu/libgnustep-base.so.1.24
#9  0x75d90a81 in -[NSNotificationCenter postNotificationName:object:]
()
   from
/usr/GNUstep/System/Library/Libraries/x86_64/linux-gnu/gnu-gnu-gnu/libgnustep-base.so.1.24
#10 0x76b648f0 in -[NSView setFrame:] (self=0x171ace8,
_cmd=0x7704ef90, frameRect=...) at NSView.m:1229
#11 0x76b6b638 in -[NSView resizeWithOldSuperviewSize:]
(self=0x171ace8, _cmd=0x7704ef00, oldSize=...) at NSView.m:2058
#12 0x76b6adf6 in -[NSView resizeSubviewsWithOldSize:]
(self=0x17632c8, _cmd=0x7704e9c0, oldSize=...) at NSView.m:1933
#13 0x76b64860 in -[NSView setFrame:] (self=0x17632c8,
_cmd=0x77d82e10, frameRect=...) at NSView.m:1226
#14 0x77a86791 in -[GormViewEditor editedObjectFrameDidChange:]
(self=0x17632c8, _cmd=0x77d39780, sender=0x17740d8) at
GormViewEditor.m:328
#15 0x75d90097 in -[NSNotificationCenter _postAndRelease:] ()
   from
/usr/GNUstep/System/Library/Libraries/x86_64/linux-gnu/gnu-gnu-gnu/libgnustep-base.so.1.24
#16 0x75d90cff in -[NSNotificationCenter
postNotificationName:object:userInfo:] ()
   from
/usr/GNUstep/System/Library/Libraries/x86_64/linux-gnu/gnu-gnu-gnu/libgnustep-base.so.1.24
#17 0x75d90a81 in -[NSNotificationCenter postNotificationName:object:]
()
   from
/usr/GNUstep/System/Library/Libraries/x86_64/linux-gnu/gnu-gnu-gnu/libgnustep-base.so.1.24
#18 0x76b648f0 in -[NSView setFrame:] (self=0x171ace8,
_cmd=0x7704ef90, frameRect=...) at NSView.m:1229
#19 0x76b6b638 in -[NSView resizeWithOldSuperviewSize:]
(self=0x171ace8, _cmd=0x7704ef00, oldSize=...) at NSView.m:2058
#20 0x76b6adf6 in -[NSView resizeSubviewsWithOldSize:]
(self=0x17632c8, _cmd=0x7704e9c0, oldSize=...) at NSView.m:1933
#21 0x76b64860 in -[NSView setFrame:] (self=0x17632c8,
_cmd=0x77d82e10, frameRect=...) at NSView.m:1226
#22 0x77a86791 in -[GormViewEditor editedObjectFrameDidChange:]
(self=0x17632c8, _cmd=0x77d39780, sender=0x17393b8) at
GormViewEditor.m:328

My local workaround is to disable the notification before setting the frame
and then reenabling it aftewards, but somebody with more insight into Gorm
should take a look at it. This happens for me on an x86_64 Linux machine with
recent (last night), base, gui, back and Gorm, (it's all built using clang
with the non-fragile ABI, but I don't know whether that's related).

Cheers,

Niels




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 problem where
clang (on x86_64 only) made NSConnection and friends go haywire. It wasn't an
exactly well defined problem so eventually *somebody* did *something* that
made it go away. Unfortunately, I have a hard time digging up the
correspondence on that bug.
Are you seeing this on a 64bit or 32bit arch? If it's on 64bit,  maybe it
could be related to the recent NSNotFound changes in NSConnection  (r34884)? 

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

Update of bug #35802 (project gnustep):

  Status:None => Ready For Test 
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

Hi,

when building libobjc2 with Makefile.clang, the `llc' tool is responsible for
generating native code from the LLVM bitcodes generated by clang. So we needed
to tell llc to build relocatable code. This should be fixed in trunk, but
Makefile.clang still seems horribly out of date. But you should be able to
build the library with `CC=clang make -f Makefile' as well.

Cheers,

Niels

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 savannah.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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
disjoint from those you send messages to from thread B (and vice-versa).
And while I agree that this can be quite tedious for a complex application,
it's even worse with the GCC runtime: If you only got the global lock, you
have to make sure that every single class that might potentially receive
messages in another thread is initialized before you go multi-threaded, which
really isn't feasible at all for a non-trivial application. 

For example, in DBusKit I need a whole pile of code that postpones creation of
a worker thread until all +initialize methods in the related DBusKit classes
have run just to work around this limitation of the GCC runtime. Not a single
line of this stuff is actually required with libobjc2.  

Cheers,

Niels

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 (if so, we set the
-march=i568 flag).
(c) Whether we need to explicitly link the static libgcc.

I concur that doing something like (b) in gnustep-make is probably a good
idea, but I think we should have that check here as a stop-gap measure because
if you have a gcc version built for i686 (like my Ubuntu VM, for example), the
libgcc will have been compiled without any atomic ops stuff.

It would be nice if somebody could check whether the change has the desired
effect on an i486 machine.

Cheers,

Niels

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 want to utilize the complete feature-set their processor
provides. 

I don't think it's a big portability issue, though: On most platforms, GCC has
code emulating atomic operations in libgcc.a, which will be used when it
cannot (or refuses to) emit target specific assembly for that purpose. The
trick is to get it to link the static library if required. I have an autoconf
thingy in DBusKit that checks whether the atomic ops are provided as builtins
or library functions and adjusts the LDFLAGS accordingly. Should I try adding
it to -base as well?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30427] Please port to native Avahi

[Niels Grewe]

Follow-up Comment #1, bug #30427 (project gnustep):

Hello Yavor,

a while back, I implemented native Avahi support for NSNetServices, mostly
because of the reasons you describe (i.e. the compatibility layer being
everything but well maintained). You can take a look at the patch at [0],
though I'm not sure whether it still applies correctly. But while it should
work, it's not the most sensible thing to do. Ideally, we would want to talk
to Avahi via its D-Bus interface (and avoid all the runloop integration
stuff). 

Allowing this is one of the motivations for my present work on D-Bus
integration for GNUstep as part of GSoC (see libs/dbuskit in svn), though I'm
not quite sure how to integrate it because at the moment, that code is
designed as a separate framework depending on gnustep-base. I'll keep you
updated on the further developments.

Cheers,

Niels

[0] http://www.halbordnung.de/~niels.grewe/gnustep/NSNetServices+avahi.patch

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 gnustep-base is being configured for.

Cheers,

Niels

PS: This also made a weird problem go away where -base was claiming that the
runtime didn't support uncaught exception handlers.

(file #20073)
___

Additional Item Attachment:

File name: configure.diff Size:0 KB


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 gnustep-make", do you mean from filesystem.*? Because
there I have GNUSTEP_(SYSTEM|LOCAL)_(HEADERS|LIBRARIES) set to the values for
the flattened layout. (Still gnustep-make will compile and install stuff just
fine and non-flattened.)

Any ideas?

Cheers,


Niels

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

URL:
  

 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: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hi,

I configured -make with a non-flattened namespace and recently ran into some
problems where the configure script wouldn't detect an installed libobjc2
properly. It turns out that apparently, it doesn't know about non-flattened
namespaces since it is trying to buld stuff with the following commandline:

clang -o conftest -g -O2 -I/usr/inlcude/x86_64-linux-gnu
-I/usr/GNUstep/System/Library/Headers -I/usr/GNUstep/Local/Library/Headers
-fgnu-runtime -x objective-c  -L/usr/GNUstep/System/Library/Libraries
-L/usr/GNUstep/Local/Library/Libraries conftest.c -ldl  -lobjc   -lpthread

Here the include and library paths should include $LIBRARY_COMBO or
$GNUSTEP_TARGET_LDIR to always point to the right place. I suspect (hope?) the
fix is trivial, but I unfortunately know nothing about autoconf.

Cheers,


Niels




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

Follow-up Comment #4, bug #27233 (project gnustep):

Although my code does not use that invocation-recording approach anymore (it
was unsound design to begin with), I checked this out once more and can
confirm that it's working for me now.
Many thanks for tracking this one done!

Cheers,


Niels

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

URL:
  

 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
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hello,

I've encountered some problems with the DO mechanism:  Vending objects for
local DO seems to be just fine (the corresponding sockets and name-service
files are being created in $TMPDIR/NSMessagePort/(names|ports), but
-rootProxyForConnectionWithRegisteredName:host: returns nil no matter what. As
far as I can tell from stepping through the code, the client obtains the port
just well so it does not seem to be a name service problem. The problem does
not only occur on 64bit Linux but also on other platforms I could test on
(32bit Linux, 64bit FreeBSD) with svn r28670. 

I have attached a test case (which works on Mac OS X) that demonstrates the
problem. Any help is greatly appreciated.

kind regards,


Niels



___

File Attachments:


---
Date: Mo 14 Sep 2009 18:06:58 GMT  Name: do-problem.m  Size: 1kB   By:
thebeing
Test case


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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
(CLEAR_RETURN_VALUE_IF_OBJECT will properly reset _retval to nil so you're not
getting into trouble in that case). I also had the chance to test the code on
Cocoa and can confirm that it works there.

Cheers,


Niels

(file #18592)
___

Additional Item Attachment:

File name: test.m Size:2 KB


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

URL:
  

 Summary: GSFFIInvocations share _retval ivar while in
-forwardInvocation:
 Project: GNUstep
Submitted by: thebeing
Submitted on: Mi 12 Aug 2009 11:55:38 GMT
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hello,

I encountered an odd problem with invocations (GNUstep SVN r28455, 64bit
Debian Linux with libffi 3.0.7). I'm working on a class that records
invocations for later use. The seems to be no problem as long as those
invocations are invoked from outside -forwardInvocation:. 

But whenever I invoke those invocations from -forwardInvocation: their
respective _retval ivars point to the same chunk of memory. This causes a
problem as soon as you have two invocations with different return types. (eg.
BOOL and id) If you invoke the id invocation first, it will set _validReturn
to yes and places a reference to the returned object in _retval. 
Invoking the BOOL invocation afterwards will then modify the _retval field to
hold its own return value. 
If you invoke the id invocation again afterwards, it will try to release
_retval with CLEAR_RETURN_VALUE_IF_OBJECT because _validReturn is YES and
info[0].type is _C_ID. This causes a message lookup to a class at some invalid
address (0x1 or 0x0 in this case) and results in a segfault. I have appended a
test case to demonstrate the problem.

kind regards,


Niels



___

File Attachments:


---
Date: Mi 12 Aug 2009 11:55:38 GMT  Name: test.m  Size: 2kB   By: thebeing
Test case


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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  (initially written for 32bit archs) wasn't entirely 64bit
safe, so the variables began trampling over each other. I guess that the map
field was simply overwritten, causing the wrong code path to be selected. 
I'm sorry for the confusion, but thank you nonetheless for the
clarification!

Cheers,


Niels

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

Follow-up Comment #2, bug #27008 (project gnustep):

Additionally, NSEndMapTableEnumeration() will do something similar at line
#493.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

URL:
  

 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
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hello,

I just experienced some wiredness with NSMapTable. NSNextMapEnumeratorPair()
seems to fail on lines #870 and 886 of NSConcreteMapTable.m (r. The
incriminated lines read:

idk = [(NSEnumerator*)enumerator->node nextObject];

and

*value = [(NSMapTable*)enumerator->bucket objectForKey: k];

respectively. From what I gather, it doesn't make sense here to treat these
as objects ('node' in the _GSIMapEnumerator struct is a GSIMapNode structure
and 'bucket' is size_t). My own attempts at fixing this failed because I
obviously don't grok GSIMap ;-)

I hope that I've diagnosed the problem correctly. If you need any further
information, please ask.

kind regards,


Niels




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #25004] NSWindowontroller -initWithCoder fails for NSKeyedUnarchivers/ NSKeyedUnarchiver doesn't implement -versionForClassName

[Niels Grewe]

URL:
  

 Summary: NSWindowontroller -initWithCoder fails for
NSKeyedUnarchivers/ NSKeyedUnarchiver doesn't implement -versionForClassName
 Project: GNUstep
Submitted by: thebeing
Submitted on: Mi 03 Dez 2008 16:01:12 GMT
Category: None
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hi,

I recently stumbled upon the following problem, which probably needs some
attention:
Since rev 26959 the -initWithCoder method of NSWindowController calls the
-versionForClassName method of the coder. This approach fails if the coder is
a NSKeyedUnarchiver, which doesn't implement the -versionForClassName method.
Since NSCoder declares this method a subclassResponsibility, decoding nibs can
sometimes raise an exception. As is the case with the MainMenu.nib of the
StepChat application from the Étoilé project
(http://svn.gna.org/svn/etoile/trunk/Etoile/Services/User/Jabber/English.lproj/MainMenu.nib).

best regards 


Niels




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #24200] NSSavePanel crashes apps

[Niels Grewe]

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 large enough directories nor contrained enough resources, so I
can't comment on whether the changed string gets drawn.

Cheers,


Niels

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #24200] NSSavePanel crashes apps

[Niels Grewe]

URL:
  

 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
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hello,

I am experiencing segmentation faults with GNUstep trunk on Debian unstable
x86-64 whenever an application tries to create a NSSavePanel (according to gdb
backtrace) and would like to ask for advice on what might be causing this. It
happens with both the cairo and the art backend. I have attached a backtrace
from running and crashing Gorm, but the problem occurs with other applications
(ProjectCenter, EasyDiff) too. I hope it will be usefull.

best regards,


Niels

Relevant versions:
base,gui,back: svn r26830
cairo: 1.6.4
libart:  1.4.2





___

File Attachments:


---
Date: Do 04 Sep 2008 10:04:10 GMT  Name: gorm-backtrace  Size: 7kB   By:
thebeing
Backtrace from running Gorm


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 missing a few (curcial) revisions. 
Thank you for pointing me into the right direction with this issue!

Cheers,

Niels

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Niels Grewe]

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 repository and when compiling from trunk. The bug occurs regardless of
X-server or window-manager, but I have so far only been able to reproduce it
under the amd64/x86_64 architecture, not on 32bit systems. So I'm guessing
that this might be implicated in this bug.
If there is any further testing/posting debug-logs that would be helpfull, I
would be glad to help out.

best regards


Niels

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep