Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » Mac OS » MacOS X woes
Re: MacOS X woes [message #7352 is a reply to message #7351] Sat, 23 December 2006 11:17 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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
Re: MacOS X woes [message #7356 is a reply to message #7352] Sat, 23 December 2006 12:10 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
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&
        )'

Re: MacOS X woes [message #7364 is a reply to message #7356] Sat, 23 December 2006 13:21 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Strange. OK, try to assign to local variable first:

word x = bfType;
bfType = SwapEndian(x);

Mirek
Re: MacOS X woes [message #7366 is a reply to message #7364] Sat, 23 December 2006 13:47 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
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..

Re: MacOS X woes [message #7367 is a reply to message #7366] Sat, 23 December 2006 14:30 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

Sample ImageViewer looks good, displays the few .bmp I have on the system.

Re: MacOS X woes [message #7368 is a reply to message #7366] Sat, 23 December 2006 15:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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
Re: MacOS X woes [message #7375 is a reply to message #7368] Sun, 24 December 2006 01:58 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
Great. Do I need to send you that file?Smile

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
Re: MacOS X woes [message #7381 is a reply to message #7375] Tue, 26 December 2006 07:20 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

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.

Re: MacOS X woes [message #7382 is a reply to message #7381] Tue, 26 December 2006 08:58 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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
Re: MacOS X woes [message #7383 is a reply to message #7382] Tue, 26 December 2006 09:43 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member


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?

Re: MacOS X woes [message #7384 is a reply to message #7383] Tue, 26 December 2006 10:47 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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
Re: MacOS X woes [message #7403 is a reply to message #7384] Wed, 27 December 2006 08:29 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

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...

Re: MacOS X woes [message #7406 is a reply to message #7403] Wed, 27 December 2006 09:06 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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
Re: MacOS X woes [message #7427 is a reply to message #7406] Fri, 29 December 2006 05:41 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
While looking into your "No 1" task, I discovered PackageOrganiser/Add/Remove-Flags.. siigghh.. all my complaining about no link-options Smile 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 Finalize(void)
{
        
}


using namespace UPP;


CONSOLE_APP_MAIN
{
        Initialize(); // Do one-time-only initialization
        
        RunApplicationEventLoop(); //Process events until time to quit
        
        Finalize(); // Do one-time-only finalization

}



Extra link flags, and post-link step added:

UPPCarbon.upp:
flags(OSX11) "-framework carbon";

uses
        Core;

link(OSX11) " -framework carbon";

file
        UPPCarbon.h,
        UPPCarbon.cpp;

mainconfig
        "" = "";

custom(OSX11) "post-link",
        "mkdir -p $(OUTTITLE).App/Contents/MacOS\ncp $(OUTPATH) $(OUTTITLE).App"
        "/Contents/MacOS",
        "";


And yes, creating the UPPCarbon.App/Contents/MacOs/ is required for it to fully function.


Looks like:

http://netbsd.interq.or.jp/~lundman/carbon.jpg


index.php?t=getfile&id=416&private=0
  • Attachment: carbon.jpg
    (Size: 31.89KB, Downloaded 939 times)
Re: MacOS X woes [message #7430 is a reply to message #7427] Fri, 29 December 2006 07:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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 Smile 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 Smile Looking forward to get my hands on it....

Mirek
Re: MacOS X woes [message #7449 is a reply to message #7430] Sat, 30 December 2006 09:16 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

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
Re: MacOS X woes [message #7452 is a reply to message #7449] Sat, 30 December 2006 09:32 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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 Smile

Starting another thread about this problem.

Mirek
Re: MacOS X woes [message #7486 is a reply to message #7452] Sun, 31 December 2006 11:32 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
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".

index.php?t=getfile&id=420&private=0


Lund
  • Attachment: idescrn.jpg
    (Size: 38.43KB, Downloaded 2709 times)
Re: MacOS X woes [message #9098 is a reply to message #7375] Tue, 17 April 2007 10:11 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
lundman wrote on Sat, 23 December 2006 19:58

Great. Do I need to send you that file?Smile

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
Next Topic: 701-dev1 / 2007.1beta on Mac OSX
Goto Forum:
  


Current Time: Fri Mar 29 09:52:49 CET 2024

Total time taken to generate the page: 0.02073 seconds