pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] 0.9

[Tony L. <to...@lo...>]

At 8:27 PM +0100 2/2/03, Just van Rossum wrote:
>
>I see no reason to not simply include the actual modules in Resources.
>Perhaps that's handy for PB, but then again, I don't use PB.

Well, I can posit a few useful scenarios for being able to use .pth 
files in Resources, such as including a CVS controlled directory of 
external Python source like I am doing with spambayes, but until 
there's an actual problem (and there's not) I'll shut up.

Speaking of app wrappers, below is a bin-python-main.m that will load 
a framework build of python. It seems to load faster than using the 
execve methods...

-Tony

/*
  This main file runs Contents/Resource/__main__.py using a framework 
build of python
  */

#import <Foundation/Foundation.h>
#import <Python/Python.h>
#import <sys/param.h>
#import <unistd.h>
#import <stdio.h>

int pyobjc_main(int argc, char * const *argv, char * const *envp)
{
     // The autorelease pool is not released on purpose, because I 
don't know much
     // about objc memory management
     [[NSAutoreleasePool alloc] init];

     // set up paths
     const char *mainPyFile = [[[[NSBundle mainBundle] resourcePath]
         stringByAppendingPathComponent: @"__main__.py"] UTF8String];

     printf("mainPyFile=%s\n", mainPyFile);
    
     Py_SetProgramName(mainPyFile);
     Py_Initialize();
     argv[0] = mainPyFile;  // PySys_SetArgv wants script in argv
         PySys_SetArgv(argc, argv);
     FILE *fp = fopen(mainPyFile, "r");
     if (fp == NULL) {
       perror("Cannot open mainPyFile");
     } else {
       PyRun_SimpleFile(fp, mainPyFile);
       fclose(fp);
     }
     Py_Finalize();

     return 0;
}

int main(int argc, char * const *argv, char * const *envp)
{
     return pyobjc_main(argc, argv, envp);
}

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> The magic is in the wrapper for NSApplicationMain, that shouldn't be a 
> problem.

It is if the wrapper doesn't pass the right args... But I've totally
lost track of what happens there. Hm, I guess we should compare sys.argv
in both situations.

