If part of all code can be compiled as .so library on Mac and also be imported by python, it will be ideal case. As I tried swig utility, it seems it does not work well on Mac. It does not show the error message. I do not know the reason. The compile and ld linker seems fine. I would like to have
Hi. I am wondering if anyone has a working example of using a WebKitCtl
for Mac with wxpython. I am wanting HTMLWindow functionality but have
not been able to create an instance. Many thanks.
David
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.or
On Dec 13, 2005, at 4:45 PM, Zhi Peng wrote:
> See if I go the right direction.
>
> On Wed, I will use my old code to build .so file which is run on
> Linux. See what happen.
>
> I used swig and get name.so file and get rid of error message. When
> I start python or pythonw and import name
>
See if I go the right direction. On Wed, I will use my old code to build .so file which is run on Linux. See what happen. I used swig and get name.so file and get rid of error message. When I start python or pythonw and import name from command line, it just hang there. It is interesting
On Dec 13, 2005, at 3:59 PM, Zhi Peng wrote:
> As I tried to make shared dynamic library, ld command shows some
> error message
>
> ld: Undefined symbols:
> dyld_stub_binding_helper
>
> I do not know which lib including this "dyld_stub_binding_helper"
> even though I used "nm" to find it. The
Hi! Bob As I tried to make shared dynamic library, ld command shows some error message ld: Undefined symbols: dyld_stub_binding_helper I do not know which lib including this "dyld_stub_binding_helper" even though I used "nm" to find it. The list libs that I used is -L/usr/lib -L/usr
Suspecting the hard drive, I ran Disk Utility on it from another
startup disk. The Disk Repair option found, among other things, a
large number of orphaned nodes (inodes?) whose names started with
"temp" and repaired them. Whatever it did, it seems to have fixed my
problem. Thanks.
On D
On Dec 13, 2005, at 1:30 PM, Zhi Peng wrote:
> Actually there is only one step away, that is, pythonw and python.
> With python, I can import modules by using PyImport_ImportModule
> ("name"). But I have to use pythonw since I used appscript. Then I
> can not import modules sucessfully with
On Dec 13, 2005, at 1:22 PM, Rob Managan wrote:
> Bob Ippolito gives a simple example of using setuptools to develop
> modules. That got me interested in installing setuptools. I followed
> the instructions for a non-admin OSX user and created a
> .pydistutils.cfg file to point to the site-packag
Bob Actually there is only one step away, that is, pythonw and python. With python, I can import modules by using PyImport_ImportModule("name"). But I have to use pythonw since I used appscript. Then I can not import modules sucessfully with same commands. If converting C code to python, th
Bob Ippolito gives a simple example of using setuptools to develop
modules. That got me interested in installing setuptools. I followed
the instructions for a non-admin OSX user and created a
.pydistutils.cfg file to point to the site-packages is use with raw
distutils stuff. Then I tried to us
On Dec 13, 2005, at 1:01 PM, Bill Spotz wrote:
> OK, I seem to be converging on something here, but I don't know what
> to do with it. Shark gives me the following tree:
>
> 97.6% 97.6% mach_kernel memcmp
> 0.0%94.3% mach_kernel vfs_addname
> 0.0%94
OK, I seem to be converging on something here, but I don't know what
to do with it. Shark gives me the following tree:
97.6% 97.6% mach_kernel memcmp
0.0%94.3% mach_kernel vfs_addname
0.0%94.3% mach_kernel hfs_create_attr_btree
OK, I seem to be converging on something here, but I don't know what
to do with it. Shark gives me the following tree:
97.6% 97.6% mach_kernel memcmp
0.0%94.3% mach_kernel vfs_addname
0.0%94.3% mach_kernel hfs_create_attr_btree
You don't have to change it all to Python, you just need to refactor it a bit. Instead of embeding Python from C, you embed C from Python. Of course, it's better to prefer Python code because there will be less of it, it's not always a good idea to just throw all the old code away.-bobOn Dec 13,
Hi! Bob What you suggested is right. The interesting thing is that I have a lot of old c code which will try to call python code. It is true that I can write pure python code and use py2app (I use py2exe on windows) to make an executable. That will make life easy. But .. I think tha
On Dec 13, 2005, at 12:18 PM, Zhi Peng wrote:
> If we use pythonw, then there may be problem in C code to call the
> python code with appscript inside because it seems
> PyImport_ImportModule("ModuleName") only works with python instead
> of pythonw.
pythonw is just a shell script. You're
First of all, Thanks 'Has"'s help during past months. If we use pythonw, then there may be problem in C code to call the python code with appscript inside because it seems PyImport_ImportModule("ModuleName") only works with python instead of pythonw. By the way, I have another question fo
On Dec 13, 2005, at 12:12 PM, Bob Ippolito wrote:
>
> On Dec 13, 2005, at 11:36 AM, Schollnick, Benjamin wrote:
>
>>
>>> Is distutils more for distributing packages/modules than developing?
>>
>> The only situation I use distutils is for installing packages/
>> modules,
>> and distributing the s
On Dec 13, 2005, at 11:36 AM, Schollnick, Benjamin wrote:
>
>> Is distutils more for distributing packages/modules than developing?
>
> The only situation I use distutils is for installing packages/modules,
> and distributing the software that I write (via py2app & py2exe).
>
> To my knowledge di
> Is distutils more for distributing packages/modules than developing?
The only situation I use distutils is for installing packages/modules,
and distributing the software that I write (via py2app & py2exe).
To my knowledge distutils is primarily for distributing packages &
modules...
Someone
Bob Ippolito wrote:
>>
>> Bob or anyone,
>>
>> I have started to look over distutils, but a question immediately comes
>> to mind. With the idea of trying to avoid learning what I don't need,
>> I gotta ask:
>>
>> Is distutils more for distributing packages/modules than developing?
>
>
> No, i
Kevin Walzer wrote:
>Not sure if appscript modules can be run interactively with the Python
>interpreter/shell--has can chime in here.
Sure, as long as you use pythonw. An interactive shell can be quite handy when
learning your way around an application's object model; appscript's built-in
help
On Dec 13, 2005, at 11:20 AM, Louis Pecora wrote:
> Bob Ippolito wrote:
>
>>
>> On Dec 13, 2005, at 10:39 AM, Louis Pecora wrote:
>>
>>> I will be honest and admit I do not grok disutils. I sense power
>>> there,
>>> but have not had the guts nor time to explore it. If you have a
>>> simple
Bob Ippolito wrote:
>
> On Dec 13, 2005, at 10:39 AM, Louis Pecora wrote:
>
>> I will be honest and admit I do not grok disutils. I sense power
>> there,
>> but have not had the guts nor time to explore it. If you have a simple
>> example that is easy to send, please do. Since I will probabl
On Dec 13, 2005, at 10:39 AM, Louis Pecora wrote:
> Rob Managan wrote:
>
>> While I have not tried WxPython I have built C modules for python
>> using SWIG and python's distutils. That trades the headaches of
>> makefiles for writing a setup.py file. I can give an example and they
>> really are n
Rob Managan wrote:
>While I have not tried WxPython I have built C modules for python
>using SWIG and python's distutils. That trades the headaches of
>makefiles for writing a setup.py file. I can give an example and they
>really are not that bad once you have done it once!
>
>
>
I will be ho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zhi Peng wrote:
> Hi! All
>
> I posted a few items in a few days. I think the first
> problem I had is that it can not import python module
> when I used "from appscrpt import *" inside modue
> because appscript need pythonw instead of python. Here
>
At 12:41 PM -0500 12/13/05, Louis Pecora wrote:
>Christopher Barker wrote:
>
> >
>>The dangers of borrowing other people's code! Why are you using tsch anyway?
>>bash really is nicer, unless you're really used to a C shell. And it's the
>>OS-X default (and most Linuxes also).
>>
>>
>Well, I thoug
At 12:41 PM -0500 12/13/05, Louis Pecora wrote:
>Christopher Barker wrote:
>
>>Hi Lou,
>>
>>I'm glad you got this working. Thanks for posting the resolution to your
>>problems, it's good to have this stuff archived. If time permits, I hope top
>>do some SWIGing myself, so perhaps we can help each o
On Dec 13, 2005, at 10:02 AM, Zhi Peng wrote:
> I posted a few items in a few days. I think the first
> problem I had is that it can not import python module
> when I used "from appscrpt import *" inside modue
> because appscript need pythonw instead of python. Here
> is the error message:
--
>
On Dec 13, 2005, at 9:38 AM, Bill Spotz wrote:
> I recently upgraded my dual-processor G5 from Mac OS X 10.3 to 10.4.
> Ever since, the python initialization has been extremely slow, maybe
> 10 seconds or so between issuing the "python" command and getting a
> prompt. I run some automated tests o
Hi! All
I posted a few items in a few days. I think the first
problem I had is that it can not import python module
when I used "from appscrpt import *" inside modue
because appscript need pythonw instead of python. Here
is the error message:
Hi! All
I posted a few items in a few days. I think the first
problem I had is that it can not import python module
when I used "from appscrpt import *" inside modue
because appscript need pythonw instead of python. Here
is the error message:
On Dec 13, 2005, at 9:41 AM, Louis Pecora wrote:
> Christopher Barker wrote:
>
>> The dangers of borrowing other people's code! Why are you using
>> tsch anyway?
>> bash really is nicer, unless you're really used to a C shell. And
>> it's the
>> OS-X default (and most Linuxes also).
>>
>>
> W
Hi Lou,
I'm glad you got this working. Thanks for posting the resolution to your
problems, it's good to have this stuff archived. If time permits, I hope top
do some SWIGing myself, so perhaps we can help each other out.
On Thursday 08 December 2005 1:17 pm, Louis Pecora wrote:
>Solution:
I recently upgraded my dual-processor G5 from Mac OS X 10.3 to 10.4.
Ever since, the python initialization has been extremely slow, maybe
10 seconds or so between issuing the "python" command and getting a
prompt. I run some automated tests on this machine, and the delays
can add up, dwar
Christopher Barker wrote:
>Hi Lou,
>
>I'm glad you got this working. Thanks for posting the resolution to your
>problems, it's good to have this stuff archived. If time permits, I hope top
>do some SWIGing myself, so perhaps we can help each other out.
>
>
Sounds good to me. I have mostly mad
Thanks [EMAIL PROTECTED] wrote: (snip) PyRun_SimpleString("sys.path.append('.\')\n");(snip)I try to throw in my 5 Cent: The backslash (Windows path separator?) following the dot might be the problem. So let me guess, the program runs on Windows, but not on Unix.(Sorry for my silly quoting, but
(snip)
PyRun_SimpleString("sys.path.append('.\')\n");
(snip)
I try to throw in my 5 Cent: The backslash (Windows path separator?)
following the dot might be the problem. So let me guess, the program runs
on Windows, but not on Unix.
(Sorry for my silly quoting, but Lotus Notes is a pain!)
40 matches
Mail list logo
