This behavior is actually defined by CPython which specs interactive input as
being:
interactive_input ::= [stmt_list] NEWLINE | compound_stmt NEWLINE
The stmt_list allows the semi-colon delinated lines and the compound_stmt
allows a single statement.
The idea here is that this is for a
Something went wrong on the machine that pushes the source code out and then
there were some changes that required the script to be updated. It's working
now and pushed out an update yesterday.
-Original Message-
From: [EMAIL PROTECTED] [mailto:users-
[EMAIL PROTECTED] On Behalf Of
I don't believe there is right now w/o a bunch of work to update to the new 2.0
hosting APIs.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yash Ganthe
Sent: Tuesday, December 09, 2008 5:59 AM
To: users@lists.ironpython.com
Subject: [IronPython] IronPython Studio and IronPython
The fix for this is pretty simple. It's going into 2.1 as we speak, and I'll
port it back to the 2.0.x branch. Unfortunately at this point I don't think
it'll make it into 2.0 final.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Jones
Sent: Tuesday, December 09, 2008
] [mailto:users-
[EMAIL PROTECTED] On Behalf Of Giulio Petrucci
Sent: Thursday, December 11, 2008 12:42 AM
To: IronPython mailing list
Subject: Re: [IronPython] Newbie Questions
Hi Dino,
first of all, thanks for your reply
2008/12/5 Dino Viehland [EMAIL PROTECTED]:
You can add a reference
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
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
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
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? :))
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
Of Michael Foord
Sent: Monday, December 15, 2008 3:04 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiled dlls and builtin modules
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
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
My guess would be that we're pushing the PythonContext._callSplatSite outside
of the sweet spot in DLR site caches.
You could check this by putting a breakpoint in PythonContext.Call(object,
params object[]). Then look and see if _callSplatSite._rules is an instance of
EmptyRuleSetT with
are
slower when executed from dlls, so the same slow down might be
triggered by sth else.
On Wed, Dec 17, 2008 at 3:21 AM, Dino Viehland di...@microsoft.com
wrote:
My guess would be that we're pushing the PythonContext._callSplatSite
outside of the sweet spot in DLR site caches.
You could
This is just a test... there were some issues with the mailing list today, just
verifying that it should be back now.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
would be
pro-backporting.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Monday, December 15, 2008 11:13 PM
To: glenn.k.jones+...@gmail.com; Discussion of IronPython
Subject: Re: [IronPython] Issue about string.upper
Are there other exceptions being thrown, potentially somewhere on the stack
below game\models\__init__.py on line 144? Maybe we're calling a built-in
function somewhere that's calling back into your code and is doing something
funky with the exception tracking. Can you run this under VS and
Strangely I don't see one - this is frequently asked for so I'm a little
surprised :)
I have a plan on how to enable this (and some other .NET scenarios) in the next
major release. My current thinking is to support this via meta-classes and
providing a new method on type which lets you
You should be able to just copy and paste throwing error sink into your own
version, it's pretty simple:
internal class ThrowingErrorSink : ErrorSink {
public static new readonly ThrowingErrorSink/*!*/ Default = new
ThrowingErrorSink();
private ThrowingErrorSink() {
}
Good places to look would be:
ExceptionHelpers.UpdateStackTrace is where the frame should be
remembered
PythonOps.CreateTraceBack should be where we actually pull the current
set of frames for exceptions and build up the stack trace
An alternate plan would be to run your script in another app domain. Then you
can just unload the app domain and all shared state will be cleared. The
hosting APIs make this pretty easy to do as well.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On
Of Renaud Durand
Sent: Wednesday, January 21, 2009 8:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Calling a Python function (compiled into an assembly)
from C# using delegates.
That is the point. I don't want to do that from a file but from an Assembly
(dll).
2009/1/21 Dino Viehland di
'Microsoft.Linq.Expressions.ParameterExpression' in
Assembly 'Microsoft.Scripting.Core, Version=0.9.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' is not marked as serializab
le.
Marc
On Wed, Jan 21, 2009 at 5:57 PM, Dino Viehland di...@microsoft.com
wrote:
Can you run w
You're right that it worked in 1.0 - but of course in 1.0 we would also end up
with an arbitrary ordering between engines. For example you could have:
Engine 1:
Sys.path = C:\
Contains Foo.dll
Engine 2:
Sys.Path = D:\
Contains Foo.dll
Which
Foord
Sent: Friday, January 30, 2009 3:30 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Two engines and clr.AddReference don't work together.
Dino Viehland wrote:
You're right that it worked in 1.0 - but of course in 1.0 we would also end
up with an arbitrary ordering between engines
You can always provide your own stream which is aware of what the current
output window is. It could store this in a thread static or just some variable
that you update whenever the active window changes. You can set that via
ScriptRuntime.IO.OutputStream. You could conceptually do the exact
: Friday, January 30, 2009 6:41 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Redirecting stdout/stderr, but with context
Dino Viehland wrote:
You can always provide your own stream which is aware of what the current
output window is. It could store this in a thread static or just
What do you mean by 'existing'? Do you want the class definitions which the
current statement is nested in? Do you want to get to an arbitrary class
definition somewhere in the AST?
Currently we don't maintain any of this but there's no reason you couldn't
modify PythonAst.TransformToAst so
) support for numpy using
our Ironclad project.
We're releasing the beta tomorrow: this has a few performance
problems (which are being addressed - many thanks to Dino Viehland
for helping with this!) but is otherwise functionally complete.
If you're interested in trying it out, drop me
that is a great plan. Having no P/Invokes makes it much more
platform agnostic.
On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland di...@microsoft.com wrote:
Current thinking is that IronPython 3k will be the 1st version that will
take a dependency on .NET 4.0 so we'll have to wait until
is a nasty hack and
we'd rather not do it :)
Regards,
Orestis Markou
Resolver Systems Ltd.
Dino Viehland wrote:
Yep, and I'm happy to move back to the old behavior - being consistent w/
ourselves and broken seems better than being inconsistent w/ ourselves and
broken :)
-Original Message
(informal) documentation for the
parser/compiler?
Eyvind.
-Opprinnelig melding-
Fra: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] På vegne av Dino Viehland
Sendt: 4. februar 2009 18:04
Til: Discussion of IronPython
Emne: Re: [IronPython] Getting hold
There's no existing functionality to do this but we could add __repr__
overloads onto the built-in types. They would presumably return something like:
System.UInt32(1)
or:
UInt32(1)
Could you open a bug?
-Original Message-
From: users-boun...@lists.ironpython.com
And the correct change to the source code would be adding __repr__ methods to
the various *Ops types (Int16Ops, UInt16Ops, etc...) which return the correct
formatting. Presumably by updating the scripts that generate these types.
OTOH there's nothing particularly unsafe about your changes
...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Saturday, February 07, 2009 6:04 AM
To: Discussion of IronPython
Subject: Re: [IronPython] repr() results with uint, etc.
Dino Viehland wrote:
And the correct change to the source code would be adding
Or if your program has no UI components you can start with the -X:MTA option
and the warning won't get issued.
Unfortunately the 2nd you hit a different warning it's likely you'll have the
same problem. So the underlying problem looks like we're somehow picking up a
different linecache.py or
.
pj
On Mon, Feb 9, 2009 at 7:49 PM, Dino Viehland di...@microsoft.com wrote:
If I setup this as you describe from the command line it just works:
x\
subdir\
__init__.py
mymodule.py:
import clr
Awesome, thanks for tracking this down. This looks trivial to fix - we're just
missing a lock statement. I've added the lock to my next change that will go
in (probably today).
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On
It sounds like you're hitting a bug in the codedom round tripping support.
IronPython Studio is really more of a sample and leaves much to be desired so
it's likely you'll hit many more. Michael Foord who has done tons of winforms
development I believe recommends designing it in C# and then
, February 19, 2009 9:55 AM
To: Discussion of IronPython
Subject: Re: [IronPython] how to use an enum from a hosted script
Dino Viehland wrote:
Generally what you'd do is:
import clr
clr.AddReference('yourdll')
from MyNamespace import NotificationTypeEnum
I have no idea where
Depending on what you're doing you might be better off using Funcobject
instead of CallTarget0. CallTarget0 is more of a Python implementation detail
and could change w/ major IronPython versions - or even be replaced w/
Funcobject. it's primary purpose is to be the delegate for calling a
Can you run w/ the -X:ExceptionDetail command line option the for the import
Crypt / from Crypto import * and report back the stack trace you get?
I'm not sure that I'll be of much use but if it's somewhere in IronPython
instead of IronClad it might be an IronPython bug.
-Original
Just some comments on this as there's a few issues intertwined here:
1. Optimized code - this is currently the default and part of the
original problem. If you execute code in optimized mode we generate an
uncollectible type. In 2.6 I'm switching the default to be non-optimized and I
that instance.
CallTarget solved my problem... Do you know any other methodology that works
better then CallTarget?
Thank you,
António Piteira
2009/2/22 Dino Viehland di...@microsoft.commailto:di...@microsoft.com
Depending on what you're doing you might be better off using Funcobject
instead
You can create the DataSeries object for them and include it in each call? Or
can you do something like:
def Init():
return DataSeries()
and only call their Init function once?
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of
-
boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Thursday, February 26, 2009 12:07 AM
To: Dino Viehland
Cc: Discussion of IronPython
Subject: Re: [IronPython] Please vote up this DLR memory leak bug
Microsoft.Scripting2.Core is a namespace copy of the IP source code -
based
I can't run it right now but if these are happening on the finalizer thread
then this has most likely been fixed in the 2.6 branch already. The issue is
that when a generator is not run to exhaustion we need to call close() on it
which causes an exception to be thrown. But we can avoid the
This one is technically by design. The python code which calls __import__/does
import is the one that gets tainted with the ability to see clr attributes. We
have discussed changing the design so that import clr is recognized at
compile time and works like from __future__ ... instead of being
This is the correct behavior. We expose protected members as normal members
that throw when the instance isn't a subclass defined in Python. But they need
to exist on the base class so that you can do things like super calls to them.
-Original Message-
From:
-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Saturday, March 07, 2009 11:51 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Patching __import__ can break .NET attribute
access
Dino Viehland wrote:
This one is technically by design. The python code which calls
or not?
On Mar 7, 7:49 pm, Dino Viehland di...@microsoft.com wrote:
This is the correct behavior. We expose protected members as normal
members that throw when the instance isn't a subclass defined in
Python. But they need to exist on the base class so that you can do
things like super calls to them
The fact that we allow setting to the dictionary when we shouldn't be much to
worry about - it is just odd. In either case we still have a .NET type defined
something like:
class NewType : YourBaseTypeHere {
public PythonDictionary __dict__;
public object[] __slots__;
This is fixed in 2.6 and we can backport the fix to 2.0. Could you open a bug
on CodePlex? If you want to add the fix locally you just need to add the lock
statement below to NewTypeMaker.StoreOverriddenMethods:
lock(PythonTypeOps._functions) {
foreach (BuiltinFunction bf
The resolution of that bug was that we now expose explicitly implemented
interfaces automatically if there are no naming conflicts. But with COM it's
usually a different story - the members should always just be there. Do the
interop libraries use explicit interface implementation (if they
Does this make it work?
class x(unicode):
def __init__(self, val): pass
def __new__(cls, val):
return unicode.__new__(cls, unicode(val))
x(1)
I've voted for the bug and raised the priority to medium. I've left it
proposed until we triage it as a team (we triage bugs every
It works on CPython 2.6 at least. You should only have to override __new__ if
you wanted to support different arguments than str/unicode.__new__ supports.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael
The method you're trying to call is generic so you need to index into it to
provide the generic type:
mycalsvc.Insert[type(myentry)](myposturi, myentry)
We're considering adding inference for these type parameters in the future.
From: users-boun...@lists.ironpython.com
The documentation for using the hosting APIs is available here:
http://dlr.codeplex.com/Wiki/View.aspx?title=Docs%20and%20specsreferringTitle=Home
as dlr-hosting-spec.doc
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On
Do you have IronPython.Modules.dll next to IronPython.dll?
IronPython.Modules.dll contains the implementation of thread.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Jonatan Nilsson
Sent: Wednesday, March 18,
Also make sure you have IronPython.Modules.dll next to IronPython.dll (if
you're hosting IronPython instead of just running from the command line).
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
: Subclassing unicode
On Mon, Mar 16, 2009 at 7:03 PM, Dino Viehland di...@microsoft.com
wrote:
Does this make it work?
class x(unicode):
def __init__(self, val): pass
def __new__(cls, val):
return unicode.__new__(cls, unicode(val))
x(1)
I've voted for the bug
It's actually a CLR bug - we can't call this method from a dynamic method. We
could probably add a workaround and force it to always be called via reflection.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Friday, March
could probably use
a delegate that takes an object[], but BuiltinFunction contains that
code already, and it is a lot more optimized than I could manage. Plus
it's less code for me to write :).
- Jeff
On Sat, Mar 21, 2009 at 11:45 AM, Dino Viehland di...@microsoft.com
wrote:
If you only
signatures for
the same method name. This could presumably be simulated by replacing the
method group in Python with a new method group that contained all the original
infos plus the new one.
On Mon, Mar 23, 2009 at 11:11 AM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
Do
Why do you need to cast to the base class? All of the members you need should
already be there.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Carolyn Johnston
(MSNAR)
Sent: Thursday, March 26, 2009 3:47 PM
To: Users@lists.ironpython.com
Yeah there is apparently an issue here, Resolver reported it to me the other
day off-line. We've been changing our code gen rather significantly and it
looks like our existing test coverage isn't hitting whatever the issue is here.
I'll probably look at it tomorrow.
From:
You can do:
import clr
from System.IO import File
clr.AddReference(Assembly.Load(File.ReadAllBytes(assemblyName)))
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Samuel Tjokrosoesilo
Sent: Thursday, April 02, 2009 10:43 AM
To: Discussion of
What DLLs you want to be loaded? The reason I ask is that .NET assembly
loading doesn't really work on the basis of the current working directory -
instead it looks at the app base which by default is where your EXE is located.
We do modify sys.path so that IronPython can load things outside
/Public/hello.zip
cd hello\build\ and die.exe will run
cd hello and run .\build\die.exe and it will fail
Thanks,
Davy Mitchell
On Mon, Apr 6, 2009 at 4:18 PM, Dino Viehland di...@microsoft.com
wrote:
What DLLs you want to be loaded? The reason I ask is that .NET
assembly
loading
This is fixed now so pre-compilation is working again in the current 2.6
sources.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Davy Mitchell
Sent: Tuesday, March 31, 2009 1:52 PM
To: Discussion of IronPython
Subject: [IronPython] PYC and 2.6
There is an implicit conversion from PythonType - Type. So
(Type)(PythonType)o will work here. Alternately you can just strongly type a
function in C# as taking a Type and call that from Python and the conversion
will happen automatically.
-Original Message-
From:
).
Thanks again,
Alex
On Tue, Apr 14, 2009 at 11:16 AM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com
wrote:
For kwargs you need to decorate the function w/ a ParamDictionary
attribute such as:
public void __init__(CodeContext/*!*/ context, object o,
[ParamDictionary
Yeah, I saw that too :(
I think we can definitely add a message for None so that this gets
better. At the very least we can report all of the types of arguments
that we received so the None is at least in your face. In general we
want to improve all of our error messages as they're frequently
In theory there's just 1 IL re-write that's required for this to work. And
that should be replacing the references to mscorlib/IronPython to point at the
Silverlight versions. There's no way to directly have the written binaries
target Silverlight because Reflection Emit has no
...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, April 20, 2009 12:43 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Dino Viehland wrote:
In theory there's just 1 IL re-write that's required for this to
work. And that should be replacing
Of Michael Foord
Sent: Monday, April 20, 2009 1:24 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Dino Viehland wrote:
An easy starting point would be to use ildasm + a Python script +
ilasm. There's also CCI (just released on CodePlex last
You're compiling to a DLL and then trying to import (vs compiling to an EXE)?
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, April 20, 2009 3:07 PM
To: Discussion of IronPython
...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Tuesday, April 21, 2009 2:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Dino Viehland wrote:
You're compiling to a DLL and then trying to import (vs compiling to
an EXE)?
Yes - it's
: Tuesday, April 21, 2009 4:02 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Dino Viehland wrote:
Do you have a simple repro XAP you can send me and I'll take a look?
I'm not entirely sure I'll know what's going on as CoreCLR isn't the
CLR I'm
Not to rain on Jeff's parade but I too have been working on a CTypes
implementation. I'll probably check the initial version into 2.6 in the
next few days but there's still a lot more to go before it's a solid
implementation.
As of right now running test\test_ctypes.py reports 358 tests run w/
: Monday, April 27, 2009 12:03 PM
To: Discussion of IronPython
Subject: Re: [IronPython] pywin32 on Iron Python?
On Mon, Apr 27, 2009 at 12:41 PM, Dino Viehland di...@microsoft.com
wrote:
Not to rain on Jeff's parade but I too have been working on a CTypes
implementation. I'll probably check
...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Monday, April 27, 2009 4:49 PM
To: Discussion of IronPython
Subject: Re: [IronPython] pywin32 on Iron Python?
On Mon, Apr 27, 2009 at 1:30 PM, Dino Viehland di...@microsoft.com
wrote:
Sorry Jeff, you're
Check to see if the object implements IPythonObject.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Ivan Porto Carrero
Sent: Tuesday, April 28, 2009 10:38 AM
To: Discussion of IronPython; ironruby-core
Subject: Re: [IronPython] Telling .NET
On 18222 - I think ctypes will drive some changes to our buffer support
making it more real. Right now it's close to useless :) There is some
way for us to make types marshalable via COM ourselves so I think
we'll be able to fix it eventually. I'm surprised that it's more of
a problem than
Yep, we're going to make it available via a command line option. The
Interesting question is what does IPython need from frames? Does it
need locals (which frequently won't be available), globals, the function
or code, or something else?
I think bug 1042 is the one to vote on:
There was some internal work going on w/ running a remote console
and it looks like this change was related to that. In
Microsoft.Scripting.Hosting.Shell there's a comment added to its
RunOneInteraction w/ the same change:
/// We check if the code read is an interactive command or
] On Behalf Of Dino Viehland
Sent: Wednesday, April 29, 2009 11:13 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Expression printing in interactive mode
There was some internal work going on w/ running a remote console
and it looks like this change was related
Yes - I've opened a bug (22235 -
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235).
I want to generally improve the doc strings everywhere. I've slowly
been pushing on this and my ultimate goal is to get all of the doc
strings moved into XML comments and then we can read them
You mention CreateEngine but are you also creating multiple runtimes? You're
only allowed 1 ScriptEngine of a given type per ScriptRuntime. So you should
create a new ScriptRuntime and then get the Python engine for each runtime and
then be isolated.
From: users-boun...@lists.ironpython.com
30, 2009 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple runtimes?
You're only allowed 1 ScriptEngine of a given type per
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple runtimes?
You're only allowed 1 ScriptEngine of a given type per ScriptRuntime
would you use to process them?
On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
Yes - I've opened a bug (22235 -
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235).
I want to generally improve the doc strings everywhere. I've
, April 30, 2009 9:47 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
And this works for me:
I just did the equivalent, from *inside* IronPython which may make a
difference, with the 'os
Based upon the feedback from the mailing list here's the 2.6 release plan and
list of new features:
http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Plan
Let me know if you have any questions or think there's areas we should include
more info on.
...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, April 30, 2009 9:28 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
And this works for me:
using System;
using
then we'll include it.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 12:26 PM
To: Discussion of IronPython
Subject: Re: [IronPython] 2.6 Release Plan
Dino Viehland
-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 12:58 PM
To: Discussion of IronPython
Subject: Re: [IronPython] 2.6 Release Plan
Michael Foord wrote:
Dino Viehland wrote:
Both of those are just oversights
Michael just brought this up on another thread but I thought I'd make it
obvious.
Let us know what bugs you particularly want to see fixed in 2.0.2. Nominate
them here and we'll collect the list and try to fix as many as possible.
___
Users mailing
My guess this is due to ngen. Normally after the .NET framework installs
there's a ngen service waiting to run in the background and compile all of
the .NET framework.
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of
Do you happen to know what baseName is when the assertion is hit?
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Sunday, May 03, 2009 1:19 PM
To: Discussion of IronPython
Subject: [IronPython]
901 - 1000 of 1614 matches
Mail list logo