U++ Forum - RDF feed
type: channel
description: Main place for discussions about U++ cross platform development framework.
items: MacOS X woes
items: Re: MacOS X woes

MacOS X woes
type: item
description: lundman wrote on Fri, 15 December 2006 07:22 Got it and recompiled all, but no difference, core the same place, the same backtrace. At what place to you pull out the number of images so I can check we are getting a sane value? All I see is zeros. Well, it is a little bit complicated.... There are two .iml formats. I guess we are dealing here with newer one. In the new format, there are image headers (with names) and images are compressed in about 4KB blocks (because compressing several small images together yields better compression ratio than compressing them individually). The problem here is most likely that number of headers does not match number of images in compression blocks (there is more headers). The critical function to investigate first is IMHO: Vector<Image> UnpackImlData(const String& d) placing a couple of LOGs and DUMPs there might reveal what is going on. BTW, moving this to the forum... Mirek
creator: mirek
date: 2006-12-15T12:52:12-00:00

Re: MacOS X woes
type: item
description: I'm not so good at your debug code, but gdb I can handle... just doing a quick run through of the UnpackImlData() function, what should "len" normally be? I would guess this number is large: (First pass, first image) (gdb) p ib $9 = { <NoCopy> = {<No data fields>}, members of ImageBuffer: kind = 0, size = { <Moveable<Size_<int>,EmptyClass>> = { <> = {<No data fields>}, <No data fields>}, members of Size_<int>: cx = 3328, cy = 3328 }, pixels = { <Moveable<Buffer<RGBA>,EmptyClass>> = { <> = {<No data fields>}, <No data fields>}, members of Buffer<RGBA>: ptr = 0x428a008 }, hotspot = { <Moveable<Point_<int>,EmptyClass>> = { <> = {<No data fields>}, <No data fields>}, members of Point_<int>: x = 256, y = 256 }, [snip] (gdb) n 240 s += 13; (gdb) n 241 int len = ib.GetLength(); (gdb) p len $10 = 11075584 Am I getting warmer?
creator: lundman
date: 2006-12-15T13:07:07-00:00

