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: NSTabView
On 7 Mar 2010, at 21:41, Fred Kiefer wrote: > Am 07.03.2010 21:42, schrieb Eric Wasylishen: >> Hi, I wonder if the change I made in December to use CAIRO_EXTEND_PAD >> when drawing images is responsible for this. I just checked now and >> the cairo docs say CAIRO_EXTEND_PAD is only implemented in 1.6 and >> later for surface patterns. >> >> Maybe try commenting out the two calls to cairo_pattern_set_extend in >> CairoGState.m? >> >> -Eric > > I bracketed these calls with a version check. Let's see whether this > helps. As this is a problem I cannot reproduce I am at complete lose here. Yes, thanks to both of you ... that now works fine for me. ___ 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
-zone in NSObject
Hi, I get from some applications this kind of warning on run: in gorm: 2010-03-07 19:11:56.888 Gorm[4340] File NSObject.m: 605. In GSObjCZone GSObjCZone() is deprecated ... use -zone instead Gorm opens fine for me and appears to work, but Gregory reports it has problem, but he didn't specify what, so ìI couldn't really try to reproduce. In AddressManager instead I subsequently also get NIB errors: 2010-03-07 23:00:00.648 AddressManager[4868] File NSObject.m: 605. In GSObjCZone GSObjCZone() is deprecated ... use -zone instead 2010-03-07 23:00:01.316 AddressManager[4868] Error while establishing connection < src=0x2972a5c8> dst= label=cNameLabel>: Unable to set nil value for key 2010-03-07 23:00:01.318 AddressManager[4868] Error while establishing connection < src=0x2972a5c8> dst= label=cRoadLabel>: Unable to set nil value for key ... and many more NSNibOutletConnector: errors AddressManager comes up, but is essentially unusable, no actions work. Where is the problem? Something inside Core or is it the app that needs some rework? Thanks, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
Am 07.03.2010 21:42, schrieb Eric Wasylishen: > Hi, I wonder if the change I made in December to use CAIRO_EXTEND_PAD > when drawing images is responsible for this. I just checked now and > the cairo docs say CAIRO_EXTEND_PAD is only implemented in 1.6 and > later for surface patterns. > > Maybe try commenting out the two calls to cairo_pattern_set_extend in > CairoGState.m? > > -Eric I bracketed these calls with a version check. Let's see whether this helps. As this is a problem I cannot reproduce I am at complete lose here. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
Hi, I wonder if the change I made in December to use CAIRO_EXTEND_PAD when drawing images is responsible for this. I just checked now and the cairo docs say CAIRO_EXTEND_PAD is only implemented in 1.6 and later for surface patterns. Maybe try commenting out the two calls to cairo_pattern_set_extend in CairoGState.m? -Eric On 2010-03-07, at 11:58 AM, Richard Frith-Macdonald wrote: > > On 7 Mar 2010, at 15:34, Fred Kiefer wrote: > >> Sounds like a different problem to me, but like a very interesting one :-) >> With the .so numbers I don't have a clue, which cairo version this >> really is. Could you please use pkg-config --modversion cairo to get the >> version number the system thinks it has? > > [rich...@centos]$ pkg-config --modversion cairo > 1.2.4 > > >> GNUstep should be able to display images with all versions of cairo >> starting from 1.0 or so. I am currently using cairo 1.8.8. >> >> The next instruction would be to recompile all of GNUstep from scratch, >> but I now you are doing this already. > > Yes ... just did it again anyway to be sure. > >> The only change in recent time that could affect you is the one I did on >> the 20th of Febuary to adjust the cairo backend to the CGFloat change of >> base. This change works correctly on my 64 bit system, but it could be >> different on a 32 bit one. Could you please try to compile base (and all >> the rest) with the definition of CGFloat turned back to float? If this >> changes the behaviour of the cairo backend then we know where to look. > > > It's already float on 32bit systems (the one I'm having image display > problems with is a 32bit system) ... it only gets defined to be double on > 64bit systems. > > ___ > 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
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: NSTabView
On 7 Mar 2010, at 15:34, Fred Kiefer wrote: > Sounds like a different problem to me, but like a very interesting one :-) > With the .so numbers I don't have a clue, which cairo version this > really is. Could you please use pkg-config --modversion cairo to get the > version number the system thinks it has? [rich...@centos]$ pkg-config --modversion cairo 1.2.4 > GNUstep should be able to display images with all versions of cairo > starting from 1.0 or so. I am currently using cairo 1.8.8. > > The next instruction would be to recompile all of GNUstep from scratch, > but I now you are doing this already. Yes ... just did it again anyway to be sure. > The only change in recent time that could affect you is the one I did on > the 20th of Febuary to adjust the cairo backend to the CGFloat change of > base. This change works correctly on my 64 bit system, but it could be > different on a 32 bit one. Could you please try to compile base (and all > the rest) with the definition of CGFloat turned back to float? If this > changes the behaviour of the cairo backend then we know where to look. It's already float on 32bit systems (the one I'm having image display problems with is a 32bit system) ... it only gets defined to be double on 64bit systems. ___ 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
Re: NSTabView
Am 04.03.2010 12:39, schrieb Richard Frith-Macdonald: > > On 1 Mar 2010, at 21:03, Fred Kiefer wrote: > >> I just recompiled Gorm and it looks different here :-) >> As this is also on a 64bit system the main difference I see is the cairo >> version. Could you please try a different backend to confirm that it is >> the cairo backend that causes this behaviour. >> >> There are a few places in CarioGState where we differentiate based on >> the cairo version number. Perhaps a few of these checks are off? >> I know that GNUstep worked with all the cairo releases that were >> available for OpenSuse (I had to get it working as I use this backend >> for years now), but there may be cairo releases where extra bugs need to >> be worked around. >> >> If it turns out, the problem isn't backend relate, it will be much hard >> to pin it down >> >> Am 01.03.2010 00:03, schrieb ici...@mail.cg.tuwien.ac.at: >>> It's my own application which shows this behaviour. I do not have a >>> theme enabled, I am using the cairo backend. Everything is built from >>> current svn trunk. Gorm shows the same broken behaviour on my machine, >>> screenshot is attached. I am on Ubuntu 8.04 AMD64, cairo version is 1.6.0. >>> >>> Thanks >>> TOM >>> >>> Zitat von Fred Kiefer : >>> I just tried to reproduce this behaviour and failed to. On which application are you seeing this and probably more important, which GNUstep backend are you using? Do you have a theme enable? Am 27.02.2010 18:54, schrieb ici...@mail.cg.tuwien.ac.at: > Looks like NSTabView in trunk is currently buggy. I attached a > screenshot to this message. Gorm from svn trunk displays it the same > way. Tell me if you need further information. > > I don't know if this is the same thing, but on my system (32bit intel, > CentOS-4.5) it seems that NO images are displaying with the Cairo backend at > present. > I don't know how long this has been the case for, since I've been > concentrating exclusively on base for the last few weeks, and haven't updated > gui/back at all (indeed it's possible that a system update has changed the > underlying cairo library or something similar without me noticing since last > time I was playing with gui). > > I did think I might have broken proxying in some way (though all the base > regression tests still pass) with all the changes I've been making, but if I > use the art backend, images display as normal. I guess the problem could be > some change in base anyway, if the cairo backend depends on something which > art doesn't. > > The following 'ls' command might tell you something (it doesn't enlighten me > at all)... > > $ ls /usr/lib/*cair* > /usr/lib/libcairo.so/usr/lib/libpangocairo-1.0.so > /usr/lib/libcairo.so.2 /usr/lib/libpangocairo-1.0.so.0 > /usr/lib/libcairo.so.2.9.2 /usr/lib/libpangocairo-1.0.so.0.1400.9 Sounds like a different problem to me, but like a very interesting one :-) With the .so numbers I don't have a clue, which cairo version this really is. Could you please use pkg-config --modversion cairo to get the version number the system thinks it has? GNUstep should be able to display images with all versions of cairo starting from 1.0 or so. I am currently using cairo 1.8.8. The next instruction would be to recompile all of GNUstep from scratch, but I now you are doing this already. The only change in recent time that could affect you is the one I did on the 20th of Febuary to adjust the cairo backend to the CGFloat change of base. This change works correctly on my 64 bit system, but it could be different on a 32 bit one. Could you please try to compile base (and all the rest) with the definition of CGFloat turned back to float? If this changes the behaviour of the cairo backend then we know where to look. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
