Re: Gorm brokeness
Hi! I installed a current version of libffi, namely version 3.0.9, now everything works as expected. Looks like the one shipped with gcc 4.2.4 on my system is not up to the task. Cheers, TOM Zitat von Gregory Casamento : There should be no theming "magic" responsible for what's going on. Could you write up a bug on this issue on the bugtracker? I've tried a few times to recreate what you're seeing my on x86_64 machine running debian (for x86_64) without any luck. I'll try on my 32bit machine to see if I can recreate it there. GC On Sat, Mar 20, 2010 at 12:37 PM, wrote: Hi! I am again able to select an item in a Gorm palette and drag it to some destination. Images are still missing, NSTabView ist still broken, same as radio buttons. So I started Gorm in gdb and had a look what is going on. I set breakpoints in [NSButtonCell setImage:] and in the corresponding parent classes methods (NSActionCell and NSCell). I found some odd behaviour there. NSCell.m, line 1190, that's where [NSCell setImage:] is. At the start of the method "anImage" is a valid pointer, after the line containing the NSAssert, "anImage" sometime is set to nil. I do not know what is causing this, since there is some proxy resolution going on and I don't have a clue about that stuff. Basically rather often the ASSIGN at the bottom of [NSCell setImage:] gets fed a nil value, so it is not a surprise that I am missing images. At least I think so, maybe I am misunderstanding the code because of all the theming magic which is going on... Cheers, TOM Zitat von Fred Kiefer : Am 07.03.2010 15:09, schrieb ici...@mail.cg.tuwien.ac.at: Because of my ongoing issues with current GNUstep from svn today I decided to do a fresh start and removed all GNUstep installation related files from my hardrive. After that I did a svn update and did a fresh build of core and gorm. Looks like Gorm is as of now rather broken. I can open an existing document of mine, I can create a new document, but the palettes do not work. I can select a palette, but I am unable to actually select an item, like a button, and drag it into a window. Also the inspector seems broken, it does not display stuff like RadioButtons or button icons. I attached two screenshots. Looks like the NSTabView issues are just syntoms of the same underlying problem. NSTabView does display correctly if it is told to display it's "item bar" at the bottom, screenshots are attached. Now that all your images are gone I would say that this is after all the same problem that Richard is having. I hope to work on this together with Richard. At the moment I don't have any 32 bit Unix system to reproduce this behaviour, so it will be hard for me to track it down alone. Fred ___ 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 -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
There should be no theming "magic" responsible for what's going on. Could you write up a bug on this issue on the bugtracker? I've tried a few times to recreate what you're seeing my on x86_64 machine running debian (for x86_64) without any luck. I'll try on my 32bit machine to see if I can recreate it there. GC On Sat, Mar 20, 2010 at 12:37 PM, wrote: > Hi! > > I am again able to select an item in a Gorm palette and drag it to some > destination. Images are still missing, NSTabView ist still broken, same as > radio buttons. So I started Gorm in gdb and had a look what is going on. I > set breakpoints in [NSButtonCell setImage:] and in the corresponding parent > classes methods (NSActionCell and NSCell). I found some odd behaviour there. > NSCell.m, line 1190, that's where [NSCell setImage:] is. At the start of the > method "anImage" is a valid pointer, after the line containing the NSAssert, > "anImage" sometime is set to nil. I do not know what is causing this, since > there is some proxy resolution going on and I don't have a clue about that > stuff. Basically rather often the ASSIGN at the bottom of [NSCell setImage:] > gets fed a nil value, so it is not a surprise that I am missing images. At > least I think so, maybe I am misunderstanding the code because of all the > theming magic which is going on... > > Cheers, > TOM > > > Zitat von Fred Kiefer : > >> Am 07.03.2010 15:09, schrieb ici...@mail.cg.tuwien.ac.at: >>> >>> Because of my ongoing issues with current GNUstep from svn today I >>> decided to do a fresh start and removed all GNUstep installation related >>> files from my hardrive. After that I did a svn update and did a fresh >>> build of core and gorm. Looks like Gorm is as of now rather broken. I >>> can open an existing document of mine, I can create a new document, but >>> the palettes do not work. I can select a palette, but I am unable to >>> actually select an item, like a button, and drag it into a window. Also >>> the inspector seems broken, it does not display stuff like RadioButtons >>> or button icons. I attached two screenshots. Looks like the NSTabView >>> issues are just syntoms of the same underlying problem. NSTabView does >>> display correctly if it is told to display it's "item bar" at the >>> bottom, screenshots are attached. >> >> Now that all your images are gone I would say that this is after all the >> same problem that Richard is having. >> I hope to work on this together with Richard. At the moment I don't have >> any 32 bit Unix system to reproduce this behaviour, so it will be hard >> for me to track it down alone. >> >> Fred >> >> >> ___ >> 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 > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
Hi! I am again able to select an item in a Gorm palette and drag it to some destination. Images are still missing, NSTabView ist still broken, same as radio buttons. So I started Gorm in gdb and had a look what is going on. I set breakpoints in [NSButtonCell setImage:] and in the corresponding parent classes methods (NSActionCell and NSCell). I found some odd behaviour there. NSCell.m, line 1190, that's where [NSCell setImage:] is. At the start of the method "anImage" is a valid pointer, after the line containing the NSAssert, "anImage" sometime is set to nil. I do not know what is causing this, since there is some proxy resolution going on and I don't have a clue about that stuff. Basically rather often the ASSIGN at the bottom of [NSCell setImage:] gets fed a nil value, so it is not a surprise that I am missing images. At least I think so, maybe I am misunderstanding the code because of all the theming magic which is going on... Cheers, TOM Zitat von Fred Kiefer : Am 07.03.2010 15:09, schrieb ici...@mail.cg.tuwien.ac.at: Because of my ongoing issues with current GNUstep from svn today I decided to do a fresh start and removed all GNUstep installation related files from my hardrive. After that I did a svn update and did a fresh build of core and gorm. Looks like Gorm is as of now rather broken. I can open an existing document of mine, I can create a new document, but the palettes do not work. I can select a palette, but I am unable to actually select an item, like a button, and drag it into a window. Also the inspector seems broken, it does not display stuff like RadioButtons or button icons. I attached two screenshots. Looks like the NSTabView issues are just syntoms of the same underlying problem. NSTabView does display correctly if it is told to display it's "item bar" at the bottom, screenshots are attached. Now that all your images are gone I would say that this is after all the same problem that Richard is having. I hope to work on this together with Richard. At the moment I don't have any 32 bit Unix system to reproduce this behaviour, so it will be hard for me to track it down alone. Fred ___ 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
Re: Gorm brokeness
On Mon, Mar 8, 2010 at 1:54 AM, Matt Rice wrote:
> It doesn't seem related, but i've also been seeing some runtime weirdness
> where objc_lookup_class("NSString") returns a bad class variable,
figured this out wasn't runtime related at all, but a missing #include
where the caller was defaulting the return value to int.
missed the warning in the plethora of other warnings.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
Am 08.03.2010 10:30, schrieb Richard Frith-Macdonald: > > On 8 Mar 2010, at 06:22, Richard Frith-Macdonald wrote: > >> >> On 7 Mar 2010, at 19:10, Fred Kiefer wrote: >> >>> Just to keep you informed on my current finding. I could follow a >>> mouse down event that should start a drag into the method >>> [XGDragView >>> dragImage:at:offset:event:pasteboard:source:slideBack:] there the >>> call to mimeTypeForPasteboardType() seems to fail, when doing >>> manual calls in gdb I get >>> >>> (gdb) po pboard (gdb) p [pboard types] >>> $14 = (class NSArray *) 0x109a610 (gdb) po [pboard types] >>> (gdb) p [[pboard types] count] $15 = >>> (void *(*)()) 0x7fffef701000 (gdb) p (int)[[pboard types] count] >>> $16 = -277884928 (gdb) p (long)[[pboard types] count] $17 = >>> 140737210454016 >>> >>> Now this may not the the root of the problem, but it looks >>> strange to me. But why wont the function >>> mimeTypeForPasteboardType return? After adding a breakpoint in >>> [NSException raise] I get: >>> >>> (gdb) bt #0 -[NSException raise] (self=0x1056940, >>> _cmd=0x76c03ab0) at NSException.m:899 #1 0x76818300 >>> in -[NSConnection(GNUstepExtensions) forwardInvocation:forProxy:] >>> (self=0xfba420, _cmd=0x76c105c0, inv=0x1062840, >>> object=0x11a81a0) at NSConnection.m:2090 #2 0x76928507 >>> in GSFFIInvocationCallback (cif=, >>> retp=0x7fffc670, args=, user=>> optimized out>) at GSFFIInvocation.m:636 #3 0x747d9729 >>> in ffi_closure_unix64_inner (closure=, >>> rvalue=, reg_args=0x75d04d3a, >>> argp=0x7fffc690 "@#�") at src/x86/ffi64.c:620 #4 >>> 0x747da0b0 in ffi_closure_unix64 () at >>> src/x86/unix64.S:228 #5 0x731f799a in >>> mimeTypeForPasteboardType (types=, >>> zone=, xDisplay=) at >>> XGDragView.m:140 #6 -[XGDragView >>> dragImage:at:offset:event:pasteboard:source:slideBack:] >>> (types=, zone=, >>> xDisplay=) at XGDragView.m:217 #7 >>> 0x77b3895d in -[GormPaletteView mouseDown:] >>> (self=0xcdd460, _cmd=, theEvent=0xf8cd00) at >>> GormPalettesManager.m:236 #8 0x76ff7393 in -[NSWindow >>> sendEvent:] (self=0xc32340, _cmd=, >>> theEvent=0xf8cd00) at NSWindow.m:3666 #9 0x76e94af4 in >>> -[NSApplication run] (self=, _cmd=>> optimized out>) at NSApplication.m:1530 #10 0x76e7612e in >>> NSApplicationMain (argc=, argv=>> optimized out>) at Functions.m:74 #11 0x75ca5a7d in >>> __libc_start_main () from /lib64/libc.so.6 #12 0x00401ac9 >>> in _start () at ../sysdeps/x86_64/elf/start.S:113 >>> >>> (gdb) po self >>> NAME:NSInvalidArgumentException REASON:subclass >>> GSMutableArray(instance) should override count >>> >>> >>> Looks like this method go lost in recent rewrites of base :-) >> >> Absolutely not. It's 'inherited' from GSArray using behavors, so >> should not be implemented in GSMutableArray. Also, many of the >> regression tests and lots of other code would clearly have failed >> horribly if mutable arrays didn't work. So how can you get this >> exception? Presumably some runtime issue. I rewrote the behavior >> code to use the new runtime API rather than the old one, and while >> it's clearly working fine most of the time, perhaps there's >> something finding a bug in this case? >> >>> I will fix this and also change all the parameters in GSArray.m >>> to NSUInteger that are now changed in the super class NSArray. >> >> Now this looks also like a possible cause of the problem >> (especially if the people experiencing this problem are using 64bit >> systems and it's not showing up on any 32bit systems). >> >> I'll remove the -count method again, and we can see whether the >> change to using NSUInteger fixed the issue. >> >> I''ll also look see if I can spot any possible problem in the >> mechanism for inheriting -count. > > None spotted so far. I have improved the debug though... > > If you set the GNUSTEP_BEHAVIOR_DEBUG environment variable to YES, > you will get all the inherited behaviors logged to stderr and can see > if there is anything going wrong there. It will report each method > added or replaced in the class (as well as methods skipped because > the class already has an implementation). > > So if the NSUinteger changes did not fix things, and there is an > issue with 'inheriting' the -count method, this should give us a clue > about where to look. This seems to work now correctly. Here the output of starting up Gorm: Adding behavior to class NSMutableDataMalloc instance methods from NSDataMalloc 3 skipped -initWithBytesNoCopy:length:freeWhenDone: skipped -dealloc skipped -copyWithZone: class methods from NSDataMalloc 0 none. Adding behavior to class NSMutableDataMalloc instance methods from NSDataStatic 10 added -deserializeTypeTag:andCrossRef:atCursor: added -deserializeDataAt:ofObjCType:atCursor:context: added -length added -getBytes:range: added -bytes skipped -classForCoder skipped -initWithBytesNoCo
Re: Gorm brokeness
Am 08.03.2010 07:22, schrieb Richard Frith-Macdonald: > > On 7 Mar 2010, at 19:10, Fred Kiefer wrote: > >> Just to keep you informed on my current finding. I could follow a mouse >> down event that should start a drag into the method [XGDragView >> dragImage:at:offset:event:pasteboard:source:slideBack:] there the call >> to mimeTypeForPasteboardType() seems to fail, when doing manual calls in >> gdb I get >> >> (gdb) po pboard >> >> (gdb) p [pboard types] >> $14 = (class NSArray *) 0x109a610 >> (gdb) po [pboard types] >> >> (gdb) p [[pboard types] count] >> $15 = (void *(*)()) 0x7fffef701000 >> (gdb) p (int)[[pboard types] count] >> $16 = -277884928 >> (gdb) p (long)[[pboard types] count] >> $17 = 140737210454016 >> >> Now this may not the the root of the problem, but it looks strange to >> me. But why wont the function mimeTypeForPasteboardType return? >> After adding a breakpoint in [NSException raise] I get: >> >> (gdb) bt >> #0 -[NSException raise] (self=0x1056940, _cmd=0x76c03ab0) at >> NSException.m:899 >> #1 0x76818300 in -[NSConnection(GNUstepExtensions) >> forwardInvocation:forProxy:] (self=0xfba420, >>_cmd=0x76c105c0, inv=0x1062840, object=0x11a81a0) at >> NSConnection.m:2090 >> #2 0x76928507 in GSFFIInvocationCallback (cif=> out>, retp=0x7fffc670, >>args=, user=) at >> GSFFIInvocation.m:636 >> #3 0x747d9729 in ffi_closure_unix64_inner (closure=> optimized out>, >>rvalue=, reg_args=0x75d04d3a, >> argp=0x7fffc690 "@#�") >>at src/x86/ffi64.c:620 >> #4 0x747da0b0 in ffi_closure_unix64 () at src/x86/unix64.S:228 >> #5 0x731f799a in mimeTypeForPasteboardType (types=> optimized out>, >>zone=, xDisplay=) at >> XGDragView.m:140 >> #6 -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] >> (types=, >>zone=, xDisplay=) at >> XGDragView.m:217 >> #7 0x77b3895d in -[GormPaletteView mouseDown:] (self=0xcdd460, >> _cmd=, >>theEvent=0xf8cd00) at GormPalettesManager.m:236 >> #8 0x76ff7393 in -[NSWindow sendEvent:] (self=0xc32340, >> _cmd=, >>theEvent=0xf8cd00) at NSWindow.m:3666 >> #9 0x76e94af4 in -[NSApplication run] (self=> out>, _cmd=) >>at NSApplication.m:1530 >> #10 0x76e7612e in NSApplicationMain (argc=, >> argv=) >>at Functions.m:74 >> #11 0x75ca5a7d in __libc_start_main () from /lib64/libc.so.6 >> #12 0x00401ac9 in _start () at ../sysdeps/x86_64/elf/start.S:113 >> >> (gdb) po self >> NAME:NSInvalidArgumentException REASON:subclass >> GSMutableArray(instance) should override count >> >> >> Looks like this method go lost in recent rewrites of base :-) > > Absolutely not. > It's 'inherited' from GSArray using behavors, so should not be implemented in > GSMutableArray. > Also, many of the regression tests and lots of other code would clearly have > failed horribly if mutable arrays didn't work. > So how can you get this exception? Presumably some runtime issue. I rewrote > the behavior code to use the new runtime API rather than the old one, and > while it's clearly working fine most of the time, perhaps there's something > finding a bug in this case? > >> I will fix this and also change all the parameters in GSArray.m to >> NSUInteger that are now changed in the super class NSArray. > > Now this looks also like a possible cause of the problem (especially if the > people experiencing this problem are using 64bit systems and it's not showing > up on any 32bit systems). > > I'll remove the -count method again, and we can see whether the change to > using NSUInteger fixed the issue. > > I''ll also look see if I can spot any possible problem in the mechanism for > inheriting -count. I agree with you that we should not just fix the problem on GSMutableArray, but need to find out, why behaviours aren't working with old runtimes. I tried to run the test suite to see whether it shows any obvious problems. It turns out the test suite is completely broken for me :-( I look at the first issue and there it should just be testWriteBasicType_ushort instead of testWriteBasicType_short. Probably most of the other issues are as simple as that. I will work my way through the test suite, and report the remaining problems. Fred --- Running tests in base --- base/coding/basictypes.m: FAIL: base/coding/basictypes.m base/coding/decoding.m: FAIL: base/coding/decoding.m base/Functions/NSGeometry1.m: FAIL: near identical points are equal FAIL: near identical sizes are equal FAIL: near identical rects are equal base/Functions/runtime.m: FAIL: base/Functions/runtime.m base/KVC/mutable.m: ofObject: context:(null) ofObject: context:(null) ofObject: context:(null) ofObject: context:(null) ofObject: context:(null) ofObject: context:(null) ofObject: context:(null) base/NSException/basic.m: FAIL: raises exception in description FAIL: working callStackSymbols : Uncaught exception NSGenericException, reason: Terminate FAIL: base/NSException/
Re: Gorm brokeness
On Mon, Mar 8, 2010 at 1:30 AM, Richard Frith-Macdonald
wrote:
>
> On 8 Mar 2010, at 06:22, Richard Frith-Macdonald wrote:
>
>>
>> On 7 Mar 2010, at 19:10, Fred Kiefer wrote:
>>
>>> Just to keep you informed on my current finding. I could follow a mouse
>>> down event that should start a drag into the method [XGDragView
>>> dragImage:at:offset:event:pasteboard:source:slideBack:] there the call
>>> to mimeTypeForPasteboardType() seems to fail, when doing manual calls in
>>> gdb I get
>>>
>>> (gdb) po pboard
>>>
>>> (gdb) p [pboard types]
>>> $14 = (class NSArray *) 0x109a610
>>> (gdb) po [pboard types]
>>>
>>> (gdb) p [[pboard types] count]
>>> $15 = (void *(*)()) 0x7fffef701000
>>> (gdb) p (int)[[pboard types] count]
>>> $16 = -277884928
>>> (gdb) p (long)[[pboard types] count]
>>> $17 = 140737210454016
>>>
>>> Now this may not the the root of the problem, but it looks strange to
>>> me. But why wont the function mimeTypeForPasteboardType return?
>>> After adding a breakpoint in [NSException raise] I get:
>>>
>>> (gdb) bt
>>> #0 -[NSException raise] (self=0x1056940, _cmd=0x76c03ab0) at
>>> NSException.m:899
>>> #1 0x76818300 in -[NSConnection(GNUstepExtensions)
>>> forwardInvocation:forProxy:] (self=0xfba420,
>>> _cmd=0x76c105c0, inv=0x1062840, object=0x11a81a0) at
>>> NSConnection.m:2090
>>> #2 0x76928507 in GSFFIInvocationCallback (cif=>> out>, retp=0x7fffc670,
>>> args=, user=) at
>>> GSFFIInvocation.m:636
>>> #3 0x747d9729 in ffi_closure_unix64_inner (closure=>> optimized out>,
>>> rvalue=, reg_args=0x75d04d3a,
>>> argp=0x7fffc690 "@#�")
>>> at src/x86/ffi64.c:620
>>> #4 0x747da0b0 in ffi_closure_unix64 () at src/x86/unix64.S:228
>>> #5 0x731f799a in mimeTypeForPasteboardType (types=>> optimized out>,
>>> zone=, xDisplay=) at
>>> XGDragView.m:140
>>> #6 -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:]
>>> (types=,
>>> zone=, xDisplay=) at
>>> XGDragView.m:217
>>> #7 0x77b3895d in -[GormPaletteView mouseDown:] (self=0xcdd460,
>>> _cmd=,
>>> theEvent=0xf8cd00) at GormPalettesManager.m:236
>>> #8 0x76ff7393 in -[NSWindow sendEvent:] (self=0xc32340,
>>> _cmd=,
>>> theEvent=0xf8cd00) at NSWindow.m:3666
>>> #9 0x76e94af4 in -[NSApplication run] (self=>> out>, _cmd=)
>>> at NSApplication.m:1530
>>> #10 0x76e7612e in NSApplicationMain (argc=,
>>> argv=)
>>> at Functions.m:74
>>> #11 0x75ca5a7d in __libc_start_main () from /lib64/libc.so.6
>>> #12 0x00401ac9 in _start () at ../sysdeps/x86_64/elf/start.S:113
>>>
>>> (gdb) po self
>>> NAME:NSInvalidArgumentException REASON:subclass
>>> GSMutableArray(instance) should override count
>>>
>>>
>>> Looks like this method go lost in recent rewrites of base :-)
>>
>> Absolutely not.
>> It's 'inherited' from GSArray using behavors, so should not be implemented
>> in GSMutableArray.
>> Also, many of the regression tests and lots of other code would clearly have
>> failed horribly if mutable arrays didn't work.
>> So how can you get this exception? Presumably some runtime issue. I
>> rewrote the behavior code to use the new runtime API rather than the old
>> one, and while it's clearly working fine most of the time, perhaps there's
>> something finding a bug in this case?
>>
>>> I will fix this and also change all the parameters in GSArray.m to
>>> NSUInteger that are now changed in the super class NSArray.
>>
>> Now this looks also like a possible cause of the problem (especially if the
>> people experiencing this problem are using 64bit systems and it's not
>> showing up on any 32bit systems).
>>
>> I'll remove the -count method again, and we can see whether the change to
>> using NSUInteger fixed the issue.
>>
>> I''ll also look see if I can spot any possible problem in the mechanism for
>> inheriting -count.
>
> None spotted so far. I have improved the debug though...
>
> If you set the GNUSTEP_BEHAVIOR_DEBUG environment variable to YES, you will
> get all the inherited behaviors logged to stderr and can see if there is
> anything going wrong there. It will report each method added or replaced in
> the class (as well as methods skipped because the class already has an
> implementation).
>
> So if the NSUinteger changes did not fix things, and there is an issue with
> 'inheriting' the -count method, this should give us a clue about where to
> look.
>
It doesn't seem related, but i've also been seeing some runtime weirdness
where objc_lookup_class("NSString") returns a bad class variable,
i've tracked it somewhat setting watchpoints on class_table_array[52]
and seen the 'correct' class being set as
class_table_array[52]->pointer (where 52 is the hash value for
NSString)
but haven't tracked down where ->pointer goes invalid, it seems to
just have a slight difference where the good one is Ox7.. and
the bad one OxF.
but the rest of the class pointer is the same, (at this poin
Re: Gorm brokeness
On 8 Mar 2010, at 06:22, Richard Frith-Macdonald wrote: > > On 7 Mar 2010, at 19:10, Fred Kiefer wrote: > >> Just to keep you informed on my current finding. I could follow a mouse >> down event that should start a drag into the method [XGDragView >> dragImage:at:offset:event:pasteboard:source:slideBack:] there the call >> to mimeTypeForPasteboardType() seems to fail, when doing manual calls in >> gdb I get >> >> (gdb) po pboard >> >> (gdb) p [pboard types] >> $14 = (class NSArray *) 0x109a610 >> (gdb) po [pboard types] >> >> (gdb) p [[pboard types] count] >> $15 = (void *(*)()) 0x7fffef701000 >> (gdb) p (int)[[pboard types] count] >> $16 = -277884928 >> (gdb) p (long)[[pboard types] count] >> $17 = 140737210454016 >> >> Now this may not the the root of the problem, but it looks strange to >> me. But why wont the function mimeTypeForPasteboardType return? >> After adding a breakpoint in [NSException raise] I get: >> >> (gdb) bt >> #0 -[NSException raise] (self=0x1056940, _cmd=0x76c03ab0) at >> NSException.m:899 >> #1 0x76818300 in -[NSConnection(GNUstepExtensions) >> forwardInvocation:forProxy:] (self=0xfba420, >> _cmd=0x76c105c0, inv=0x1062840, object=0x11a81a0) at >> NSConnection.m:2090 >> #2 0x76928507 in GSFFIInvocationCallback (cif=> out>, retp=0x7fffc670, >> args=, user=) at >> GSFFIInvocation.m:636 >> #3 0x747d9729 in ffi_closure_unix64_inner (closure=> optimized out>, >> rvalue=, reg_args=0x75d04d3a, >> argp=0x7fffc690 "@#�") >> at src/x86/ffi64.c:620 >> #4 0x747da0b0 in ffi_closure_unix64 () at src/x86/unix64.S:228 >> #5 0x731f799a in mimeTypeForPasteboardType (types=> optimized out>, >> zone=, xDisplay=) at >> XGDragView.m:140 >> #6 -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] >> (types=, >> zone=, xDisplay=) at >> XGDragView.m:217 >> #7 0x77b3895d in -[GormPaletteView mouseDown:] (self=0xcdd460, >> _cmd=, >> theEvent=0xf8cd00) at GormPalettesManager.m:236 >> #8 0x76ff7393 in -[NSWindow sendEvent:] (self=0xc32340, >> _cmd=, >> theEvent=0xf8cd00) at NSWindow.m:3666 >> #9 0x76e94af4 in -[NSApplication run] (self=> out>, _cmd=) >> at NSApplication.m:1530 >> #10 0x76e7612e in NSApplicationMain (argc=, >> argv=) >> at Functions.m:74 >> #11 0x75ca5a7d in __libc_start_main () from /lib64/libc.so.6 >> #12 0x00401ac9 in _start () at ../sysdeps/x86_64/elf/start.S:113 >> >> (gdb) po self >> NAME:NSInvalidArgumentException REASON:subclass >> GSMutableArray(instance) should override count >> >> >> Looks like this method go lost in recent rewrites of base :-) > > Absolutely not. > It's 'inherited' from GSArray using behavors, so should not be implemented in > GSMutableArray. > Also, many of the regression tests and lots of other code would clearly have > failed horribly if mutable arrays didn't work. > So how can you get this exception? Presumably some runtime issue. I rewrote > the behavior code to use the new runtime API rather than the old one, and > while it's clearly working fine most of the time, perhaps there's something > finding a bug in this case? > >> I will fix this and also change all the parameters in GSArray.m to >> NSUInteger that are now changed in the super class NSArray. > > Now this looks also like a possible cause of the problem (especially if the > people experiencing this problem are using 64bit systems and it's not showing > up on any 32bit systems). > > I'll remove the -count method again, and we can see whether the change to > using NSUInteger fixed the issue. > > I''ll also look see if I can spot any possible problem in the mechanism for > inheriting -count. None spotted so far. I have improved the debug though... If you set the GNUSTEP_BEHAVIOR_DEBUG environment variable to YES, you will get all the inherited behaviors logged to stderr and can see if there is anything going wrong there. It will report each method added or replaced in the class (as well as methods skipped because the class already has an implementation). So if the NSUinteger changes did not fix things, and there is an issue with 'inheriting' the -count method, this should give us a clue about where to look. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
On 7 Mar 2010, at 19:10, Fred Kiefer wrote: > Just to keep you informed on my current finding. I could follow a mouse > down event that should start a drag into the method [XGDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] there the call > to mimeTypeForPasteboardType() seems to fail, when doing manual calls in > gdb I get > > (gdb) po pboard > > (gdb) p [pboard types] > $14 = (class NSArray *) 0x109a610 > (gdb) po [pboard types] > > (gdb) p [[pboard types] count] > $15 = (void *(*)()) 0x7fffef701000 > (gdb) p (int)[[pboard types] count] > $16 = -277884928 > (gdb) p (long)[[pboard types] count] > $17 = 140737210454016 > > Now this may not the the root of the problem, but it looks strange to > me. But why wont the function mimeTypeForPasteboardType return? > After adding a breakpoint in [NSException raise] I get: > > (gdb) bt > #0 -[NSException raise] (self=0x1056940, _cmd=0x76c03ab0) at > NSException.m:899 > #1 0x76818300 in -[NSConnection(GNUstepExtensions) > forwardInvocation:forProxy:] (self=0xfba420, >_cmd=0x76c105c0, inv=0x1062840, object=0x11a81a0) at > NSConnection.m:2090 > #2 0x76928507 in GSFFIInvocationCallback (cif= out>, retp=0x7fffc670, >args=, user=) at > GSFFIInvocation.m:636 > #3 0x747d9729 in ffi_closure_unix64_inner (closure= optimized out>, >rvalue=, reg_args=0x75d04d3a, > argp=0x7fffc690 "@#�") >at src/x86/ffi64.c:620 > #4 0x747da0b0 in ffi_closure_unix64 () at src/x86/unix64.S:228 > #5 0x731f799a in mimeTypeForPasteboardType (types= optimized out>, >zone=, xDisplay=) at > XGDragView.m:140 > #6 -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] > (types=, >zone=, xDisplay=) at > XGDragView.m:217 > #7 0x77b3895d in -[GormPaletteView mouseDown:] (self=0xcdd460, > _cmd=, >theEvent=0xf8cd00) at GormPalettesManager.m:236 > #8 0x76ff7393 in -[NSWindow sendEvent:] (self=0xc32340, > _cmd=, >theEvent=0xf8cd00) at NSWindow.m:3666 > #9 0x76e94af4 in -[NSApplication run] (self= out>, _cmd=) >at NSApplication.m:1530 > #10 0x76e7612e in NSApplicationMain (argc=, > argv=) >at Functions.m:74 > #11 0x75ca5a7d in __libc_start_main () from /lib64/libc.so.6 > #12 0x00401ac9 in _start () at ../sysdeps/x86_64/elf/start.S:113 > > (gdb) po self > NAME:NSInvalidArgumentException REASON:subclass > GSMutableArray(instance) should override count > > > Looks like this method go lost in recent rewrites of base :-) Absolutely not. It's 'inherited' from GSArray using behavors, so should not be implemented in GSMutableArray. Also, many of the regression tests and lots of other code would clearly have failed horribly if mutable arrays didn't work. So how can you get this exception? Presumably some runtime issue. I rewrote the behavior code to use the new runtime API rather than the old one, and while it's clearly working fine most of the time, perhaps there's something finding a bug in this case? > I will fix this and also change all the parameters in GSArray.m to > NSUInteger that are now changed in the super class NSArray. Now this looks also like a possible cause of the problem (especially if the people experiencing this problem are using 64bit systems and it's not showing up on any 32bit systems). I'll remove the -count method again, and we can see whether the change to using NSUInteger fixed the issue. I''ll also look see if I can spot any possible problem in the mechanism for inheriting -count. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
Hi, as with your TabView problems, I am unable to reproduce your problem. I updated GNUstep base and gui today again, I run gorm, make a new application, all palettes show up correctly and I can drag&drop everything as usual. I suspect there is something stup-dependent, since also your TabView problem cannot be reproduced by everybody. Riccardo ici...@mail.cg.tuwien.ac.at wrote: Hi, all! Because of my ongoing issues with current GNUstep from svn today I decided to do a fresh start and removed all GNUstep installation related files from my hardrive. After that I did a svn update and did a fresh build of core and gorm. Looks like Gorm is as of now rather broken. I can open an existing document of mine, I can create a new document, but the palettes do not work. I can select a palette, but I am unable to actually select an item, like a button, and drag it into a window. Also the inspector seems broken, it does not display stuff like RadioButtons or button icons. I attached two screenshots. Looks like the NSTabView issues are just syntoms of the same underlying problem. NSTabView does display correctly if it is told to display it's "item bar" at the bottom, screenshots are attached. Please, help TOM ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
Just to keep you informed on my current finding. I could follow a mouse down event that should start a drag into the method [XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] there the call to mimeTypeForPasteboardType() seems to fail, when doing manual calls in gdb I get (gdb) po pboard (gdb) p [pboard types] $14 = (class NSArray *) 0x109a610 (gdb) po [pboard types] (gdb) p [[pboard types] count] $15 = (void *(*)()) 0x7fffef701000 (gdb) p (int)[[pboard types] count] $16 = -277884928 (gdb) p (long)[[pboard types] count] $17 = 140737210454016 Now this may not the the root of the problem, but it looks strange to me. But why wont the function mimeTypeForPasteboardType return? After adding a breakpoint in [NSException raise] I get: (gdb) bt #0 -[NSException raise] (self=0x1056940, _cmd=0x76c03ab0) at NSException.m:899 #1 0x76818300 in -[NSConnection(GNUstepExtensions) forwardInvocation:forProxy:] (self=0xfba420, _cmd=0x76c105c0, inv=0x1062840, object=0x11a81a0) at NSConnection.m:2090 #2 0x76928507 in GSFFIInvocationCallback (cif=, retp=0x7fffc670, args=, user=) at GSFFIInvocation.m:636 #3 0x747d9729 in ffi_closure_unix64_inner (closure=, rvalue=, reg_args=0x75d04d3a, argp=0x7fffc690 "@#�") at src/x86/ffi64.c:620 #4 0x747da0b0 in ffi_closure_unix64 () at src/x86/unix64.S:228 #5 0x731f799a in mimeTypeForPasteboardType (types=, zone=, xDisplay=) at XGDragView.m:140 #6 -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (types=, zone=, xDisplay=) at XGDragView.m:217 #7 0x77b3895d in -[GormPaletteView mouseDown:] (self=0xcdd460, _cmd=, theEvent=0xf8cd00) at GormPalettesManager.m:236 #8 0x76ff7393 in -[NSWindow sendEvent:] (self=0xc32340, _cmd=, theEvent=0xf8cd00) at NSWindow.m:3666 #9 0x76e94af4 in -[NSApplication run] (self=, _cmd=) at NSApplication.m:1530 #10 0x76e7612e in NSApplicationMain (argc=, argv=) at Functions.m:74 #11 0x75ca5a7d in __libc_start_main () from /lib64/libc.so.6 #12 0x00401ac9 in _start () at ../sysdeps/x86_64/elf/start.S:113 (gdb) po self NAME:NSInvalidArgumentException REASON:subclass GSMutableArray(instance) should override count Looks like this method go lost in recent rewrites of base :-) I will fix this and also change all the parameters in GSArray.m to NSUInteger that are now changed in the super class NSArray. Fred Am 07.03.2010 18:46, schrieb Fred Kiefer: > The non-working palettes are at least something I am able to reproduce > on my system. This doesn't seem to be relate to the selected backend. > It might either be a Gorm or a gui problem. I will look into this. > > Am 07.03.2010 17:20, schrieb Gregory Casamento: >> I can confirm that I can't drag anything from the palettes. It >> appears that recent changes in GUI may have broken something. >> >> GC >> >> On Sun, Mar 7, 2010 at 9:09 AM, wrote: >>> Hi, all! >>> >>> Because of my ongoing issues with current GNUstep from svn today I decided >>> to do a fresh start and removed all GNUstep installation related files from >>> my hardrive. After that I did a svn update and did a fresh build of core and >>> gorm. Looks like Gorm is as of now rather broken. I can open an existing >>> document of mine, I can create a new document, but the palettes do not work. >>> I can select a palette, but I am unable to actually select an item, like a >>> button, and drag it into a window. Also the inspector seems broken, it does >>> not display stuff like RadioButtons or button icons. I attached two >>> screenshots. Looks like the NSTabView issues are just syntoms of the same >>> underlying problem. NSTabView does display correctly if it is told to >>> display it's "item bar" at the bottom, screenshots are attached. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
On 7 Mar 2010, at 17:41, Fred Kiefer wrote: > Am 07.03.2010 15:09, schrieb ici...@mail.cg.tuwien.ac.at: >> Because of my ongoing issues with current GNUstep from svn today I >> decided to do a fresh start and removed all GNUstep installation related >> files from my hardrive. After that I did a svn update and did a fresh >> build of core and gorm. Looks like Gorm is as of now rather broken. I >> can open an existing document of mine, I can create a new document, but >> the palettes do not work. I can select a palette, but I am unable to >> actually select an item, like a button, and drag it into a window. Also >> the inspector seems broken, it does not display stuff like RadioButtons >> or button icons. I attached two screenshots. Looks like the NSTabView >> issues are just syntoms of the same underlying problem. NSTabView does >> display correctly if it is told to display it's "item bar" at the >> bottom, screenshots are attached. > > Now that all your images are gone I would say that this is after all the > same problem that Richard is having. > I hope to work on this together with Richard. At the moment I don't have > any 32 bit Unix system to reproduce this behaviour, so it will be hard > for me to track it down alone. I don't have any problem with palettes in Gorm ... they work fine for me with current code from svn. I just did a clean rebuild of make,base,gui,back, gorm from svn trunk and apart from the images not displaying, everything is fine. I have a suspicion that any current problems may be my own fault (all the recent changes in base, sometimes with global search/replace, worry me), but I have nothing concrete to go on. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
The non-working palettes are at least something I am able to reproduce on my system. This doesn't seem to be relate to the selected backend. It might either be a Gorm or a gui problem. I will look into this. Fred Am 07.03.2010 17:20, schrieb Gregory Casamento: > I can confirm that I can't drag anything from the palettes. It > appears that recent changes in GUI may have broken something. > > GC > > On Sun, Mar 7, 2010 at 9:09 AM, wrote: >> Hi, all! >> >> Because of my ongoing issues with current GNUstep from svn today I decided >> to do a fresh start and removed all GNUstep installation related files from >> my hardrive. After that I did a svn update and did a fresh build of core and >> gorm. Looks like Gorm is as of now rather broken. I can open an existing >> document of mine, I can create a new document, but the palettes do not work. >> I can select a palette, but I am unable to actually select an item, like a >> button, and drag it into a window. Also the inspector seems broken, it does >> not display stuff like RadioButtons or button icons. I attached two >> screenshots. Looks like the NSTabView issues are just syntoms of the same >> underlying problem. NSTabView does display correctly if it is told to >> display it's "item bar" at the bottom, screenshots are attached. >> >> Please, help >> >> TOM ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
Am 07.03.2010 15:09, schrieb ici...@mail.cg.tuwien.ac.at: > Because of my ongoing issues with current GNUstep from svn today I > decided to do a fresh start and removed all GNUstep installation related > files from my hardrive. After that I did a svn update and did a fresh > build of core and gorm. Looks like Gorm is as of now rather broken. I > can open an existing document of mine, I can create a new document, but > the palettes do not work. I can select a palette, but I am unable to > actually select an item, like a button, and drag it into a window. Also > the inspector seems broken, it does not display stuff like RadioButtons > or button icons. I attached two screenshots. Looks like the NSTabView > issues are just syntoms of the same underlying problem. NSTabView does > display correctly if it is told to display it's "item bar" at the > bottom, screenshots are attached. Now that all your images are gone I would say that this is after all the same problem that Richard is having. I hope to work on this together with Richard. At the moment I don't have any 32 bit Unix system to reproduce this behaviour, so it will be hard for me to track it down alone. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
I can confirm that I can't drag anything from the palettes. It appears that recent changes in GUI may have broken something. GC On Sun, Mar 7, 2010 at 9:09 AM, wrote: > Hi, all! > > Because of my ongoing issues with current GNUstep from svn today I decided > to do a fresh start and removed all GNUstep installation related files from > my hardrive. After that I did a svn update and did a fresh build of core and > gorm. Looks like Gorm is as of now rather broken. I can open an existing > document of mine, I can create a new document, but the palettes do not work. > I can select a palette, but I am unable to actually select an item, like a > button, and drag it into a window. Also the inspector seems broken, it does > not display stuff like RadioButtons or button icons. I attached two > screenshots. Looks like the NSTabView issues are just syntoms of the same > underlying problem. NSTabView does display correctly if it is told to > display it's "item bar" at the bottom, screenshots are attached. > > Please, help > > TOM > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