Re: MacOS X woes
type: item
description: Actually, its just size.cx*size.cy and at 3328 pixels each, that is the right value. So assuming 3328x3328 is correct.. The function ends with, after just one pass: 255 return img; (gdb) p img $3 = { <MoveableAndDeepCopyOption<Vector<Image>,EmptyClass>> = { <Moveable<Vector<Image>,DeepCopyOption<Vector<Image>, EmptyClass> >> = { <DeepCopyOption<Vector<Image>,EmptyClass>> = { <> = {<No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, members of Vector<Image>: vector = 0xbffff740, items = -1, alloc = 2315384 }
creator: lundman
date: 2006-12-15T13:10:35-00:00

Re: MacOS X woes
type: item
description: If I'm posting too much, just tell me off #1 0x002ffbd0 in UnpackImlData (d=@0xbffff78c) at ImageBlit.cpp:237 237 ImageBuffer ib(Peek16le(s + 1), Peek16le(s + 3)); (gdb) x/16x s 0xffb014: 0x000d000d 0x00010001 0x00000000 0x00000000 0xffb024: 0x00000000 0x00000000 0x00b2b2be 0xff676789 So +1, and +3 should be 0d00 0d00, in LE, or rather, 13x13. However, I get 3328. ($D00) Peek16le isn't flipping?
creator: lundman
date: 2006-12-15T13:19:14-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Fri, 15 December 2006 08:10 Actually, its just size.cx*size.cy and at 3328 pixels each, that is the right value. So assuming 3328x3328 is correct.. ...but 3328 almost certainly is not... -> is 0xd00, 0x00d is much more realistical (first picture in the .iml is 13x13 pixel image). We are definitely getting nuxi problem here... Are you sure that Peek16le is in correct version? (Maybe just preprocess the file and look.) Mirek
creator: mirek
date: 2006-12-15T13:25:33-00:00

Re: MacOS X woes
type: item
description: When I rsynced the new Util.h it over-wrote my port changing, including setting of flagPPC. Sigh. Anyway, back to where we were, looking at the image editor segv. Called LoadIml(), which does not find IMAGE_ID and IMAGE_DATA, so it throws the exception, and loads in a more low-level loader. Seems to parse the input ok, until is reaches: (gdb) p parser $28 = (CParser &) @0xbffe5a70: { term = 0x2161732 "IMAGE_SCAN(\"?\\377\\377\\377\\13????????????????????????????????\\377\\377\\377\")\nIMAGE_PACKED(ufxp, \"\\2\\20\\0\\0\\0\\20\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\")\nIMAGE_BEGIN(options)\n\tIMAGE_SCAN(\"?\\1vlV????\\1??m?\\2??s?"..., 100 else if(id == "IMAGE_PACKED" && parser.IsChar('\"')) (gdb) n 105 StringStream ss(d); (gdb) n 106 ss % image; (gdb) n 107 if(!ss.IsError()) (gdb) n 108 accepted = true; (gdb) n 109 } (gdb) n 112 if(name.GetLength() >= 6 && !memcmp(name, "_java_", 6)) (gdb) p name [snip] ptr = 0x1b89654 "ufxp" (gdb) n 115 if(accepted) (gdb) n 117 if(name.GetLength() >= 4 && !memcmp(name, "im__", 4)) (gdb) n 120 Image m = RLEToAlpha(encoded_data, image.size); (gdb) p encoded_data $34 = { <AString<char,String>> = { <Moveable<String,EmptyClass>> = { <> = {<No data fields>}, <No data fields>}, members of AString<char,String>: ptr = 0x20c9414 "????\001?????????????????????\004????????????????\002??????????????\004???[[[?????????\003ooo??????????????\n???\036\036\036\033\033\033??????ooo\f\f\f\016\016\016???????????????\n999\001\001\001" }, <No data fields>} (gdb) p image.size $35 = { <Moveable<Size_<int>,EmptyClass>> = { <> = {<No data fields>}, <No data fields>}, members of Size_<int>: cx = 268435456, cy = 268435456 } Should sizes be set here? Before we call, or is it just uninitialised? encoded_data looks correct, in that it was parsed in ok. (gdb) x/16bx encoded_data.ptr 0x20c9414: 0x83 0xff 0xff 0xff 0x01 0xfd 0xfd 0xfd 0x20c941c: 0x82 0xfc 0xfc 0xfc 0x83 0xff 0xff 0xff But it dies in RLEToAlpha. Breakpoint 3, RLEToAlpha (rle=@0xbffe5898, sz=@0x…
creator: lundman
date: 2006-12-16T01:30:57-00:00

Re: MacOS X woes
type: item
description: I can confirm that with the following hack ImlFile.cpp:112 if (image.size.cx > 1000) { image.size.cx = 16; image.size.cy = 16; } ...since I know that my two icons are 16x16... The image editor loads without core dumping, and displays my first icon just fine.
creator: lundman
date: 2006-12-16T01:49:52-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Fri, 15 December 2006 20:30 When I rsynced the new Util.h it over-wrote my port changing, including setting of flagPPC. Ooops. Can you post the patch please so that I can apply it? Quote: Anyway, back to where we were, looking at the image editor segv. Based on the code, looks like problem in serialization. Will look at it asap. Mirek
creator: mirek
date: 2006-12-17T14:03:02-00:00

Re: MacOS X woes
type: item
description: Coonfirmed&fixed (well, at least I hope). In the process, I have encountered an interesting problem - serialization of float and double. How is the float/double format on PowerPC (or other non-x86 CPUs)? Is it the same, just needing to swap the order of bytes like integer types? Mirek
creator: mirek
date: 2006-12-17T14:22:41-00:00

Re: MacOS X woes
type: item
description: OK. It really seems like fp numbers are the same, just swapped. Altering code to this.. Mirek
creator: mirek
date: 2006-12-17T14:38:53-00:00

Re: MacOS X woes
type: item
description: I stepped through the serialisation code earlier to confirm it did indeed break endianess. (File is saved in little). After setting the sizes to 16x16 it became saved in big-endian and just worked but that's not ideal either Changes for OSX11 are: Package Organiser: CtrlLib: Add Package, When "OSX11": PdfDraw Draw: New Libraries, When "OSX11": X11 Xft fontconfig Xrender freetype expat Only patching that is questionable is the plugin/bmp/bmphdr.h with my extra casting. So currently, you set "flagPPC" or "flagX86" in the Build Environment variables. This will trigger code to add "-arch X" for cc and lnk times.
creator: lundman
date: 2006-12-18T02:33:12-00:00

Re: MacOS X woes
type: item
description: Hmm, seems that -DflagPPC does not trigger the code with HasFlag("PPC") so that won't work either. Need to be able to trigger extra linking variables (since they can not be specified in Build Environment). I guess I could change it so that you specify "-arch ppc" or "-arch i386" in BE instead, then add: Core/Core.h: #ifdef __BIG_ENDIAN__ #define flagPPC #undef flagX86 #endif #ifdef __LITTLE_ENDIAN__ #undef flagPPC #define flagX86 #endif (those endian defines are set by gcc based on the -arch flag) then I can add linking flags in GccBuilder.cpp. Which way to do you prefer?
creator: lundman
date: 2006-12-18T02:48:31-00:00

Re: MacOS X woes
type: item
description: Hm, what this says http://developer.apple.com/qa/qa2005/qa1424.html ? Maybe for the moment, we could use some of predefined macros... Mirek
creator: mirek
date: 2006-12-18T07:28:36-00:00

Re: MacOS X woes
type: item
description: Yeah I'm okay with that. I will change it to be as shown above, and we specify the build type with "-arch" in BuildEnv. Then the lnk additions will also work.
creator: lundman
date: 2006-12-18T08:28:21-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Mon, 18 December 2006 03:28 Yeah I'm okay with that. I will change it to be as shown above, and we specify the build type with "-arch" in BuildEnv. Then the lnk additions will also work. Well, I am afraid that __LITTLE_ENDIAN__ could bite us with ARM. Is not there some __power_pc__ macro? Mirek
creator: mirek
date: 2006-12-18T09:36:06-00:00

Re: MacOS X woes
type: item
description: #define __ppc__ 1 #define __POWERPC__ 1 #define _ARCH_PPC 1 Last one could be interesting. Similarly: #define i386 1 #define __i386 1 #define __i386__ 1
creator: lundman
date: 2006-12-18T09:53:55-00:00

Re: MacOS X woes
type: item
description: Although I should mention I put the #ifdef ENDIAN inside that of PLATFORM_OSX11 so it shouldn't matter, but based on arch is better than endianess
creator: lundman
date: 2006-12-18T10:15:40-00:00

Re: MacOS X woes
type: item
description: Another small issue: Maybe instead CPU_PPC it should be CPU_POWERPC, because PPC clashes with PocketPC a bit... Mirek
creator: mirek
date: 2006-12-18T12:50:18-00:00

Re: MacOS X woes
type: item
description: Ah whoopsie.. I assumed you had previously done CPU_PPC to be powerpc, since the PocketPC cpu arch is ARM, SH3 or MIPS. I will guess what is needed here and submit a patch. I use something along the lines of: #ifdef flagOSX11 #define PLATFORM_OSX11 #define PLATFORM_POSIX #ifdef flagGUI #define PLATFORM_X11 #endif #ifdef flagTESTLEAKS #define TESTLEAKS #endif // defines set by OsX for us. #ifdef __POWERPC__ #define flagPOWERPC #endif #ifdef __i386__ #define flagX86 #endif #endif However, can you help to find a solution as to how to be able to do Intel build on a PPC platform and vv. The problem is, I need to set "-arch i386", which currently I set in "Build Environment". This is only use for Compile, and not use in Linking. There are no Linking options that I can see in Build Environment. So without that set, "__i386__" is not set, so the linking is done as POWERPC. If no extra input boxes in the GUI, how can I user-optionally build for different archs? The sources specify "linkoptions" which is Gathered from pkg.link. Not sure where that comes from. I could take out "flagOSX11" and make two flags, but that seems uneccessary when you have a fully features build environment setup. Can I define a new GCC32 and supply different flags?
creator: lundman
date: 2006-12-19T00:15:05-00:00

Re: MacOS X woes
type: item
description: Fetched latest sources to try out the Serialization changes (20th GMT 01:00). Lots of issues in Installer.cpp (path not defines etc) but I assume that is just work in progress, so //'ing my way through that. It didn't like "::" in "::GetLastError()" in Socket.cpp. Anyway, loading "ide" I get: Assertion failed in /Users/lundman/src/upp/uppsrc/Core/Stream.cpp, line 1362 !backup.IsError() (gdb) bt #0 0x9004796c in kill () #1 0x9012dc14 in abort () #2 0x00237abc in Upp::AssertFailed (file=0x3a68d0 "/Users/lundman/src/upp/uppsrc/Core/Stream.cpp", line=1362, cond=0x3a6c14 "!backup.IsError()") at Util.cpp:83 #3 0x002495fc in Upp::Load (serialize=@0xbffe6cb8, stream=@0xbffe6cc0) at Stream.cpp:1362 #4 0x0026ae5c in Upp::LoadFromFile (serialize=@0xbffe6d70, file=0x0) at Stream.cpp:1390 #5 0x00456624 in Upp::LoadFromFile<Ide> (x=@0xbffe6ee8, name=0x0) at Util.h:339 #6 0x00086bf0 in GuiMainFn_ () at idewin.cpp:805 #7 0x0008749c in main (argc=1, argv=0xbffffaec, envptr=0xbffffaf4) at idewin.cpp:571 That "name" and "file" are NULL probably is not good? But might be normal behavior for all I know. Also, I'm in _awe_ of the size of your "ide" variable. I'm never doing "p ide" again.
creator: lundman
date: 2006-12-20T03:13:38-00:00

Re: MacOS X woes
type: item
description: Fails due to 53 int version = 5; (gdb) s 54 s.Magic(0x12346); (gdb) s Upp::Stream::Magic (this=0xbffe6c20, magic=74566) at Stream.cpp:719 719 dword a = magic; (gdb) s 720 *this % a; [snip] Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbffe6a68, count=1) at Stream.cpp:459 459 EndianSwap(data, count); [snip] (gdb) n Upp::Stream::operator% (this=0xbffe6c20, d=@0xbffe6a68) at Stream.cpp:592 592 return *this; Upp::Stream::Magic (this=0xbffe6c20, magic=74566) at Stream.cpp:721 721 if(magic != a) LoadError(); (gdb) p magic $16 = 74566 (gdb) p a $17 = 1176699136
creator: lundman
date: 2006-12-20T03:44:50-00:00

Re: MacOS X woes
type: item
description: D'oh, you should have said I need to delete my .ide/ config files since they are all big-endian However, we do get this situation: rm .ide/ide.cfg gdb ide (gdb) run (Once loaded, click Cancel instead of Selection a main Package) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x1876d580 0x00275584 in Upp::RichEdit::SetupRuler (this=0xbfff707c) at Editor.cpp:272 272 zoom, q.grid, q.numbers, q.numbermul, q.marks); (gdb) p unit $1 = 16777216 And indeed, now that it has written "ide.cfg" it won't load it unless I delete it first, with the exact same core. So for some reason "unit" ends up big-endian in memory (as well as on disk?) even when Initialised from scratch.
creator: lundman
date: 2006-12-20T04:01:02-00:00

Re: MacOS X woes
type: item
description: I do not see obvious problem. I think breakpoint at RichEdit/Editor.cpp 452 and see what is going on.... Mirek
creator: mirek
date: 2006-12-20T07:55:31-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Mon, 18 December 2006 19:15 Ah whoopsie.. I assumed you had previously done CPU_PPC to be powerpc, since the PocketPC cpu arch is ARM, SH3 or MIPS. I will guess what is needed here and submit a patch. I use something along the lines of: #ifdef flagOSX11 OK, now at the beginning of Core.h. Mirek
creator: mirek
date: 2006-12-20T07:57:15-00:00

Re: MacOS X woes
type: item
description: Right Breakpoint 1, Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:453 453 int version = 1; (gdb) s 454 s / version; (gdb) s Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223 223 Stream& operator/(int& i) { dword w = i + 1; Pack(w); i = w - 1; return *this; } (gdb) s Upp::Stream::Pack (this=0xbffe6c20, w=@0xbffe6958) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:471 471 if(IsError()) return; (gdb) n 491 } (gdb) n 0x0041d410 in Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223 223 Stream& operator/(int& i) { dword w = i + 1; Pack(w); i = w - 1; return *this; } (gdb) n Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:455 455 s % unit; (gdb) p version $4 = 1 (gdb) p unit $5 = 1 (gdb) s Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:585 585 SerializeRaw((dword *)&d, 1); (gdb) s Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:457 457 SerializeRaw((byte *)data, 4 * count); (gdb) s Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c "", size=4) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:442 442 if(IsError()) return; (gdb) n 447 } (gdb) n Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:459 459 EndianSwap(data, count); (gdb) p data $6 = (dword *) 0xbfffb67c (gdb) p *data $7 = 1 (gdb) n 461 } (gdb) p *data $8 = 16777216 (gdb) n Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:586 586 return *this; (gdb) 587 } (gdb) Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:456 456 s % showcodes; (gdb) p unit $9 = 16777216 Seems it is given a default value, then gets …
creator: lundman
date: 2006-12-20T08:14:04-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Wed, 20 December 2006 03:14 Right Breakpoint 1, Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:453 453 int version = 1; (gdb) s 454 s / version; (gdb) s Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223 223 Stream& operator/(int& i) { dword w = i + 1; Pack(w); i = w - 1; return *this; } (gdb) s Upp::Stream::Pack (this=0xbffe6c20, w=@0xbffe6958) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:471 471 if(IsError()) return; (gdb) n 491 } (gdb) n 0x0041d410 in Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223 223 Stream& operator/(int& i) { dword w = i + 1; Pack(w); i = w - 1; return *this; } (gdb) n Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:455 455 s % unit; (gdb) p version $4 = 1 (gdb) p unit $5 = 1 (gdb) s Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:585 585 SerializeRaw((dword *)&d, 1); (gdb) s Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:457 457 SerializeRaw((byte *)data, 4 * count); (gdb) s Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c "", size=4) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:442 442 if(IsError()) return; (gdb) n 447 } (gdb) n Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:459 459 EndianSwap(data, count); (gdb) p data $6 = (dword *) 0xbfffb67c (gdb) p *data $7 = 1 (gdb) n 461 } (gdb) p *data $8 = 16777216 (gdb) n Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:586 586 return *this; (gdb) 587 } (gdb) Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:456 456 s % showcodes; (gdb) p unit $9 = 16777216 …
creator: mirek
date: 2006-12-20T08:29:12-00:00

