Hi Martin,
Thanks! It's great to hear you're planning to support
both. I'm planning to jot down my experience with Iron
Python and put it up in my site, but to make this more
useful for .NET developers, I want to focus on "you
have a concept. you express it this way in C#. now,
here's how you expr
Yes, you are right, I forgot to update the makefile. I am going to fix
it for the next release, I hope local change will work for you in the
meantime.
Thanks
Martin
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Zoltan Varga
> Sent: Monday, Au
I'm not worried about compiling -- just execution.
And I'm just allergic enough to not want to install cygwin and an svn browser
just to recompile the latest mono. Really, I'm just checking mono + fepy for
kicks. The fact that it runs at all makes me snigger behind the back of the
Anti-MS Le
Hi,
Hopefully this will work better in the next mono release.
Speaking of the test suite, the makefile in the IronPython distribution does not
seem to build the IronPythonTest.dll assembly.
Zoltan
On 8/16/05, Keith J. Farmer <[EMAIL PRO
On Mon, Aug 15, 2005 at 05:05:18PM -0700, Keith J. Farmer wrote:
> Not terribly exciting, but if nobody's noticed:
>
> C:\IronPython-0.9\Scripts>mono
> \IronPython-0.9\bin\IronPythonConsole.exe .\TestAll.py
>
> ** (\IronPython-0.9\bin\IronPythonConsole.exe:316): WARNING **: The
> class System.Str
Not terribly exciting, but if nobody's noticed:
C:\IronPython-0.9\Scripts>mono \IronPython-0.9\bin\IronPythonConsole.exe
.\TestAll.py
** (\IronPython-0.9\bin\IronPythonConsole.exe:316): WARNING **: The class
System.StringSplitOptions could not be loaded, used in
\IronPython-0.9\bin\IronPython.
By calling "C", you mean calling "CPython bytecode", right, since Python only
calls C by virtue of having stubs available (eg, such as those produced by
SWIG). IronPython could have these even more directly, I think (via DllImport,
and no need for SWIG)
As far as CPython bytecode, someone cou
IronPython implements Python in C#, and can
call .NET but not C.
PythonNet implements Python in C, and can
call both .NET and C.
IronPython is probably the closest to what
you want, since Python classes should also be .NET classes.
Regards,
Mike
- Original Message -
From:
I've been asked:
Are there hopes for 1.0 release at PDC, or (as I think more likely)
DevConnections/Whidbey release?
From: [EMAIL PROTECTED] on behalf of Martin Maly
Sent: Mon 8/15/2005 1:10 PM
We surely want to find the right answer before 1.0
<>__
We did have discussion on this on the alias before that brought the
__future__ magic as one option. Jim and I are thinking about the right
approach, the __future__ is absolutely a valid candidate we are looking
at. We surely want to find the right answer before 1.0
Martin
> -Original Message-
Martin Maly wrote:
It is not obvious how to approach this, but definitely our goal is to
make sure that we stay true to the Python lanugage and its libraries and
as I said, it is our focus from now on to make progress on the libraries
and built-in modules etc.
What about __future__ magic?
--
J
Hi Ray,
Thanks for your compliments, we are happy that you find IronPython
useful.
You are right, there are many built-in modules missing or incomplete in
IronPython 0.9.
Our focus for 0.9 was interoperability with .Net and between 0.9 and 1.0
we are going to invest a lot into making CPython and
12 matches
Mail list logo
