Re: [IronPython] IronPython 2.0 Alpha 6

2007-11-09 Thread Dino Viehland
, but not in ipy 2.0 alpha 4. Very best regards. On 9 nov, 19:10, Dino Viehland [EMAIL PROTECTED] wrote: Are you seeing something different on Alpha 6? I see the same behavior between CPython and Python but I am on a slightly later build - although the list of methods is slightly different (e.g

Re: [IronPython] __getattribute__ bug

2007-11-12 Thread Dino Viehland
Thanks for the bug report, and sorry for missing the original mail. This is a bug in a code path that will ultimately be going away - currently we still have a mix of code paths that use the new DynamicSite and Rules mechanism and the old interface / PythonType (Formerly DynamicType) / CLR type

Re: [IronPython] Another trivial bug

2007-11-12 Thread Dino Viehland
It's technically over (now it's hosting API feature development week) but I still have 2 check-ins that aren't in yet. I'll include this in one of those. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo Sent: Monday, November 12, 2007 7:21

Re: [IronPython] Another trivial bug

2007-11-12 Thread Dino Viehland
that's happening. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, November 12, 2007 10:12 AM To: Discussion of IronPython Subject: Re: [IronPython] Another trivial bug Dino Viehland wrote: It's technically over (now it's

Re: [IronPython] [python] Re: Another trivial bug

2007-11-12 Thread Dino Viehland
: Monday, November 12, 2007 2:55 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Another trivial bug That's great! Once you have added static compilation back into IP 2 we might be able to start using it at Resolver. :-) Michael http://www.manning.com/foord Dino Viehland

Re: [IronPython] [python] Re: Another trivial bug

2007-11-12 Thread Dino Viehland
] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, November 12, 2007 3:09 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Another trivial bug Dino Viehland wrote: Do you mean the hacky static compilation which lets you create real .NET types or the pyc pre

Re: [IronPython] FW: FW: DLR question

2007-11-13 Thread Dino Viehland
There's no direct support for this but it shouldn't be too hard to do. You can carry the AST around w/ you by doing an Ast.RuntimeConstant(myAstRoot). For example let's say that we wanted to hold onto the AST for all Python functions. Over in FunctionDefinition.cs we call a helper method

Re: [IronPython] (trivial) bug in binding varargs

2007-11-16 Thread Dino Viehland
Luckily this is already fixed in 2.0 (method dispatch, in particular kw-arg dispatch, is completely different now). We're discussing v1.x servicing plans next week so I'm going to hold off on opening a bug but will follow up after that. -Original Message- From: [EMAIL PROTECTED]

Re: [IronPython] Disabling optimized methods

2007-11-19 Thread Dino Viehland
This isn't actually optimization but rather dynamic methods. You can use the -X:StaticMethods which will force all methods into types. But the consequence of this is if methods are getting dynamically defined (e.g. exex def foo(): pass) then we'll leak memory because the methods can never be

[IronPython] DLR Hosting Spec

2007-11-19 Thread Dino Viehland
As I mentioned a couple of weeks ago we've been wrapping up work on designing the hosting APIs and just this past week we've started implementing the new hosting APIs. We'll be continuing this work off-and-on over the next few months so now is a great time to start collecting feedback on the

Re: [IronPython] TypeError: expected Tuple, got tuple

2007-11-24 Thread Dino Viehland
They're actually two rather distinct data types and there's no plans to merge them right now. Tuple is used for creating strongly-typed fixed-sized collections and is used internally by the DLR. We use it for creating our FunctionEnvironment's (for closures), for creating storage which back

Re: [IronPython] Problems with 8-bit strings

2007-11-24 Thread Dino Viehland
I think the construction w/ characters 0x80 is a bug. But the returning of unicode vs. 8-bit strings is just a display issue. IronPython only has unicode strings and is one of the big differences between CPython and IronPython. If you haven't already I'll open a bug when I'm back after

Re: [IronPython] C# and IronPython Interface.

2007-11-27 Thread Dino Viehland
You're going to want to do something like (only compiled w/ Outlook, so there may be some small compile errors here): PythonEngine pe = new PythonEngine(); EngineModule mod = pe.CreateModule(); pe.Execute(File.ReadAllText(ArithmeticOperations.py), mod); object func =

