Greg:
That is what I expected. Just trying to imagine one impossible
thing before breakfast is all I was doing...
--
+---+
| Dale Amon Immortal Data|
| CEO Midland International Air a
This only works with clang, I believe.
On Tue, May 22, 2018 at 19:21 Dale Amon wrote:
> Yes. On the one laptop I tried it, I get stray '@' in program.
>
> --
> +---+
> | Dale Amon Immortal Data|
>
Yes. On the one laptop I tried it, I get stray '@' in program.
--
+---+
| Dale Amon Immortal Data|
| CEO Midland International Air and Space Port|
| a...@vnl.com "Data System
Do any versions of gcc support the @ format? @"string"
has long been supported there. If not, are there plans for it to
be supported in future revs?
It would be very useful to be able to use numeric literals at
some point, but I have to support gcc based machines.
I am certain the answer is "You
That looks interesting. Could you please add a view more outputs of self before
this line. EG, at the start of the method, after the super call and after the
[self image] call. I suspect one of these will corrupt self.
Fred
> Am 22.05.2018 um 14:38 schrieb Andreas Höschler :
>
> Hi all,
>
> I
Hi,
Yavor Doganov wrote:
Good practice is to check the result of that assignment. If it fails for
some reason, it would explain (to an extent) why your program crashes
when you attempt to assign a value to the ivar at line 168. Also, if
self is nil, -retain will do nothing.
exactly, this is
В Tue, 22 May 2018 13:54:08 +0200, Andreas Höschler написа:
> - (id)initWithFrame:(NSRect)frameRect {
>NSLog(@"initWithFrame ...");
>self = [super initWithFrame: frameRect];
^^^
>[self retain];
>...
> }
Good practice is to check the result
Hi Andreas,
are you able to extract a miminal program that uses your MapView class
trimimed down enough so that compiling and running it reproduces the
problem?
I could then test the problem on my system and, as soon as I get back
home, also on my Ubuntu installation.
It could be useful for tr
> On 22 May 2018, at 13:55, Andreas Höschler wrote:
>
> Hi Richard,
>
>>> Aha, interesting. But this still rings no bell (no idea how this could be).
>>
>> Well, anything that overwrite the memory location in which 'self' is stored
>> could cause this.
>> The most common thing (as suggested
Hi,
Andreas Höschler wrote:
2018-05-22 14:32:37.291 TimberNav[10763:10763] MapView drawRect {x =
0; y = 0; width = 817; height = 334} ... _osmDrawing 0
2018-05-22 14:32:37.291 TimberNav[10763:10763] After super drawRect:rect
2018-05-22 14:32:37.291 TimberNav[10763:10763] bums
2018-05-22 14:32
Hi Richard,
>> Aha, interesting. But this still rings no bell (no idea how this could be).
>
> Well, anything that overwrite the memory location in which 'self' is stored
> could cause this.
> The most common thing (as suggested by Wolfgang) would be if the object was
> deallocated and the memo
> On 22 May 2018, at 13:09, Andreas Höschler wrote:
>
> Hi Wolfgang,
>
>> From the self pointer in the call frame:
>> self=0xb7ca746e <-[NSView displayRectIgnoringOpacity:inContext:]+318>
>> gdb resolves this address to an address in the code of the
>> displayRectIgnoringOpacity:inContext: m
Hi all,
I just added
- (void)drawRect:(NSRect)rect
{
NSLog(@"MapView drawRect %@ ... _osmDrawing %d", NSStringFromRect(rect),
_osmDrawing);
[super drawRect:rect];
NSLog(@"After super drawRect:rect");
NSImage *image = [self image];
NSSize imageSize = [image size];
Hi Wolfgang,
> From the self pointer in the call frame:
> self=0xb7ca746e <-[NSView displayRectIgnoringOpacity:inContext:]+318>
> gdb resolves this address to an address in the code of the
> displayRectIgnoringOpacity:inContext: method from the NSView class. :-)
Aha, interesting. But this still
> Am 22.05.2018 um 13:54 schrieb Andreas Höschler :
>
> Hi Wolfgang,
>
>>> Any further ideas?
>>
>> Looking back at your initial report, it has this telling line about the
>> crash:
>>
>> Thread 1 "TimberNav" received signal SIGSEGV, Segmentation fault.
>> -[MapView drawRect:] (self=0xb7ca74
Hi Wolfgang,
>> Any further ideas?
>
> Looking back at your initial report, it has this telling line about the crash:
>
> Thread 1 "TimberNav" received signal SIGSEGV, Segmentation fault.
> -[MapView drawRect:] (self=0xb7ca746e <-[NSView
> displayRectIgnoringOpacity:inContext:]+318>,
>_cmd=
Am 22.05.2018 um 11:31 schrieb Andreas Höschler :
> Any further ideas?
Looking back at your initial report, it has this telling line about the crash:
Thread 1 "TimberNav" received signal SIGSEGV, Segmentation fault.
-[MapView drawRect:] (self=0xb7ca746e <-[NSView
displayRectIgnoringOpacity:inCo
Hi Fred and all,
>>> The best way to find out about this would be to run the application with
>>> valgrind. Many mysterious problems became quite clear when looking at them
>>> through the valgrind toolset. If you require help with that, I could
>>> provide you with detailed instructions.
>>
>
The current git version of libobjc2 seems broken
The version I used before (commit 14889c540fe7da84080aaa87342df40e0a7091e7)
worked.
The current one spills out a lot of undefined header stuff
for example in
extern struct objc_slot_v1 *objc_get_slot(Class, SEL)
OBJC_NONPORTABLE OBJC_D
> On 22 May 2018, at 09:45, Andreas Fink wrote:
>
> The current git version of libobjc2 seems broken
>
> The version I used before (commit 14889c540fe7da84080aaa87342df40e0a7091e7)
> worked.
> The current one spills out a lot of undefined header stuff
>
> for example in
>
> extern struct
Hi,
Svetlana Tkachenko wrote:
Is there a way to check this from within GNUMail itself to ensure that I am
running the correct version? Please let me know and I would attempt to test the
other open issues that I had as soon as possible.
I forgot to push the relevant updates. If you update now
21 matches
Mail list logo
