> > 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".
>
>
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),
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 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 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 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
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 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 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 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 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 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 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
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
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
15 matches
Mail list logo
