[Pythonmac-SIG] A question about embedding with Mac OS X
Carbon
Alexandre Parenteau
alexp@strata.com
Mon, 15 Jul 2002 14:40:59 -0700
Jay,
I make my best to come up with a set of examples of how to do it properly. I
should have that by the ned of the week. I see you run into specific and
real issues here:
You need GUSI2 distributed by Jack (Jack already told why).
If the SIOUX console is still showing up, try to do this prior of calling
PyMac_SetConsoleHandler and PyMac_Initialize :
#if TARGET_RT_MAC_CFM
// work around for a bug of Python 2.2 which draws the
// Sioux menu even though we have a custom console
extern int console_output_state;
console_output_state = 1;
#endif
I thought this problem was corrected in 2.2.1, but I might be wrong.
MAKE SURE YOU USE the correct Python (look inside your /Library/CFMSupport
folder), you may have an earlier Python 2.2 which messes the things around.
Alex.
> At 11:50 AM -0700 on 7/13/02, Alexandre Parenteau wrote:
>
>> Jay,
>>
>> Please type inside the MacCVs console :
>>
>> import sys
>> print sys.version
>>
>> 2.2.1 (#133, May 8 2002, 22:24:21) [CW CARBON GUSI2 THREADS GC]
>>
>> print sys.exec_prefix
>>
>> Sources:python:dist:src:
>>
>> This will help us to see if you use the good thing.
>>
>> alex.
>
> Alex,
>
> I had the problem when using my own hacked-up build of
> PythonCoreCarbon myself. When I use the PythonCoreCarbon that comes
> in the binary installation, all works well. No double menus.
>
> Cool, so I went and used the shipping PythonCoreCarbon library with
> my application. It initializes well with this opening code:
>
> ---
> mHasPython = (Ptr) PyMac_Initialize !=
> (Ptr)kUnresolvedCFragSymbolAddress;
> if( mHasPython )
> {
> PyMac_SetConsoleHandler(PyMac_DummyReadHandler,
> PyMac_DummyWriteHandler,
> PyMac_DummyWriteHandler);
> PyMac_Initialize();
> }
> ---
>
> However, shortly later, my application crashes when it attempts to
> load one my custom resource types, a type of resource I've been using
> for months before I introduced Python to the mix. If I don't make the
> above two calls to Python, then the error goes away. So, I thought
> "Maybe it's because PyMac_Initialize() is doing those couple of
> toolbox initialization calls (InitCursor, InitAppearanceManager),
> what if I took those away, will the crash also go?" So, of course, I
> had to build my own version of PythonCoreCarbon.
>
> When I tried to build PythonCoreCarbon "out of the box" I get GUSI
> compile errors. I'm using the latest GUSI, 2.2.2, downloaded from
> Source Forge. The compile errors, when I try to build
> PythonCoreCarbon are:
>
> Error : expression syntax error
> GUSIBasics.h line 34 ..GENERATINGCFM_is_obsolete..
>
> Error : undefined identifier 'LMGetTicks'
> GUSISocket.h line 117 void CheckClose(UInt32 now = LMGetTicks())
>
> I get the impression that GUSI 2.2.2 isn't Carbon ready.
>
> I poked around in the MacPython README file and saw mention of this:
>
> ---
> A special mention is deserved by Matthias Neeracher, who has written
> the brilliant unix-compatible GUSI I/O library, without which
> MacPython would not have sockets or select, and to Alexandre
> Parenteau, who has ported this library to Carbon.
> ---
>
> Did you (Alex) do tweaks to GUSI to make it Carbon friendly? Where
> are these tweaks, how do I apply them?
>
> Really looking forward to moving past this point.
>
> Thanks,
>
> /Jay
>
>
>
>>
>> ----- Original Message -----
>> From: "Jay Koutavas" <jay@heynow.com>
>> To: <pythonmac-sig@python.org>
>> Sent: Saturday, July 13, 2002 11:23 AM
>> Subject: Re: [Pythonmac-SIG] A question about embedding with Mac OS X Carbon
>>
>>
>>> [Although this email is slightly off-topic (it goes into some
>>> specifics about building MacCVS), I think it's worth adding to the
>>> public thread I've started on this subject.
>>>
>>> Note, the troubles I'm seeing with building MacCVS are *not*
>>> indicative of the quality of MacCVS. I've used MacCVS before and can
>>> say it's a very worthy CVS client. More accurately, they're
>>> indicative of missing information I have as I come up to speed on the
>>> subject of building MacCVS and Python.
>>>
>>> With that all said, here's my next email on this subject, which
>>> contains additional information on what I'm trying to achieve with my
>>> Python embed.
>>>
>>> /Jay]
>>>
>>> Alex,
>>>
>>> Thank you for your emails on this subject.
>>>
>>> One thing I realized, after reading the thread was that I didn't
>>> clarify the target of my OS X Carbon application. It's CFM, not
>>> Mach-O. The reason I am CFM-targeted is that my application needs to
>>> also run on Mac OS 9. Single binary. It is not a requirement that the
>>> application supports Python when running on OS 9, thus the weak link
>>> I spoke of in my opening email. Also, for sake of providing possible
>>> missing useful information, I'm using CodeWarrior 7.2 as my
>>> development environment. My C/C++ application also runs on Windows,
>>> and am using CodeWarrior there too.
>>>
>>> I learned from this thread that if I'm going to embed Carbon Python
>>> into a CFM application running on Mac OS X, I'll either have to use
>>> GUSI, or I'll have to do the rather tedious Mach-O --> CFM wrapping
>>> technic you outlined in this email. I've done this sort of wrapping
>>> for specific Quartz calls, so I am familiar with it.
>>>
>>> So, I looked over MacCVS. First, I build MacCVS 3.2 Carbon from
>>> sources and built Python 2.2.1's PythonCarbonLib and dropped it into
>>> the same folder as the MacCVS application. Launching MacCVS on Mac OS
>>> X 10.1.5, I found the following two problems:
>>>
>>> 1) the console window that you provide comes up under macCVS's
>>> toolbar. I see no way to get it moved into the foreground
>>>
>>> 2) MacCVS is suffering from the "dual menubar problem" -- where SIOUX
>>> (via PythonCarbonLib) is presenting it's own rendition of the main
>>> menu to the right of MacCVS's, resulting in an unusable application.
>>>
>>> At this point I thought I'd better get the latest sources, and did a
>>> full CVS get of MacCVS. I built the Carbon target of MacCVS with
>>> minimum fuss (there's a broken copy of getdate.c in CVS at the
>>> moment) and dropped my same copy of PythonCarbonLib into the
>>> application's folder. MacCVS from latest sources won't launch. What
>>> happens is it brings up a dialog stating that no debugger was found
>>> and that it's not a fatal thing, but then silently the application
>>> quits.
>>>
>>> I then tried to make the Mach-O target of MacCVS from latest sources.
>>> When launching it, there's a dialog saying "You need to put
>>> PythonCarbonLib into the application folder to get python support." I
>>> have one there. The MacCVS Mach-o application doesn't recognize it.
>>>
>>> My questions:
>>>
>>> 1) How do I get MacCVS Mach-o to run with Python via latest sources?
>>>
>>> 2) (the question I was persuing at the start of this) Should I
>>> attempt to follow your lead and wrap Python-Mach-O calls for use in
>>> my CFM application? How much work is it? Will it be a mere matter of
>>> copy/pasting your work?
>>>
>>> Best,
>>>
>>> /Jay
>>>
>>> --
>>> '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>>> Jay Koutavas mailto:jay@heynow.com
>>> Heynow Software http://www.heynow.com
>>> Windham, New Hampshire, USA
>>> '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>>>
>>>
>>> _______________________________________________
>>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org
>>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>>
>