So I'm reworking how debugging is handled in PyOXIDE and I've come to a problem (several, but this is the biggy for the morning).My goal is to separate interacting with the (remote) debugged client in a separate thread, which forwards messages to the main thread as needed to run the debugger UI (si
On May 16, 2005, at 12:35 PM, [EMAIL PROTECTED] wrote:
> So I'm reworking how debugging is handled in PyOXIDE and I've come
> to a problem (several, but this is the biggy for the morning).
>
> My goal is to separate interacting with the (remote) debugged
> client in a separate thread, which f
> first, second, third, fourth, fifth, . = struct.unpack
> ("iiIIiIiiILllfd", data)
>
> It is SO EASY to screw this up. Pick the wrong type code, or
> misalign the type and field. It needs to look more like something sane:
>
> class Point(struct.BigEndianStruct):
> x = struct.SInt32(
On May 16, 2005, at 1:31 PM, Bill Janssen wrote:
>> first, second, third, fourth, fifth, . = struct.unpack
>> ("iiIIiIiiILllfd", data)
>>
>> It is SO EASY to screw this up. Pick the wrong type code, or
>> misalign the type and field. It needs to look more like something
>> sane:
>>
>> cla
On May 16, 2005, at 11:59 AM, Bob Ippolito wrote:
>
> On May 16, 2005, at 12:35 PM, [EMAIL PROTECTED] wrote:
>
>
>> So I'm reworking how debugging is handled in PyOXIDE and I've come
>> to a problem (several, but this is the biggy for the morning).
>>
>> My goal is to separate interacting with
Pascal data structures?!
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
On May 16, 2005, at 2:01 PM, [EMAIL PROTECTED] wrote:
> On May 16, 2005, at 11:59 AM, Bob Ippolito wrote:
>
>
>> On May 16, 2005, at 12:35 PM, [EMAIL PROTECTED] wrote:
>>
>>> So I'm reworking how debugging is handled in PyOXIDE and I've come
>>> to a problem (several, but this is the biggy for th
On May 16, 2005, at 2:08 PM, Bill Janssen wrote:
> Pascal data structures?!
Have you ever looked at the Carbon/QuickTime APIs? I guess not. Mac
OS past was originally written with Pascal calling conventions and
pascal strings (unsigned char length prefixed strings), so you see
them all o
On May 16, 2005, at 1:22 PM, Bob Ippolito wrote:
>
> On May 16, 2005, at 2:01 PM, [EMAIL PROTECTED] wrote:
>>>
>>
>> The debugged app works like that, but the way that the "remote
>> object" interface works is also designed to use sync TCP on the host
>> side. Since it's pure python, I didn't wan
On 16-mei-2005, at 20:01, [EMAIL PROTECTED] wrote:
So, it appears that performSelectorOnMainThread needs some way to
release the lock to let Python code in the main thread be
executed. Any suggestions for workarounds?
Update to PyObjC from svn and see if that makes a difference.
Can't do that -
>
> On May 16, 2005, at 2:08 PM, Bill Janssen wrote:
>
> > Pascal data structures?!
>
> Have you ever looked at the Carbon/QuickTime APIs? I guess not.
Nope.
> Mac OS past was originally written with Pascal calling conventions and
> pascal strings (unsigned char length prefixed strings), so
On 16-mei-2005, at 20:53, [EMAIL PROTECTED] wrote:
NO! That is really really horribly bad to do. Working around a
bug in PyObjC by writing code that will break in correct versions
of PyObjC is absolutely horrible. You should NEVER release the
lock unless you own it.
Here, then, is probably the
On May 16, 2005, at 2:53 PM, [EMAIL PROTECTED] wrote:
>
> On May 16, 2005, at 1:22 PM, Bob Ippolito wrote:
>
>
>>
>> On May 16, 2005, at 2:01 PM, [EMAIL PROTECTED] wrote:
>>
>>> The debugged app works like that, but the way that the "remote
>>> object" interface works is also designed to use sync
On May 16, 2005, at 2:12 PM, Ronald Oussoren wrote:
>
> On 16-mei-2005, at 20:53, [EMAIL PROTECTED] wrote:
>
>>>
>>> NO! That is really really horribly bad to do. Working around a
>>> bug in PyObjC by writing code that will break in correct versions
>>> of PyObjC is absolutely horrible. You sh
On 16-mei-2005, at 21:28, [EMAIL PROTECTED] wrote:
On May 16, 2005, at 2:12 PM, Ronald Oussoren wrote:
On 16-mei-2005, at 20:53, [EMAIL PROTECTED] wrote:
NO! That is really really horribly bad to do. Working around a
bug in PyObjC by writing code that will break in correct versions
of PyObjC is
I'm building Python 2.4.1 from source (--enable-framework) and
noticed that test_long is failing. Is anyone having this problem?
$ sw_vers
ProductName:Mac OS X
ProductVersion: 10.4
BuildVersion: 8A428
$ make test
...
test_long
test test_long failed -- 9007199254740991.0 9007199254740991L 0
On May 16, 2005, at 3:44 PM, Ronald Oussoren wrote:
> I'm building Python 2.4.1 from source (--enable-framework) and
> noticed that test_long is failing. Is anyone having this problem?
>
> $ sw_vers
> ProductName:Mac OS X
> ProductVersion: 10.4
> BuildVersion: 8A428
>
> $ make test
> ...
On May 16, 2005, at 2:39 PM, Ronald Oussoren wrote:
>
> On 16-mei-2005, at 21:28, [EMAIL PROTECTED] wrote:
>
>> The problem isn't the Cocoa threads (Cocoa knows that the
>> application is multithreaded). The problem is that the python
>> code that is executing in a threading.Thread calls
On May 16, 2005, at 2:22 PM, Bob Ippolito wrote:
>
> On May 16, 2005, at 2:53 PM, [EMAIL PROTECTED] wrote:
>
>> I should be able to directly send the signal from the IDE to the
>> targeted app (since it's a child of the IDE), and the standard
>> "catch a unix signal invokes the debugger" act
On May 16, 2005, at 4:29 PM, [EMAIL PROTECTED] wrote:
> On May 16, 2005, at 2:39 PM, Ronald Oussoren wrote:
>
>
>> On 16-mei-2005, at 21:28, [EMAIL PROTECTED] wrote:
>>
>>
>>> The problem isn't the Cocoa threads (Cocoa knows that the
>>> application is multithreaded). The problem is that the
On May 16, 2005, at 4:32 PM, [EMAIL PROTECTED] wrote:
>
> On May 16, 2005, at 2:22 PM, Bob Ippolito wrote:
>
>
>>
>> On May 16, 2005, at 2:53 PM, [EMAIL PROTECTED] wrote:
>>
>>
>>> I should be able to directly send the signal from the IDE to the
>>> targeted app (since it's a child of the IDE),
> > Including an entire "custom" version of Python just seems like a
> > bad solution to me. It may be the only solution, depending on
> > various other circumstances, but it seems kind of sad to say "well,
> > OS X ships with Python.framework, but it can't be used to write a
> > Python IDE".
>
>
All,
I know this is a novice question but I'm trying to create a new group
using the python pyobjc module. I'm ure I've made a juvenile mistake
but help would be appreciated.
-Joe
if undefined is None:
undefined = ABGroup.alloc().init()
undefined.setValueForProperty_("GroupNa
On May 16, 2005, at 7:56 PM, Joe Duhamel wrote:
> All,
> I know this is a novice question but I'm trying to create a new group
> using the python pyobjc module. I'm ure I've made a juvenile mistake
> but help would be appreciated.
>
>
> -Joe
>
> if undefined is None:
> undefined = ABGroup.
On May 16, 2005, at 3:58 PM, Bob Ippolito wrote:
>
> On May 16, 2005, at 3:44 PM, Ronald Oussoren wrote:
>
>
>> I'm building Python 2.4.1 from source (--enable-framework) and
>> noticed that test_long is failing. Is anyone having this problem?
>>
>> $ sw_vers
>> ProductName:Mac OS X
>> Produc
Yeah, that is the correct argument order, I wasn't paying attention
to the arguments, I copied those in the order you wrote them. The
name of the selector and the syntax were what I noticed as being
obviously wrong.
I highly suggest you read the Introduction to PyObjC document until
you u
Python Interest Group Query
I'm aware of the Boston PIG, a smaller one in Amherst and have been
told that there is possibly a PIG in Manchester, NH.
Basically I'm trying to find out if there are any, or any interest in
(or even any other Python users at all :~)) in a PIG in the northern
NE
27 matches
Mail list logo