> > Speaking of which: my first shell script ever (the exec wrapper) 
> > suffers
> > from a typical bug: it doesn't work if the path to the app contains
> > spaces :-( I'll look into it.
> 
> This should do it (quoting all assignments):
> 
> #!/bin/sh
> 
> execdir="$(dirname ${0})"

One of the main problems was that ${0} _itself_ needed quoting,
otherwise dirname only takes the part up to the first space. Or at least
that's what I understood was happening.

See the CVS log for bundlebuilder.py for my actual patch: it seems to
work, but if you see other potential problems, please tell me...

> executable="${execdir}/python"
> resdir="$(dirname "${execdir}")/Resources"
> main="${resdir}/main.py"
> PYTHONPATH="$resdir"
> export PYTHONPATH
> exec "${executable}" ${main} ${@:+"${@}"}
> 
> The ${@:"${@}"} should allow 0 or more arguments with proper quoting 
> (completely untested).

I'll try this, thanks. (It does look worse than Perl, though...)

Just

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

[Ronald O. <ous...@ci...>]

On Sunday, Feb 2, 2003, at 19:42 Europe/Amsterdam, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>> That's weird.   I just tried:
>>
>> - creating new project from multi-doc template
>>
>> - changing the YES to a NO as shown below
>>
>> - ran the app
>>
>> Untitled document showed up...
>
> Maybe Ronald tried with an app built with bundlebuilder?
That to (I'm also using Python 2.3).

>
> I just tried
> this and can't get an untitled window to begin with... What was the
> magic you hacked around again to make this work? Maybe the sh wrapper
> doesn't pass the right arguments.
The magic is in the wrapper for NSApplicationMain, that shouldn't be a 
problem.

>
> Speaking of which: my first shell script ever (the exec wrapper) 
> suffers
> from a typical bug: it doesn't work if the path to the app contains
> spaces :-( I'll look into it.

This should do it (quoting all assignments):

#!/bin/sh

execdir="$(dirname ${0})"
executable="${execdir}/python"
resdir="$(dirname "${execdir}")/Resources"
main="${resdir}/main.py"
PYTHONPATH="$resdir"
export PYTHONPATH
exec "${executable}" ${main} ${@:+"${@}"}

The ${@:"${@}"} should allow 0 or more arguments with proper quoting 
(completely untested).

Ronald

Re: [Pyobjc-dev] Constants etc.

[Ronald O. <ous...@ci...>]

On Sunday, Feb 2, 2003, at 19:08 Europe/Amsterdam, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>> Ronald:   should we go ahead and auto-generate the source to cover all
>> of AB's compiled constants?   This would require creating
>> yet-another-module.  Maybe AddressBook should be moved out of PyObjC
>> and into its own project given that most apps will not use the AB API?
>
> I've been wondering, if interfacing an arbitrary framework is mostly
> automated, we could make it more dynamic with an import hook: if 
> "import
> SomeFramework" fails, a hook can be called to wrap it if it happens to
> be ean existing framework. That way we could delete AddressBook
> altogether ;-)

The new import-hook mechanism looks easy enough to use for things like 
this. You'd loose the mapping of constants and global functions this 
way, but if you want those you can still implement wrappers the hard 
way.

Ronald

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

[<bb...@ma...>]

On Sunday, Feb 2, 2003, at 15:00 US/Eastern, Ronald Oussoren wrote:
> That's very weird. I was using Python 2.3, maybe that explains things. 
> I'll rebuild the bridge for Python 2.2 and check if this helps.

I tried with both!   Same behavior.

> You are using the fixes to libffi_support.m I checked in last week, 
> aren't you? These include a fix for BOOL values (actually 
> signed/unsigned characters). Hmm, but that's only relevant when 
> calling into Objective-C, not for this problem.
>
Yes, latest from CVS.

b.bum

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

[Ronald O. <ous...@ci...>]

On Sunday, Feb 2, 2003, at 19:09 Europe/Amsterdam, bb...@ma... wrote:

> That's weird.   I just tried:
>
> - creating new project from multi-doc template
>
> - changing the YES to a NO as shown below
>
> - ran the app
>
> Untitled document showed up...
That's very weird. I was using Python 2.3, maybe that explains things. 
I'll rebuild the bridge for Python 2.2 and check if this helps.

You are using the fixes to libffi_support.m I checked in last week, 
aren't you? These include a fix for BOOL values (actually 
signed/unsigned characters). Hmm, but that's only relevant when calling 
into Objective-C, not for this problem.

Ronald

Re: [Pyobjc-dev] 0.9

[Just v. R. <ju...@le...>]

Tony Lownds wrote:

> When I mentioned the need for extra code, I was thinking about 
> including PyObjC in the application bundle. As it turns out putting 
> the PyObjC directory + the PyObjC.pth into 
> SomeApp.app/Contents/Resources/ "just works".
> 
> The reason it works feels coincidental. In both app wrappers 
> (bundlebuilder's and bin-python-main.m) the 
> SomeApp.app/Contents/Resources/ directory is added to the path by 
> setting the PYTHONPATH environment variable and then exec'ing python. 
> Python runs site.py, which scans for .pth files, and then the user 
> code. If some other app wrapper is devised, and if that app wrapper 
> modifies the path by sys.path, then those .pth files will no longer 
> work.
> 
> This is all academic now, but it would be nice to guarantee that any 
> new app wrappers
> A) add SomeApp.app/Contents/Resources to the path
> B) honor .pth files in SomeApp.app/Contents/Resources

I see no reason to not simply include the actual modules in Resources.
Perhaps that's handy for PB, but then again, I don't use PB.

Idea: is PB pluggable enough so we can have a Python program that
calculates the actual dependencies?

Just

Re: [Pyobjc-dev] 0.9

[Tony L. <to...@lo...>]

>  > 3. Its not hard to package the modules in a subdirectory, using .pth
>>  files in /usr/lib/site-packages and with minimal extra code in
>>  bin-python-main.m.
>
>Yes, distutils supports this easily. I've used it myself and I know
>NumPy does it, too. If we choose to do this I volunteer to patch
>setup.py. Note that this makes upgrading harder (once), as you probably
>need to manually delete the modules from the "old" place.
>
>>  Hmm, and some extra code in bundlebuilder.py too, I think.
>
>Hm, I can't see why. Can you elaborate?

When I mentioned the need for extra code, I was thinking about 
including PyObjC in the application bundle. As it turns out putting 
the PyObjC directory + the PyObjC.pth into 
SomeApp.app/Contents/Resources/ "just works".

The reason it works feels coincidental. In both app wrappers 
(bundlebuilder's and bin-python-main.m) the 
SomeApp.app/Contents/Resources/ directory is added to the path by 
setting the PYTHONPATH environment variable and then exec'ing python. 
Python runs site.py, which scans for .pth files, and then the user 
code. If some other app wrapper is devised, and if that app wrapper 
modifies the path by sys.path, then those .pth files will no longer 
work.

This is all academic now, but it would be nice to guarantee that any 
new app wrappers
A) add SomeApp.app/Contents/Resources to the path
B) honor .pth files in SomeApp.app/Contents/Resources

-Tony

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

[Just v. R. <ju...@le...>]

bb...@ma... wrote:

> That's weird.   I just tried:
> 
> - creating new project from multi-doc template
> 
> - changing the YES to a NO as shown below
> 
> - ran the app
> 
> Untitled document showed up...

Maybe Ronald tried with an app built with bundlebuilder? I just tried
this and can't get an untitled window to begin with... What was the
magic you hacked around again to make this work? Maybe the sh wrapper
doesn't pass the right arguments.

Speaking of which: my first shell script ever (the exec wrapper) suffers
from a typical bug: it doesn't work if the path to the app contains
spaces :-( I'll look into it.

Just

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

[<bb...@ma...>]

That's weird.   I just tried:

- creating new project from multi-doc template

- changing the YES to a NO as shown below

- ran the app

Untitled document showed up...

b.bum

On Sunday, Feb 2, 2003, at 13:00 US/Eastern, Ronald Oussoren wrote:
> On Sunday, Feb 2, 2003, at 18:36 Europe/Amsterdam, bb...@ma... wrote:
>>
>> I was just looking into this and there appears to be a bug that was 
>> introduced sometime recently.   The following code used to work, now 
>> it doesn't.  I'm not sure why:
>>
>> # create ObjC classes as defined in MainMenu.nib
>> NibClassBuilder.extractClasses("MainMenu")
>> class MyAppDelegate(AutoBaseClass, NSApplicationDelegate):
>>     def applicationShouldOpenUntitledFile_(self, sender):
>>         # return NO if you don't want untitled document to be opened 
>> on app launch
>>         return NO
>>
> Works for me. I added this to the Todo example and if the function 
> returns False it doesn't open a default document and if it returns 
> True it does open a default document.

Re: [Pyobjc-dev] Constants etc.

[Just v. R. <ju...@le...>]

bb...@ma... wrote:

> Ronald:   should we go ahead and auto-generate the source to cover all 
> of AB's compiled constants?   This would require creating 
> yet-another-module.  Maybe AddressBook should be moved out of PyObjC 
> and into its own project given that most apps will not use the AB API?

I've been wondering, if interfacing an arbitrary framework is mostly
automated, we could make it more dynamic with an import hook: if "import
SomeFramework" fails, a hook can be called to wrap it if it happens to
be ean existing framework. That way we could delete AddressBook
altogether ;-)

just

Re: [Pyobjc-dev] Constants etc.

[Ronald O. <ous...@ci...>]

On Sunday, Feb 2, 2003, at 18:40 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, Feb 2, 2003, at 12:17 US/Eastern, Martina Oefelein wrote:
>> Hi Bill,
>>> Most constants should be bridged and are available directly in the 
>>> AppKit namespace.
>>>
>>> There may be some that slipped through the cracks.  If you have 
>>> specific examples, please let us know!
>> I have an example: All AddressBook constants.
>
> Ahh... those aren't Cocoa constants. :-)
>
> The AddressBook constants are not currently bridged, but the address 
> book API is still quite usable.
>
> See Examples/addressbook.py.
>
> Ronald:   should we go ahead and auto-generate the source to cover all 
> of AB's compiled constants?   This would require creating 
> yet-another-module.  Maybe AddressBook should be moved out of PyObjC 
> and into its own project given that most apps will not use the AB API?

Generating the constants shouldn't be too hard. We could even generate 
a pure-python file (that would require an intermediate Objective-C 
program, but it is easily doable).

I'd keep the module in PyObjC, maintaining it as part of PyObjC is not 
much work, maintaining it seperately would IMO be a sure way to 
introduce bitrot.

Ronald

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

[Ronald O. <ous...@ci...>]

On Sunday, Feb 2, 2003, at 18:36 Europe/Amsterdam, bb...@ma... wrote:
>
> I was just looking into this and there appears to be a bug that was 
> introduced sometime recently.   The following code used to work, now 
> it doesn't.  I'm not sure why:
>
> # create ObjC classes as defined in MainMenu.nib
> NibClassBuilder.extractClasses("MainMenu")
> class MyAppDelegate(AutoBaseClass, NSApplicationDelegate):
>     def applicationShouldOpenUntitledFile_(self, sender):
>         # return NO if you don't want untitled document to be opened 
> on app launch
>         return NO
>
Works for me. I added this to the Todo example and if the function 
returns False it doesn't open a default document and if it returns True 
it does open a default document.

Ronald

Re: [Pyobjc-dev] *** Important Notice for people working from CVS

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> > Done. So forget my previous warning/notice... (The setup.py hack
> > wasn't as nearly as bad as I though it would be...)
> 
> Yuck. As this is a one-time afair I don't think setup.py should
> remove the previous version.

Why not? It's _very_ convenient and will prevent many surprises. Who
reads READMEs anyway? ;-)

We can remove the hack once 0.9 is out the door. By then only people who
migrate from 0.8 to >0.9 will have to remove the old stuff by hand.

Just

Re: [Pyobjc-dev] Constants etc.

[<bb...@ma...>]

On Sunday, Feb 2, 2003, at 12:17 US/Eastern, Martina Oefelein wrote:
> Hi Bill,
>> Most constants should be bridged and are available directly in the 
>> AppKit namespace.
>>
>> There may be some that slipped through the cracks.  If you have 
>> specific examples, please let us know!
> I have an example: All AddressBook constants.

Ahh... those aren't Cocoa constants. :-)

The AddressBook constants are not currently bridged, but the address 
book API is still quite usable.

See Examples/addressbook.py.

Ronald:   should we go ahead and auto-generate the source to cover all 
of AB's compiled constants?   This would require creating 
yet-another-module.  Maybe AddressBook should be moved out of PyObjC 
and into its own project given that most apps will not use the AB API?

b.bum

Re: [Pyobjc-dev] [ pyobjc-Bugs-678818 ] Missing NSCFNumber to int conversions

[<bb...@ma...>]

On Sunday, Feb 2, 2003, at 12:21 US/Eastern, Ronald Oussoren wrote:
> For some values of 'NSSomeClass' the interpreter will crash when 
> trying to print the repr of the return value of alloc. The interpreter 
> seems to call __repr__, so we should be safe if we only map __str__ to 
> description.

Should probably undo that change that I made, then... :-)

b.bum

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

[<bb...@ma...>]

On Sunday, Feb 2, 2003, at 12:26 US/Eastern, Etienne Posthumus wrote:
> On Sunday, Feb 2, 2003, at 08:22 Europe/Amsterdam, Mitch Chapman wrote:
>> On Saturday, February 1, 2003, at 11:00 PM, bb...@ma... wrote:
>>> Very easy fix and not at all obvious.  The problem is that there is 
>>> no way for the bridge to know that your implementation of the method 
>>> should return BOOL.  So, you either have to tell the bridge that 
>>> your method returns a BOOL through the use of the objc.selector() 
>>> function or, better yet, declare that your class implements the 
>>> informal NSApplication delegate protocol.
>
>> Hm... I think the project template already did this for me.
>> (BTW thanks for including the project templates -- way cool.)
>> Here's the relevant code, showing the class declaration provided by
>> the template:
>
>> The log message is showing up in the PB Run window, right about the
>> time the unwanted Untitled document appears.
>
> In trying to make a delegate for a window responding to 
> windowShouldClose, I can also not get it to NOT close the window even 
> if I have only one statement in the method:
>     return NO
>
> Could this be related to the above behaviour?

Very likely.   The problem is that there is no way for the bridge to 
know that your method should return a BOOL unless you use 
objc.selector() or declare your object to be an NSWindowDelegate.

I was just looking into this and there appears to be a bug that was 
introduced sometime recently.   The following code used to work, now it 
doesn't.  I'm not sure why:

# create ObjC classes as defined in MainMenu.nib
NibClassBuilder.extractClasses("MainMenu")
class MyAppDelegate(AutoBaseClass, NSApplicationDelegate):
     def applicationShouldOpenUntitledFile_(self, sender):
         # return NO if you don't want untitled document to be opened on 
app launch
         return NO

Re: [Pyobjc-dev] Constants etc.

[Ronald O. <ous...@ci...>]

On Sunday, Feb 2, 2003, at 18:03 Europe/Amsterdam, Martina Oefelein 
wrote:

> Hi All,
>
> Currently, PyObjC bridges apparently only classes, but the Cocoa 
> headers contain a lot of stuff outside the class definitions, e.g. 
> constants. Is there any intent to bridge these definitions?

Guido isn't looking, maybe I can sneak my way into his timemachine.... 
Done.

We already wrap most constants in Cocoa. I consider it a bug if some 
constants are not wrapped.

Ronald

Re: [Pyobjc-dev] *** Important Notice for people working from CVS

[Ronald O. <ous...@ci...>]

On Sunday, Feb 2, 2003, at 02:16 Europe/Amsterdam, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>>> The same goes for people that don't use the installer but build
>>> from the source. Hmmm. Perhaps setup.py should be hacked to do this.
>>
>> Yes.  It should.  That would be very helpful.
>
> Done. So forget my previous warning/notice... (The setup.py hack wasn't
> as nearly as bad as I though it would be...)

Yuck. As this is a one-time afair I don't think setup.py should remove 
the previous version.

>
> Must Sleep.
Sleep well ;-)

Ronald

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

[Etienne P. <ep...@ep...>]

On Sunday, Feb 2, 2003, at 08:22 Europe/Amsterdam, Mitch Chapman wrote:
> On Saturday, February 1, 2003, at 11:00 PM, bb...@ma... wrote:
>> Very easy fix and not at all obvious.  The problem is that there is 
>> no way for the bridge to know that your implementation of the method 
>> should return BOOL.  So, you either have to tell the bridge that your 
>> method returns a BOOL through the use of the objc.selector() function 
>> or, better yet, declare that your class implements the informal 
>> NSApplication delegate protocol.

> Hm... I think the project template already did this for me.
> (BTW thanks for including the project templates -- way cool.)
> Here's the relevant code, showing the class declaration provided by
> the template:

> The log message is showing up in the PB Run window, right about the
> time the unwanted Untitled document appears.

In trying to make a delegate for a window responding to 
windowShouldClose, I can also not get it to NOT close the window even 
if I have only one statement in the method:
     return NO

Could this be related to the above behaviour?

EP

Re: [Pyobjc-dev] [ pyobjc-Bugs-678818 ] Missing NSCFNumber to int conversions

[Ronald O. <ous...@ci...>]

On Sunday, Feb 2, 2003, at 00:15 Europe/Amsterdam, bb...@ma... wrote:

> On Saturday, Feb 1, 2003, at 17:16 US/Eastern, SourceForge.net wrote:
>> 1. if x: should only execute the if clause when x is
>> nonzero.  But if x is a zero NSCFNumber, the clause
>> gets executed erroneously (third line of code's output
>> is "Increment by ..." instead of "Null increment")
>
> I believe this is working correctly on my system?
Probably because I checked in a fix for this just before the weekend 
:-) NSCFNumber evaluates to true if the value returned by 'boolValue' 
does (as do all other objects that have a boolValue method)