Re: [IronPython] Problems with 8-bit strings

2007-11-27 Thread Dino Viehland
To: Discussion of IronPython Subject: Re: [IronPython] Problems with 8-bit strings I didn't see a bug open, so I opened one: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14104 Thanks, Pat On Nov 24, 2007 3:54 PM, Dino Viehland [EMAIL PROTECTED] wrote: I think the construction w

Re: [IronPython] C# and IronPython Interface.

2007-11-28 Thread Dino Viehland
I missing something primitive in the Project Settings ? Regards -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Dienstag, 27. November 2007 18:32 To: Discussion of IronPython Subject: Re: [IronPython] C# and IronPython Interface

Re: [IronPython] Issues with Silly Module Tricks

2007-11-28 Thread Dino Viehland
Thanks for the bug report. There's actually a few issues here: types.ModuleType is actually SystemState (you can see this by doing import clr; clr.GetClrType(types.ModuleType)) ScriptModule (the type we use to represent module's currently) is currently sealed, so you can't

Re: [IronPython] Intefaces

2007-11-28 Thread Dino Viehland
I don't think there's any great documentation on this, but you can do interface.property.GetValue(instance) or interface.property.SetValue(instance, value). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Pardy Sent: Wednesday, November 28, 2007 4:02 PM To:

Re: [IronPython] Intefaces

2007-11-28 Thread Dino Viehland
Oh, now that I read the entire thread I see that that part was known :) We haven't actually gotten around to documenting this unfortunately. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Wednesday, November 28, 2007 4:08 PM To: Discussion of IronPython

Re: [IronPython] ipy.exe crashes after attempting import in VS 2008 command window

2007-12-03 Thread Dino Viehland
. 0__b03f5f7f11d50a3a\ISymWrapper.dll IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.1433 Copyright (c) Microsoft Corporation. All rights reserved. Any suggestions? Thanks, Dave On Nov 30, 2007 11:41 AM, Dino Viehland [EMAIL PROTECTED] wrote: This seems to work fine for me

[IronPython] Mailing list vs. Web discussions on CodePlex

2007-12-10 Thread Dino Viehland
Just thought I'd collect some opinions here. Internally we discussed this sometime ago but never made any decisions and haven't done much to push this forward... On CodePlex we have the ability to enable a discussion forum (which would look like

Re: [IronPython] Libraries: python and iron python

2007-12-10 Thread Dino Viehland
Given I mentioned it before, I may as well mention it again... :) We are still trying to get our ducks in order to include the std lib ourselves. Hopefully we'll have more to say soon. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Patrick

Re: [IronPython] -X:SaveAssemblies

2007-12-13 Thread Dino Viehland
In v2.0 we currently don't support re-running the assemblies that are saved to disk. There are a number of places where to simplify things we've taken a dependency of passing live objects from compilation through to runtime. Unfortunately I don't know when we'll be fixing that yet. You're

Re: [IronPython] IP 2.0 Hosting

2007-12-17 Thread Dino Viehland
Yes, the document is not yet up to date - we're currently working on implementing it so the next release will probably have some of it, and subsequence releases will have the whole thing. For giving objects to C# code you need to derive from the interface (and implement the methods). If you

Re: [IronPython] IP 2.0 Hosting

2007-12-17 Thread Dino Viehland
Subject: Re: [IronPython] IP 2.0 Hosting On Dec 17, 2007 9:48 AM, Dino Viehland [EMAIL PROTECTED] wrote: Yes, the document is not yet up to date - we're currently working on implementing it so the next release will probably have some of it, and subsequence releases will have the whole thing

Re: [IronPython] Mailing list vs. Web discussions on CodePlex

2007-12-17 Thread Dino Viehland
, Dino Viehland [EMAIL PROTECTED] wrote: Just thought I'd collect some opinions here. Internally we discussed this sometime ago but never made any decisions and haven't done much to push this forward... On CodePlex we have the ability to enable a discussion forum (which would look like http

Re: [IronPython] Mailing list vs. Web discussions on CodePlex

2007-12-17 Thread Dino Viehland
Subject: Re: [IronPython] Mailing list vs. Web discussions on CodePlex On 12/17/07, Dino Viehland [EMAIL PROTECTED] wrote: Thanks everyone for your feedback here - it's been a week, so I'm assuming no one new is going to chime in. Just to break your assumption... :) I think it's best to stick

