On 1/21/07, Michael Foord <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> What is the IronPython team's intention with respect to Python 2.X and
> Python 3 ?
Note that Py3K is still a work in progress. Py2.6 will attempt to
support (through use of from __future__, &c) compatibility with 2.5 as
well as
On 12/26/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote:
> Eh, I realized that my previous take on this was flawed. IronPython's
> FunctionN is *not* VarArgs. IronPython's FunctionX is used for both
> VarArgs and KwArgs.
>
> In other words:
>
> def foo(a, b, c, d, e, f): pass # 6 arguments to force Fu
On 12/25/06, Michael Foord <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I'm trying to determine function signatures from IronPython.
>
> In Python I'd use 'inspect.getargspec'.
>
> In IronPython this raises a 'NotImplementedError'.
'inspect' is a pure-python module. Where's the NotImplementedError
On 12/18/06, Neil(木野狐) <[EMAIL PROTECTED]> wrote:
> Thank you, Seo,
>
> But what's the relation of this project to IronPython released by Microsoft?
This is IronPython, with a bunch of patches to make it work better on
Mono, to enable parts of the standard library that don't currently
work, and in
On 12/13/06, Miguel de Icaza <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > IPCE on Mono 1.1.17 works really nicely in interactive mode. Backspace
> > works, ^D to exit works, the lot. On 1.2.2, however, it's a world of
> > broken. Backspace is just insane, ^D stopped working again... it's
> > pretty mu
On 12/12/06, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Unfortunately I think the format for 1.1 is the format that we want to keep
> going forward.
> Just for the purposes of comparison:
>
> 1.0: IronPython 1.0.60816 on .NET 2.0.50727.42
> 1.0.1: IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.
On 12/10/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote:
> 2006/12/9, Anthony Baxter <[EMAIL PROTECTED]>:
> > This works on each version of FePy I could find.
>
> God helps us, it still doesn't parse sys.version from IronPython
> to-be-1.1, namely change set 1
On 12/9/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
The following patch makes Lib/platform.py correctly parse the
sys.version string for FePy 1.0 and 1.0.1. It would be good if it
could be added to IPCE - then pybench will work.
Damn. diffed wrong version. Try this patch, instead
The following patch makes Lib/platform.py correctly parse the
sys.version string for FePy 1.0 and 1.0.1. It would be good if it
could be added to IPCE - then pybench will work.
--- platform.py 2006-12-05 21:25:22.0 +1100
+++ /usr/lib/python2.5/platform.py 2006-10-07 01:23:11.0 +100
I did a very quick port of Bruce (http://bruce.python-hosting.com) to
IronPython the other night for my "futurepython" talk at OSDC 2006.
Bruce is built on top of pygame at the moment. I grabbed sdldotnet
(http://cs-sdl.sourceforge.net/), installed it, and started reading
the docs for it (they're i
Hi Seo (and others).
IPCE on Mono 1.1.17 works really nicely in interactive mode. Backspace
works, ^D to exit works, the lot. On 1.2.2, however, it's a world of
broken. Backspace is just insane, ^D stopped working again... it's
pretty much unusable. I'm not sure whether this is a Mono bug (in
whic
On 12/8/06, Paolo Molaro <[EMAIL PROTECTED]> wrote:
> The bug is fixed in svn (at least on non-win32): Process didn't handle
> the case when only the filename is set in ProcessStartInfo.
Fabulous! Thanks for the quick response. This will be in the 1.2.3 release?
___
The following patch makes codeop.py (and therefore stuff that depends
on it, such as code.py) work on IronPython. I needed this for the talk
I did on Thursday, where I had an interactive interpreter example
built on a rough port of Bruce (http://bruce.python-hosting.com)
outputting to SDL. It would
On both IronPython 1.0.1 and IPCE release 4, os.popen() segfaults
under Mono 1.17.1 (on Ubuntu edgy).
To reproduce:
ipy.exe -c "import os; print os.popen('/bin/ls', 'r').read()"
Stacktrace follows, for whatever value it is... I can't tell
immediately whether it's an IronPython or Mono problem, al
On 10/20/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote:
> Python standard library is shared between CPython and IronPython.
> Comparing 2.4.3 and 2.4.4, 105 files and 2280 lines were changed in
> the library, all mostly bugfixes.
Um, "mostly" bugfixes? They should be _all_ bugfixes, that's part of
h
On 10/11/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote:
> 2006/10/11, Anthony Baxter <[EMAIL PROTECTED]>:
> > Right now, there is no easy way (aside from parsing sys.version) to
> > say "is this code running on CPython or IronPython." And, as I started
>
> import System
> a =
> [].GetType().Assembly.GetCustomAttributes(System.Reflection.AssemblyFileVersionAttribute,
> False)
> if len(a) > 0:
> if a[0].Version == "1.0.61005.1977": print "IronPython 1.0.1"
> else: print "Unknown version"
> else:
> print "IronPython 1.0"
Er - what? This
> Regarding the Mono bugs: let us know what pending issues Mono has, and
> we will be glad to fix them.
>
> We rewrote the Console class recently to cope better with the 2.0 APIs
> for screen coloring, positioning and we would love to hear if there are
> problems with it.
Will this fix the problem
I notice the format of sys.version has changed. Since sys.version_info
lies, and sys.subversion isn't supported, could this please not be
changed so much?
Old:
IronPython 1.0.2453 on .NET 2.0.50727.42
New:
IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
On another related matter, there reall
It appears that Monodevelop chokes and dies on the version of Visual
Studio used for IronPython. So I recreated the project using
MonoDevelop's own formats. The following link contains a tarball that
can be unpacked over the top of the IronPython source tree to make it
all "just work" in monodevelo
On 9/26/06, fabio.pliger <[EMAIL PROTECTED]> wrote:
>
> Agree... But huge use of decorators in a complex application tends tslow
> down performance and generate complex and longer tracebacks...
Why? Decorators are applied at the time the function or method is
created, not at runtime.
On 9/23/06, Dino Viehland <[EMAIL PROTECTED]> wrote:
> From the IronPython side you can look at Ops.UpdateTraceBack. This is called
> during fault blocks (catch & rethrow blocks in dynamic methods) to store line
> number
> information when we have code that PDBs (or whatever Mono uses here) don't
On 9/23/06, anil <[EMAIL PROTECTED]> wrote:
> i have dotnet
> but i need help running this, if you can tell me how to do this
See the message I just posted a couple of hours ago - if those patches
don't make it work for you, please post the output of pybench --debug
and I'll look into fixing it.
_
Just grab the latest Mono from the Mono website, and install it to a
different location (I use /app/mono/{version}/
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
If you apply patches www.python.org/sf/1563842 and
www.python.org/sf/1563844, you can run the pybench benchmark under
IronPython. It requires a patched version of platform.py (the first of
the two patches) and a patched version of Pybench. The latter is
available in the Python source tree in Tools/
On 9/22/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote:
> 2006/9/22, Anthony Baxter <[EMAIL PROTECTED]>:
> > Tracebacks appear to be missing line numbers on this install of
> > Ironpython (it's the IPCE 1.0 version, running against Mono 1.1.17).
> > Before I
Tracebacks appear to be missing line numbers on this install of
Ironpython (it's the IPCE 1.0 version, running against Mono 1.1.17).
Before I dig into this too far, is this a known issue?
Traceback (most recent call last):
File chimp, line unknown, in Initialize
File chimp, line unknown, in m
27 matches
Mail list logo