Re: MacOS X woes
type: item
description: I pretty guessed that was the case, and it fixed it. It starts up correctly, and looks nice. No change in the icons that are off-colour still. Can't build anything at the moment, but I think that is due to that the -current version is "in between" versions, maybe. HelloWorld.cpp: hello.cpp:3: error: expected class name before `{' token Hmm odd - but anyway, will sync again next change. What we were fixing was the Image Editor in ide, and that does work now (reading my little endian .iml file and displays correctly) so that is one bug down. To focus on why icons in the IDE are odd coloured, where are they coming from? For example the "Help Topics"'s question mark icon? Any of the Examples do simple .png, .bmp tests?
creator: lundman
date: 2006-12-20T08:50:29-00:00

Re: MacOS X woes
type: item
description: Ah no I lie, it was just that my icon had little colour. If I draw a line on icons line of red line of green line of blue line of purple I visually see line of "nothing" line of "nothing" line of blue line of cyan Hmm maybe I shoul dhave screenshot that.. So, are RGBA perhaps needed to be Endian swapped too?
creator: lundman
date: 2006-12-20T08:59:51-00:00

Re: MacOS X woes
type: item
description: Yes, very likely, RGBA has to be swapped before being sent to X11. There are two ways how to do that. I think we should try to alter RGBA structure itself first Core/Color.cpp #ifdef CPU_LE struct RGBA : Moveable<RGBA> { byte b, g, r, a; }; #else struct RGBA : Moveable<RGBA> { byte a, r, g, b; }; #endif Mirek
creator: mirek
date: 2006-12-20T09:50:17-00:00

Re: MacOS X woes
type: item
description: http://netbsd.interq.or.jp/~lundman/osx8.jpg Very pretty. Running out of things to fix now. Only thing missing is the ability to specify linking options, or somehow be able to do cross-compile for the other arch. Final code changes: Core/Core.h #endif // #ifdef flagFREEBSD #ifdef flagOSX11 #define PLATFORM_OSX11 #define PLATFORM_POSIX #ifdef flagGUI #define PLATFORM_X11 #endif #ifdef flagTESTLEAKS #define TESTLEAKS #endif // defines set by OsX for us. #ifdef __POWERPC__ #define flagPOWERPC #endif #ifdef __i386__ #define flagX86 #endif #endif #elif defined(flagPPC) #define CPU_32 #define CPU_PPC #define CPU_BE #define CPU_BIG_ENDIAN #define CPU_ALIGNED +#elif defined(flagPOWERPC) + #define CPU_32 + #define CPU_POWERPC + #define CPU_BE + #define CPU_BIG_ENDIAN + #define CPU_ALIGNED #else And the same changed in CppBuilder.cpp and GccBuilder.cpp, Host.cpp, bmphdr.h And the 2 PackageOrganiser changes. Next semi-stable release I can make a PPC binary, but Intel needs to wait for the Link options (unless I temporarily hardcode it)
creator: lundman
date: 2006-12-20T12:23:08-00:00