[IronPython] IronPython 1.1.1 wish-list?

2007-12-17 Thread Dino Viehland
Are there any particular bugs you'd like to see fixed in IronPython 1.1.1? We're planning on updating the 1.1 release w/ a targeted set of bug fixes. Unfortunately we've started to use the CodePlex bug list to track primarily 2.0 bugs. We can still use this to find the highest ranked bugs

Re: [IronPython] IronPython 1.1.1 wish-list?

2007-12-28 Thread Dino Viehland
This sounds like a bug and could quite possibly be fixed for 1.1.1 (it's hard to brake things by not dereferncing a null pointer :) ). Could you re-run w/ the -X:ExceptionDetail command line option and give us that stack trace? From: [EMAIL PROTECTED]

Re: [IronPython] IronPython 1.1.1 wish-list?

2008-01-02 Thread Dino Viehland
This is easy enough to fix for 1.1.1. The issue here (I think) is that somewhere in your sys.path you have a file called Oracle.exe that contains exactly 1 type (which, not surprisingly, is not a subtype of CompiledModule). Apparently we can create an instance of that type but because it's

Re: [IronPython] Difference in 1.1 and 2.0 with Dialog Result

2008-01-02 Thread Dino Viehland
I think this is bug - .NET conventions say that enum's should generally have a zero value (FxCop CA1008 :)). Because of that we can safely define __nonzero__ on enums and have that return true/false based upon if the value is zero/non-zero. Otherwise Python says all expressions otherwise

Re: [IronPython] IronPython 1.1.1 wish-list?

2008-01-02 Thread Dino Viehland
. Regards, 2007/12/18, Dino Viehland [EMAIL PROTECTED]: Are there any particular bugs you'd like to see fixed in IronPython 1.1.1? We're planning on updating the 1.1 release w/ a targeted set of bug fixes. Unfortunately we've started to use the CodePlex bug list to track primarily 2.0 bugs

Re: [IronPython] [python] Re: IronPython 1.1.1 wish-list?

2008-01-02 Thread Dino Viehland
-ironpython.com/2007-February/004500.html is fixed or somebody shows me a good example how to inherit file class in IronPython 1.1, I will be happy. 2nd, please provide quit() function, which eases my interactive IronPython session. Regards, 2007/12/18, Dino Viehland [EMAIL PROTECTED

Re: [IronPython] IronPython 1.1.1 wish-list?

2008-01-02 Thread Dino Viehland
interactive IronPython session. Regards, 2007/12/18, Dino Viehland [EMAIL PROTECTED]: Are there any particular bugs you'd like to see fixed in IronPython 1.1.1? We're planning on updating the 1.1 release w/ a targeted set of bug fixes. Unfortunately we've started to use the CodePlex bug

Re: [IronPython] Deleting a module from the host

2008-01-04 Thread Dino Viehland
Unfortunately the answer is it depends, and it's probably not supported in Alpha 7 :( The depends part is how the module got there and it all revolves around the design we've come up with for the hosting of multiple languages. We have a global object per ScriptRuntime which is (currently) a

Re: [IronPython] IronPython 1.1.1 wish-list?

2008-01-04 Thread Dino Viehland
Yep, I think this can be fixed. I've got a tentative fix and it looks like it works and doesn't break anything. Thanks for bringing attention to this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil Dworakowski Sent: Friday, January 04, 2008

Re: [IronPython] Deleting a module from the host

2008-01-04 Thread Dino Viehland
good to have it tracked. Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Friday, January 04, 2008 3:36 PM To: Discussion of IronPython Subject: Re: [IronPython] Deleting a module from the host On Jan 4, 2008 3:26 PM, Dino

Re: [IronPython] IronPython 1.1.1 wish-list?

2008-01-07 Thread Dino Viehland
We hope to have an RC sometime soon and the final release will probably be later this month or early February. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil Dworakowski Sent: Saturday, January 05, 2008 2:53 PM To: Discussion of IronPython

Re: [IronPython] Where to submit project related to IronPython?

2008-01-12 Thread Dino Viehland
Currently IronPython is not directly accepting contributions but FePy is the IronPython Community Edition and does except contributions. Seo Sanghyeon, who also maintains FePy, also has (in the past?) worked on a ctypes implementation to enable similar functionality as well. My best

Re: [IronPython] No import this?

2008-01-14 Thread Dino Viehland
We just don't include the standard library by default (which is where this comes from). If you set IRONPYTHONPATH=C:\Python25\Lib (or wherever your Python lib dir is) or you start IronPython from the lib dir it'll work. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David

Re: [IronPython] No import this?

2008-01-14 Thread Dino Viehland
this? David Seruyange wrote: Does IronPython strip the easter egg? 2008/1/15, Dino Viehland [EMAIL PROTECTED]: We just don't include the standard library by default (which is where this comes from). If you set IRONPYTHONPATH=C:\Python25\Lib (or wherever your Python lib dir is) or you start

Re: [IronPython] Reloading Modules

2008-01-15 Thread Dino Viehland
You could always make a 4th module which reloads the 1st three :) The other option would be to just put them all in one module - that's certainly not unprecedented and if you're not planning on reusing the components/modules individually might make the most sense. From: [EMAIL PROTECTED]

Re: [IronPython] Roadmap for IronPython 2.0

2008-01-15 Thread Dino Viehland
We don't really have a document like this but the general goal is to ship IronPython 2.0 by the end of the year. The goals for IronPython generally include CPython 2.5 compatibility and fully running on top of the DLR. And of course we've already seen numerous improvements from IronPython 1.1

Re: [IronPython] Roadmap for IronPython 2.0

2008-01-15 Thread Dino Viehland
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Tuesday, January 15, 2008 2:16 PM To: Discussion of IronPython Subject: Re: [IronPython] Roadmap for IronPython 2.0 We don't really have a document like this but the general goal is to ship IronPython 2.0

Re: [IronPython] invoking new form

2008-01-18 Thread Dino Viehland
What happens when you do this? Is an exception thrown? Does it just hang waiting w/ nothing happening? Also, are you doing this from the console or from modules which just get executed stand alone (e.g. ipy foo.py)? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vadim Khaskel

Re: [IronPython] [python] Re: The __hello__ Module

2008-01-21 Thread Dino Viehland
PROTECTED] On Behalf Of Michael Foord Sent: Monday, January 21, 2008 4:58 AM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: The __hello__ Module Dino Viehland wrote: I was planning on focusing on bugs this week so I guess I'll kick it off with the silly bugs: this one

