Re: Emacs.app (from BZR) and GNUstep (from SVN)

[Fred Kiefer]

Don't get fooled by the name. I had a short look at the Emacs GIT source code 
yesterday and things are a lot more complicated as they seem. (Aren't they 
always?)
What is called Pixmap here should be an EmacsImage object if the code in 
nsimage.m behaves correctly. Emacs just reuses the X function call prototype 
for Cocoa but expects completely differnet behaviour from it. No idea why they 
do it that way.
From what Icould see I would expect that we are notdealing with an X Pixmap 
here and that the real problem may be somewhere else. But the last time I tried 
to track down an issue in Emacs I failed, because of this unusual code 
structure.

Fred

On the road

Am 24.12.2011 um 05:47 schrieb Germán Arias <address@hidden>:

> You are right this is confusing. But maybe is possible delete this code 
> that don't have sense.
> 
> On 2011-12-23 03:07:24 -0600 Ivan Vučica <address@hidden> wrote:
> 
>> I'm new to Xlib, but isn't Pixmap an integer? How could have one ever sent 
>> an 
>> Objective-C message to an integer?
>> 
>> Shouldn't there be a wrapper around this integer if one wants to retain it?
>> 
>> Why bother retaining an object which is not a part of Objective-C reference 
>> counting system?
>> 
>> I'm confused. :)
>> 
>> Regards,
>> 
>> Ivan Vučica
>> via phone
>> 
>> On 23. 12. 2011., at 02:47, Germán Arias <address@hidden> wrote:
>> 
>>> Currently Emacs.app crash at launch with GNUstep. It worked fine 
>>> previously. I thought
>>> it was caused by changes in emacs, but someone has confirmed it works fine 
>>> with the stable
>>> packages of GNUstep (I will test it tomorrow). So the problem could be in 
>>> gnustep. Below I
>>> add the backtrace. The app crash because can't retain a pixmap.
>>> 
>>> Here the backtrace:
>>> 
>>> (gdb) backtrace
>>> #0  objc_msg_lookup (receiver=0x1400016, op=0x8482710)
>>>    at /home/german/Instalados/GCC/gcc-4.6.0/libobjc/sendmsg.c:397
>>> #1  0x082657b0 in ns_retain_object (obj=0x1400016) at nsterm.m:466
>>> #2  0x08255ac2 in XGetImage (display=0x89af8e8, pixmap=0x1400016, x=0, y=0,
>>>    width=64, height=64, plane_mask=4294967295, format=2) at image.c:160
>>> #3  0xb50a62ea in ?? () from /usr/lib/libcairo.so.2
>>> #4  0x089af8e8 in ?? ()
>>> #5  0x01400016 in ?? ()
>>> #6  0x00000000 in ?? ()
>>> (gdb)
>>> 
>>> 
>>> At frame 2 the function XGetImage is:
>>> 
>>> XImagePtr
>>> XGetImage (Display *display, Pixmap pixmap, int x, int y,
>>>           unsigned int width, unsigned int height,
>>>           unsigned long plane_mask, int format)
>>> {
>>>  /* TODO: not sure what this function is supposed to do.. */
>>>  ns_retain_object (pixmap);
>>>  return pixmap;
>>> }
>>> 
>>> And at frame 1 the function ns_retain_object is:
>>> 
>>> void
>>> ns_retain_object (void *obj)
>>> /* 
>>> --------------------------------------------------------------------------
>>>    Retain an object (callable from C)
>>> 
>>> -------------------------------------------------------------------------- 
>>> */
>>> {
>>>    [(id)obj retain];
>>> }
>>> 
>>> Can this problem be related with the changes about how the images
>>> are handled? Any idea? Thanks.
>>> 
>>> 
>>> _______________________________________________
>>> Gnustep-dev mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>> 
>> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev