Re: [IronPython] Preprocessor directives in IronPython 2.0

2008-12-15 Thread Curt Hagenlocher
Nope. Why do you think you want them? Or rather, what's wrong with this: debug = False def Main(): if debug: print 'DEBUG is set' else: print 'DEBUG is not set' On Mon, Dec 15, 2008 at 5:46 AM, Yash Ganthe yas...@gmail.com wrote: In C# we can code for conditional

[IronPython] Help contents

2008-12-15 Thread Hernán Martínez Foffani
Where does IP find the help content for .NET libraries? I mean, for instance, the output of help(System.DateTime.ToBoolean) Does it parse the Help.2 files? If so where does it look for them? Only under %ALLUSERSPROFILE%\{Program Data}\Microsoft Help? Regards, -H.

[IronPython] IronPython and file descriptors

2008-12-15 Thread Tom Wright
Hi, At the moment file.fileno() returns an arbitrary identifier of a python file rather than a true file descriptor. This is semi-blocking the Ironclad port of PIL. Code in PIL gets an integer using fileno() and passes it directly to C code where a call to write() is made. To fix this one

Re: [IronPython] IronPython and file descriptors

2008-12-15 Thread Curt Hagenlocher
There's no such thing as a file descriptor number in .NET -- or, for that matter, in Windows itself! :) (The latter is something of a semantic point, of course, as a HANDLE serves something of the same role in Win32 as a file descriptor number does in Unix.) If you have a FileStream, I think you

Re: [IronPython] IronPython and file descriptors

2008-12-15 Thread Tom Wright
Not so: Though admittedly you have to do quite a bit of work to get the file descriptor into .NET. http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx To clarify - the C library was written to work with Python (not IronPython) and is not my code. Thanks, Tom Curt Hagenlocher

Re: [IronPython] IronPython and file descriptors

2008-12-15 Thread Curt Hagenlocher
Ah, that was the function I was looking for. Sure, the file descriptor exists in the C library under Windows. But the C library is basically doing exactly the same thing as IronPython is; it's maintaining the file descriptor number as an abstraction on top of the HANDLE that the operating system

Re: [IronPython] IronPython and file descriptors

2008-12-15 Thread Tom Wright
Agreed. It is certainly possible with some work to get a file descriptor and pass it to C code. This is not the problem, however. Ironclad's aim (eventually) is to allow *arbitrary* C extensions to work with Ironpython without changing the extensions. Ctypes aim is to allow arbitrary C code

Re: [IronPython] IronPython and file descriptors

2008-12-15 Thread Slide
On Mon, Dec 15, 2008 at 11:18 AM, Tom Wright tom.wri...@resolversystems.com wrote: Agreed. It is certainly possible with some work to get a file descriptor and pass it to C code. This is not the problem, however. Ironclad's aim (eventually) is to allow *arbitrary* C extensions to work with

Re: [IronPython] Preprocessor directives in IronPython 2.0

2008-12-15 Thread Dino Viehland
The one form this is available is with the assert keyword. Assert statements will be removed in optimized code so you don't have the if debug check. But they won't let you have the else branch. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of

Re: [IronPython] IronPython and file descriptors

2008-12-15 Thread Curt Hagenlocher
I think I understand the motivation pretty well; what I'm saying is that I don't see that this is possible. IronPython has no access to the table being used by the C library to map between Windows HANDLEs and clib file descriptors, so we can't return a clib-compatible fd. Even if we were to

Re: [IronPython] Help contents

2008-12-15 Thread Hernán Martínez Foffani
It seems clear now, thank you. Reading DocBuilder.cs:GetXPathDocument(..) I assume that if I want to let our users to be able to get IP console help on our own C# libraries, we can place the XML docs in a culture subdirectory under the DLLs install directory, right? This is generated from the

Re: [IronPython] IronPython and file descriptors

2008-12-15 Thread Dino Viehland
Presumably CPython is linking against msvcrt and is using the C abstraction rather than calling the Win32 APIs which return handles directly. As Curt said the biggest problem for us is that .NET does not expose C file descriptors. Therefore we could fix this by P/Invoking out to msvcrt. For

Re: [IronPython] Help contents

2008-12-15 Thread Curt Hagenlocher
If you have only one version/culture, I believe you can just place the XML doc in the same directory as the DLL. On Mon, Dec 15, 2008 at 10:45 AM, Hernán Martínez Foffani hernan.marti...@ecc.es wrote: It seems clear now, thank you. Reading DocBuilder.cs:GetXPathDocument(..) I assume that if

Re: [IronPython] IronPython and file descriptors

2008-12-15 Thread Curt Hagenlocher
I guess I'm too much of a purist when it comes to managed code. But it would make me sad to P/Invoke by default for this purpose, even if Mono compatibility is the only real counterargument I can muster. On Mon, Dec 15, 2008 at 10:49 AM, Dino Viehland di...@microsoft.com wrote: Presumably

[IronPython] Determine the classes/interfaces a Python implements

2008-12-15 Thread Jeff Slutter
I have a Python script that creates a class within it. This Python class is derived off of a class, or interface, I made in C# - something like: class MyClass(Test.MainForm.IScript): ... Now, back in C#, I have gotten access to MyClass by: object myclass = someScope.GetVariable(MyClass);

Re: [IronPython] IronPython and file descriptors

2008-12-15 Thread Michael Foord
2008/12/15 Dino Viehland di...@microsoft.com Presumably CPython is linking against msvcrt and is using the C abstraction rather than calling the Win32 APIs which return handles directly. As Curt said the biggest problem for us is that .NET does not expose C file descriptors. Therefore we

Re: [IronPython] Determine the classes/interfaces a Python implements

2008-12-15 Thread Michael Foord
Hi Jeff, Probably the easiest way of doing this is to define a Python function that uses issubtype. You can use this as a delegate from the C# side (warning untested): ScriptScope scope = engine.CreateScope(); ScriptSource imports = engine.CreateScriptSourceFromString(from System import

Re: [IronPython] Determine the classes/interfaces a Python implements

2008-12-15 Thread Seo Sanghyeon
2008/12/16 Michael Foord fuzzy...@voidspace.org.uk: Probably the easiest way of doing this is to define a Python function that uses issubtype. You can use this as a delegate from the C# side (warning untested): You mean issubclass... -- Seo Sanghyeon

Re: [IronPython] Determine the classes/interfaces a Python implements

2008-12-15 Thread Dino Viehland
You should call PythonOps.IsSubClass and pass in the PythonType and the interface you want to compare it with. The interface can be either a .NET type object or another Python type object (or a tuple, etc...) The not raising on missing functions is a feature :) You could build a meta-class

Re: [IronPython] Determine the classes/interfaces a Python implements

2008-12-15 Thread Dino Viehland
Can you open a feature request on CodePlex? It's certainly an interesting idea to ponder and I'm leaning towards it but there's lots of details to be gotten right. Do you know if this needs to work w/ sockets as well? (There's also the question of can we make it work with sockets? :))

Re: [IronPython] Determine the classes/interfaces a Python implements

2008-12-15 Thread Curt Hagenlocher
(Dino clearly meant this to be a reply to the other thread with respect to C file descriptors. :) On Mon, Dec 15, 2008 at 1:24 PM, Dino Viehland di...@microsoft.com wrote: Can you open a feature request on CodePlex? It's certainly an interesting idea to ponder and I'm leaning towards it but

Re: [IronPython] IronPython and file descriptors

2008-12-15 Thread Michael Foord
Dino Viehland wrote: (now I’ve replied to the correct thread…) Can you open a feature request on CodePlex? It's certainly an interesting idea to ponder and I'm leaning towards it but there's lots of details to be gotten right. Do you know if this needs to work w/ sockets as well? (There's

Re: [IronPython] Compiled dlls and builtin modules

2008-12-15 Thread Dino Viehland
I think this behavior is currently by design because we're using sys.meta_path which does take precedence over the built-in modules. We could switch to using sys.path_hooks in 2.1 or 3.0 if the consensus is this behavior in undesirable (which would also give control over when pre-compiled

Re: [IronPython] Compiled dlls and builtin modules

2008-12-15 Thread Michael Foord
Dino Viehland wrote: I think this behavior is currently by design because we’re using sys.meta_path which does take precedence over the built-in modules. We could switch to using sys.path_hooks in 2.1 or 3.0 if the consensus is this behavior in undesirable (which would also give control over

Re: [IronPython] Compiled dlls and builtin modules

2008-12-15 Thread Curt Hagenlocher
Sounds waaay too easy :P. In the long run, I'd prefer that we implement only the C part of these modules and share the Python part with CPython. But this is not only a potentially breaking change, it also would require modification to the standard library for at least the socket module. On Mon,

Re: [IronPython] Invalid construct in DLR's MSBuild file?

2008-12-15 Thread Curt Hagenlocher
This looks like a problem in quite a few of our csproj files. Could you open up a bug report on CodePlex for this? Thanks, -Curt On Wed, Dec 10, 2008 at 2:39 AM, Seo Sanghyeon sanx...@gmail.com wrote: Hello, now I am trying to use xbuild (open source implementation of MSBuild language) to

Re: [IronPython] Compiled dlls and builtin modules

2008-12-15 Thread Dino Viehland
Yeah, it's funny, I thought we were supposed to have done that for at least some of them. Maybe these were just missed, but I agree we should definitely do at least that. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf

Re: [IronPython] Issue about string.upper and string.lower

2008-12-15 Thread Dino Viehland
I've actually looked at this not too long ago and I think your proposal of calling the Invariant functions is the correct solution. I was looking at a few things: This bug http://bugs.python.org/issue1528802, the 3.0 decimal.py module, and also just using Turkish I at the command prompt. If