Re: [IronPython] WinForms UserComponent binding a IronPythonConsole

2008-01-23 Thread Dino Viehland
Generally speaking you want to do 2 things: 1. Wire up std out / std err to a stream you can send to your window. You can do this via PythonEngine.SetStandardOutput/PythonEngine.SetStandardInput. You could also wire up std-in but that'll be less important (it's only going to matter if

Re: [IronPython] IronPython and polymorphism? Help with interfaces

2008-01-23 Thread Dino Viehland
It's a feature, explicit interfaces require an explicit call :). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miha Valencic Sent: Wednesday, January 23, 2008 12:18 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython and polymorphism? Help with interfaces

Re: [IronPython] IronPython and polymorphism? Help with interfaces

2008-01-23 Thread Dino Viehland
and polymorphism? Help with interfaces Thanks for the explanation. The docs could/should mention that... :) I guess we're not used, because it works in C#, so it should double-work in Ipy. You know, inferred types and all... :)) rgds, Miha. On Jan 23, 2008 9:21 PM, Dino Viehland [EMAIL PROTECTED

Re: [IronPython] [python] [IronPythonStudio] NamespaceClassesandAssembly Files

2008-01-30 Thread Dino Viehland
Michael's probably at least partially correct about this. The other, evil, side of using CodeDom is that we might be using the static type compiler which primarily exists for supporting ASP.NET. There we're not only using CodeDom but we're also required to generate a .NET type that ASP.NET

Re: [IronPython] Template argument type inference