>
> [bumbox:~/bbum-developer/sourceforge/pyobjc] bbum% python foo.py
> Increment by 3 to 3
> Null decrement to 3
> Null increment to 3
> Decrement by <NSCFNumber objective-c instance 0x470330> to 0
>
>> 2. str(x) should produce a decimal representation of x,
>> but if x is an NSCFNumber, it instead produces a string
>> like '<NSCFNumber objective-c instance 0x832ed0>'
>> (third and fourth lines of code's output).
>
> This is definitely broken.  Both str() and repr() do not do what one 
> might expect.
>
> Why doesn't str() invoke -description?  ...or repr()?  __repr__ 
> mapping to -description was commented out of _convenience.py.

I have no idea why this was removed. ... Oh, I do know: If you invoke 
-description from __str__ and __repr__ you may cause a coredump if you 
do something like this in an interactive interpreter:
	>>> NSSomeClass.alloc()
	<NSSomeClass instance at 0xabcdabcd>
	>>> _.init()
	<NSSomeClass instance at 0xabcdabcd>

For some values of 'NSSomeClass' the interpreter will crash when trying 
to print the repr of the return value of alloc. The interpreter seems 
to call __repr__, so we should be safe if we only map __str__ to 
description.

Ronald

Re: [Pyobjc-dev] Constants etc.

[Martina O. <Ma...@Oe...>]

Hi Bill,

> Most constants should be bridged and are available directly in the 
> AppKit namespace.
>
> There may be some that slipped through the cracks.  If you have 
> specific examples, please let us know!

I have an example: All AddressBook constants.

ciao
Martina

[Pyobjc-dev] NSBeginAlertSheet support

[Etienne P. <ep...@ep...>]

Working my way through the Learning Cocoa book, but doing the examples 
in Python in stead of Objective-C.
'Dotview' worked fine, but in trying to add an alert sheet I can't 
import NSBeginAlertSheet from AppKit.
I get a 0 on 'NSBeginAlertSheet' in dir(AppKit), but according to the 
docs it is a function in AppKit.

Where do I begin looking for what functions get bridged, and how to 
confirm if it is truly missing or just me barking up the wrong tree?

Using a CVS version from 2 February 2003 with libFFI, Python 2.2 
built-in on OS X 10.2.3.


EP

Re: [Pyobjc-dev] Constants etc.

[<bb...@ma...>]

On Sunday, Feb 2, 2003, at 12:03 US/Eastern, Martina Oefelein wrote:
> Hi All,
>
> Currently, PyObjC bridges apparently only classes, but the Cocoa 
> headers contain a lot of stuff outside the class definitions, e.g. 
> constants. Is there any intent to bridge these definitions?

Most constants should be bridged and are available directly in the 
AppKit namespace.

There may be some that slipped through the cracks.  If you have 
specific examples, please let us know!

thanks,
b.bum

Re: [Pyobjc-dev] Debugging PyObjc Apps

[Ronald O. <ous...@ci...>]

On Saturday, Feb 1, 2003, at 21:23 Europe/Amsterdam, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>> I did confirm that the Wing IDE works with PyObjC correctly,
>> including the debugger.
>
> Ah, that's cool. I've never tried it, even though I got a CD at the
> EuroPython conference...
>
> [OT: Speaking of conferences: is anyone going to PyCon? I'm not, but it
> would be great if someone could do a PyObjC talk there. It's in DC, so
> Bill is pretty closeby (compared to me, Ronald and Jack at least ;-) so
> I think we should elect him as the official representative ;-]

I've pondered about writing an abstract, but I had too much to do at 
the time...

>
>> Obviously, there is a big issue with the way app startup happens.
>> The situation may improve with an embedded interpreter-- certainly
>> makes it possible to use gdb directly-- but I'm not 100% sure.
>
> I don't think gdb helps all that much when debugging Python. The Python
> debugger (bdb.py/pdb.py) is pure Python, so the startup funkiness
> shouldn't get in the way there.

Maybe we should combine PDB with your TelnetInspector. Does that have 
any change of working?

Ronald