Re: MacOS X woes
type: item
description: Do you think you could zip and post all changed files? (Just to be sure that I apply changes correctly). Mirek
creator: mirek
date: 2006-12-20T15:06:39-00:00

Re: MacOS X woes
type: item
description: As requested, attached file. I guess I could also mention two other things, they don't really affect the usage of U++, but sometimes perfection is desirable. When a Window is minimized (or possibly removed) Console gets: X Error: BadMatch (invalid parameter attributes), request: X_SetInputFocus, resource id: 6295038 = 600DFE but it is just noisy, no noticable impact. And when you exit the Ide: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x000004d0 0x00f20468 in XQueryExtension () (gdb) bt #0 0x00f20468 in XQueryExtension () #1 0x00f161c0 in XInitExtension () #2 0x018bf34c in XextAddDisplay () #3 0x00df11e0 in XRenderFreePicture () #4 0x00320568 in Upp::Image::Data::SysRelease (this=0x1bd3488) at /Users/lundman/src/upp/uppsrc/Draw/ImageX11.cpp:63 #5 0x002fdbf4 in Upp::Image::Data::~Data (this=0x1bd3488) at Image.cpp:324 #6 0x005850dc in Upp::Image::Data::Release (this=0x1bd3488) at Image.h:117 #7 0x002fdd04 in Upp::Image::~Image (this=0x200993c) at Image.cpp:278 #8 0x0044928c in Upp::Iml::IImage::~IImage (this=0x2009938) at Image.h:253 #9 0x0045a694 in Upp::DestroyArray<Upp::Iml::IImage> (t=0x2009938, lim=0x2009a10) at Topt.h:175 #10 0x0045a76c in Upp::Vector<Upp::Iml::IImage>::Free (this=0x91ea40) at Vcont.hpp:101 #11 0x0045a80c in Upp::Vector<Upp::Iml::IImage>::~Vector (this=0x91ea40) at Vcont.h:82 #12 0x0045a848 in Upp::AMap<Upp::String, Upp::Iml::IImage, Upp::Vector<Upp::Iml::IImage>, Upp::StdHash<Upp::String> >::~AMap (this=0x91ea04) at Map.h:2 #13 0x0045a8c0 in Upp::VectorMap<Upp::String, Upp::Iml::IImage, Upp::StdHash<Upp::String> >::~VectorMap (this=0x91ea00) at Map.h:130 #14 0x0047571c in Upp::Iml::~Iml (this=0x91e9f4) at Image.h:252 #15 0x002ae584 in __tcf_0 () at iml_source.h:54 #16 0x00003a44 in cxa_atexit_wrapper () #17 0x9001455c in __cxa_finalize () #18 0x90014444 in exit () #19 0x00002c58 in _start () #20 0x00002958 in start () But all files are saved correctly, so again, no impact, just…
creator: lundman
date: 2006-12-21T01:21:53-00:00

Re: MacOS X woes
type: item
description: Bored at work, so I looked at it. Reason it complains, is that Xdisplay is NULL, presumably already been freed. I changed the code to void Image::Data::SysRelease() { if(picture) { if(Xdisplay) XRenderFreePicture(Xdisplay, picture); ResCount -= !paintonly; picture = 0; } if(picture8) { if (Xdisplay) XRenderFreePicture(Xdisplay, picture8); And now I get: Program exited normally. So that is something. Might not be the proper fix though.
creator: lundman
date: 2006-12-21T03:29:19-00:00

Re: MacOS X woes
type: item
description: I sent a binary of my app to a colleague to check and we found an interesting problem. It does not start up, but spins forever, ktrace tells us it is in: 11119 UFxp CALL open(0xe521f4,0,0) 11119 UFxp NAMI "libgtk-x11-2.0.so" 11119 UFxp RET open -1 errno 2 No such file or directory 11119 UFxp CALL close(0xffffffff) 11119 UFxp RET close -1 errno 9 Bad file descriptor 11119 UFxp CALL open(0xbfffefa0,0,0) 11119 UFxp NAMI "libgtk-x11-2.0.so.36" 11119 UFxp RET open -1 errno 2 No such file or directory Which is interesting, since it isn't linked against those libraries the usual way. I assume then that you use dynamic library load at run time, and perhaps does not deal with the error as well as one would hope? What should normally happen on failure to open a library? Lund
creator: lundman
date: 2006-12-21T13:05:06-00:00

Re: MacOS X woes
type: item
description: U++ tries to dlopen gtk libraries to use it for theming widgets. If that fails, "standard" look is used. Mirek
creator: mirek
date: 2006-12-21T20:25:46-00:00

Re: MacOS X woes
type: item
description: Ok, I will try with the latest build to see if it still happens, that was a 605 build. I will hold off on 612-dev2 as it doesn't have all the OsX changes, and stay with the -current versions for now.
creator: lundman
date: 2006-12-22T11:34:47-00:00

Re: MacOS X woes
type: item
description: Applied all changes EXCEPT bmphdr, which does not make a sense to me... (casting word reference to word reference?!). But maybe it was just old version. Mirek
creator: mirek
date: 2006-12-22T18:09:30-00:00

Re: MacOS X woes
type: item
description: Thank you! Synced and trying... You forgot the Color.h changes for RGBA. Compiling we get: Bmp.cpp /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h: In member function 'void Upp::BMP_FILEHEADER::SwapEndian()': /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:18: error: cannot bind packed field '((Upp::BMP_FILEHEADER*)this)->Upp::BMP_FILEHEADER:: bfType' to 'Upp::word&' /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:19: error: cannot bind packed field '((Upp::BMP_FILEHEADER*)this)->Upp::BMP_FILEHEADER:: bfSize' to 'Upp::dword&' [snip] Which I can "fix" by casting it (lets me compile it at least) Later on I get: uppsrc/CtrlCore/Win32Proc.cpp:3:20 error winnls.h: No such file or directory I assume it is just too high up, actually its included twice, so I just removed the top one. Install.cpp /Users/lundman/src/upp/uppsrc/ide/Install.cpp: In member function 'void XInstallDlg::FindInstFolder()': /Users/lundman/src/upp/uppsrc/ide/Install.cpp:267: error: 'path' was not declared in this scope /Users/lundman/src/upp/uppsrc/ide/Install.cpp: In constructor 'XInstallDlg::XInstallDlg()': /Users/lundman/src/upp/uppsrc/ide/Install.cpp:280: error: 'tutorial' was not declared in this scope /Users/lundman/src/upp/uppsrc/ide/Install.cpp:281: error: 'path' was not declared in this scope /Users/lundman/src/upp/uppsrc/ide/Install.cpp: In function 'bool Install()': /Users/lundman/src/upp/uppsrc/ide/Install.cpp:304: error: 'struct XInstallDlg' has no member named 'path' /Users/lundman/src/upp/uppsrc/ide/Install.cpp:311: error: 'struct XInstallDlg' has no member named 'path' /Users/lundman/src/upp/uppsrc/ide/Install.cpp:346: error: 'struct XInstallDlg' has no member named 'tutorial' ide: 1 file(s) built in (0:04.97), 4977 msecs / file, duration = 5748 msecs Apart from that, builds.
creator: lundman
date: 2006-12-23T03:43:04-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Fri, 22 December 2006 22:43 Thank you! Synced and trying... You forgot the Color.h changes for RGBA. You forgot to send the file Quote: /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:18: error: cannot bind packed field '((Upp::BMP_FILEHEADER*)this)->Upp::BMP_FILEHEADER:: bfType' to 'Upp::word&' Ahh, "packed field" rings the bell - it treats the __atrribute__(packed) using bit fields! Which makes your fix most likely wrong. Tried to fix (by adding SwapEndian functions which operate with value input and value return). If it compiles, please try to load some .bmp files - there is nice examples/ImageView. Quote: Later on I get: uppsrc/CtrlCore/Win32Proc.cpp:3:20 error winnls.h: No such file or directory I assume it is just too high up, actually its included twice, so I just removed the top one. Fixed. Quote: Install.cpp /Users/lundman/src/upp/uppsrc/ide/Install.cpp: In member function 'void XInstallDlg::FindInstFolder()': /Users/lundman/src/upp/uppsrc/ide/Install.cpp:267: error: 'path' was not declared in this scope Interesting. path should be defined in ide.lay. Mirek
creator: mirek
date: 2006-12-23T08:03:01-00:00

Re: MacOS X woes
type: item
description: It was your fix Color.h: #ifdef PLATFORM_WIN32 struct RGBA : Moveable<RGBA> { byte b, g, r, a; }; #endif #ifdef PLATFORM_POSIX #ifdef CPU_BE struct RGBA : Moveable<RGBA> { byte a, r, g, b; }; #else struct RGBA : Moveable<RGBA> { byte b, g, r, a; }; #endif #endif #ifndef PLATFORM_WIN32 "path" is defined in .lay, I checked, but it just doesn't want to compile bmphdr (looks like no change): /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h: In member function 'void Upp::BMP_FILEHEADER::SwapEndian()': /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:18: error: no matching function for call to 'Upp::BMP_FILEHEADER::SwapEndian(Upp::word&) ' /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:15: note: candidates are: void Upp::BMP_FILEHEADER::SwapEndian() /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:19: error: no matching function for call to 'Upp::BMP_FILEHEADER::SwapEndian(Upp::dword& )' etc
creator: lundman
date: 2006-12-23T09:58:04-00:00

Re: MacOS X woes
type: item
description: bmphdr: In Core/util.h there should be inline word SwapEndian(word v) { EndianSwap(v); return v; } inline int16 SwapEndian(int16 v) { EndianSwap(v); return v; } inline dword SwapEndian(dword v) { EndianSwap(v); return v; } inline int SwapEndian(int v) { EndianSwap(v); return v; } inline long SwapEndian(long v) { EndianSwap(v); return v; } inline int64 SwapEndian(int64 v) { EndianSwap(v); return v; } inline uint64 SwapEndian(uint64 v) { EndianSwap(v); return v; } I am really not sure what can be wrong here.... (Color.h altered). Mirek
creator: mirek
date: 2006-12-23T10:17:10-00:00

Re: MacOS X woes
type: item
description: I can confirm those functions are in there, and both my utils.h and bmphdr.h are up to date. c++ -c -I"/Users/lundman/MyApps" -I"/Users/lundman/src/upp/uppsrc" -I"/usr/X11R6/include" -I"/opt/local/include" -I"/usr/X11R6/include/fr eetype2" -DflagGUI -DflagMT -DflagGCC32 -DflagSHARED -DflagOSX11 -DbmYEAR=2006 -DbmMONTH=12 -DbmDAY=23 -DbmHOUR=20 -DbmMINUTE=4 -DbmSE COND=18 -m32 -fexceptions -Os -finline-limit=20 -x c++ "/Users/lundman/src/upp/uppsrc/plugin/bmp/Icon.cpp" -o "/Users/lundman/uppsrc -612d/out/plugin/bmp/GCC32.Gui.Mt.Shared/Icon.o" /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h: In member function 'void Upp::BMP_FILEHEADER::SwapEndian()': /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:18: error: no matching function for call to 'Upp::BMP_FILEHEADER::SwapEndian(Upp::word&) ' /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:15: note: candidates are: void Upp::BMP_FILEHEADER::SwapEndian() /Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:19: error: no matching function for call to 'Upp::BMP_FILEHEADER::SwapEndian(Upp::dword& )'
creator: lundman
date: 2006-12-23T11:10:41-00:00

Re: MacOS X woes
type: item
description: Strange. OK, try to assign to local variable first: word x = bfType; bfType = SwapEndian(x); Mirek
creator: mirek
date: 2006-12-23T12:21:37-00:00

Re: MacOS X woes
type: item
description: Same deal. The only candidates are SwapEndian which line 15 above, in bmphdr.h However if I make it UPP::SwapEndian it compiles too. Trying sample..
creator: lundman
date: 2006-12-23T12:47:06-00:00

Re: MacOS X woes
type: item
description: Sample ImageViewer looks good, displays the few .bmp I have on the system.
creator: lundman
date: 2006-12-23T13:30:45-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Sat, 23 December 2006 07:47 Same deal. The only candidates are SwapEndian which line 15 above, in bmphdr.h However if I make it UPP::SwapEndian it compiles too. Trying sample.. OMG, I am so stupid... Of course. Clashes with the method name... I guess we can consider that resolved... Mirek
creator: mirek
date: 2006-12-23T14:30:01-00:00

Re: MacOS X woes
type: item
description: Great. Do I need to send you that file? Also, possible bug, on my colleague's machine, which don't have much of the X11 stuff, he dies in XftCharExists(), from DrawTextXftp.cpp:86. XftFont *xftfont = XftFontOpen(Xdisplay, Xscreenno, XFT_FAMILY, XftTypeString, (char *)face, XFT_PIXEL_SIZE, XftTypeInteger, 20, (void *)0); int n = 0; for(int c = 0; c < 128; c++) if(!XftCharExists(Xdisplay, xftfont, c + 256)) n++; So I added: XftFont *xftfont = XftFontOpen(Xdisplay, Xscreenno, XFT_FAMILY, XftTypeString, (char *)face, XFT_PIXEL_SIZE, XftTypeInteger, 20, (void *)0); if (!xftfont) return 0; int n = 0; Which stops it from coring and gets further in. Lund
creator: lundman
date: 2006-12-24T00:58:40-00:00

Re: MacOS X woes
type: item
description: After fixing that Xft issue, it actually starts the application, but dies in Acquire() later on, so I guess his Xft is returning many non-standard things (he seems to have no X11 fonts). f->xftfont = CreateXftFont(font, angle); f->filename = NULL; f->ascent = (int16)f->xftfont->ascent; f->descent = (int16)f->xftfont->descent; Which happens because CreateXftFont() returns NULL. But I am unsure how to fix this, or if we would just consider it "too broken" not to have fonts? But complaining would be nicer than coring. I can add: f->xftfont = CreateXftFont(font, angle); if (f->xftfont) return NULL; But we've already called InsertNext(HASH) on it, so would have to roll that back. If I call CreateXftFont() before we call fh->InsertNext() it will eventually die in; Draw.h: void Retain(const FontInfo& f) { ptr = f.ptr; ptr->count++; charset = f.charset; } Because ptr is NULL. If I wrap that with "if (ptr)" ... 0x0033fa68 in Upp::FontInfo::GetAveWidth (this=0xbffe4080) at Draw.h:316 316 int GetAveWidth() const { return ptr->avewidth; } So not sure how deep I would need to go, or if I am even doing the right thing I can simulate his setup by renaming the "fonts.conf" file to something else.
creator: lundman
date: 2006-12-26T06:20:27-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Tue, 26 December 2006 01:20 After fixing that Xft issue, it actually starts the application, but dies in Acquire() later on, so I guess his Xft is returning many non-standard things (he seems to have no X11 fonts). f->xftfont = CreateXftFont(font, angle); f->filename = NULL; f->ascent = (int16)f->xftfont->ascent; f->descent = (int16)f->xftfont->descent; Which happens because CreateXftFont() returns NULL. But I am unsure how to fix this, or if we would just consider it "too broken" not to have fonts? Yes, too broken. I would not waste the time with this; the final Mac solution should use Carbon anyway, I consider this effort as an intermediate step (but very important, because we have actually fixed all CPU incompatibility bugs in this productive session). Mirek
creator: mirek
date: 2006-12-26T07:58:02-00:00

Re: MacOS X woes
type: item
description: Yeah, I might stick a message into CharExists() call returning NULL, it'll core, but at least it will tell the user why. What is the step for native? I see about 11 files for the X11 support, so presumably the same will be needed for native. Are you going to install OsX and make it happen?
creator: lundman
date: 2006-12-26T08:43:48-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Tue, 26 December 2006 03:43 Yeah, I might stick a message into CharExists() call returning NULL, it'll core, but at least it will tell the user why. What is the step for native? I see about 11 files for the X11 support, so presumably the same will be needed for native. Are you going to install OsX and make it happen? ...as soon as 2007.1 is out... Mirek
creator: mirek
date: 2006-12-26T09:47:43-00:00

Re: MacOS X woes
type: item
description: Neat. well, hmm, guess I ran out of things to do.. back to being bored at work.. suppose I could go through the app's todo list and fix somethings...
creator: lundman
date: 2006-12-27T07:29:23-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Wed, 27 December 2006 02:29 Neat. well, hmm, guess I ran out of things to do.. back to being bored at work.. suppose I could go through the app's todo list and fix somethings... If you wish, there is still a couple of MacOS X things that can be done now as preparation for things to come: * create minimal carbon app (using just U++ Core) in TheIDE - means something that just opens main carbon window and builds in TheIDE * investigate how to get basic drawing primitives working, DrawRect, DrawText and DrawImage. * investigate how to get event loops Mirek
creator: mirek
date: 2006-12-27T08:06:31-00:00

Re: MacOS X woes
type: item
description: While looking into your "No 1" task, I discovered PackageOrganiser/Add/Remove-Flags.. siigghh.. all my complaining about no link-options Anyway, it would be nice if the "WHEN" could also sense the BuildEnvironment-name used. "GCC32" and "GCC32CARBON" or what not. Anyway, very simple carbon app compiled in U++ as "Core console project", straight out of developer.apple.com, so no credits to me: UPPCarbon.cpp: #include <Carbon/Carbon.h> #include "UPPCarbon.h" #define kWindowTop 100 #define kWindowLeft 50 #define kWindowRight 250 #define kWindowBottom 250 const EventTypeSpec eventList[] = { { kEventClassWindow, kEventWindowClose }, { kEventClassWindow, kEventWindowActivated }, { kEventClassWindow, kEventWindowDeactivated }, }; static pascal OSStatus MyWindowEventHandler(EventHandlerCallRef nextHandler, EventRef theEvent, void *userData) { OSStatus result = eventNotHandledErr; WindowRef theWindow = (WindowRef) userData; UInt32 whatHappened; whatHappened = GetEventKind(theEvent); switch(whatHappened) { case kEventWindowClose: DisposeWindow(theWindow); QuitApplicationEventLoop(); result = noErr; break; case kEventWindowActivated: ::CallNextEventHandler(nextHandler, theEvent); result = noErr; break; case kEventWindowDeactivated: ::CallNextEventHandler(nextHandler, theEvent); result = noErr; break; } return result; } void Initialize(void) { // Do one-time-only initialization WindowRef theWindow; WindowAttributes windowAttrs; Rect contentRect; EventHandlerUPP handlerUPP; windowAttrs = kWindowStandardDocumentAttributes | kWindowStandardHandlerAttribute; SetRect(&contentRect, kWindowLeft, kWindowTop, kWindowRight, kWindowBottom); CreateNewWindow(kDocumentWindowClass, windowAttrs, &contentRect, &theWindow); SetWindowTitleWithCFString(theWindow, CFSTR("U++ Carbon Example")); handlerUPP = NewEventHandlerUPP(MyWindowEventHandler); InstallWindowEventHandler(theWindow, handlerUPP, GetEventTypeCount(eventList), eventList, theWindow, NULL); ShowWindow(theWindow); InitCursor(); } void F…
creator: lundman
date: 2006-12-29T04:41:17-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Thu, 28 December 2006 23:41 While looking into your "No 1" task, I discovered PackageOrganiser/Add/Remove-Flags.. siigghh.. all my complaining about no link-options Anyway, it would be nice if the "WHEN" could also sense the BuildEnvironment-name used. "GCC32" and "GCC32CARBON" or what not. I believe that would not be very systematic, because end users can use any name for build method they want to (unlike build flags).... Carbon app in U++ is cool Looking forward to get my hands on it.... Mirek
creator: mirek
date: 2006-12-29T06:34:41-00:00

Re: MacOS X woes
type: item
description: Thanks, that was quite fun, and the apple docs are pretty good. But yes, we need someway to be able to specify linker flags, I think you should just add link options, next to compile options in the build environment, but I guess I can also get around that with -Wl,flags but that is very noisy. Also, the ide leaves a lot of zombies around when compiling, are you calling wait(3) properly on the children? Lund
creator: lundman
date: 2006-12-30T08:16:29-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Sat, 30 December 2006 03:16 Also, the ide leaves a lot of zombies around when compiling, are you calling wait(3) properly on the children? Yes, I am aware of the problem. No, most likely not (I mean, I am not calling wait properly Starting another thread about this problem. Mirek
creator: mirek
date: 2006-12-30T08:32:13-00:00

Re: MacOS X woes
type: item
description: Well, for those who want to play with the IDE on OsX, or yourself, since it is easier to build U++ when you have a working u++ ide, I put this together: # file Ultimate++-612dev3/ide.App/Contents/MacOS/ide Ultimate++-612dev3/ide.App/Contents/MacOS/ide: Mach-O fat file with 2 architectures Ultimate++-612dev3/ide.App/Contents/MacOS/ide (for architecture ppc): Mach-O executable ppc Ultimate++-612dev3/ide.App/Contents/MacOS/ide (for architecture i386): Mach-O executable i386 Which can be fetched from here: http://www.lundman.net/ftp/Ultimate++-612dev3.dmg Which is the 612dev2 ide+patches, with the 612dev3 sources "as-is". Lund
creator: lundman
date: 2006-12-31T10:32:06-00:00

Re: MacOS X woes
type: item
description: lundman wrote on Sat, 23 December 2006 19:58 Great. Do I need to send you that file? Also, possible bug, on my colleague's machine, which don't have much of the X11 stuff, he dies in XftCharExists(), from DrawTextXftp.cpp:86. BTW, as I was stucked a day or two at the same trouble, the one thing that heals this issue is: sudo fc-cache After that, TheIDE finally starts again... Mirek
creator: mirek
date: 2007-04-17T08:11:43-00:00