2008-02-04 Thread Dino Viehland
A bug on the error message would be great. We haven't talked about inferring template arguments in a long time but it certainly does seem like it could be possible in some cases in the future. If you want to file a feature request for it that'd be great too. From: [EMAIL PROTECTED]

Re: [IronPython] PyYAML on IronPython

2008-02-04 Thread Dino Viehland
This is a great suggestion - coming up in March we're planning on spending some time looking at app compat so this would be a good time for us to do this. It also looks like it's under a license that would allow us to look at it. It's great to see that we've already fixed 1 problem from 1.1

Re: [IronPython] Assemblies loaded by default

2008-02-04 Thread Dino Viehland
Just FYI but this change reflects a change to the underlying DLR hosting APIs. Under the new hosting APIs the loaded assemblies and there namespaces are reflected through ScriptEnvironment.Globals ScriptScope (and the Python importer now looks there for things to import). It used to be that

Re: [IronPython] Decorators on classes

2008-02-04 Thread Dino Viehland
FYI IP 2.0 is tracking 2.5 and we have the big pieces in place plus many small pieces (although there's more to go). In 1.1 we had -X:Python25 which enabled selective 2.5 features and we could conceptually do the same sort of thing for 2.0 so that it includes one or two 2.6 features such as

Re: [IronPython] Decorators on classes

2008-02-04 Thread Dino Viehland
PROTECTED] On Behalf Of Michael Foord Sent: Monday, February 04, 2008 2:03 PM To: Discussion of IronPython Subject: Re: [IronPython] Decorators on classes Dino Viehland wrote: FYI IP 2.0 is tracking 2.5 and we have the big pieces in place plus many small pieces (although there's more to go). In 1.1 we

Re: [IronPython] Decorators on classes

2008-02-04 Thread Dino Viehland
Dino, That sounds *great*, and is something really needed by IronPython. How long do you think it will take you to implement? 0.5 wink Michael http://www.manning.com/foord Dino Viehland wrote: Ok, maybe it's a little optimistic or maybe it needs a couple of hooks exposed, but it's not too crazy

Re: [IronPython] Decorators on classes

2008-02-04 Thread Dino Viehland
on classes On Feb 4, 2008 2:27 PM, Dino Viehland [EMAIL PROTECTED] wrote: As other people have pointed out decorators are a runtime concept and I don't think we get to change that. So consider a class decorator You could theoretically have a slightly alternate parsing mode that recognizes

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Dino Viehland
Data binding isn't working for you? We have support for this via CustomTypeDescriptors which describe the Python objects and we have some test cases to verify it works. Note it was broken before 1.1.1 although it's been working in 2.0 for a little while now. For example: import clr

Re: [IronPython] Value can not be null

2008-02-06 Thread Dino Viehland
Is this using ASP.NET futures? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Praveen Kumar Sent: Wednesday, February 06, 2008 2:45 AM To: users@lists.ironpython.com Subject: [IronPython] Value can not be null Hi I am new of ironPython for VisualStudio.net 2005 Description of

Re: [IronPython] Delegates

2008-02-06 Thread Dino Viehland
You need to match the signature of Application.Idle. But once you have the right signature += should work. It looks like Idle is just an EventHandler so: def MyIdle(self, sender, eventArgs): self.Invalidate() Application.Idle += self.MyIdle Should work. And to make it more

Re: [IronPython] Exporting Python code as an assembly

2008-02-06 Thread Dino Viehland
that it cannot find the constructor for my type, whether or not I have defined it. Is this also to be expected or not? Thank you, Rocco Pigneri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Tuesday, February 05, 2008 4:55 PM

Re: [IronPython] Exporting Python code as an assembly

2008-02-07 Thread Dino Viehland
an idea of what stages it has left to go through (how many more alpha stages, beta releases, RC's)? I couldn't find this on CodePlex. Thanks, Rocco From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Wednesday, February 06, 2008 3:54

Re: [IronPython] HybridMapping is full Error

2008-02-07 Thread Dino Viehland
It looks like there's an internal limit that prevents us from ever having more than 4096 PythonFile objects in existance. Is it possible that you have that many file objects in existence that aren't getting freed? Also just closing them won't be enough, they actually have to get collected by

Re: [IronPython] Please help me out its very urgent

2008-02-12 Thread Dino Viehland
urgent Dino Viehland wrote: Can you try using the library just from the command line and see what the result is? You might want to try running w/ -X:ExceptionDetail to see where the exception is actually coming from. I tried and was able to open a XLS saved in Office 2003 and earlier format w/o

Re: [IronPython] Please help me out its very urgent

2008-02-12 Thread Dino Viehland
Can you try using the library just from the command line and see what the result is? You might want to try running w/ -X:ExceptionDetail to see where the exception is actually coming from. I tried and was able to open a XLS saved in Office 2003 and earlier format w/o any problems using this

Re: [IronPython] Help with Ops.GetAttr

2008-02-12 Thread Dino Viehland
You could use Ops.TryGetAttr which doesn't take a context (and flows the default context in for you). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Turbett Sent: Tuesday, February 12, 2008 5:30 AM To: users@lists.ironpython.com Subject:

Re: [IronPython] v1.1.1: Problem loading assembly, I think

2008-02-13 Thread Dino Viehland
Does this simple case work for you? It works for me on 1.0, 1.1, and 1.1.1: Test.cs: using System; using IronPython.Hosting; public class Foo { public static void Main(string[]args) { PythonEngine pe = new PythonEngine(); EngineModule module = pe.CreateModule();

Re: [IronPython] Import xlrd

2008-02-13 Thread Dino Viehland
It seems like the simple answer is no - that version of IronPython is too old and has a bug which prevents xlrd from working. The ASP.NET Futures package may have a recent enough version that it works. Using ASP.NET futures it should be as simple as doing a sys.path.append('location_of_xlrd')

Re: [IronPython] Parsing Stack Traces

2008-02-13 Thread Dino Viehland
Are you using the Python code dom provider from 1.x or directly interacting w/ the hosting APIs? I think you should get a list of errors like you'd normally get w/ CodeDom - although it'll probably only include 1 error (but it should have line info). Otherwise in 1.x you can subclass the

Re: [IronPython] Import xlrd

2008-02-13 Thread Dino Viehland
Yeah, adding Lib to sys.path will definitely also be necessary. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Machin Sent: Wednesday, February 13, 2008 12:26 PM To: Discussion of IronPython Subject: Re: [IronPython] Import xlrd Dino Viehland wrote

Re: [IronPython] Parsing Stack Traces

2008-02-13 Thread Dino Viehland
. thanks slide On Feb 13, 2008 2:23 PM, Dino Viehland [EMAIL PROTECTED] wrote: Are you using the Python code dom provider from 1.x or directly interacting w/ the hosting APIs? I think you should get a list of errors like you'd normally get w/ CodeDom - although it'll probably only include 1

Re: [IronPython] Save Assemblies without Running Script

2008-02-15 Thread Dino Viehland
The pyc sample available here: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=47 should enable you to do that. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco Sent: Friday, February 15, 2008 9:57 AM To: Discussion of IronPython Subject:

Re: [IronPython] urllib.urlretrieve with IronPython 2a8

2008-02-18 Thread Dino Viehland
Certainly sounds like a bug - did this work before alpha 8? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Sunday, February 17, 2008 6:27 AM To: Discussion of IronPython Subject: [IronPython] urllib.urlretrieve with IronPython 2a8

Re: [IronPython] urllib.urlretrieve with IronPython 2a8

2008-02-18 Thread Dino Viehland
/WorkItem/View.aspx?WorkItemId=10518 The item was marked as a duplicate of 10825, which has been marked as resolved in 1.1.1. However, I am able to reproduce the problem with 1.1, 1.1.1 and alpha 8. On Feb 18, 2008 10:54 AM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Certainly

Re: [IronPython] urllib.urlretrieve with IronPython 2a8

2008-02-18 Thread Dino Viehland
This is a great analysis - based upon this I think it'll be pretty easy to fix this. I'll take a look at it tomorrow and respond back. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Monday, February 18, 2008 4:19 PM To:

Re: [IronPython] Overriding __iter__ in dict subclass

2008-02-19 Thread Dino Viehland
This one's interesting. I've got a fix for this for 2.0 on my machine - I've been looking at some other tweaks to dictionaries so we can cleanup our type system (funny how those two are related) and this fits in nicely with that. So it should be in the next release. Thanks for the report!

Re: [IronPython] Slow Performance of CPython libs?

2008-02-20 Thread Dino Viehland
We've actually had this issue reported once before a long time ago - it's a very low CodePlex ID - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=651 We haven't had a chance to investigate the end-to-end scenario. If someone could come up with a smaller simpler repro that'd

[IronPython] Our team is growing!

2008-02-20 Thread Dino Viehland
Hi everyone! I just wanted to let you know that our team is growing and we're looking to hire some new people to work on IronPython, IronRuby, and F#. We have 6 new positions we're trying to fill. IronPython developer position:

Re: [IronPython] Bug Query - dict(...) broken on new style class dictionaries

2008-02-20 Thread Dino Viehland
Sure, I can fix that one at the same time I'm doing the other dictionary stuff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davy Mitchell Sent: Wednesday, February 20, 2008 1:22 PM To: Discussion of IronPython Subject: [IronPython] Bug Query -

Re: [IronPython] Slow Performance of CPython libs?

2008-02-21 Thread Dino Viehland
Throwing exceptions is a whole lot slower. But for what it's worth the cost of try/except though is much cheaper on IronPython if no exception is thrown. Here's the exception results on PyBench. Note these are actually results I happen to have on my machine from a while ago - but nothing's

Re: [IronPython] Slow Performance of CPython libs?

2008-02-21 Thread Dino Viehland
regexps (searched for re.compile). I think your suggestion is very relevant in this case. It makes sense to replicate the compile once use many behavior that is commonly used with regexp. -Birsch On Thu, Feb 21, 2008 at 7:30 PM, Dino Viehland [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote

Re: [IronPython] Slow Performance of CPython libs?

2008-02-22 Thread Dino Viehland
Michael Foord http://www.manning.com/foord On Thu, Feb 21, 2008 at 8:48 PM, Dino Viehland [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: After Birsh's last comment that they're calling compile I was thinking we might be doing something really stupid. Turns out that we

Re: [IronPython] Slow Performance of CPython libs?

2008-02-22 Thread Dino Viehland
: [IronPython] Slow Performance of CPython libs? Dino - do you want me to register a workitem? Also, if I wanted to patch v1.1.1, where should I start? On Thu, Feb 21, 2008 at 8:48 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: After Birsh's last comment that they're calling compile I

Re: [IronPython] How to import python folders as modules

2008-02-26 Thread Dino Viehland
As long as there's an __init__.py we should recognize it as a module. If by xmpp you're referring to PyXMPP at http://pyxmpp.jajcus.net/ then it looks like it relies upon a C Extension Library for libxml2. IronPython doesn't support C Extension libraries - although there is an external

Re: [IronPython] Exporting Python code as an assembly

2008-02-26 Thread Dino Viehland
What's MakeModule.py? Normally in v1.x if you do -X:SaveAssemblies or you use the pyc sample to compile a .py file you'll just be able to import it (like a .pyc file in Cpython). AddReference is used for normal .NET assemblies. But from the exception this looks like 2.0 - and I don't know how

Re: [IronPython] Hashing in IronPython

2008-02-28 Thread Dino Viehland
I'll fix this for the next release. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Thursday, February 28, 2008 2:04 PM To: Discussion of IronPython Subject: [IronPython] Hashing in IronPython At Resolver Systems we are seeing

Re: [IronPython] ipy 1.1.1crash at startup

2008-02-28 Thread Dino Viehland
Are you possibly running it off of a network share? .NET lowers the permissions for managed code when running from a network share. Are other managed apps running alright? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathew Yeates Sent: Thursday,

Re: [IronPython] Code generation questions

2008-02-29 Thread Dino Viehland
In the code you have below we should generate everything as collectible code. As long as you hold onto the delegate to Run you'll keep all of the code alive. Calling it after the engine is disposed will result in undefined behavior. And in this case Run will be generated as a dynamic method

Re: [IronPython] Integration: now I am totally confused

2008-03-03 Thread Dino Viehland
For integrated mode you can use the VS SDK sample of IronPython which IPS is based off of. But it's more onerous as you need to build the sample it's not just something you download and install. I do agree though that this is an alpha product - after all at its core is just a sample. While

Re: [IronPython] Using callback function

2008-03-04 Thread Dino Viehland
Calling it isn't really the interesting part, the interesting part is what arguments do you pass to it. To call it you just need to import the class that the function is defined in. You can do that using: import clr clr.AddReference('VBAssemblyName') from VBNamespaceName import * where

Re: [IronPython] how to use IronPython in Silverlight 2

2008-03-06 Thread Dino Viehland
You'll need to download the Silverlight 2 SDK. After installing that you'll get all the necessary components installed into something like C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Client. Also installed is an extremely useful tool called Chiron which you'll find somewhere

Re: [IronPython] Crash

2008-03-07 Thread Dino Viehland
One thing that might help is running w/ -X:ExceptionDetail to get the full .NET stack trace. I also suspect this exception must be coming from the finalizer thread or from a newly created thread. Is your app multi-threaded? If you create threads w/ Python's thread module then your threads

Re: [IronPython] how to use IronPython in Silverlight 2

2008-03-07 Thread Dino Viehland
x:Class=System.Windows.Controls.UserControl xmlns=http://schemas.microsoft.com/client/2007; xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml; Grid x:Name=grid Background=White TextBlock x:Name=message FontSize=30 / /Grid /UserControl On Fri, Mar 7, 2008 at 11:55 AM, Dino

Re: [IronPython] vs 2008

2008-03-07 Thread Dino Viehland
VS 2008 doesn't ship with support for IronPython. There was a recent thread here about VS integration - check out http://search.live.com/results.aspx?q=%22integration%3A+now+i+am+totally+confused%22mkt=en-usscope=FORM=LIVSOP for more information. As for XP vs. Vista it shouldn't make much of

Re: [IronPython] Silverlight 2 Controls

2008-03-09 Thread Dino Viehland
: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Michael Foord [EMAIL PROTECTED] Sent: Sunday, March 09, 2008 1:09 PM To: Discussion of IronPython Subject: Re: [IronPython] Silverlight 2 Controls Dino Viehland wrote: This comes back to the manifest mentioned in the previous question. You can

Re: [IronPython] Silverlight 2 Controls

2008-03-10 Thread Dino Viehland
better. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Sunday, March 09, 2008 5:22 PM To: Discussion of IronPython Subject: Re: [IronPython] Silverlight 2 Controls Dino Viehland wrote: Importing I haven't actually tried, I've only used

Re: [IronPython] Silverlight 2 Controls

2008-03-10 Thread Dino Viehland
- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Monday, March 10, 2008 8:52 AM To: Discussion of IronPython Subject: Re: [IronPython] Silverlight 2 Controls This is a horrible workaround but I think it should work. You can create the object in XAML, then get

Re: [IronPython] Silverlight 2 Controls

2008-03-10 Thread Dino Viehland
your help. Dino Viehland wrote: Two more possibilities which are little less ugly: 1. AddReference to the fully qualified type name including strong name I'm sorry to be dense - can you remind me how to get this strong name? I now have Visual Studio 2008 and the Silverlight tools

Re: [IronPython] how to use IronPython in Silverlight 2

2008-03-10 Thread Dino Viehland
://dynamicsilverlight.net Suppose you don't want to load a XAML file - how do you do that (but say set a 'Canvas' instance you have created programatically) ? Michael ~Jimmy *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Dino Viehland *Sent:* Friday, March 07, 2008 11:25 AM

Re: [IronPython] compile bug

2008-03-11 Thread Dino Viehland
I'll take a look and get back to you. Recompiling the dynamic silverlight bits might be a bit of a pain though (there's a bunch of internal process required to ship out binaries). One option might be to use the Parser class directly but I don't know if that'll help you too much.

Re: [IronPython] __dict__ of exception instances

2008-03-11 Thread Dino Viehland
Interestingly it happens for any exception class with any property: BaseException().abc OperationFailed object at 0x002C This is somehow related to the new-style exception support for 2.5 compatibility. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

<    1   2   3   4   5   6   7   8   9   10   >