Thanks, I've reported this bug via the CodePlex error page. I can't even view
that bug. I don't think we'll get _getframe(n) working but probably will get
_getframe(0) working (unfortunately it won't be in 1.1 Alpha).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
As far as I can tell the issue here seems to be that the data source is getting
the column names from the list and not from the individual elements that are
being added to the list. For example I tried the code below which hooks the
ColumnAdded event to see what columns are actually getting
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.42
1.1 Alpha: 2.4.0 (IronPython 1.1 Alpha (1.1) on .NET
: Monday, December 11, 2006 4:36 PM
To: Discussion of IronPython
Subject: Re: [IronPython] stdlib platform.py patch
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
Hello IronPython Community,
We have just released IronPython 1.1 Alpha. This release introduces several
new modules and features built upon the 1.0 code base along with
many of our top requested bug fixes. This is the start of the 1.1 release
cycle and future releases will focus primarily on
You're right, it should have be IronPython-1.1a1. We'll get it fixed for the
next release - there was some churn in our release process (we've switched to
Team Foundation Server internally which caused some churn) and this appears to
have broken in the process.
-Original Message-
Is wpf the Avalon.py we ship in the tutorial renamed? The tutorial version
creates a 2nd thread where all the UI requests from the interpreter will be
executed on. I believe the code sample below should work with our Avalon.py.
If you've modified Avalon.py to do some of your own GUI creation
If you want to follow the way you're currently doing it you can just publish
the DynamicType in Globals, eg:
Globals['foo'] = Ops.GetDynamicType(typeof(PublicResources));
You can also add a reference to your C# DLL and then the user can import all of
your public types / namespaces (although
Sorry, that 1st line should have been
Ops.GetDynamicTypeFromType(typeof(PublicResources)).
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Monday, December 18, 2006 3:42 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Accesses static ResourceManager
the resources using ResourceManager:
icon = RSWE.ResourceManager.GetObject(Open)
print icon
(Icon)
Any ideas?
Thanks,
Chris.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Monday, December 18, 2006 6:43 PM
To: Discussion
This sounds reasonable. Another approach might be to implement IReflect in the
interceptor class and then use the Ops.* functions (GetAttr, GetAttrNames,
etc...) in order to expose the dynamic types out to COM dynamically - but
that's considerably more work :)
If you don't want to use events
Thanks for the report Seo! I've opened CodePlex bug #6735 for this
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=6735).
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Sanghyeon Seo [EMAIL
PROTECTED]
Sent: Wednesday, December
Unfortunately you can't the CPython extension libraries w/ IronPython. You
could do it w/ templates instead of macros and force the instantiation of the
generic public class like:
templatetypename T class NativeData {
public:
T foo;
};
templatetypename T public ref class GenericData {
Yep, definitely a bug... I've opened CodePlex Work Item 7050 for this (and
tentatively marked it for v1.1, I think it should be an easy fix).
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7050
Thanks for reporting this!
-Original Message-
From: [EMAIL PROTECTED]
This part isn't so bad - you'd just need to have a library which has all the
same exports as Python that the C extension would call into instead of calling
into the real Python. The wrapper library would then translate the C Python
extension interface into calls into the IronPython runtime.
I
(attr));
Console.WriteLine(attr = {0}, type = {}\n, attr);
}
Thanks in advance...
Mike
-Original Message-
From: [EMAIL PROTECTED] [mailto:users-
[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Monday, January 15, 2007 11:46 AM
To: Discussion of IronPython
be public class DefaultContext?
Mike
-Original Message-
From: [EMAIL PROTECTED] [mailto:users-
[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Monday, January 15, 2007 1:08 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Calling Python objects from C#?
For the context
This is a bug, thanks for reporting it. Ops.In() needs to check for
IPythonContainer before checking for IDictionary to detect the overridden
method. I've opened bug 7426 for this
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7426).
-Original Message-
From: [EMAIL
Thanks for the bug report Seo! I've filed bug #7531 for this
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7531).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo
Sent: Sunday, January 21, 2007 5:51 AM
To: Discussion of
This should be solvable in a similar but slightly different way. We wouldn't
want to require an extra argument (in this case the versioned IronPython
engine) to be required for each call. Also I'm going to pick a slightly more
generic example DoOperation instead of Add (because a bug fix to
It might be interesting to also run with -X:ExceptionDetail to see where the
exception is coming from and report that back to the Mono team.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Haibo Luo
Sent: Tuesday, January 23, 2007 9:05 AM
To: Discussion
We haven't had much in the ways of discussing supporting Py3k features yet and
it might still be a little too early to do so. We have been following some of
the changes and we'll probably start following the changes a little more
closely.
We also still have some catching up to do with v2.5
Thanks for reporting this bug. I've opened CodePlex bug #7766
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7766).
There's some other weird behavior I was looking at for __builtins__ last week
and maybe this will turn out to be related. Redefining __builtins__ at the
Presumably someone could also modify IronPython's CodeGen class to turn all
methods into generators that yield at regular intervals. This would take a
significant performance hit as all the locals would be hoisted into a
FunctionEnvironmentDictionary and would still need the scheduler /
One thing I'll point out is we have no direct support for this in IronPython
today. But our events are all dispatched using an EventDispatcher class (see
ReflectedMembers.cs, EventDispatcher is an inner class of ReflectedEvent).
This class registers a single event against the underlying .NET
We auto-generate the code via Python script files. The source code for the
generation ships w/ IronPython and is in Src\Scripts\generate.py and individual
scripts (generate_*.py). If you're looking for the code that handles a
specific block you can grep/findstr for that block's region name
Corporation. All rights reserved.
class F(object):
... def __call__(self, *args, **kwargs):
... print F.__call__(%s, %s) % (args, kwargs)
...
print F.__call__
class '__main__.F'
Dino Viehland wrote:
Thanks for the bug report. I've opened bug #8246 to track this (
http
Thanks for the suggestion. I've opened a bug to track this but I don't expect
any immediate resolution here (the bug is
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8362).
The problem here is that we're trying to get several different scenarios
working correctly with our
In addition to the memory efficiency we get correctness in supporting
re-assignment to __class__. All of the types derived from one built-in type
share the same in-memory layout. Therefore __class__ can be assigned
arbitrarily between them changing the underlying dynamic type - just like
{IronPython.Runtime.PythonFile}
length 260759 object {int}
Thanks again,
Joe
On 2/21/07, Dino Viehland [EMAIL PROTECTED] wrote:
Hello IronPython Community,
We have just released IronPython 1.1 Beta 1. This release primarily focuses
on adding the remaining new functionality for the 1.1 release (array module
of
time to look at this more today. I am sort of confused why IP uses n
* ItemSize.
Thanks, Joe
On 2/22/07, Dino Viehland [EMAIL PROTECTED] wrote:
Depending on how similar your array.py was to CPython's built-in array the
problem here may be that our long data type is 8 bytes instead of 4 like
Unfortunately there are several switch statements that will need to be updated.
They are in CreateData (generic type), ToStream (cast), FromStream (call
Read?Int32). If you update all 3 you should be consistent then.
If I had to take a guess here I would think maybe there's an earlier read
broken.
Thanks, JoeSox
On 2/24/07, Dino Viehland [EMAIL PROTECTED] wrote:
Unfortunately there are several switch statements that will need to be
updated. They are in CreateData (generic type), ToStream (cast), FromStream
(call Read?Int32). If you update all 3 you should be consistent
Thanks for reporting this. I don't think we currently support Pickling the
various re objects. I've opened CodePlex bug #8592 to track it
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8592).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Unfortunately the answer is no. We don't work w/ the Compact Framework which
is what I believe ships w/ all versions of Windows Mobile. The problem here is
that the Compact Framework is missing the Reflection.Emit APIs that we need for
code generation.
I think we'll also accept utf_8 or utf8. This is basically covered under this
bug http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3094
(although the description doesn't make it entirely obvious).
If you could vote on the bug it'd help raise the visibility of the issue and
Thanks for reporting this. This is actually slightly different than the bug
described in the differences doc. There we're actually just preventing you
from an inevitable OOM and here we're failing to do the power which should
succeed.
This seems to work as long as the left hand side of the
- Original Message -
From: Dino Viehland [EMAIL PROTECTED]
To: Discussion of IronPython users@lists.ironpython.com
Sent: Friday, March 09, 2007 1:21 PM
Subject: Re: [IronPython] IronPython and Big Numbers
Thanks for reporting this. This is actually slightly different than the
bug described
Could it be that you have 1st chance exceptions enabled and this exception is
actually handled and recovered from? Python programs tend to throw exceptions
more than your typical C# app. Given that stepping out seems to allow the
program to complete this sounds like what's happening.
You can
goes fine (the fact that it hung before was
probably due to interference with NUnit).
Dino Viehland wrote:
Could it be that you have 1st chance exceptions enabled and this exception is
actually handled and recovered from? Python programs tend to throw
exceptions more than your typical C# app
You are correct in that __new__ methods map to the .NET ctor (both __new__ and
the ctor can only be run once, while __init__ can be called an arbitrary number
of times). Of course someone can construct a type from C# which has particular
__init__ or __new__ semantics but you won't run into
(self.children)
'docutils.nodes.len' is a 'field' but is used like a 'method'
self
{paragraphSomething to publish/paragraph}
self.parent
'object' does not contain a definition for 'parent'
self.children
'object' does not contain a definition for 'children'
Dino Viehland wrote:
Unfortunately I don't
You're getting back a subclass of NameValueCollection from
Configuration.Appsettings. The NameValueCollection class uses ArrayList's to
associate a key to multiple values. If you change the code to set an array
list it will work:
import clr
clr.AddReference(System.Configuration)
from
The .NET namespaces don't live in sys.modules instead they live in their own
hierarchy which is implemented as a ReflectedPackage class. The
ReflectedPackage is checked after we fail to find the module in sys.modules so
if you to stick something into sys.modules you'll take precedence over the
Thanks for reporting this. I've opened bug #9066 to track this. If you don't
need to add custom runtime behavior to the objects as a work around you could
create a new module using imp.new_module and push the values into there. I'm
marking this as a v2.0 bug but if it's blocking you let me
Hello IronPython Community,
We have just released IronPython 1.1 Release Candidate 1. IronPython v1.1 is a
minor update to IronPython including both new functionality as well as a number
of targeted bug fixes. The new functionality in v1.1 includes several new
modules (array, SHA, MD5, and
Now with the link to the release :)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Friday, March 23, 2007 1:09 PM
To: users@lists.ironpython.com
Subject: [IronPython] IronPython v1.1 RC1 Released
Hello IronPython Community,
We have just released IronPython
I think the problem is we're not setting the module name to __main__. If I do
this with:
import clr
clr.AddReference('System.Windows.Forms')
from System.Windows.Forms import MessageBox
MessageBox.Show(__name__)
From 'hello.py' the message box shows 'hello'.
I believe this is the same as bug
In general I think this is a good idea. Not only will it improve support in
interop scenarios but it also helps with thinks like debugging, profiling,
etc... for those of us doing lots of that w/ VS and IronPython. Personally I
always use an x86 IronPython on my 64-bit machines simply
This seems to work for me:
from IronPython.Hosting import PythonEngine
from System.IO import Stream
class C(Stream):
@property
def CanRead(self): return False
@property
def CanSeek(self): return False
@property
def CanWrite(self): return True
@property
def
How exactly are you doing this? If I take the code you've provided and put it
into a .cs file, compile it to a DLL, and import it I get:
IronPython 1.1b1 (1.1) on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
import clr
clr.AddReference('test')
import FooUser,
Anomoly with SetStandardOutput
Dino Viehland wrote:
The reason why I asked about multiple engine support is that it's actually a
feature we don't know if we can maintain long-term. The problem is that it's
actually impossible for us to always know what engine we were calling from
directly from the ipy shell does not trigger the
observed behavior.
Matt
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Monday, April 02, 2007 5:37 PM
To: Discussion of IronPython
Subject: Re: [IronPython] strange runtime error
Yep, this another is one of those spots where the engine isolation falls down
:(. Unfortunately this one is currently by design. SystemState not being a
real module was done to better support multiple engines as well. We probably
won't fix that in v1.x but maybe in v2.x it could become a
There's two ways I can think of how to enforce the time limit:
1. An external monitor which aborts the thread when a quantum has
expired. This has the problem of potentially aborting at any native CPU
instruction which most code is in no way prepared to handle. Therefore
2.
It looks like there are managed APIs (maybe they're just COM wrappers?) for
SharePoint which you could use from IronPython. A quick search turned up this
site http://www.codeproject.com/useritems/SharePoint_Automation.asp which is
using SharePoint from C#. From IronPython you would add
The answer to this all depends upon how the scripts are getting executed. If
you have a bunch of .py files which are getting loaded as modules from disk
(e.g. your typical import scenario) and you haven't used the
-X:GenerateAsSnippets mode then the answer is yes.
You should be able to attach
Hello IronPython Community,
We have just released IronPython 1.1. It started out as the work on v1.0
started to wind down. We could not get the features ready before we started
locking down for the v1.0 release but we're happy we can finally include them -
as will be our summer interns who
For the call to .Load I think you'll want to provide goodbye instead of the
fully qualified path.
If that still doesn't work there's a tool called fuslogvw.exe which is part of
the .NET Framework SDK (on my machine it's in %ProgramFiles%\Microsoft Visual
Studio 8\SDK\v2.0\Bin but if you don't
It seems like some people didn't get this announcement sent to them (including
myself) so I'm re-sending it in case there was a hiccup w/ our mailing list
server.
-Original Message-
From: Dino Viehland
Sent: Tuesday, April 17, 2007 2:44 PM
To: Discussion of IronPython
Subject
just that the import has problems.
I've just tried the example on another computer, and it's showing the
same issue.
Thanks for the help,
Tony
Dino Viehland wrote:
I haven't had a chance to track down what the underlying problem here is (and
suspect this is a bug), but is there a reason you
, April 23, 2007 2:29 PM
To: Discussion of IronPython
Subject: Re: [IronPython] wierd import problem
On 4/24/07, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote:
Oh, it seems to be the presence of the '.dll' in the filename (although I still
haven't looked too deeply to understand
There's still no direct LINQ support. We believe we're getting the correct
architecture in place to support extension methods in v2.0 (note though we
still haven't done the actual work to enable the extension methods and when we
ship the first 2.0 builds there will be no dependencies on
Hello IronPython Community,
We have just released IronPython 2.0 Alpha 1. IronPython 2.0 will be the first
release of IronPython built upon a common dynamic language runtime (DLR) as
well as targeting version 2.5 of Python. These release notes list what is new
in IronPython 2.0, a brief
These shared modules are for consumption from one dynamic language to another.
So for example in Python I could do import foo. Today IronPython v1.x falls
back to looking at .NET assemblies to find namespaces if a Python
module/package isn't found. In v2.0 we'll also fall back to the DLR
questions you might have, or
if anything I've wrote here is unclear.
One thing to think about: eventually we want to make our simulation
engine multi-threaded. Script functions will probably be getting
executed in parallel at some point.
Thanks,
Tony
Dino Viehland wrote:
I'm not actually the one
PROTECTED] On Behalf Of Dino Viehland
Sent: Wednesday 2 May 2007 19:17
To: Discussion of IronPython
Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond
(was IronPython 2.0 Alpha 1 Released)
Thanks for the info... Darn, it sounds like you actually want sys to be
isolated
Released)
My guess is that you have to use outlook. It does seem to encourage
top-posting. ;-)
Dino Viehland wrote:
The scripts are running on multiple threads?
Usually - although sometimes code is executed on the GUI thread, but in
this case we always know where to send the output.
The easy way
] Multiple engine instances in IP 2.0 and beyond (was
IronPython 2.0 Alpha 1 Released)
Dino Viehland wrote:
I didn't even realize posting at the top was considered a no-no on mailing
list etiquette... But indeed, I am using Outlook. I wonder if there's an
option to change that somewhere...
I
I think www.codeplex.com/DynamicSilverlight is the best spot for these. Thanks!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Friday, May 04, 2007 4:25 PM
To: Discussion of IronPython
Subject: [IronPython] DLR Console Bugs
Hello
Thanks for the bug report. I believe this is the same as bug #7594
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7594). We've
already fixed that in the v2.0 branch (where types are behaving quite
differently than they were in v1.x).
Could you vote on the issue - that way
FYI getting this to work w/ v2.0 is probably no small amount of work. We've
temporarily removed several features from v2.0 (such as CodeDom and the static
type compiler) which were used by the VS SDK integration to varying degrees.
The AST has also significantly changed which probably means
This has moved to
ScriptDomainManager.CurrentManager.GetCommandDispatcher/SetCommandDispatcher.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerard Braad Jr.
Sent: Tuesday, May 15, 2007 9:56 AM
To: users@lists.ironpython.com
Subject: [IronPython]
.
Since it seems
AttributeError: attribute 'SetCommandDispatcher' of
'ScriptDomainManager' object is read-only
Can the ScriptDomainManager also handle configuration files on a per
assembly base?
On May 15, 9:49 pm, Dino Viehland [EMAIL PROTECTED] wrote:
This has moved
Definitely a bug, I've got an idea on a better way to fit it then just change
when the we change the name.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo
Sent: Tuesday, May 15, 2007 9:17 AM
To: Discussion of IronPython
Subject:
We don't generate a type that can be easily consumed from static languages.
Can you use an interface in the DataTemplate line, eg:
DataTemplate DataType={x:Type IFancyData}
If so then you could declare an interface in C# (or find an existing one which
has what you want) and inherit
In the Vista CLR (and this is in the Orcas CLR as well) there's an improvement
to the performance of dispatching to a delegate closed over a parameter. We
tend to be pushing on delegates more and more these days for things like the
dynamic site infrastructure so this shows up there.
these wrinkles.
I wonder if the DLR is addressing these sort of typing issues? Up to
now I'm a little unclear what those chaps are up to.
Thanks for your prompt answer.
On 5/17/07, Dino Viehland [EMAIL PROTECTED] wrote:
We don't generate a type that can be easily consumed from static languages.
Can you
My vague recollection is that it involved not shuffling the parameters around
on the stack to make the call where as we used to do this before (for not real
good reason). But I could be completely wrong :). I'll follow up with the
person who made the change and get back to you. The CLR team
. I don't know if that'll apply to Mono or not but
maybe it gives you some ideas on where to look for own improvements :).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Thursday, May 17, 2007 12:11 PM
To: Discussion of IronPython
For the decisions on what goes into releases... For small issues and requests
we track these on CodePlex and pick them largely based upon the number of
votes. For minor releases we also take into consideration how destabilizing
the change will be.
Currently we don't support external
I also stumbled onto this in my blog reading today. This is similar to what we
do but we throw generics into the mix (so the Function delegate is strongly
typed) and we also inline the test (IOW, a highly optimized CheckFunctionCache
in the terms of the blog entry). Of course the tests
Thanks for the report Michael. I've opened bug #10474 for this
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=10474) and
assigned it to the 2.0 Alpha 2 release for the time being.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Thanks for the bug report Benjamin. And thanks for the workaround Seo. I've
opened bug #10518 for this:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=10518. I
haven't had a chance to look at the issue yet though.
-Original Message-
From: [EMAIL PROTECTED]
We don't yet support defining attributes from Python. It's a common feature
request.
For that you'll need to go to a static language like C# :(.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West
Sent: Wednesday, May 23, 2007 2:31 PM
To:
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West
Sent: Wednesday, May 23, 2007 3:40 PM
To: Discussion of IronPython
Subject: Re: [IronPython] how to apply guid
On 5/23/07, Dino Viehland [EMAIL PROTECTED] wrote:
We don't yet support defining attributes from Python. It's a common feature
I'll also add if it's your own application you should be coding to receive
IList or IListT instead of List. Typically they'll have everything you need
and accept a wider range of inputs - e.g. arrays, LinkedList's, normal List's,
etc... And if you can get away with it maybe just IEnumerable.
Some tweaks to make it better:
.\ipy.exe -X:ColorfulConsole -X:TabCompletion -X:AutoIndent
Or some combination thereof (I don't like AutoIndent because copy pasting
code breaks).
And make sure to enable Quickedit Mode on the console (Right Click menu bar,
Properties-Options-Quick Edit Mode)
Very cool!
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, May 30, 2007 9:00 AM
To: users@lists.ironpython.com
Subject: [IronPython] IronPython Wiki Cookbook
IronPython Wiki Cookbook
[http://www.voidspace.org.uk/emoticons/nightmare.gif]One of
Unfortunately we're still not accepting patches. It looks like this is just a
new CodePlex feature but there doesn't appear to be anyway to turn it off.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sylvain
Hellegouarch
Sent: Tuesday, June 19, 2007
If the exception was raised in Python then you should be able to do:
print event.Exception.Data['PythonExceptionInfo']
which will contain the Python exception object, not that I'm sure you can
format that one much better.
What you probably want to do is call
] .NET Exception to Python Exception conversion
Dino Viehland wrote:
If the exception was raised in Python then you should be able to do:
print event.Exception.Data['PythonExceptionInfo']
which will contain the Python exception object, not that I'm sure you
can format that one much better.
What
You need to pass the -X:TabCompletion command-line option and it should work.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mike arty
Sent: Thursday, June 21, 2007 6:34 AM
To: users@lists.ironpython.com
Subject: [IronPython] tab-complete?
Yet another IronPython newbie question-
Is there only one implicit conversion? If so I think you should be able to
call the op_Implicit method directly on XDate, e.g: XDate.op_Implicit(d).
If there's more than one I'm not sure how you'd select the one you want to call
off the top of my head.
-Original Message-
From: [EMAIL
How exactly are you passing this? I assume the quotes aren't being included?
The 1st form below prompts me and the 2nd form doesn't prompt (ignoring the UAC
prompt on Vista of course which is a whole other ball of wax), are you doing
something different?
import System
of people having this similar problem
but people seem to give up before posting a solution. Any other ideas?
On Jun 22, 10:32 am, Dino Viehland [EMAIL PROTECTED]
wrote:
How exactly are you passing this? I assume the quotes aren't being included?
The 1st form below prompts me and the 2nd form doesn't
Thanks Michael, I've opened bug #11283 and assigned it to the v1.1.1 release.
If you could take the time to vote on this bug that'd be great.
If there are other bugs that you, or anyone else, would like to see in v1.1.1
release please let us know. I'll start tagging those appropriately and
Alpha 2's coming sometime soon.
1.1.1's just so we can start assigning bugs against that release and have a
good way to track the important issues there.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Tuesday, June 26, 2007 3:48 PM
Hello IronPython Community,
We have just released IronPython 2.0 Alpha 2. This release is a snapshot of the
on-going progress with IronPython 2.0 and the DLR.
One of the most significant changes in this release is the removal of
Microsoft.Scripting.Vestigial. Previously this DLL was a
an update on the status of the multiple engine debate
and does this release change anything on that front?
When Alpha 1 was released, we discussed swappable SystemStates as an
alternative to multiple engine instances. Does this release include
this functionality?
Thanks,
Tony
Dino Viehland wrote
301 - 400 of 1614 matches
Mail list logo
