Re: [IronPython] How to place static class in script name space
We specifically allow from staticclass import * because we treat a static class as if it were like a module. So you could simply run that line of code in the scope on behalf of the user. Otherwise you'll need to re-create getting the dynamic members and then setting them in the scope. Then you can use PythonOps.GetAttrNames to get the defined names and finally PythonOps.GetBoundAttr to get the actual members which you'll then set in the scope. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Tom Unger Sent: Monday, June 13, 2011 10:16 AM To: 'users@lists.ironpython.com' Subject: [IronPython] How to place static class in script name space I am using IronPython for scripting an application. To make writing scripts easier I want to place several objects in the script name space so they can be easily used. I got stuck with how to place a reference to a static object, App, in the name space. This is probably a simple operation and just don't know what it is. 1. Python import works: from AppFrame import App gives the script access to the static fields and methods on App. But I want to eliminate the need for each script to do that import by setting up the scope with: scriptScope.SetVariable(App, App); This does not compile because App is a static class, not an object. How does my hosing application place a reference to the static class in the script's scope such that it can be used as if it was imported? Thanks Tom Seattle ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Seattle IronPython Meetup
I'd be up for it - personally I'd prefer downtown but I could drive to the east side if that's preferable. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Friday, June 10, 2011 10:43 AM To: Discussion of IronPython Subject: [IronPython] Seattle IronPython Meetup Hi all, Is anyone in the Seattle area interested in an IronPython meetup, or even a sprint? Anybody fancy a hands-on crash course in how IronPython works? Let me know! If enough people are interested, I'll work something out (probably for the coming week). I'm new to the area, so if anyone has any suggestions on where to meet, feel free. I'd prefer to avoid downtown Seattle, unless that works for everyone else. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Dispatcher Problem
AndyF wrote: Hi Chaps I have attempted to purloin some of the code shipped with IP in Action and, following issues, I have even gone to the lengths of reading the book! I am getting the error 'expect Delegate, got Function' when I use the following code. FYI I am passing in a reference to a WPF textBox so I should have a dispatcher on my UI element I have removed all of the threading pipe reading stuff just to leave 'test' code: import System import System.IO import Avacta.Optim.Server.WebServices import Avacta.Optim.Server.DataModel import sys import clr import time from System import Console from System.Threading import Thread, ThreadStart def SetDispatcher(ui_element): global dispatcher # needed else Exception: 'NoneType' object has no attribute 'BeginInvoke' dispatcher = ui_element.Dispatcher def Dispatch(function, *args): dispatcher.BeginInvoke(lambda *_: function(*args)) def GetDispatchFunction(function): return lambda *args: Dispatch(function, *args) class ListOutput: def __init__(self, textbox): self.textbox = textbox def write(self, string): Dispatch(self.addText, string) # error: expect Delegate, got Function # self.addText(string) # ok works fine w-w/o dispatcher stuff def addText(self, string): textbox.AppendText(string) if textbox != None: listout = ListOutput(textbox) sys.stdout = listout SetDispatcher(textbox) print Define running #running = True Thread.Sleep(0) time.sleep(2) print Start The Comms Thread... #comms_t = Thread(ThreadStart(run_comms)) #comms_t.Start() Thread.Sleep(0) time.sleep(2) Any clues would be greatly appreciated! The WPF invocation functions just take a type which is typed to Delegate instead of a type of a specific delegate. Therefore we don't know what type of delegate to create for you automatically. Instead you can convert the Python function into a delegate by calling the delegate type directly, e.g.: dispatcher.BeginInvoke(System.Action(lambda *_: function(*args))) or you can use another delegate type (e.g. System.Action[object]) with the appropriate signature you need. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Moving forward on 2.7.1
I have a few bugs I wanted to get fixed so I'll actually start working on those :) -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Tuesday, May 31, 2011 2:27 PM To: Discussion of IronPython Subject: [IronPython] Moving forward on 2.7.1 Hi all, I think it's about time to get 2.7.1 shipped. I don't have a timeline in mind, but I'd like it out by the end of June. There's a few new modules and some bug fixes as well, but I'd like to see some more bugs fixed. If there's anything in 2.7.0 that's blocking you and not already fixed, post it here and I'll adjust the priorities. I'm also going to update the stdlib to match CPython 2.7.1. After 2.7.1 I doubt I will be putting much effort into the 2.7 branch (3.0 is just more interesting), so if there's continued interest in future 2.7 releases, someone else will probably have to step up. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Issue reading an InternalDictionary, Overloads fails with 2147483647 arguments bug.
I think your .Overloads needs to be: .Overloads[Action[Avatar]] Or maybe: .Overloads[InternalDictionary[UInt32, Avatar], Avatar] -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Intertricity Sent: Monday, May 23, 2011 12:53 AM To: users@lists.ironpython.com Subject: [IronPython] Issue reading an InternalDictionary, Overloads fails with 2147483647 arguments bug. I'm trying to read the keys of an InternalDictionary of a .Net dll I'm loading into IronPython. The library is libomv. I've googled for several hours now, and I can't seem to find a clear way to get around this. Here's the doc string on the ForEach I'm trying to use, I've referenced temp to the object in question to keep things short while I'm at the interpreter. print temp.ForEach.__doc__ ForEach(self: InternalDictionary[UInt32, Avatar], action: Action[KeyValuePair[UI nt32, Avatar]]) Perform an on each key of an action: to perform ForEach(self: InternalDictionary[UInt32, Avatar], action: Action[UInt32]) Perform an on each key of an action: to perform ForEach(self: InternalDictionary[UInt32, Avatar], action: Action[Avatar]) Perform an on each key of an action: to perform And here's what happens when I try to use the Overloads method to solve overloading: temp.ForEach.Overloads[Avatar](lambda x: x.FirstName) Traceback (most recent call last): File stdin, line 1, in module TypeError: ForEach() takes at least 2147483647 arguments (1 given) Anyone have a clue how to get this to work? I'm not too familiar with .Net, and got into it through IronPython, so I'm not sure what I could be doing wrong. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Issue reading an InternalDictionary, Overloads fails with 2147483647 arguments bug.
Sounds like Action[Avatar] is working then - it's just that the lambda isn't doing anything that you can see. If you change it to: l = [] temp.ForEach.Overloads[Action[Avatar]](lambda x: l.append(x.FirstName)) Then l should be populated with all the first names you're called with. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Intertricity Sent: Monday, May 23, 2011 5:55 PM To: users@lists.ironpython.com Subject: Re: [IronPython] Issue reading an InternalDictionary, Overloads fails with 2147483647 arguments bug. Still get the same problem :\ although the Action[Avatar] one returns a NoneType instead of complaining about an insane number of arguments. # temp.ForEach.Overloads[InternalDictionary[UInt32,Avatar],Avatar](lam bda x: x .FirstName) Traceback (most recent call last): File stdin, line 1, in module TypeError: ForEach() takes at least 2147483647 arguments (1 given) # # temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName) dir(temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName)) ['Equals', 'GetHashCode', 'GetType', 'MemberwiseClone', 'ReferenceEquals', 'ToSt ring', '__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '_ _setattr__', '__sizeof__', '__str__', '__subclasshook__'] type(temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName)) type 'NoneType' # On May 23, 12:56 pm, Dino Viehland di...@microsoft.com wrote: I think your .Overloads needs to be: .Overloads[Action[Avatar]] Or maybe: .Overloads[InternalDictionary[UInt32, Avatar], Avatar] -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Intertricity Sent: Monday, May 23, 2011 12:53 AM To: us...@lists.ironpython.com Subject: [IronPython] Issue reading an InternalDictionary, Overloads fails with 2147483647 arguments bug. I'm trying to read the keys of an InternalDictionary of a .Net dll I'm loading into IronPython. The library is libomv. I've googled for several hours now, and I can't seem to find a clear way to get around this. Here's the doc string on the ForEach I'm trying to use, I've referenced temp to the object in question to keep things short while I'm at the interpreter. print temp.ForEach.__doc__ ForEach(self: InternalDictionary[UInt32, Avatar], action: Action[KeyValuePair[UI nt32, Avatar]]) Perform an on each key of an action: to perform ForEach(self: InternalDictionary[UInt32, Avatar], action: Action[UInt32]) Perform an on each key of an action: to perform ForEach(self: InternalDictionary[UInt32, Avatar], action: Action[Avatar]) Perform an on each key of an action: to perform And here's what happens when I try to use the Overloads method to solve overloading: temp.ForEach.Overloads[Avatar](lambda x: x.FirstName) Traceback (most recent call last): File stdin, line 1, in module TypeError: ForEach() takes at least 2147483647 arguments (1 given) Anyone have a clue how to get this to work? I'm not too familiar with .Net, and got into it through IronPython, so I'm not sure what I could be doing wrong. ___ Users mailing list us...@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Us...@lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/use rs-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] socket, _socket, and socket.py
There is actually more of a story to this though - Cpython's socket.py relies upon reference counting for handling dup. See this comment from socket.py: # Wrapper around platform socket objects. This implements # a platform-independent dup() functionality. The # implementation currently relies on reference counting # to close the underlying socket object. class _socketobject(object): Because IronPython doesn't have a reference counting GC we cannot simply use socket.py. So someone would need to patch both IronPython and socket.py so this would work. For the record it looks like Jython also has a custom socket.py. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Tuesday, May 17, 2011 2:59 PM To: Discussion of IronPython Subject: Re: [IronPython] socket, _socket, and socket.py Originally, we weren't allowed to redistribute the Python standard library with IronPython. So it made sense to implement the socket module directly. When IronPython started shipping the standard lib, it could have been changed, but never was. I think it makes sense to follow the CPython pattern. On Tue, May 17, 2011 at 2:33 PM, Zachary Gramana zgram...@pottsconsultinggroup.commailto:zgram...@pottsconsultinggroup.com wrote: Hi: I've been working on adapting Mercurial to run on IronPython 2.7, and ran into http://ironpython.codeplex.com/workitem/26852 which has stopped me from getting `hg clone` working over SSL. I noticed that for the ssl module, the IPY team mirrored the CPython pattern of placing the platform-specific code in the _ssl compiled module, and then wrapped the platform-independent around it in ssl.py (almost entirely shared with CPython 2.7). The socket module, however, does not. I admit I have a limited understanding of the code, but at first blush, it appears that adopting the _socket.cs/socket.py isn't out-of-the-question. Is there a story behind this, or am I missing something obvious to everyone else? The immediate benefit would be getting a free implementation of _socketobject, _dummy, and dup(); it also improves DRY conformance, and would help to limit behavioral differences with respect to other implementations. Thanks! Regards, Zack P.S. Any advice on tackling issue #26852 is very warmly appreciated. ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] socket, _socket, and socket.py
I think manual ref count tracking (like _make_filerefs) + defining __del__ on the socket objects would fix it. But there may be issues w/ that - when we first encountered this I pinged python-dev and I recall Guido saying that there were problems getting anything else working on Windows. So there may be some oddity that prevents this from working but I don't know what that is off the top of my head. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Zachary Gramana Sent: Tuesday, May 17, 2011 3:38 PM To: Discussion of IronPython Subject: Re: [IronPython] socket, _socket, and socket.py I noticed this, with a little disappointment. I also noticed that they implemented a sort of ersatz/platform agnostic reference tracking system in ssl.py. Seeing the _makefile_refs system got me thinking about the whole ssl.py/_ssl.pyd paradigm and sockets.cs, since I remembered you tackled this issue once before (or one very similar to it: http://lists.ironpython.com/pipermail/users-ironpython.com/2007- May/004946.html). Perhaps something along the lines of _makefile_refs and GC.SuppressFinalize might get us closer? On 5/17/2011 6:06 PM, Dino Viehland wrote: There is actually more of a story to this though - Cpython's socket.py relies upon reference counting for handling dup. See this comment from socket.py: # Wrapper around platform socket objects. This implements # a platform-independent dup() functionality. The # implementation currently relies on reference counting # to close the underlying socket object. class _socketobject(object): Because IronPython doesn't have a reference counting GC we cannot simply use socket.py. So someone would need to patch both IronPython and socket.py so this would work. For the record it looks like Jython also has a custom socket.py. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] clr.ImportExtensions are not available outside module ?
Daniel wrote:
Just as Dave Wald, I have also trying out the ImportExtensions methods
which I personally find very useful, thank you for implementing. Everything is
working fine on using 2.7 (and .net 4), but extension methods loaded by one
module seem not available on another...
This is by design. It works similar to how import clr only effects the
current module
and how extension methods work in C# where they are scoped by file. So if you
want extension methods available in a file you'll need to import them in that
file.
If they were globally scoped it would be easy for one module to break another by
bringing in the 'wrong' extension methods.
I will stick to Dave's code exmaple:
import clr
clr.AddReference(System.Core)
import System
from System import Linq
clr.ImportExtensions(Linq)
class Product(object):
def __init__(self, cat, id, qtyOnHand ):
self.Cat = cat
self.ID = id
self.QtyOnHand = qtyOnHand
self.Q = self.QtyOnHand
If I put this into a file, lets say test.py and now use the module on the
command line:
import test
products = [test.Product('food', i, 10) for i in range(3)]
products.Where
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'list' object has no attribute 'Where'
The linq extensions are not available. I have to re-import them:
test.clr.ImportExtensions(test.Linq)
products.Where
built-in method Where of list object at 0x002B
Is this a current limitation, or should I be doing things differently ?
Any help appreciated.
Greetings,
Daniel
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] clr.ImportExtensions are not available outside module ?
Daniel wrote:
Ok.
I am not sure what you mean by similar to import clr, though.
It's similar to import clr in that importing clr not only gives you the clr
module
but also makes .NET members available to the module which imported clr.
For example before doing import clr calling .ToString() on an object will
raise an AttributeError but afterwards it will call the .NET ToString method.
If you'd like to provide a set of globally available extension methods
specifically
for IronPython users you could use ExtensionTypeAttribute (which is defined
in the DLR outer layer). IronPython will look for that attribute declared on an
assembly. The attribute will give a type to extend and a type to pull the
extension
methods from. All you need to do is load the assembly into the script runtime
either via the hosting APIs or clr.AddReference. This was the mechanism we
originally used to add the Python methods to the .NET types like string (we now
hard code the types for Python rather reflecting over the types at startup, but
the mechanism remains for backwards compat).
Because in my example, clr is available from outside test; its just named
test.clr...
Let me give you another example which is closer on how I ran into this...
Lets say you have in C#:
--- iron.Example.cs
namespace iron
{
public class Example
{
public Example()
{
}
public int foo()
{
return 1;
}
}
public static class ExampleExtension
{
public static int bar(this Example example)
{
return example.foo() + 1;
}
}
}
--- EOF
Then I define an example.py to wrap this up:
--- test.py
import clr
clr.AddReference(iron)
import iron
clr.ImportExtensions(iron.ExampleExtension)
# lets use this just to test it out
e = iron.Example()
print e.foo()
print e.bar()
--- EOF
now on my command line I get
import example
1
2
ex = example.iron.Example()
ex.foo()
1
ex.bar()
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'Example' object has no attribute 'bar'
And so I don't find a nice way to wrap my C# functionality in just one python
module,
where I whish I could offer the extension methods just like any other
method...
or is my import strategy somehow flawed ?
Greetings,
Daniel
namespace native
{
public class Example
{
}
public static class ExampleExtension
{
public static void
}
add some extension methods to it, and then want to import everything in
one
python stub module. E.g.
- Original Message
From: Dino Viehland di...@microsoft.com
To: Discussion of IronPython users@lists.ironpython.com
Sent: Thu, May 12, 2011 1:01:33 PM
Subject: Re: [IronPython] clr.ImportExtensions are not available outside
module
?
Daniel wrote:
Just as Dave Wald, I have also trying out the ImportExtensions methods
which I personally find very useful, thank you for implementing. Everything
is
working fine on using 2.7 (and .net 4), but extension methods loaded by
one
module seem not available on another...
This is by design. It works similar to how import clr only effects the
current module
and how extension methods work in C# where they are scoped by file. So if
you
want extension methods available in a file you'll need to import them in that
file.
If they were globally scoped it would be easy for one module to break
another by
bringing in the 'wrong' extension methods.
I will stick to Dave's code exmaple:
import clr
clr.AddReference(System.Core)
import System
from System import Linq
clr.ImportExtensions(Linq)
class Product(object):
def __init__(self, cat, id, qtyOnHand ):
self.Cat = cat
self.ID = id
self.QtyOnHand = qtyOnHand
self.Q = self.QtyOnHand
If I put this into a file, lets say test.py and now use the module on the
command line:
import test
products = [test.Product('food', i, 10) for i in range(3)]
products.Where
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'list' object has no attribute 'Where'
The linq extensions are not available. I have to re-import them:
test.clr.ImportExtensions(test.Linq)
products.Where
built-in method Where of list object at 0x002B
Is this a current limitation, or should I be doing things differently ?
Any help appreciated.
Greetings,
Daniel
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] pytest results in unsupported PythonDictionary system error
Piotr wrote: Hi This is for IronPython 2.7 Pytest 2.0.3 installed in site-packages Running a test with pytest results in the following system error: SystemError: Unsupported param dictionary type: IronPython.Runtime.PythonDictionary Any ideas what the problem is? -- Here is the example and the error: class TestBasic: def test_01(self): for n in (2, 4, 6, 8, 10): yield self.n_greater_than_zero, n def n_greater_than_zero(self, n): assert n 0 if __name__ == '__main__': import pytest pytest.main() C:\IronPython\ipy.exe .\test_001_dd.py Traceback (most recent call last): File .\test_001_dd.py, line 11, in module File C:\IronPython\lib\site-packages\pytest.py, line 6, in module File C:\IronPython\lib\site-packages\_pytest\core.py, line 7, in module File C:\IronPython\lib\site-packages\py\__init__.py, line 19, in module File C:\IronPython\lib\site-packages\py\_apipkg.py, line 33, in initpkg SystemError: Unsupported param dictionary type: IronPython.Runtime.PythonDictionary Can you send the code in _apipkg.py on line 33 (and maybe some surrounding code)? Anyway, it sounds like a binder bug but that code might help create a simple repro. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Python Tools for Visual Studio now accepting contributions
We've been in a difficult place with having two sets of tools for Visual Studio that both work with IronPython. Those are the existing IronPython Tools that shipped w/ 2.7 and the newer Python Tools for Visual Studio which are derived from the original IronPython code base. To make things more difficult we've been living in a world where you could contribute back to IronPython Tools but contributions weren't being accepted back to PTVS. That's obviously not the best environment for encouraging users to submit changes back and today I'm happy to announce that we've fixed this problem and we're now accepting contributions back to PTVS! If you're interested in contributing back feel free to fork PTVS (http://pytools.codeplex.com/SourceControl/network) and submit a pull request for your changes. Basic contribution guidelines are available here: http://pytools.codeplex.com/wikipage?title=Contributing%20to%20PTVSversion=1 and instructions for getting setup to build are available here: http://pytools.codeplex.com/wikipage?title=Build%20Instructions%20for%20PTVS ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Python Tools for Visual Studio now accepting contributions
Keith wrote: Please forgive my ignorance on this matter (I don't currently use any of the integrated VS functionality - have been working with embedding the runtime in an existing application), but what is the difference between IronPython Tools and Python Tools for Visual Studio? I was under the impression this was the same thing? IronPython Tools was the initial version that was undergoing development while Microsoft was still funding IronPython development. After we released IronPython back to the community I switched to a new team and started working on PTVS (using the IronPython Tools code base as a starting point). PTVS keeps all of the functionality that IpyTools had but adds: Support for CPython (and other Python implementations like Jython and PyPy) Support for multiple versions of Python (2.5 - 3.2) A Python specific debugger (instead of just using the .NET debugger) Profiling of CPython apps MPI projects and debugging There's probably some other new features that I'm missing. So it's basically a more general and better version of IpyTools but our core focus is on high performance computing scenarios where you'd like to use Python - but we're also making sure we just have a great Python development experience as well. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Python Tools for Visual Studio now accepting contributions
Jeff wrote: The IronPython Tools (or old tools) are the original VS integration tools, developed when IronPython was still funded by MS. PTVS is a new set of Python (not IronPython-specific; they support CPython and IronPython, and some Jython and PyPy) tools Dino's working on for MS's Technical Computing group. Some of the features are HPC-specific (like MPI cluster debugging) but for the most part it's just a nice Python environment, and a lot more stable than the old tools. Dino, can the HPC stuff be split out for people who don't need it? Not only can it be split out, it already is! :) It's in its own VS package already and when you install it's an optional component. That's basically a necessity because it depends upon the HPC SDK which we don't want to require everyone to have. It does mean if you're doing development on PTVS that you need to have the VS SDK installed or unload that project from the solution. PTVS is significantly better then the old tools and is also under active development, and now that they're accepting contributions it makes sense to me to retire the old tools and just get people to download PTVS (I doubt we'll bundle them, but instead have a big link next on the download page). ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Cannot compile IronPythonTools
You can go into project properties for IronPythonTools and on the debug settings choose launch external program. Then just add the same command line you used to launch under the exp hive and F5 will work. Sent from my Windows Phone From: Raghavendra Chandrashekara Sent: Wednesday, May 11, 2011 5:13 PM To: Discussion of IronPython Subject: Re: [IronPython] Cannot compile IronPythonTools On Tue, May 10, 2011 at 9:00 PM, Dino Viehland di...@microsoft.commailto:di...@microsoft.com wrote: You’ll need to install the VS SDK (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5displaylang=en) in addition to Visual Studio. The reason for that is because we use the SDK’s project types to get things like a good debugging experience in the experimental hive (you can set IronPythonTools as your setup project and have it launch VS with F5 under the experimental hive. When building the extension automatically gets deployed to the experimental hive). One more question, how do I debug the IronPython tools? I have created the experimental hive using the command: CreateExpInstance.exe /Reset /VSInstance=10.0 /RootSuffix=Exp and then started the experimental instance of Visual Studio using: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe /RootSuffix Exp This starts an Experimental Instance of Visual Studio which I can see in the title bar. But when I set IronPythonTools as the startup project and press F5 I get a message saying that A project with an Output Type of Class Library cannot be started directly. Thanks, Raj ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Intellisense with imported dlls
Where are the assemblies? Currently we'll only find assemblies in the gac. Sent from my Windows Phone From: Raghavendra Chandrashekara Sent: Wednesday, May 11, 2011 4:49 PM To: Discussion of IronPython Subject: [IronPython] Intellisense with imported dlls Hi All, I added a couple of custom .NET dlls using the clr.AddReference() method in my program and I was expecting IronPython Tools for Visual Studio to be able to parse the imported dlls and provide intellisense for the imported classes. However I don't see any imported methods when I press either Ctrl + Space or the '.' key after a class object. Is there something extra I need to do? Thanks, Raj ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Intellisense with imported dlls
Cool, this shouldn’t be too hard to fix. We load the assemblies in ProjectState.cs and it should just be a matter of flowing the VS project settings down to the analysis ProjectState class and then attempting to load the assemblies from there. If you’d like to fix it in PTVS, which I’d encourage you to do, it’s been moved to IronPythonInterpreter.cs. In PTVS it might be more difficult to flow in the VS project but you could update the IPythonInterpreter interface or IInterpreterState so that we either push down or allow pulling out the search paths. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Raghavendra Chandrashekara Sent: Wednesday, May 11, 2011 6:07 PM To: Discussion of IronPython Cc: Discussion of IronPython Subject: Re: [IronPython] Intellisense with imported dlls Ah, I see. The referenced assemblies are in a sub-directory of my project. Would it be too difficult to add the list of assemblies in the Search Path directories of the project? I can try to change the IronPythonTools code to do this if you could give a hint as to where I should start. Thanks, Raj On 2011-05-11, at 20:51, Dino Viehland di...@microsoft.commailto:di...@microsoft.com wrote: Where are the assemblies? Currently we'll only find assemblies in the gac. Sent from my Windows Phone From: Raghavendra Chandrashekara Sent: Wednesday, May 11, 2011 4:49 PM To: Discussion of IronPython Subject: [IronPython] Intellisense with imported dlls Hi All, I added a couple of custom .NET dlls using the clr.AddReference() method in my program and I was expecting IronPython Tools for Visual Studio to be able to parse the imported dlls and provide intellisense for the imported classes. However I don't see any imported methods when I press either Ctrl + Space or the '.' key after a class object. Is there something extra I need to do? Thanks, Raj ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Cannot compile IronPythonTools
You'll need to install the VS SDK (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5displaylang=en) in addition to Visual Studio. The reason for that is because we use the SDK's project types to get things like a good debugging experience in the experimental hive (you can set IronPythonTools as your setup project and have it launch VS with F5 under the experimental hive. When building the extension automatically gets deployed to the experimental hive). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Raghavendra Chandrashekara Sent: Tuesday, May 10, 2011 5:30 PM To: Discussion of IronPython Subject: [IronPython] Cannot compile IronPythonTools Hi All, I downloaded the latest code from the git repository and tried to compile IronPythonTools.sln but I got the following error: D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronPythonTools\IronPythonTools.csproj : error : The project file 'D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronPythonTools\IronPythonTools.csproj' cannot be opened. The project type is not supported by this installation. D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronStudio\IronStudio.csproj : error : Unable to read the project file 'IronStudio.csproj'. D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronStudio\IronStudio.csproj(369,3): The imported project C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets was not found. Confirm that the path in the Import declaration is correct, and that the file exists on disk. Am I missing a component from VS 2010? Thanks for any help you can give. Raj ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problems running simple executable compiled with the pyc.py tool
When running are Program.dll and Program.exe in the same location? The reason
I ask is that Program.exe will change the CWD to where it is currently located
and then it'll attempt to load Program.dll from that directory. That's the
only thing that immediately comes to mind as having potential to break this for
you.
Also, did you install IronPython via the MSI or by downloading the binary zip
file?
I just tried this and it all seemed to work for me (I'm installed via the MSI
so we can pick up the IronPython DLLs from the GAC):
C:\Users\dinov type test.py
print('hi')
10:11:04.07
C:\Users\dinov C:\Program Files (x86)\IronPython 2.7\ipy.exe C:\Program
Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py /target:exe /out:test
/main:test.py test.py
Input Files:
test.py
Output:
test
Target:
ConsoleApplication
Platform:
ILOnly
Machine:
I386
Compiling...
Saved to test
10:11:13.82
C:\Users\dinov .\test.exe
hi
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of iiyo cc
Sent: Friday, May 06, 2011 9:57 AM
To: users@lists.ironpython.com
Subject: [IronPython] Problems running simple executable compiled with the
pyc.py tool
Hello,
I keep coming up with the same problem when trying to run a compiled executable
from the pyc.py tool. The error I'm getting is as follows:
Unhandled Exception: System.IO.FileNotFoundException: The system cannon find
the file specified. (Exception from HRESULT: 0x80070002)
at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence evidence)
at System.Reflection.Assembly.LoadFile(String path)
at PythonMain.Main()
My file is a simple Hello, World! program saved as Program.py with the
following contents:
print 'Hello, World!'
I use the following command line to compile:
C:\IronPy\ipy C:\IronPy\Tools\Scripts\pyc.py Program.py /out:Program
/main:Program.py /target:exe
Note: I'm using the latest 2.7 release through the IronPython installer on a
Windows 7 64bit system, the executables are built (Program.dll and Program.exe)
successfully, yet won't run even when sitting in the same directory as all the
dlls one can find in the IronPython distribution. I've also tried targeting the
x64 platform specifically with pyc, but to no avail. Here's what my working
directory looks like when the project is built:
IronPython.dll, IronPython.Modules.dll, IronPython.Wpf.dll,
Microsoft.Dynamic.dll, Microsoft.Scripting.dll,
Microsoft.Scripting.Metadata.dll, Program.dll, Program.exe, Program.py
Hopefully someone knows what's going on, or if i'm doing something wrong.
Thanks.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problems running simple executable compiled with the pyc.py tool
Feel free to open a bug on supporting directories - it seems pretty reasonable
to expect that to work.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of iiyo cc
Sent: Friday, May 06, 2011 11:02 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problems running simple executable compiled with the
pyc.py tool
I followed your example, and it worked perfectly for me. I then realized it was
my error all along - I assumed /out: could support directories (I had actually
used /out:build\Program because of the batch file used to generate it), but
this seems not to work in the way I'd imagined. Anyway, it's all working
properly now.
Thanks, and apologies for the stupidity!
On Fri, May 6, 2011 at 6:12 PM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
When running are Program.dll and Program.exe in the same location? The reason
I ask is that Program.exe will change the CWD to where it is currently located
and then it'll attempt to load Program.dll from that directory. That's the
only thing that immediately comes to mind as having potential to break this for
you.
Also, did you install IronPython via the MSI or by downloading the binary zip
file?
I just tried this and it all seemed to work for me (I'm installed via the MSI
so we can pick up the IronPython DLLs from the GAC):
C:\Users\dinov type test.py
print('hi')
10:11:04.07
C:\Users\dinov C:\Program Files (x86)\IronPython 2.7\ipy.exe C:\Program
Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py /target:exe /out:test
/main:test.py test.py
Input Files:
test.py
Output:
test
Target:
ConsoleApplication
Platform:
ILOnly
Machine:
I386
Compiling...
Saved to test
10:11:13.82
C:\Users\dinov .\test.exe
hi
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com]
On Behalf Of iiyo cc
Sent: Friday, May 06, 2011 9:57 AM
To: users@lists.ironpython.commailto:users@lists.ironpython.com
Subject: [IronPython] Problems running simple executable compiled with the
pyc.py tool
Hello,
I keep coming up with the same problem when trying to run a compiled executable
from the pyc.py tool. The error I'm getting is as follows:
Unhandled Exception: System.IO.FileNotFoundException: The system cannon find
the file specified. (Exception from HRESULT: 0x80070002)
at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence evidence)
at System.Reflection.Assembly.LoadFile(String path)
at PythonMain.Main()
My file is a simple Hello, World! program saved as Program.py with the
following contents:
print 'Hello, World!'
I use the following command line to compile:
C:\IronPy\ipy C:\IronPy\Tools\Scripts\pyc.py Program.py /out:Program
/main:Program.py /target:exe
Note: I'm using the latest 2.7 release through the IronPython installer on a
Windows 7 64bit system, the executables are built (Program.dll and Program.exe)
successfully, yet won't run even when sitting in the same directory as all the
dlls one can find in the IronPython distribution. I've also tried targeting the
x64 platform specifically with pyc, but to no avail. Here's what my working
directory looks like when the project is built:
IronPython.dll, IronPython.Modules.dll, IronPython.Wpf.dll,
Microsoft.Dynamic.dll, Microsoft.Scripting.dll,
Microsoft.Scripting.Metadata.dll, Program.dll, Program.exe, Program.py
Hopefully someone knows what's going on, or if i'm doing something wrong.
Thanks.
___
Users mailing list
Users@lists.ironpython.commailto:Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problems running simple executable compiled with the pyc.py tool
I see a couple of things going on here:
The choice of wpf as your compiled name is unfortunate. When
we execute your import wpf is actually just bringing in your own module
rather than bringing in the real wpf module.
But even if you change the name it's still broken because we
don't pick up the IronPython.Wpf.dll which is in the DLLs directory of the
IronPython install.
I'm not exactly sure what the best fix for the latter issue is -we probably
need to try looking into the registry, seeing where IronPython is installed,
and adding any references to the DLLs directory there for compiled apps. Not
sure if there's something better we could do though.
But you can work around it easily enough, you just need to add:
import clr
clr.AddReference('IronPython.Wpf')
before the import wpf and make sure that IronPython.Wpf.dll is in the same dir
as your app (we don't GAC this DLL).
Then compiling with this command line worked for me:
C:\Program Files (x86)\IronPython 2.7\ipy.exe C:\Program Files
(x86)\IronPython 2.7\Tools\Scripts\pyc.py /out:wpfx /main:wpfx.py wpfx.py
/target:winexe
The way I debugged this was I compiled as a normal EXE so I could see the stack
trace when things went wrong. Once I got to this exception:
Unhandled Exception: System.InvalidOperationException: The calling thread must
be STA, because many UI components require this.
at System.Windows.Input.InputManager..ctor()
at System.Windows.Input.InputManager.GetCurrentInputManagerImpl()
at System.Windows.Input.KeyboardNavigation..ctor()
at System.Windows.FrameworkElement.EnsureFrameworkServices()
at System.Windows.FrameworkElement..ctor()
at System.Windows.Controls.Control..ctor()
at System.Windows.Window..ctor()
Then I switched back to compiling as a winexe.
The argument parsing in pyc.py definitely sucks, it should probably be switched
to using a std lib arg parser.Contributions are welcome if you'd like to
improve any of this!
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of iiyo cc
Sent: Friday, May 06, 2011 1:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Problems running simple executable compiled with the
pyc.py tool
Alright, I've come upon another problem, this time with using /target:winexe
with a wpf type project. It seems to crash without any kind of error. I also
noticed some curious things about the parameter order.
Here's the sample source I used to test: wpf.py and wpf.xaml -
http://codepad.org/XRLF8OSc
Compiling with:
C:\Program Files (x86)\IronPython 2.7\ipy.exe C:\Program Files
(x86)\IronPython 2.7\Tools\Scripts\pyc.py /out:wpf /target:winexe /main:wpf.py
wpf.py
For some reason, this will compile as a Console Application type
Changing the order:
C:\Program Files (x86)\IronPython 2.7\ipy.exe C:\Program Files
(x86)\IronPython 2.7\Tools\Scripts\pyc.py /out:wpf /main:wpf.py
/target:winexe wpf.py
This compiles correctly, although it simply crashes on load.
Any ideas? Is it possible to compile if using wpf? I'm lost here - enjoying
IronPython, but its distribution sure is hell.
On Fri, May 6, 2011 at 7:04 PM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
Feel free to open a bug on supporting directories - it seems pretty reasonable
to expect that to work.
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com]
On Behalf Of iiyo cc
Sent: Friday, May 06, 2011 11:02 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problems running simple executable compiled with the
pyc.py tool
I followed your example, and it worked perfectly for me. I then realized it was
my error all along - I assumed /out: could support directories (I had actually
used /out:build\Program because of the batch file used to generate it), but
this seems not to work in the way I'd imagined. Anyway, it's all working
properly now.
Thanks, and apologies for the stupidity!
On Fri, May 6, 2011 at 6:12 PM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
When running are Program.dll and Program.exe in the same location? The reason
I ask is that Program.exe will change the CWD to where it is currently located
and then it'll attempt to load Program.dll from that directory. That's the
only thing that immediately comes to mind as having potential to break this for
you.
Also, did you install IronPython via the MSI or by downloading the binary zip
file?
I just tried this and it all seemed to work for me (I'm installed via the MSI
so we can pick up the IronPython DLLs from the GAC):
C:\Users\dinov type test.py
print('hi')
10:11:04.07
C:\Users\dinov C:\Program Files (x86)\IronPython 2.7\ipy.exe C:\Program
Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py /target:exe /out:test
/main:test.py test.py
Input Files:
test.py
Output
Re: [IronPython] Extending Gtk.TextView
Doug wrote: From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Doug Blank Sent: Friday, May 06, 2011 2:13 PM To: Discussion of IronPython Subject: [IronPython] Extending Gtk.TextView Does anyone have an idea what this would mean, or how to fix it? import Gtk class MyTextView(Gtk.TextView): ... pass mtv = MyTextView() (pyjama:611): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.28.6/./gobject/gsignal.c:1549: signal set_scroll_adjustments already exists in the `GtkTextView' class ancestry Does this happen if you just subclass Gtk.TextView from C#? We shouldn't be really doing anything special when we subclass (other than overriding every single virtual member). ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] ctypes .net interaction (casting a pointer to a .net object)
Sebastien wrote: In my effort to be able to use the GetRunningObjectTable in ironpython, I succeeded in recovering a pointer to a IBindCtx object by using the ctypes library. Is it possible to then cast this pointer (or transform it) to a IBindCtx Ironpython type on which I could call other methods ? You should be able to call Marshal.GetObjectForIUnknown such as: from System import IntPtr from System.Runtime.InteropServices import Marshal obj = Marshal.GetObjectForIUnknown(IntPtr(ptr)) From there you should be able to do IBindCtx.GetRunningObjectTable(obj). If the COM object supports automation or provides type info then you could just do obj.GetRunningObjectTable(). And more generally, is it possible to use both the native .net objects in ipy and the ctypes library in ipy (and so transform from one world to the other) ? I think the answer to this is generally yes. In particular for COM objects you can because of the CLR and IronPython's support for COM interop. If you're dealing with other plain old structures and you have a .NET version of them you'll just need to copy all of the fields yourself . ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] how to generate multiple concurrent scriptign engines?
It might come from CopyReg but the bug is definitely in GetEqualSite - we just
need a lock(_equalSites) { ... } around the TryGetValue and creation of the
equal site.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Friday, April 15, 2011 7:29 AM
To: surangika ranathunga
Cc: Discussion of IronPython
Subject: Re: [IronPython] how to generate multiple concurrent scriptign engines?
Any chance you can share what the source is? The exception comes from
PythonCopyReg's initialization, which means we might have a bug (it might not
be thread-safe, or something else). If you could create a minimal sample that
has the issue that would be even better.
- Jeff
On Thu, Apr 14, 2011 at 9:18 PM, surangika ranathunga
lady_ra...@yahoo.commailto:lady_ra...@yahoo.com wrote:
Hi,
Below is the exception I receive:
here, D:\PhD
Work\Research\libomv\test\MonitorService\MonitorService\ExpectationMonitor.cs:line
88 refers to source.Execute(scope); in the below given code.
System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation. --- System.Reflection.TargetInvocationException:
Exception has been thrown by the target of an invocation. ---
System.NullReferenceExce
ption: Object reference not set to an instance of an object.
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value,
Boolean add)
at System.Collections.Generic.Dictionary`2.set_Item(TKey key, TValue value)
at IronPython.Runtime.PythonContext.GetEqualSite(Type type)
at IronPython.Runtime.CommonDictionaryStorage.UpdateHelperFunctions(Type t,
Object key)
at IronPython.Runtime.CommonDictionaryStorage.AddNoLock(Object key, Object
value)
at IronPython.Runtime.CommonDictionaryStorage.Add(Object key, Object value)
at IronPython.Runtime.PythonDictionary.SetItem(Object key, Object value)
at IronPython.Runtime.PythonDictionary.set_Item(Object key, Object value)
at IronPython.Modules.PythonCopyReg.PerformModuleReload(PythonContext
context, PythonDictionary dict)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method,
Object target, Object[] arguments, SignatureStruct sig, MethodAttributes
methodAttributes, RuntimeType typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method,
Object target, Object[] arguments, Signature sig, MethodAttributes
methodAttributes, RuntimeType typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean
skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at IronPython.Runtime.PythonContext.CreateBuiltinModule(String moduleName,
Type type, ModuleOptions options)
at IronPython.Runtime.PythonContext.CreateBuiltinModule(String moduleName,
Type type)
at IronPython.Runtime.PythonContext.CreateBuiltinModule(String name)
at IronPython.Runtime.PythonContext.GetBuiltinModule(String name)
at IronPython.Runtime.Importer.ImportBuiltin(CodeContext context, String
name)
at IronPython.Modules.PythonCopyReg.EnsureModuleInitialized(CodeContext
context)
at IronPython.Modules.PythonCopyReg.GetDispatchTable(CodeContext context)
at IronPython.Modules.PythonRegex.PerformModuleReload(PythonContext
context,PythonDictionary dict)
--- End of inner exception stack trace ---
at Microsoft.Scripting.Actions.Calls.MethodCandidate.Caller.Call(Object[]
args, Boolean shouldOptimize)
at
IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`5.Call4(CallSite
site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3 arg3)
at
System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite
site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)
at IronPython.Runtime.Importer.Import(CodeContext context, String fullName,
PythonTuple from, Int32 level)
at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext context,
String fullName, Int32 level)
at
Microsoft.Scripting.Interpreter.FuncCallInstruction`4.Run(InterpretedFrame
frame)
at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame)
at Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0 arg0, T1
arg1)
at IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx)
at IronPython.Compiler.PythonScriptCode.Run(Scope scope)
at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope)
at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope)
at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink errorSink)
at Microsoft.Scripting.SourceUnit.Execute(Scope scope)
at
Re: [IronPython] WPF module in IronPython scripting?
Lukáš wrote: Hi there everyone, I just bumped into a problem where when I run the IPy.exe console and execute a script that contains: import wpf all works well. However, when I want to import the wpf namespace into the same script, but run outside the IPy.exe (i.e. as an embedded engine) I get an error saying that the module wpf doesn't exist! I even tried to add the IronPython.Wpf.dll into the PATH, I tried referencing it in my script via clr.AddReferenceToFile, nothing works and I don't have access to the wpf methods etc... Is there anything I can do about it? I would have expected AddReferenceToFile to work but what about doing a scriptRuntime.LoadAssembly(typeof(Wpf).Assembly); where the host app has a reference to IronPython.Wpf.dll? I think the code for loading from the DLLs directory is ipy.exe specific - you could also look at replicating that for your host app so there's a general way to add additional Python built-in modules. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] how to generate multiple concurrent scriptign engines?
Filed as http://ironpython.codeplex.com/workitem/30551
From: Jeff Hardy [mailto:jdha...@gmail.com]
Sent: Friday, April 15, 2011 9:41 AM
To: Discussion of IronPython
Cc: Dino Viehland; surangika ranathunga
Subject: Re: [IronPython] how to generate multiple concurrent scriptign engines?
Can one of your alter-egos file a bug so it doesn't get lost?
- Jeff
On Fri, Apr 15, 2011 at 10:36 AM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
It might come from CopyReg but the bug is definitely in GetEqualSite - we just
need a lock(_equalSites) { ... } around the TryGetValue and creation of the
equal site.
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com]
On Behalf Of Jeff Hardy
Sent: Friday, April 15, 2011 7:29 AM
To: surangika ranathunga
Cc: Discussion of IronPython
Subject: Re: [IronPython] how to generate multiple concurrent scriptign engines?
Any chance you can share what the source is? The exception comes from
PythonCopyReg's initialization, which means we might have a bug (it might not
be thread-safe, or something else). If you could create a minimal sample that
has the issue that would be even better.
- Jeff
On Thu, Apr 14, 2011 at 9:18 PM, surangika ranathunga
lady_ra...@yahoo.commailto:lady_ra...@yahoo.com wrote:
Hi,
Below is the exception I receive:
here, D:\PhD
Work\Research\libomv\test\MonitorService\MonitorService\ExpectationMonitor.cs:line
88 refers to source.Execute(scope); in the below given code.
System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation. --- System.Reflection.TargetInvocationException:
Exception has been thrown by the target of an invocation. ---
System.NullReferenceExce
ption: Object reference not set to an instance of an object.
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value,
Boolean add)
at System.Collections.Generic.Dictionary`2.set_Item(TKey key, TValue value)
at IronPython.Runtime.PythonContext.GetEqualSite(Type type)
at IronPython.Runtime.CommonDictionaryStorage.UpdateHelperFunctions(Type t,
Object key)
at IronPython.Runtime.CommonDictionaryStorage.AddNoLock(Object key, Object
value)
at IronPython.Runtime.CommonDictionaryStorage.Add(Object key, Object value)
at IronPython.Runtime.PythonDictionary.SetItem(Object key, Object value)
at IronPython.Runtime.PythonDictionary.set_Item(Object key, Object value)
at IronPython.Modules.PythonCopyReg.PerformModuleReload(PythonContext
context, PythonDictionary dict)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method,
Object target, Object[] arguments, SignatureStruct sig, MethodAttributes
methodAttributes, RuntimeType typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method,
Object target, Object[] arguments, Signature sig, MethodAttributes
methodAttributes, RuntimeType typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean
skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at IronPython.Runtime.PythonContext.CreateBuiltinModule(String moduleName,
Type type, ModuleOptions options)
at IronPython.Runtime.PythonContext.CreateBuiltinModule(String moduleName,
Type type)
at IronPython.Runtime.PythonContext.CreateBuiltinModule(String name)
at IronPython.Runtime.PythonContext.GetBuiltinModule(String name)
at IronPython.Runtime.Importer.ImportBuiltin(CodeContext context, String
name)
at IronPython.Modules.PythonCopyReg.EnsureModuleInitialized(CodeContext
context)
at IronPython.Modules.PythonCopyReg.GetDispatchTable(CodeContext context)
at IronPython.Modules.PythonRegex.PerformModuleReload(PythonContext
context,PythonDictionary dict)
--- End of inner exception stack trace ---
at Microsoft.Scripting.Actions.Calls.MethodCandidate.Caller.Call(Object[]
args, Boolean shouldOptimize)
at
IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`5.Call4(CallSite
site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3 arg3)
at
System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite
site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)
at IronPython.Runtime.Importer.Import(CodeContext context, String fullName,
PythonTuple from, Int32 level)
at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext context,
String fullName, Int32 level)
at
Microsoft.Scripting.Interpreter.FuncCallInstruction`4.Run(InterpretedFrame
frame)
at Microsoft.Scripting.Interpreter.Interpreter.Run
Re: [IronPython] IronPython for Silverlight 5?
Jeff wrote: On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman cha...@slb.com wrote: I see Silverlight 5 now has something besides simple reflection (ICustomTypeProvider) - http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data Will we see an update to Iron*/DLR to support binding to dynamic objects any time soon? This will open fantastic options for using IronPython in Silverlight. If someone provides a patch, yes. We actually need someone with an interest in Silverlight to keep an eye on it and make sure that we don't break SL support and new features like this. We don't have anyone in that role right now. If anyone's interested on working on this it'd probably mean adding an implementation of this onto OldInstance as well as adding it onto our new-style instances whose classes are created by NewTypeMaker. Adding the interface is probably pretty easy, making it return useful things may be a little more difficult. I'm a little surprised they didn't go with the already existing ICustomTypeDescriptor. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] How to make a gtk event?
Unless GTK has some event class of its own my guess is the answer is no. But if
it doesn't have an event class of its own then it probably doesn't matter as
I'd think
it would never consume your events - only other Python code would.
-Original Message-
From: Martin Matusiak [mailto:numero...@gmail.com]
Sent: Thursday, April 14, 2011 1:57 AM
To: Discussion of IronPython
Cc: Dino Viehland
Subject: Re: [IronPython] How to make a gtk event?
Yes, that works. But pedantically speaking, is it possible to manufacture an
event that would agree on type with the gtk produced ones? I really don't
know if this ever comes up but suppose at one point it needs to be
interchangeable with a built in event?
Martin
2011/4/13 Dino Viehland di...@microsoft.com:
Oh, reading comprehension fail... as long as you don't want it
statically declared (e.g. it's only ever accessed from Python) then
there's a sample pyevent.py in the Tutorial which does this. It's just
an object with __iadd__ / __isub__ and a list of handlers to dispatch to.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Martin Matusiak
Sent: Wednesday, April 13, 2011 9:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] How to make a gtk event?
I'm not talking about the handler, I'm talking about creating a new
event for this widget. As in:
mywidget.SomethingHappened += some_handler
2011/4/13 Dino Viehland di...@microsoft.com:
Martin wrote:
Hey guys,
I'm writing a program using using gtk# and I have a custom widget
that I want to make an event for. Here is what an event looks like:
print self.mainwindow.Shown
IronPython.Runtime.Types.ReflectedEvent+BoundEvent object at
0x002B
[IronPython.Runtime.Types.ReflectedEvent+BoundEvent]
So I seem to need to instantiate this type with my event name and
trigger function somehow as parameters, but I don't know how. Any
ideas?
The BoundEvent object supports in place addition and subtraction
for adding/removing the events and it'll accept any callable object
on the right hand side. So you should just do
+= on shown, such as:
def handler(sender, args):
print('hello')
self.mainwindow.shown += handler
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] How to make a gtk event?
Martin wrote:
Hey guys,
I'm writing a program using using gtk# and I have a custom widget that I want
to make an event for. Here is what an event looks like:
print self.mainwindow.Shown
IronPython.Runtime.Types.ReflectedEvent+BoundEvent object at
0x002B
[IronPython.Runtime.Types.ReflectedEvent+BoundEvent]
So I seem to need to instantiate this type with my event name and trigger
function somehow as parameters, but I don't know how. Any ideas?
The BoundEvent object supports in place addition and subtraction for
adding/removing
the events and it'll accept any callable object on the right hand side. So you
should just do
+= on shown, such as:
def handler(sender, args):
print('hello')
self.mainwindow.shown += handler
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] How to make a gtk event?
Oh, reading comprehension fail... as long as you don't want it statically
declared
(e.g. it's only ever accessed from Python) then there's a sample pyevent.py in
the Tutorial which does this. It's just an object with __iadd__ / __isub__ and
a
list of handlers to dispatch to.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Martin Matusiak
Sent: Wednesday, April 13, 2011 9:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] How to make a gtk event?
I'm not talking about the handler, I'm talking about creating a new event for
this widget. As in:
mywidget.SomethingHappened += some_handler
2011/4/13 Dino Viehland di...@microsoft.com:
Martin wrote:
Hey guys,
I'm writing a program using using gtk# and I have a custom widget
that I want to make an event for. Here is what an event looks like:
print self.mainwindow.Shown
IronPython.Runtime.Types.ReflectedEvent+BoundEvent object at
0x002B
[IronPython.Runtime.Types.ReflectedEvent+BoundEvent]
So I seem to need to instantiate this type with my event name and
trigger function somehow as parameters, but I don't know how. Any
ideas?
The BoundEvent object supports in place addition and subtraction for
adding/removing the events and it'll accept any callable object on the
right hand side. So you should just do
+= on shown, such as:
def handler(sender, args):
print('hello')
self.mainwindow.shown += handler
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] VS 2010 Integrated Shell question
Lukáš wrote: Now, I'm wondering, how did you get the WPF designer to work in the Integrated Shell version of VS? I don't seem to be able to get it working (basically after choosing the WPF IPy template to start with, nothing shows up). :( I just did file-new project, selected the WPF project, and then double clicked on the XAML file in the new project to open the designer. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Python Tools Beta Pluing - No Toolbox Items
Beta 2 is now out w/ the fix for this - http://pytools.codeplex.com/releases/view/63597 It also fixes Silverlight debugging which was broken in Beta 1. It should now be back at parity w/ IronPython Tools for pure IronPython development not to mention all the other improvements over IronPython Tools that have been made. So please give it a try and let us know if you run into any additional issues. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dave Wald Sent: Friday, April 08, 2011 7:06 PM To: Discussion of IronPython Subject: Re: [IronPython] Python Tools Beta Pluing - No Toolbox Items Chris, Lest you think I gave you a bum steer the other day, here's what happened: By the time I switched over to the new tools, I already had all my layout done in the designer, and was just working in XAML and code. I never realized the toolbox wasn't working! But thanks for the heads up. I would've been somewhat consternated... ;-) Dave On 4/8/2011 9:26 AM, Chris wrote: Hi all, I have installed the Python Tools for Visual Studio beta 1, and im having trouble getting any tools in the WPF designer. This has worked OK, but with the tools packaged with the IronPython install. I actually did a fresh install on another box recently and only ever installed the beta Tools. When i create a new WPF project and drop into designer mode all the toolbox icons are greyed out. Does anyone else have this issue, or know how to fix? Thanks, Chris ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] New clr.ImportExtensions (LINQ) Syntax
Dave wrote: Okay. Never mind. There's already an open bug for this I just found. http://ironpython.codeplex.com/workitem/30379 I've assigned this bug to myself. I'll take a look and fix it, my guess is there's something wrong with extension method support on generic classes (e.g. class FooT : IEnumerableT) that needs to be fixed in our type inferer. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Python Tools Beta Pluing - No Toolbox Items
I ran into that too and it's fixed for the next release (along w/ IronPython Silverlight debugging which was also broken). The fix is checked in so if you can build from source you can download the current sources and do that. Otherwise the next release should be happening in the next few days so you can probably just wait. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Chris Sent: Friday, April 08, 2011 7:27 AM To: Discussion of IronPython Subject: [IronPython] Python Tools Beta Pluing - No Toolbox Items Hi all, I have installed the Python Tools for Visual Studio beta 1, and im having trouble getting any tools in the WPF designer. This has worked OK, but with the tools packaged with the IronPython install. I actually did a fresh install on another box recently and only ever installed the beta Tools. When i create a new WPF project and drop into designer mode all the toolbox icons are greyed out. Does anyone else have this issue, or know how to fix? Thanks, Chris ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Migration warnings to python 3
We do support the -3 option which turns those warnings on but I don't think we have as many warnings as CPython did. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Markus Schaber Sent: Friday, April 01, 2011 7:25 AM To: Discussion of IronPython Subject: [IronPython] Migration warnings to python 3 Hello, The current estimate for IronPython to implement python 3 was not before fall. So applications hosting IronPython must think about paving a good migration path for their users. AFAIR, the cPython implementation can spit out a bunch of warnings for Code incompatible with cPython 3. Is this mechanism supported by hosted IronPython? Grüße, Markus ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Debugging hosted python scripts
Jeff wrote: On Wed, Mar 30, 2011 at 8:52 PM, Keith Rome r...@wintellect.com wrote: I have been going down the path of using ScriptEngine.SetTrace() and inspecting frames in the callback. This works fine if I am not doing anything interactive. For example, dumping some information to Debug.WriteLine(). However what I really need (I think?) is to be able to suspend the script execution during a trace callback. I don't see a clear way to do this though. The script runtime simply continues execution when my callback returns. I have done some work around running the debugged script on a background thread, and then blocking it during breakpoint callbacks - but these scripts are normally run within the UI thread because they interact with data structures that are often databound to UI controls, and running them from a background thread is becoming a minefield of cross-thread violations. I cannot simply run the script in the UI thread, because blocking in the trace callback would make the application unresponsive. I think this is going to be your biggest issue with debugging - AFAIK the Python engine is not designed to be suspendable; it relies on .NET's normal thread suspension mechanism to handle that case. If the scripts are on the UI thread, and the debugger is on the UI thread, that 's going to be an issue. Now, if the engine were running in interpreted mode (i.e. it doesn't try to convert Python to IL), it would probably be possible to suspend it without suspending the thread, but I have no idea how much work that would be. (Heck, it might already support it - Dino?) My hunch is that it wouldn't be a huge amount of work, but I'm not familiar with the interpreter loop at all. There's certainly nothing that does this today - this is effectively how to do stackless on IronPython. There've been similar questions on the mailing list on how to do this (for greenlets) in the past. There's basically two changes which need to happen to get this working: 1. We need to re-write the trees we produce so all local variables are hoisted into a heap allocated data structure. We already do this for generators and for sys.settrace support so that one's not so hard. 2. We need to re-write the trees so that rather than performing a dynamic operation they yield control back to a loop which then performs the dynamic operation. 3. We might need to do #2 but with certain built in calls (for example import if you don't want imports to block, maybe some other built-in operations as well). Doing #2 isn't that difficult either - it's really just a tree rewrite that changes each Dynamic node (or one of the DLR outer layers dynamic like nodes) into a node which returns a call site plus arguments. The outer loop can then dispatch into the call site or it can yield appropriately. Finally this needs to be combined with the debugging mechanism which it's self is just an AST re-write. sys.settrace uses the same basic rewrite we need for #1 to hoist the variables. In addition to that it introduces the line, call, exception, etc... callbacks as well. I think the final tweak here would be to make those yield control back to the dispatch loop which then can then make the sys.settrace call. Finally you'll probably need to update functions so that if they're called externally (not directly from the dispatch loop) that they setup a new dispatch loop. So the delegates that are held in the FunctionCode object will need to be distinct from the normal delegates (this is similar to how we have a normal delegate and a light throwing delegate today). I'd suggest by trying to add the stackless re-write and dispatch loop to the DebugInfoRewriter class (or a fork of it) and then getting simple stackless function calls going. Then you can worry about fitting it in with the rest of the system. I could even see us adding this back to the core if it worked out to be sufficiently on the side which if implemented just as these AST rewrites it could be. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [Code Review] Custom PAL fixes
LGTM. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jimmy Schementi Sent: Thursday, March 31, 2011 6:06 PM To: Discussion of IronPython Subject: [IronPython] [Code Review] Custom PAL fixes Just checked in some small fixes to make the Importer use a custom Platform Adaptation Layer. I also started to tweak clr.CompileModules a bit, but backed those changes out, so just ignore those. Take a look at the recent commits to https://github.com/jschementi/iron. If there are no objections, I'll push them to main. By the way, is it about time to split this list into a development and users list, or you all don't mind seeing these type of mails? ~Jimmy ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython Tools for VS2010 Questions
Bill wrote: 1. Intellisense/autocomplete will be really useful for our users. Can anyone tell me what should and shouldn't provide this capability. So far it seems that some System types provide it and Python Module Methods work as well but I'm not sure what else should work as it is a little buggy. For example is there any way to get intellisense from 3rd party c# dll's? It will work with any Python code that you have loaded into your project or with any .NET assemblies which can be successfully loaded by Visual Studio process and which there are clr.AddReference calls. Likely that means the assemblies will need to be in the GAC for them to be loaded. Once we see the clr.AddReference call you should be able to get completion on their namespaces and types. 2. Using a Python Project and Chiron, what is the best way to include 3rd party .dlls in the xap? At the moment I've copied the .dlls to the IP Silverlight\bin folder and added them to the assemblies attribute of IPy's Language\ tag in Chiron.exe.config. This works OK but means all .dlls will be included for all python projects. Is there a way of getting this to work for each project individually without the users having to do anything manually (I want to create project templates that they can be up and running without doing any config themselves). Alternatively could the .dlls be downloaded from outside the xap e.g. from another .xap or .slvx? I don't think there's a specific feature here. If you'd like to see this in PTVS which Jeff mentioned then you could open a feature request over at pytools.codeplex.com. 3. Is anyone currently working on the IPy tools specifically? There are quite a lot of bugs right now unfortunately and many of them would need to be fixed if we were to use it. Note that my company may be willing to provide some resource in that area if we decide to proceed, but we don't have much experience with VS extensions so we may need some guidance. Yep, see Jeff's response. We're working on our side to improve the situation with PTVS but don't have anything more to say yet. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronLanguages
Just to chime in on how to do the conversion: the answer is that you probably
can't, at least not for something like TestClass. You could look at what sort
of type you're converting from in JS (number, string, function, etc...) and see
if TestClass has any implicit conversions to it from primitive .NET types
(double, string, delegate, etc...) and if so you could invoke one of those
conversions. But most likely you won't be able to convert directly to
TestClass. If TestClass was something more like IList then you could do a
conversion there as well. The only way you're likely able to convert to
TestClass is if the user got a TestClass object from .NET, brought it into JS
(where you wrapped it in some object of your own), and then you brought it back
to .NET - but then when you bring it back to .NET you should bring it back as
the real TestClass instead of your wrapped TestClass.
The only other way would be figuring out somehow to allow a JavaScript
developer to subclass a .NET TestClass type. We allow this in IronPython via
our NewTypeMaker class but we are lucky in that everything is in the .NET
world. One way you could go about this is having a function like CreateClass
which takes a subtype (TestClass) and a dictionary of string - JS functions
which you then call into for the implementation of the various subclass
methods. You would then have a .NET type which is being extended by JavaScript
- there's probably going to be some fun and tricky problems in doing this
though. Then the user can call the resulting class you give them, they'll get
an instance which is wrapped in JavaScript, and when you pass it back to .NET
you can unwrap it.
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Bill Chiles
Sent: Tuesday, March 29, 2011 9:57 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronLanguages
You'll want to look at the DLR overview doc and then the Sympl sample
walkthrough doc:
http://dlr.codeplex.com/wikipage?title=Docs%20and%20specsreferringTitle=HomeProjectName=dlr
You'll want to type the parameter to testComplexObject as 'dynamic' and
implement IDMOP on JSObject, which you can see how to do from the Sympl sample.
Now, the Sympl sample is VERY light on real .NET bindin, but if it all maps to
GetProp/SetProp, then maybe this is fine. If you might flow into your code a
regular C# object (not just a JSObj), then you may want to make use of the
DefaultBinder from the DLR project, which is what the Iron languages use to get
much richer binding. You could also make use of the C# runtime binder to get
C#'s semantics for binding members of objects at runtime, but you get that for
free if you declare the parameter 'dynamic' and have your JSOjbectMetaObject
simply punt whenever the object is not a derived type of JSObject. You get
that for free because you'll call back on the binder at the obj.message call
site, and C# will have compiled that callsite to use its binder.
Bill
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Matthias
Sent: Tuesday, March 29, 2011 3:34 AM
To: users@lists.ironpython.com
Subject: [IronPython] IronLanguages
Hello,
this question is not 100% targeted at IronPython, but I didn't know a better
list to write to.
I've started writing a C# - javascript bridge. Unlike IronPython and IronRuby
I don't want to write a javascript engine in .net, but rather use existing
ones. I can already access C# classes from javascript and instance them. The
opposite way turns out to be much harder for non-PODs.
Example:
public class JSObject
{
// has members like GetProperty/SetProperty which can act upon the
javascript object }
public class TestClass
{
public string message = This is a C# string; }
public class TestApp
{
public string testComplexObject(TestClass obj)
{
return obj.message;
}
public void runTest()
{
JSObject jsObj = ...;
string message = testComplexObject(jsObj);
}
}
The problem here is the testComplexObject(jsObj) call. Of course the jsObj
cannot be converted directly to a TestClass, because it's an arbitrary
javascript object.
I am wondering how IronPython solves this problem. I've read the sources a bit
and it seems it makes use of IDynamicMetaObjectProvider etc. If JSObject
provided IDynamicMetaObjectProvider, would it allow converting
the jsObj to a TestClass obj? How?
It's not easy to find information on using the DLR for things like this on the
net, so I've asked here. Apologies if I am off-topic.
-Matthias
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
Re: [IronPython] IPy 2.7 successfully built for .NET 3.5, but problem w. indirect v4 dependencies
It sounds like you need to re-build your own DLLs (or whatever SPTools is) to run against .NET 3.5 instead of .NET 4.0. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jaromír Matýšek Sent: Monday, March 28, 2011 8:09 AM To: iro...@googlegroups.com Subject: [IronPython] IPy 2.7 successfully built for .NET 3.5, but problem w. indirect v4 dependencies Hi, I've suceeded building 2.7 for .NET 3.5 (I'm using it in SharePoint, so there's no way to use .NET 4) and it works, using v2release configuration. I've built IronPython, IronPython.Modules, Microsoft.Dynamic, Microsoft.Scripting and Microsoft.Scripting.Core dlls. However, when I reference my class library (which is referencing my custom-built 2.7 dlls) from another solution and try to compile, I get several instances of the following warning and of course errors wherever I'm using some of my class library functions: The primary reference SPTools ... could not be resolved because it has an indirect dependency on the .NET Framework assembly mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 which has a higher version 4.0.0.0 than the version 2.0.0.0 in the current target framework. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets I've now spent a day and half trying to get rid of this problem. I've combed through the project files - they're all switched to v2, there's nothing even vaguely v4 related, it all compiles too, the problem remains. I'd be very grateful for any ideas. Thanks Jaromír Matýšek ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronLanguages
Matthias wrote: Yes, this was my main idea. It's very similar how SWIG directors handle cross-language polymorphism. At runtime I'd create a class which derives from TestClass and which overrides all virtual methods and properties. The C# overrides would call the JSObject to see if there's a javascript implementation for them. If there is, it will call the javascript implementation, otherwise it will call the base class's (TestClass in the example) implementation. Ok, then you totally want to look at NewTypeMaker in either IronRuby or IronPython - they're slightly different but they both do the same thing and already handle all sorts of corner cases w/ .NET types so it should be a good starting point. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython2.7 import locking error
It looks like the CRT implements this by calling the LockFile/UnlockFile Win32 APIs (potentially retrying w/ 1 second between tries depending on the mode) so we could do that ourselves w/ the OS file handles. -Original Message- From: Jeff Hardy [mailto:jdha...@gmail.com] Sent: Friday, March 25, 2011 11:08 AM To: Discussion of IronPython Cc: Dino Viehland Subject: Re: [IronPython] IronPython2.7 import locking error On Thu, Mar 24, 2011 at 6:41 PM, Dino Viehland di...@microsoft.com wrote: Oh I see I missed the line containing msvcrt. This just looks like it hasn't been implemented (we still have only a very partially implemented version of msvcrt). It should be trivial to do add this , it should just be a P/Invoke out to msvcrt100, if someone wants to provide a patch. It seems to me that msvcrt.locking is actually quite tricky, as it normally uses the CRT file handles when calling the locking functions. We'd have to emulate the behavior using the .NET locking functions (or rewrite all of our file APIs to use the CRT). - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] The return value (out)
Is the method overloaded? There could be enough confusion w/overloads where we aren't picking the right overload. Alternately you can do: import clr ref = clr.Reference[TPick]() And then call it with the reference value whose's .Value property will be updated on a successful call such as: int_res = EntityPick(ref, ...) print ref.Value If it is overloaded you can also index into the .Overloads property to select the proper overload but hopefully using Reference (which is an alias for StrongBox) should work. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Afan Olovcic Sent: Friday, March 25, 2011 7:24 PM To: Discussion of IronPython Subject: Re: [IronPython] The return value (out) Hi, It doesn't work I have an error message Microsoft.Scripting.ArgumentTypeException: expected StrongBox[TPick], got TMesh code: result, pick = LE.EntityPick(entity,10.0) On Sat, Mar 26, 2011 at 3:13 AM, Tomas Matousek tomas.matou...@microsoft.commailto:tomas.matou...@microsoft.com wrote: This should work: result, pick = EntityPick(entity) That is, out arguments are returned bundled in a tuple with the result of the method. Tomas From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com] On Behalf Of Afan Olovcic Sent: Friday, March 25, 2011 6:56 PM To: users@lists.ironpython.commailto:users@lists.ironpython.com Subject: [IronPython] The return value (out) Hi, Can somebody help me to solve this problem please ? in the .NET Assembly there is C# function: public static extern int EntityPick(out TPick pick, TEntity entity, float range = 100, float radius = 0, int collisionType = 0, PickFilterCallback pickfilter = null); how to call that function in ironPython and get return value of pick I can't find working solution Thanks ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython2.7 import locking error
Locking isn't part of the standard lib, did you install something into site packages called locking? -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of amy yau Sent: Thursday, March 24, 2011 3:18 PM To: users@lists.ironpython.com Subject: [IronPython] IronPython2.7 import locking error Hi I have some python library which compiled fine using Python2.5 But when using ironPython2.7 I got the following error from the console: from msvcrt import locking Traceback (most recent call last): File stdin, line 1, in module importError: Cannot import name locking I do not get any error mesaage when using the Python2.5 interactive window. Anyidea how I can make the standard library to compile on ironPython2.7? -- View this message in context: http://old.nabble.com/IronPython2.7-import-locking-error-tp31233423p31233423.html Sent from the IronPython mailing list archive at Nabble.com. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython2.7 import locking error
Oh I see I missed the line containing msvcrt. This just looks like it hasn't been implemented (we still have only a very partially implemented version of msvcrt). It should be trivial to do add this , it should just be a P/Invoke out to msvcrt100, if someone wants to provide a patch. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of amy yau Sent: Thursday, March 24, 2011 4:45 PM To: users@lists.ironpython.com Subject: Re: [IronPython] IronPython2.7 import locking error what I can see is when I import msvcrt on Python2.5 console and do a dir(msvcrt). it has a method called locking but when I import msvcrt on IronPython2.7 it does not have the method locking. What I can do is I will try to find out what the python lib does using this msvcrt module and modify it for IronPython2.7 standard library. Thanks Amy amy yau wrote: Hi I have some python library which compiled fine using Python2.5 But when using ironPython2.7 I got the following error from the console: from msvcrt import locking Traceback (most recent call last): File stdin, line 1, in module importError: Cannot import name locking I do not get any error mesaage when using the Python2.5 interactive window. Anyidea how I can make the standard library to compile on ironPython2.7? -- View this message in context: http://old.nabble.com/IronPython2.7-import-locking-error-tp31233423p31234024.html Sent from the IronPython mailing list archive at Nabble.com. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython tools - minor suggestion
Lukáš wrote: first off, the IronPython Tools for VS 2010 are really great! Could you open bugs for these? I'd suggest opening them on pytools.codeplex.com just because that seems like the more likely future of Python tooling in VS. But you could open them on ironpython.codeplex.com in case there's someone who will fix them there. However, one minor suggestion: could you please add an option to remove the annoying wavy underline for error highlighting in the code? This should be easy. And also could you add tab (indentation) vertical guides (like SciTe has) for easier indent navigation in heavily nested code? Is this something like the vertical lines in this image? http://www.autohotkey.net/~mosaic/NPP/2007-06-07_084710_npp.jpg Or do you have a link to an image of what you'd want? This one might not be so easy but it'd be good to capture it in a list of possible features. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] PTVS question
Chuck wrote: And a follow up question about Python Tools for Visual Studio I would have expected that the Interactive Window has the same context as an IronPython script that is currently being debugged so that one can inspect variables, exec methods, while debugging. This is how PythonWin always worked. Is this the case? Or not. It doesn't seem to work. Could you file a feature request for this on pytools.codeplex.com? Some IDEs have both a debug REPL as well as a development REPL and we may eventually add a debug REPL. But currently we only have the development REPL which we setup so it can import your projects files but isn't attached to the debug process. That also means it's state remains unmodified as you debug and stop debugging which is kind of handy. Until it's implemented there is the immediate window which will give you some limited REPL like capabilities against the process being debugged. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] PTVS question
Charles wrote: For both. Just now I added an: import os Print os.getcwd() (don't know why that didn't dawn on me before) and it prints the solution/project directory. Even so, somehow it ignores the app.config unless I drop it into the IPy dir. This works, but its not ideal if one has apps with a different app.config. Perhaps there is/should be a way to copy Ipy.exe to my project dir and get it to use the local copy of the app.config? I see, I think this is effectively this issue: http://ironpython.codeplex.com/workitem/26165 We need to add a feature to IronPython to support starting an app domain with a user supplied app configuration file. Then we can run the code in that app domain and it'll have the correct configuration in place. It's not really a PTVS issue but once that feature is implemented we could easily support it in PTVS with both the IronPython launcher and even the default Python launcher. It should be a pretty simple feature to implement if anyone out there was looking for something straight forward to get started with. :) ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.7 Now Available
The PTVS release is really an extended version of the tools in IronPython 2.7. It adds support for CPython including debugging, profiling, etc... while still supporting IronPython as well. We'll likely either replace the tools distributed w/ IronPython with this version (maybe minus things like HPC support) or we'll pull the IpyTools out of the distribution and encourage people to go for the separate download. No changes will likely happen until IronPython 3.x though as 2.7 is now out the door and it'd be a pretty significant change. For the time being you'll need to choose one or the other - you can always choose to not by either not installing the IpyTools w/ the IronPython install and install the PTVS or you can just stick w/ the existing IronPython tools. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Medcoff, Charles Sent: Sunday, March 13, 2011 2:15 PM To: Discussion of IronPython; python-list Subject: Re: [IronPython] IronPython 2.7 Now Available Can someone on the list clarify differences or overlap between the tools included in this release, and the PTVS release? ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.7 Now Available
You'll need to install the integrated shell - the express editions unfortunately don't allow extensions to be installed but the integrated shell is basically a blank VS which does support installing extensions. It's available here: http://www.microsoft.com/downloads/en/details.aspx?familyid=8E5AA7B6-8436-43F0-B778-00C3BCA733D3displaylang=en Once you have that installed you can re-run the IronPython installer and you'll have the option of installing the tools. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Medcoff, Charles Sent: Sunday, March 13, 2011 3:59 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.7 Now Available Sorry - I had forgot about the free editions. Yes they may work with those. The older set of tools for IPy are optional part of the install. Assuming you installed with that option, new templates for IPY appear within Visual Studio. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Lukáš Dubeda Sent: Sunday, March 13, 2011 3:57 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.7 Now Available I've downloaded the Visual Studio for C# 2010 Express. Last time I was checking out the VS tools they worked on the Express edition. Did they remove this functionality of the free Express version? That'd suck! Lukáš Duběda Director [T] +420 602 444 164 duber studio(tm) [M] i...@duber.cz [W] http://www.duber.cz [A] R.A.Dvorského 601, Praha 10 [A] 10900, Czech Republic, Europe On 13.3.2011 20:54, Medcoff, Charles wrote: The python tools are only extensions to the existing Visual Studio product. You have to own a copy of Visual Studio - they must be purchased from Microsoft or an MS software distributor. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukáš Dubeda Sent: Sunday, March 13, 2011 3:15 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.7 Now Available Sorry to hijack the thread, however, where exactly do I get the Visual Studio tools? Are they included in the IPy 2.7 installation? I installed everything in there, but I can't seem to find the link in the Visual Studio. I have to admit I have very little knowledge of Visual Studio, though. Lukáš Duběda Director [T] +420 602 444 164 duber studio(tm) [M] i...@duber.cz [W] http://www.duber.cz [A] R.A.Dvorského 601, Praha 10 [A] 10900, Czech Republic, Europe On 13.3.2011 19:24, Medcoff, Charles wrote: Thanks that helps. I've tried the first option. Not doing much Python stuff at the moment, but I'll follow up if I experience any issues with this approach. I'm very excited that both the language and tools support is forging ahead - thanks all. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Sunday, March 13, 2011 2:22 PM To: Discussion of IronPython; python-list Subject: Re: [IronPython] IronPython 2.7 Now Available The PTVS release is really an extended version of the tools in IronPython 2.7. It adds support for CPython including debugging, profiling, etc... while still supporting IronPython as well. We'll likely either replace the tools distributed w/ IronPython with this version (maybe minus things like HPC support) or we'll pull the IpyTools out of the distribution and encourage people to go for the separate download. No changes will likely happen until IronPython 3.x though as 2.7 is now out the door and it'd be a pretty significant change. For the time being you'll need to choose one or the other - you can always choose to not by either not installing the IpyTools w/ the IronPython install and install the PTVS or you can just stick w/ the existing IronPython tools. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Medcoff, Charles Sent: Sunday, March 13, 2011 2:15 PM To: Discussion of IronPython; python-list Subject: Re: [IronPython] IronPython 2.7 Now Available Can someone on the list clarify differences or overlap between the tools included in this release, and the PTVS release? ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Python Tools for Visual Studio
(I'll post this on my blog as soon as I can login into it, but it's been so long I'm having issues. Anyway it seems appropriate for this alias as well): Some people may have been wondering what I've been working on since IronPython was released into the wild and late last night we announced it - Python Tools for Visual Studio [http://pytools.codeplex.com/]. For me this was an awesome opportunity to continue work on a Python focused open source project at Microsoft. I'm particularly excited I can extend the work we did to support IronPython in Visual Studio and add in support for CPython and other Python implementations. I'm also really happy to be able to continue work with the Python community. PTVS keeps all the features we had in IronPython Tools for VS and adds a bunch of new features. For starters we add support for both REPLs and debugging in CPython and other Python implementations. We also add profiling support for CPython, support for multiple language versions (2.5 through 3.2), and attach to process for CPython processes - both local and remote. Meanwhile we still support all the features we had before including great intellisense and drag and drop GUI development for IronPython. But we're also focusing on developing new features in a specific area - High Performance Computing. For our first beta we've focused on enabling two different scenarios - batch computing via MPI and interactive computing via IPython. For batch computing we support publishing to and running on the cluster via a simple F5 scenario . If you're not yet ready to run on the cluster you can do the same multi-process launch on the local machine. For interactive development we are focusing on the bleeding edge of IPython (.11+) where the new architecture is designed from the ground up to support parallel computing and alternate REPL UIs. If you're an IronPython user I encourage you to give the new tools a try - you'll first need to uninstall the tools feature in IronPython 2.7RC2 which you can do simply by re-running the MSI and choosing the change option. If you're a CPython user I hope you'll also give it a try - you should find that it'll support your existing CPython installs for Python 2.5 through 3.2. Thanks - I look forward to hearing your feedback. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Python Tools for Visual Studio
Can you elaborate on efficient? Do you mean response time or actual usefulness? IronPython does take a little while to bring up members for a type you haven't completed against yet because reflection is slow. But for CPython we have a separate database that's much faster. If it's actual usefulness you may find the PyTools analysis to be better as there have been some general improvements and bug fixes there. If you have some specific repros I'd love to hear about them so we can fix them. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Federico Vaggi Sent: Thursday, March 10, 2011 6:37 AM To: Discussion of IronPython Subject: Re: [IronPython] Python Tools for Visual Studio Thanks a lot for all the work Dino, I will give it a try for sure. I am not sure what other IDE people use for Python code writing, but I found that the auto-complete feature in pydev (the Eclipse plug-in) was a lot more efficient than the autocomplete for Ironpython. Federico On 10/03/2011 15:30, Dino Viehland wrote: (I'll post this on my blog as soon as I can login into it, but it's been so long I'm having issues. Anyway it seems appropriate for this alias as well): Some people may have been wondering what I've been working on since IronPython was released into the wild and late last night we announced it - Python Tools for Visual Studio [http://pytools.codeplex.com/]. For me this was an awesome opportunity to continue work on a Python focused open source project at Microsoft. I'm particularly excited I can extend the work we did to support IronPython in Visual Studio and add in support for CPython and other Python implementations. I'm also really happy to be able to continue work with the Python community. PTVS keeps all the features we had in IronPython Tools for VS and adds a bunch of new features. For starters we add support for both REPLs and debugging in CPython and other Python implementations. We also add profiling support for CPython, support for multiple language versions (2.5 through 3.2), and attach to process for CPython processes - both local and remote. Meanwhile we still support all the features we had before including great intellisense and drag and drop GUI development for IronPython. But we're also focusing on developing new features in a specific area - High Performance Computing. For our first beta we've focused on enabling two different scenarios - batch computing via MPI and interactive computing via IPython. For batch computing we support publishing to and running on the cluster via a simple F5 scenario . If you're not yet ready to run on the cluster you can do the same multi-process launch on the local machine. For interactive development we are focusing on the bleeding edge of IPython (.11+) where the new architecture is designed from the ground up to support parallel computing and alternate REPL UIs. If you're an IronPython user I encourage you to give the new tools a try - you'll first need to uninstall the tools feature in IronPython 2.7RC2 which you can do simply by re-running the MSI and choosing the change option. If you're a CPython user I hope you'll also give it a try - you should find that it'll support your existing CPython installs for Python 2.5 through 3.2. Thanks - I look forward to hearing your feedback. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Python Tools for Visual Studio
Thanks for the feedback! #1 is surprising... Was it Ipy 2.7 RC2? We won't pick up IronPython 2.6 but I can probably make that work as well. We'll need to use the generic-(C)Python integration rather than the IronPython specific integration for that so you won't get automatic support for clr.AddReference() and friends which you do w/ 2.7. I can definitely fix #3 and make it more robust so we don't crash. For #4 you'll also need to install the HPC client utilities (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0a7ba619-fe0e-4e71-82c8-ab4f19c149ad) although that's not your particular build problem. You should just need to do: sn -Vr *,b03f5f7f11d50a3a from a VS command prompt. If you're on a 64-bit machine you'll need to do that from a normal VS command prompt as well as a 64-bit command prompt. This is different from the normal IpyTools because we use a MS key which we don't have the full key for. Alternately you can do a bunch of sn -Vr commands for the individual assemblies if you don't want to disable strong name verification for everything w/ that key. That's the same key that all of the Visual Studio assemblies are signed with. If you'd like you can open bugs on pytools.codeplex.com for #1-#3 (or if you don't I'll go ahead and open them later today). -Original Message- From: Steve Dower [mailto:s.j.do...@gmail.com] Sent: Thursday, March 10, 2011 4:03 PM To: Discussion of IronPython Cc: Dino Viehland Subject: Re: [IronPython] Python Tools for Visual Studio This is great! First reports: 1. The installer refused to work until I completely removed IronPython - not just the VS tools (I'm okay with this, I tend to use repo builds of IronPy anyway.) 2. I love that it detects my Python installs (though apparently not my IronPython 2.6 install?) and including all files by default is far more robust than it was back when I complained about it. 3. Opening a .py file caused a crash in Microsoft.PythonTools.Analysis (submitted through WER): 'key __next__ was not found'. This is apparently due to my file being for Python 2.7 but the default interpreter being Python 3.2. (Obviously using a project with the right setting fixes this.) Stack trace: at Microsoft.PythonTools.Analysis.Values.BuiltinNamespace`1.get_Item(String name) at Microsoft.PythonTools.Analysis.Values.GeneratorInfo..ctor(FunctionInfo functionInfo) at Microsoft.PythonTools.Analysis.Interpreter.ExpressionEvaluator.EvaluateYiel d(ExpressionEvaluator ee, Node node) at Microsoft.PythonTools.Analysis.Interpreter.ExpressionEvaluator.EvaluateWo rker(Node node) at Microsoft.PythonTools.Analysis.Interpreter.DDG.Walk(ExpressionStatement node) at Microsoft.PythonTools.Parsing.Ast.ExpressionStatement.Walk(PythonWalke r walker) at Microsoft.PythonTools.Parsing.Ast.SuiteStatement.Walk(PythonWalker walker) at Microsoft.PythonTools.Analysis.Interpreter.DDG.Walk(WhileStatement node) at Microsoft.PythonTools.Parsing.Ast.WhileStatement.Walk(PythonWalker walker) at Microsoft.PythonTools.Parsing.Ast.SuiteStatement.Walk(PythonWalker walker) at Microsoft.PythonTools.Analysis.Interpreter.FunctionAnalysisUnit.AnalyzeWo rker(DDG ddg) at Microsoft.PythonTools.Analysis.Interpreter.DDG.Analyze(Deque`1 queue) at 4. I was unable to build the code in the repository (from the VS 2010 command prompt, x86 tools, latest VSSDK installed). I've attached the entire msbuild output, the command line I used is below and the warning/error output is below that. msbuild /t:Rebuild /p:Configuration=Debug /p:Platform=Any CPU PythonTools.sln D:\...\Projects\pytools.hg.cp\PythonTools.sln (Rebuild target) (1) - D:\...\Projects\pytools.hg.cp\Release\Tests\AnalysisTest\AnalysisTest.cspr oj (Rebuild target) (3) - D:\...\Projects\pytools.hg.cp\Release\Tests\Common\TestUtilities\TestUtili ties.csproj (default target) (15:2) - (StyleCop target) - VSUtility.cs(1,1): warning : SA1633: The file has no header, the header Xml is invalid, or the header is not located at the top of the file. [D:\...\Projects\pytools.hg.cp\Release\Tests\Common\TestUtilities\TestUtili ties.csproj] IWarningLogger.cs(1,1): warning : SA1633: The file has no header, the header Xml is invalid, or the header is not located at the top of the file. [D:\...\Projects\pytools.hg.cp\Release\Tests\Common\TestUtilities\TestUtili ties.csproj] AssertListener.cs(1,1): warning : SA1633: The file has no header, the header Xml is invalid, or the header is not located at the top of the file. [D:\...\Projects\pytools.hg.cp\Release\Tests\Common\TestUtilities\TestUtili ties.csproj] D:\...\Projects\pytools.hg.cp\PythonTools.sln (Rebuild target) (1) - D:\...\Projects\pytools.hg.cp\Release\Tests\AnalysisTest\AnalysisTest.cspr oj (Rebuild target) (3) - D:\...\Projects\pytools.hg.cp\Release\Product\Python\IronPython\IronPyt hon.csproj (default target) (7
Re: [IronPython] IronPython @ PyCon 2011
I'm there Wednesday through Monday morning. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Brian Curtin Sent: Monday, March 07, 2011 8:47 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython @ PyCon 2011 On Mon, Mar 7, 2011 at 10:42, Jeff Hardy jdha...@gmail.commailto:jdha...@gmail.com wrote: I'll be there, and so will Dino (with something very cool to show off). Anybody else? - Jeff I'll be there Wednesday night through Tuesday night. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Road to IronPython 2.7 (update)
Can you run w/ -X:ExceptionDetail? My guess is there's something different about Mono's big integer implementation when you do bigInt.ToString(X). We used to convert the string to hex ourselves but that was slower than .NETs ToString implementation so I switched to using ToString instead (and uuid goes through this path). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Tristan Zajonc Sent: Monday, February 21, 2011 6:11 PM To: Discussion of IronPython Subject: Re: [IronPython] Road to IronPython 2.7 (update) There seems to be some regressions between 2.6 and 2.7 for OSX/Mono. In particular, in addition to the traceback bug, the uuid module still has a problem: http://ironpython.codeplex.com/workitem/28904 Given that uuid appears all over the place, this is relatively serious, I think. I'd look into these, but the standard IronPython solution doesn't compile on OSX/Mono. Tristan On Mon, Feb 21, 2011 at 7:31 PM, Jimmy Schementi ji...@schementi.commailto:ji...@schementi.com wrote: I can do a quick test pass of the silverlight support. ~Jimmy On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower s.j.do...@gmail.commailto:s.j.do...@gmail.com wrote: The tools problem seems to be to do with the installer. IPyTools (PythonRuntimeHost.cs:89-100) tries to load the installed path from HKLM\SOFTWARE\IronPython\2.7\(default). On my machine (Win7 x64, IPy 2.7 RC1 installed without IPyTools, which were built from source) this is actually in HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) which contains ipy64, which is then combined (PythonStarter.cs:69) with ipy.exe to make ipy64\ipy.exe as the interpreter path (which doesn't exist). If I set HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) to my actual install path (where ipy.exe is) it works fine. I assume this should be done in the installer. Steve On Tue, Feb 22, 2011 at 10:12, Jeff Hardy jdha...@gmail.commailto:jdha...@gmail.com wrote: Hi all, The following issues are blockers for IronPython 2.7: * #29841 - sysconfig traceback when starting 2.7B1 - http://ironpython.codeplex.com/workitem/29841 I don't know enough about Mono/MacOS/POSIX to fix this one properly. I haven't yet chercked what the Mono guys did to get it working on Linux. * (no issue) - Visual Studio tools The Visual Studio tools are basically broken right now - I can't launch or debug even the default console program. I think it's because it can't find the interpreter, but I thought I fixed that already. * (no issue) - silverlight support I have no idea what the status of the silverlight support is. Once these are resolved (one way of another) I think 2.7 will be ready to go. - Jeff P.S. In all honesty I would have preferred to call the latest release Beta 3 instead of RC1, but I had already changed the version strings and didn't want to change them back :|. ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Arright dangit! Where is the OFFICIAL IronPython source code?
It's actually IronLanguages as it's where both IronPython and IronRuby are being developed out of - https://github.com/IronLanguages/main From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Vernon Cole Sent: Sunday, February 20, 2011 2:17 PM To: Jeff Hardy Cc: Discussion of IronPython Subject: Re: [IronPython] Arright dangit! Where is the OFFICIAL IronPython source code? I searched on Github for the keyword IronPython. The search returns 20 repositories and 399 source trees. None of the repositories seems to be IronPython. I only checked the first 25 source references What's the URL? -- Vernon On Sun, Feb 20, 2011 at 2:54 PM, Jeff Hardy jdha...@gmail.commailto:jdha...@gmail.com wrote: Github is the master source. And yes, the various websites need straightening out. - Jeff On Sun, Feb 20, 2011 at 9:42 AM, Vernon Cole vernondc...@gmail.commailto:vernondc...@gmail.com wrote: I've lost my link, and cannot muddle my way to meaningful results on either Codeplex, Wikepedia or Github. Github actually refers me back to Codeplex, where the most recent release is October of last year. What is the URL to the real, true, current official source for IronPython? -- Vernon Cole ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] List of easy to fix issues
I've updated the bugs list on the contributing to IronPython page - some of the bugs were fixed and I've added some more. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Richard Nienaber Sent: Thursday, February 17, 2011 11:12 PM To: Discussion of IronPython Subject: Re: [IronPython] List of easy to fix issues For a list of easy to fix issues, the Contributing to IronPythonhttp://ironpython.codeplex.com/wikipage?title=Contributing%20to%20IronPythonreferringTitle=Home page on Codeplex has a few suggestions. You may also want to look at Repository Instructionshttp://ironpython.codeplex.com/wikipage?title=Respository%20InstructionsreferringTitle=Home to get at the source on githubhttps://github.com/IronLanguages/main. Richard On Fri, Feb 18, 2011 at 5:29 AM, haniti grk haniti@gmail.commailto:haniti@gmail.com wrote: I am trying to get my feet wet with IronPython, can anyone come with a new list of easy to fix issues? Guidance is also appreciated. ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Red Flag(?) change in import
This is fixed now. Apparently there was an invalid optimization that I added - so I removed it. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Vernon Cole Sent: Thursday, February 10, 2011 3:50 PM To: Discussion of IronPython Subject: Re: [IronPython] Red Flag(?) change in import Okay, I have filed codeplex issue 30143 for this, with a simple test module which demonstrates the problem. This completely breaks adodbapi, and would probably kill many other imported modules. I think someone should go in an jack up the priority to high. IMHO it is a release breaker. Is not adodbapi still part of the test suite? The failure should have shown up there. -- Vernon Cole On Thu, Feb 10, 2011 at 3:42 AM, Federico Vaggi va...@cosbi.eumailto:va...@cosbi.eu wrote: I ran into a relatively similar problem with importing networkx into IronPython, but was able to fix it by editing out a few of the lines. It seems that the import behaviour in cpython and ironpython is slightly different sometime. I can post a list of the steps that I took if it is helpful at all. Federico On 09/02/2011 23:45, Vernon Cole wrote: I can't see an item like this on the bug list. Perhaps the sky is falling, perhaps, not. I am reporting the problem here in case it is. It seems like something the big guns should be made aware of right away. The behavior seems to have changed since IPy 2.6, and if someone has indeed been working on import then we have a regression. First here's CPython 2.7 -- I install the package and then import it from another directory... console dump C:\hg\adodbapipy27 setup.py install C:\hg\adodbapic:\python27\python.exe setup.py install adodbapi version=2.4.0.2 running install running build running build_py copying adodbapi.py - build\lib\adodbapi copying ado_consts.py - build\lib\adodbapi copying __init__.py - build\lib\adodbapi running install_lib copying build\lib\adodbapi\adodbapi.py - c:\python27\Lib\site-packages\adodbapi running install_egg_info Writing c:\python27\Lib\site-packages\adodbapi-2.4.0.2-py2.7.egg-info C:\hg\adodbapihome C:\hg\adodbapiC: C:\hg\adodbapicd \Users\vernon C:\Users\vernonpy27 C:\Users\vernonc:\python27\python.exe Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import adodbapi adodbapi.version 'adodbapi v2.4.0.2' /console ... The version attribute works Now I try the same thing on an administrator console (I think that IronPython is correct in required the higher privilege here) and a big THANK YOU for having a working distutils! console AS ADMINISTRATOR dump C:\hg\adodbapiipy setup.py install C:\hg\adodbapic:\program files\IronPython 2.7\ipy.exe setup.py install adodbapi version=2.4.0.2 running install running build running build_py copying adodbapi.py - build\lib\adodbapi copying ado_consts.py - build\lib\adodbapi copying __init__.py - build\lib\adodbapi warning: build_py: byte-compiling is disabled, skipping. running install_lib warning: install_lib: byte-compiling is disabled, skipping. running install_egg_info Removing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2. 7.egg-info Writing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.7 .egg-info C:\hg\adodbapihome C:\hg\adodbapiC: C:\hg\adodbapicd \Users\vernon C:\Users\vernonipy C:\Users\vernonc:\program files\IronPython 2.7\ipy.exe IronPython 2.7 Beta 2 (2.7.0.20) on .NET 4.0.30319.1 Type help, copyright, credits or license for more information. import adodbapi adodbapi.version Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'module' object has no attribute 'version' /console . Where did the attribute go?? Now I hand copy the adodbapi folder from IronPython 2.7 site-packages into IronPython 2.6 site packages (because 2.6 distutils will not work) and continue with the same admin console... console dump continues exit() C:\Users\vernonipy26 C:\Users\vernonc:\program files\Ironpython 2.6\ipy.exe IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.4206 Type help, copyright, credits or license for more information. import adodbapi adodbapi.version 'adodbapi v2.4.0.2' /console so it seems to me that import is badly broken. I am unable to test adodbapi. The code I am testing is at: hg clone http://adodbapi.hg.sourceforge.net:8000/hgroot/adodbapi/adodbapi#main Is there anything I should do? -- Vernon ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Contents of Lib (packaging for RPM)
Andrew wrote: On Wed, Feb 9, 2011 at 2:42 PM, Dino Viehland di...@microsoft.com wrote: In the case of IronPython the script is just pulling the files from Languages/IronPython/StdLib/StdLib.pyproj so you could just go straight to that MSbuild file to get the list of files to use. StdLib.pyproj is generated from Languages/IronPython/StdLib/MakeModuleList.py which you could run on Linux to see if there's any differences between the modules which can be successfully imported. Excellent. Thank you! For now I'll just parse StdLib.pyproj, in future I'll modify MakeModuleList.py to work on Linux and output a plain list of paths or something. Further question though: when I build using xbuild Solutions/IronPython.Mono.sln some files get put into bin/Configuration/Lib, specifically __future__.py iptest/ runpy.py site.py, and these files are not the same as the ones in External.LCA_RESTRICTED. Which one should be in my Lib directory in my package? You want the ones from External.LCA_RESTRICTED. These are skeleton versions of Those files there that enable running w/o the standard library. We used to run all of tests both w/ and w/o the CPython std lib but we no longer do that - we now always run w/ the std lib so these are probably obsolete. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Red Flag(?) change in import
If no one else steps up to look at it I can take a look this weekend. But let me tell everyone fixing import bugs is awesome fun! I thought adodbapi was still part of the test suite but I don't know how it transitioned when MS gave the project to the community. It may have not been pushed out and may need to be re-added. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Vernon Cole Sent: Thursday, February 10, 2011 3:50 PM To: Discussion of IronPython Subject: Re: [IronPython] Red Flag(?) change in import Okay, I have filed codeplex issue 30143 for this, with a simple test module which demonstrates the problem. This completely breaks adodbapi, and would probably kill many other imported modules. I think someone should go in an jack up the priority to high. IMHO it is a release breaker. Is not adodbapi still part of the test suite? The failure should have shown up there. -- Vernon Cole On Thu, Feb 10, 2011 at 3:42 AM, Federico Vaggi va...@cosbi.eumailto:va...@cosbi.eu wrote: I ran into a relatively similar problem with importing networkx into IronPython, but was able to fix it by editing out a few of the lines. It seems that the import behaviour in cpython and ironpython is slightly different sometime. I can post a list of the steps that I took if it is helpful at all. Federico On 09/02/2011 23:45, Vernon Cole wrote: I can't see an item like this on the bug list. Perhaps the sky is falling, perhaps, not. I am reporting the problem here in case it is. It seems like something the big guns should be made aware of right away. The behavior seems to have changed since IPy 2.6, and if someone has indeed been working on import then we have a regression. First here's CPython 2.7 -- I install the package and then import it from another directory... console dump C:\hg\adodbapipy27 setup.py install C:\hg\adodbapic:\python27\python.exe setup.py install adodbapi version=2.4.0.2 running install running build running build_py copying adodbapi.py - build\lib\adodbapi copying ado_consts.py - build\lib\adodbapi copying __init__.py - build\lib\adodbapi running install_lib copying build\lib\adodbapi\adodbapi.py - c:\python27\Lib\site-packages\adodbapi running install_egg_info Writing c:\python27\Lib\site-packages\adodbapi-2.4.0.2-py2.7.egg-info C:\hg\adodbapihome C:\hg\adodbapiC: C:\hg\adodbapicd \Users\vernon C:\Users\vernonpy27 C:\Users\vernonc:\python27\python.exe Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import adodbapi adodbapi.version 'adodbapi v2.4.0.2' /console ... The version attribute works Now I try the same thing on an administrator console (I think that IronPython is correct in required the higher privilege here) and a big THANK YOU for having a working distutils! console AS ADMINISTRATOR dump C:\hg\adodbapiipy setup.py install C:\hg\adodbapic:\program files\IronPython 2.7\ipy.exe setup.py install adodbapi version=2.4.0.2 running install running build running build_py copying adodbapi.py - build\lib\adodbapi copying ado_consts.py - build\lib\adodbapi copying __init__.py - build\lib\adodbapi warning: build_py: byte-compiling is disabled, skipping. running install_lib warning: install_lib: byte-compiling is disabled, skipping. running install_egg_info Removing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2. 7.egg-info Writing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.7 .egg-info C:\hg\adodbapihome C:\hg\adodbapiC: C:\hg\adodbapicd \Users\vernon C:\Users\vernonipy C:\Users\vernonc:\program files\IronPython 2.7\ipy.exe IronPython 2.7 Beta 2 (2.7.0.20) on .NET 4.0.30319.1 Type help, copyright, credits or license for more information. import adodbapi adodbapi.version Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'module' object has no attribute 'version' /console . Where did the attribute go?? Now I hand copy the adodbapi folder from IronPython 2.7 site-packages into IronPython 2.6 site packages (because 2.6 distutils will not work) and continue with the same admin console... console dump continues exit() C:\Users\vernonipy26 C:\Users\vernonc:\program files\Ironpython 2.6\ipy.exe IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.4206 Type help, copyright, credits or license for more information. import adodbapi adodbapi.version 'adodbapi v2.4.0.2' /console so it seems to me that import is badly broken. I am unable to test adodbapi. The code I am testing is at: hg clone http://adodbapi.hg.sourceforge.net:8000/hgroot/adodbapi/adodbapi#main Is there anything I should do? -- Vernon ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com
Re: [IronPython] Stopping, Closing, and Unloading of running IronPython code?
Doug wrote: If you have embedded IronPython engines (and perhaps a few other DLR languages) running in a thread, what is the recommended method of stopping the running programs, and calling the objects' delete methods? For example, say you have a serial port open in an IronPython program running in a thread, and you want to stop the thread, and close the port? Is there something general that would take care of all closing, just like it would if you killed a process? Thanks for any suggestions, You can run the code in an app domain and then just unload the app domain. Any code running in the app domain will be Thread.Abort'd by the CLR and all of the finalizers will run once the threads have been killed - and that should close the serial port or any other resources. Any code with finally blocks and the such will still be given a chance to cleanup as well. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Cast to a method pointer using CTYPES
You want to pass a Python function, method, or other callable into C as a
function pointer? This stack overflow question covers that:
http://stackoverflow.com/questions/874245/python-ctypes-and-function-pointers
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Andrew Evans
Sent: Wednesday, February 09, 2011 10:41 AM
To: users@lists.ironpython.com
Subject: [IronPython] Cast to a method pointer using CTYPES
Forgive me if what I ask is a novice question. I have some C code that was
asked to bring to Python I prefer IronPython and remember seeing that CTYPES
was implemented into it :-)
I am not really the best C coder and was suggested by C coders that it couldn't
be done in Python. I aim to prove them wrong
int main(int argc, char **argv)
{
int (*func)();
func = (int (*)()) myCode;
printf(myCode Length is : %d,strlen(myCode));
(int)(*func)();
}
is it possible to cast to a function pointer in IronPython using CTYPES I was
looking at the CTYPES docs and from what I understand CTYPES has something
called callback functions.
Anyway any idea or help
would be very valuable
Thank You
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Cast to a method pointer using CTYPES
So you want to generate the assembly in memory and then execute it? I think
you want something like:
import array
myCode = array.array('b',
\x31\xc0\x31\xdb\x31\xc9\x31\xd2\x51\x68\x6c\x6c\x20\x20\x68\x33)
buffer = myCode.buffer_info()[0]
from ctypes import *
my_callback = CFUNCTYPE(c_int)
my_callback(buffer)()
This creates an array from your code, and then gets the address of that array.
Then it creates a callback type which just returns an int, and then it creates
an instance of that callback type using the address of the code and calls that
instance (which then causes an access violation when I run this).
If you're on a machine w/ the NX bit you may need to call VirtualAlloc and copy
the bytes to the allocated executable memory rather than using a buffer.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Andrew Evans
Sent: Wednesday, February 09, 2011 12:23 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Cast to a method pointer using CTYPES
Hey thank you for the fast reply :-)
I am working on building a security framework in Python for exploit development
as a part time hobby. But I am missing something key to what I am doing. I am
having a hard time understanding it as well.
from ctypes import *
myCode = (\x31\xc0\x31\xdb\x31\xc9\x31\xd2
\x51\x68\x6c\x6c\x20\x20\x68\x33) #example hex not full for post don't
want to put up red flags
my_callback = CFUNCTYPE(c_int, c_void_p,
POINTER(myCode),
POINTER(c_int32), c_void_p)
print type(my_callback)
this returns type '_ctypes.PyCFuncPtrType' which is what I want I assume.
but when I run this code nothing happens. Maybe in how I am running it just by
adding my_callback to the source. Any idea what I am doing wrong.
*cheers in advance if you can help
If not I understand
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Contents of Lib (packaging for RPM)
In the case of IronPython the script is just pulling the files from Languages/IronPython/StdLib/StdLib.pyproj so you could just go straight to that MSbuild file to get the list of files to use. StdLib.pyproj is generated from Languages/IronPython/StdLib/MakeModuleList.py which you could run on Linux to see if there's any differences between the modules which can be successfully imported. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Tomas Matousek Sent: Wednesday, February 09, 2011 1:01 PM To: Discussion of IronPython Cc: ironruby-c...@rubyforge.org Subject: Re: [IronPython] Contents of Lib (packaging for RPM) [Including IronRuby list]. We have a script in Msi directory called harvest.rb. This is used by another scripts Msi\Python\generate_wxis.rb and Msi\Ruby\generate_wxis.rb that launch it with Python and Ruby specific parameters, respectively. The generated .wxi files fully describe the files and directory hierarchy that is created by the Windows installer on the target machine. I think you can easily run them thru a script that converts them to whatever format you need. They are just XML files. Would it be possible to create a script (Python or Ruby) that builds RPM package and runs on Windows as well? This would allow us to build new releases in one pass on a single machine and just publish the Mac packages on CodePlex next to .msi's. Let me know if you had any issues. Tomas -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Andrew Jorgensen Sent: Wednesday, February 09, 2011 12:42 PM To: users@lists.ironpython.com Subject: [IronPython] Contents of Lib (packaging for RPM) Hello Folks, First let me thank you for making IronPython easy to compile on Mono. I'm the release manager for the Mono Project at Novell and I'm currently working on packaging IronPython and IronRuby for openSUSE (also to be included in the Mono Mac framework package). Where I've run into trouble is the stdlibs for both. I can see that the -Bin.zip contains a Lib directory with various standard libraries in it but I don't see how I can reliably and repeatably get that exact content into my RPM packages (short of including the -Bin.zip in the build). Is there a script of some sort that takes the appropriate files from the correct source and puts them where I need them (the script used to build the - Bin.zip perhaps?) Thanks! Andrew Jorgensen ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Misleading test runner output /all VS /test:name_of_test
Daniel wrote: Please, help me wrap my head around this issue. Wanted to run unittests to see what areas need to be addressed. This is the tail of ... Languages\IronPython\IronPython\cpy test_univnewlines_cpy PASSED6.7633868 Languages\IronPython\IronPython\cpy test_weakref_cpy FAILED14.8568497 Languages\IronPython\IronPython\cpy test_zipfile_cpy DISABLED 0 Languages\IronPython\IronPython\cpy test_zipfile64_cpy DISABLED 0 Languages\IronPython\IronPython\modules modules_io_related_ipy PASSED15.1468663 Failed test summary: test_pyc_ipy modules_system_related_ipy test_subprocess_cpy test_weakref_cpy Total time: 1743.824741 seconds Immediately after that ran the failing test_subprocess_cpy individually and got a passing grade: C:\work\ironlangTest\TestRunner\TestRunner\bin\Debug\TestRunner.exe Test\IronPython.tests /test:test_subprocess_cpy /verbose Languages\IronPython\IronPython\cpy test_subprocess_cpy PASSED343.3856406 Total time: 343.428643 seconds I guess we can expect some variation in outcome there, due to random load effects on pipe throughput between subprocess and calling parent code, and I will check for that. Besides the randomness of conditions, are there variations in settings between /all and /test:name_of_test that would cause different test outcomes? The only difference between running a single test and running multiple tests is that we do attempt to run tests in parallel when we run multiple tests (by default we run 6 at a time which can be configured w/ the /threads: option). Test_subprocess is marked as being parallel safe so this can run w/ other processes. If it's failing only when run in parallel then it should be marked as being not-parallel safe and then it'll run at the end of the test run after all of the parallel safe tests have completed. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Bug Weekend prior to 2.7
Me too From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Richard Nienaber Sent: Thursday, February 03, 2011 12:11 PM To: Discussion of IronPython Subject: Re: [IronPython] Bug Weekend prior to 2.7 Anyone else willing and able to participate? I reckon I could find a couple of hours to help out. Count me in. Richard On Thu, Feb 3, 2011 at 7:35 PM, Jeff Hardy jdha...@gmail.commailto:jdha...@gmail.com wrote: I'd like to organize a bug weekend prior to the release of 2.7, to try and get some low-hanging fruit dealt with. For those not familiar with the idea, a couple of days are set aside and as many people as possible go through the issue tracker verifying bugs and creating patches and test cases, and getting those patches into the tree. Also, you don't have to dedicate your whole weekend; the idea is to get more people as possible involved by giving them an easy way to get their feet wet. I would rather see lots of people spend a couple of hours than a couple of people spend the whole weekend. There is no release scheduled (http://bit.ly/gJx2zI) for the weekend of Feb. 12, which would make it ideal to get bugs into RC1. I should be mostly free that weekend to help out. Anyone else willing and able to participate? - Jeff ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] indentation in VS2010
What are your settings in Tools-Options-Text Editor-IronPython-Tabs? Are you editing non-.py files and copying and pasting between the two within VS? If so are the tab settings for those file types or All Languages different? From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Pablo Dalmazzo Sent: Wednesday, February 02, 2011 8:09 AM To: IronPython Mailing list Subject: [IronPython] indentation in VS2010 Hi there, I just wanted to ask you if you get python missidentations when using VS2010 ultimate. I'm not reporting you to fix anything because it might be indeed VS2010 managing differently something, I just wanted to know if you get this behavior so I can confirm where it comes from and may be you know how to avoid it or workaroundit We use webforms. I suspect it's VS2010 because we didnt have these problems before (and before we used VS2008). We dont get this problems using the cPython idle either. I dont know if it's when we copy and paste pieces of code or what, but sometimes we have to open the files with another editor to fix the missindentations and it gets really annoying sometimes. I wouldnt be surprised if it's VS2010 because we are having other problems with it too. Greetings, Pablo ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Disabling optimized methods
You can use -X:Debug now to specifiy this at the command line. If you want to do it while you're hosting you can set the DebugMode option to true on the ScriptRuntimeSetup object used to create the ScriptRuntime. You'll need to make sure the ScriptSource's you create have filenames though. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings Sent: Tuesday, February 01, 2011 11:55 AM To: Discussion of IronPython Subject: [IronPython] Disabling optimized methods I was reading an old post by Dino here: http://www.mail-archive.com/users@lists.ironpython.com/msg04829.html that mentions that using -X:StaticMethods will force methods into types so that you can get the typical CLR-style debugging. I was wondering two things: 1. Is this still relavant to 2.7A1? 2. How do you specify such a flag when you're embedding IronPython in your application (building your own engine.) Thanks! ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Disabling optimized methods
Is Path on your ScriptSource non-null? That should be the only other thing which has an effect. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings Sent: Tuesday, February 01, 2011 12:51 PM To: Discussion of IronPython Subject: Re: [IronPython] Disabling optimized methods Alright, we're using DebugMode = true already (when the application starts with the debugger attached) so we must be seeing something else that is causing us to get the 'function has been optimized' message. Thanks From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, February 01, 2011 12:50 PM To: Discussion of IronPython Subject: Re: [IronPython] Disabling optimized methods You can use -X:Debug now to specifiy this at the command line. If you want to do it while you're hosting you can set the DebugMode option to true on the ScriptRuntimeSetup object used to create the ScriptRuntime. You'll need to make sure the ScriptSource's you create have filenames though. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel Jennings Sent: Tuesday, February 01, 2011 11:55 AM To: Discussion of IronPython Subject: [IronPython] Disabling optimized methods I was reading an old post by Dino here: http://www.mail-archive.com/users@lists.ironpython.com/msg04829.html that mentions that using -X:StaticMethods will force methods into types so that you can get the typical CLR-style debugging. I was wondering two things: 1. Is this still relavant to 2.7A1? 2. How do you specify such a flag when you're embedding IronPython in your application (building your own engine.) Thanks! ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Issue Triage
There's probably an Integer.py somewhere in sympy and this is probably an import bug. If someone was particularly ambitious they could re-write import by porting CPython's import to IronPython - viola, no more import bugs! :) Otherwise it's all about figuring out how we're differing in import semantics - I usually start import bugs by trying to re-create a simple repro of the issue and then work from there. I always thought import bugs but if you look at the CPython source code it might be much easier. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Bruce Bromberek Sent: Sunday, January 30, 2011 12:22 PM To: Discussion of IronPython Subject: [IronPython] Issue Triage I though I'd help by going through any issues tagged with High importance, unassigned, starting with ones from previous releases and seeing is they are still relevant. Issue 26426, which involves sympy (algebraic manipulation) under ironpython. With the most recent git version of sympy and IronPython 2.7B1, I get a better error message. C:\GITHUB\sympyc:\Program Files\IronPython 2.7\ipy.exe IronPython 2.7 Beta 1 (2.7.0.10) on .NET 4.0.30319.1 Type help, copyright, credits or license for more information. import sympy Traceback (most recent call last): File stdin, line 1, in module File C:\GITHUB\sympy\sympy\__init__.py, line 30, in module File C:\GITHUB\sympy\sympy\core\__init__.py, line 8, in module File C:\GITHUB\sympy\sympy\core\expr.py, line 1008, in module File C:\GITHUB\sympy\sympy\core\mul.py, line 962, in module File C:\GITHUB\sympy\sympy\core\power.py, line 806, in module File C:\GITHUB\sympy\sympy\core\add.py, line 516, in module File C:\GITHUB\sympy\sympy\core\symbol.py, line 6, in module File C:\GITHUB\sympy\sympy\logic\__init__.py, line 1, in module File C:\GITHUB\sympy\sympy\logic\boolalg.py, line 4, in module File C:\GITHUB\sympy\sympy\core\function.py, line 1091, in module ImportError: Cannot import name Integer Line 1091 is : from numbers import Rational, Integer I though the issue was 'Integer' as a reserved word in Ironpython. However, I can create a function or a class named Integer in the interpreter without a problem. Now I'm stuck. Any thoughts on how to proceed ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Visual Studio Interactive Shell Search Path:
Federico wrote: When testing a script using the IronPython interactive window in Visual Studio, the path variable in system.sys is a bunch of meaningless directories: import sys sys.path ['.', 'C:\\PROGRAM FILES (X86)\\MICROSOFT VISUAL STUDIO 10.0\\COMMON7\\IDE\\EXTENSIONS\\MICROSOFT\\IRONSTUDIO\\0.4\\Lib', 'C:\\PROGRAM FILES (X86)\\MICROSOFT VISUAL STUDIO 10.0\\COMMON7\\IDE\\EXTENSIONS\\MICROSOFT\\IRONSTUDIO\\0.4\\DLLs'] when I do the same operation in the IronPython console outside of Visual Studio, I get this: IronPython 2.7 Beta 1 (2.7.0.10) on .NET 4.0.30319.1 Type help, copyright, credits or license for more information. import sys sys.path ['.', 'C:\\Windows\\system32', 'C:\\Program Files (x86)\\IronPython 2.7\\Lib', ' C:\\Python27\\Lib\\site-packages', 'C:\\Python27\\Lib', 'C:\\Windows\\system32', 'C:\\Program Files (x86)\\IronPython 2.7\\DLLs', 'C:\\Program Files (x86)\\Iron Python 2.7'] when I do the same operation in Visual Studio, just executing a script (not in the interactive mode) I get this: ['C:\\Users\\FedeV\\Documents\\Systems Biology\\Fission Yeast\\Network Analysis\ \Source Code', '.', 'C:\\Users\\FedeV\\Documents\\Systems Biology\\Fission Yeast \\Network Analysis\\Source Code', 'C:\\Program Files (x86)\\IronPython 2.7\\Lib' , 'C:\\Python27\\Lib\\site-packages', 'C:\\Python27\\Lib', 'C:\\Users\\FedeV\\Do cuments\\Systems Biology\\Fission Yeast\\Network Analysis\\Source Code', 'C:\\Pr ogram Files (x86)\\IronPython 2.7\\DLLs', 'C:\\Program Files (x86)\\IronPython 2 .7'] Press any key to continue . . . I have set up an IRONPYTHONPATH variable in Windows, it seems that the interactive visual studio shell fails to import the proper path variable. Other than appending the correct directories to sys.path anyone know any 'proper' fix? If you reset the REPL window with your project window do you get the paths of your project? What I think may be happening here is that when you first start VS you don't have a project open but you do have the REPL open. The REPL is therefore created and is running inside of Visual Studio's directory. But when the REPL is created w/ a project open it'll property pick up the projects settings for where to start the REPL. You can also try Debug- Execute in Interactive Window which should reset the REPL and set it up properly. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Visual Studio Interactive Shell Search Path:
Federico wrote: Opening visual studio with no project open, and running the Ironpython interactive window, gives me this: import sys sys.path ['.', 'C:\\PROGRAM FILES (X86)\\MICROSOFT VISUAL STUDIO 10.0\\COMMON7\\IDE\\EXTENSIONS\\MICROSOFT\\IRONSTUDIO\\0.4\\Lib', 'C:\\PROGRAM FILES (X86)\\MICROSOFT VISUAL STUDIO 10.0\\COMMON7\\IDE\\EXTENSIONS\\MICROSOFT\\IRONSTUDIO\\0.4\\DLLs'] Making a dummy project, then running it via the debug command in interactive mode, gives me this: Running c:\users\fedev\documents\visual studio 2010\Projects\ConsoleApplication1\ConsoleApplication1\Program.py Remote process has been reset... ['.', 'C:\\PROGRAM FILES (X86)\\MICROSOFT VISUAL STUDIO 10.0\\COMMON7\\IDE\\EXTENSIONS\\MICROSOFT\\IRONSTUDIO\\0.4\\Lib', 'C:\\PROGRAM FILES (X86)\\MICROSOFT VISUAL STUDIO 10.0\\COMMON7\\IDE\\EXTENSIONS\\MICROSOFT\\IRONSTUDIO\\0.4\\DLLs'] It doesn't appear that having a project open fixes it. Where does the interactive window pick up its path from anyway? Or is it hardcoded? Ahh, I guess we're just setting the current working directory so that you can import things but we still don't include the standard lib in the path. So the . part is reasonable now but we're picking up Lib/DLLs from where we have our RemoteScriptFactory class. We probably need to figure out where ipy.exe is installed and call SetSearchPaths on the remote script engine in RemotePythonVsEvaluator.Initialize. PythonRuntimeHost.GetPythonInstallDir() already has the code for finding IronPython so it should be pretty easy to fix if anyone wants to give it a try. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Issue Triage
On Thu, Jan 27, 2011 at 6:38 AM, Richard Nienaber rjniena...@gmail.com wrote: Issues that reference 'SNAP' and 'merlin-*' e.g. SNAP: test_memory.py has begun failing IronPython: test_weakref.py fails on merlin-18 If the test passes, is it okay to close issues like this? I know SNAP was a Microsoft specific test running framework but I'm not sure about merlin-*. I think merlin was the code name for the DLR. If those tests are now passing, feel free to close them. Yep, and the merlin- here is just referring to a particular machine. These are both tests which can have intermittent failures due to their non-deterministic nature (waiting for the garbage collector to kick in and free memory/run finalizers). You might want to make sure the tests pass over multiple runs but generally speaking if they pass once then things are working. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Which modules collection to use?
Daniel wrote: Re: IRONPYTHONPATH It looks like the magic is already in place in dev.bat to set [IRON]PYTHONPATH to the right path. However, the setting is conditional on If DEFINED THISISSNAP I am not a stupid fella, but i had to resort to bugging you and asking about the modules set up. I am sure there are / were / will be other stumped ones. I wonder if this would be a big deal to change the dev.bat to set the right paths without relying on THISISSNAP being set. Since this would only affect those who run within dev.bat's magic land, the extra bit of default magic should not be a surprise, no? I'd propose a patch, but don't undersand what half of dev.bat does, and would prefer people familiar with the matter to make the change, if it is agreed upon. This sounds fine - anything related to SNAP can be disregarded at this point, SNAP is an internal Microsoft gated checkin system which we used for submitting checkins and running all of the tests. I don't see why we wouldn't want to always set IRONPYTHONPATH. We did at one point run our own tests both w/ and w/o the std lib but we stopped doing that some time ago. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Working towards IronPython 2.7 RTM
Jeff wrote: For a nice easy fix to start with, take a look at http://ironpython.codeplex.com/workitem/29928. You can either attach a patch to the issue, or (preferably) create a fork on GitHub and send us a pull request. Here's some other bugs which look like they might be good to start on. Many of these are bug 28171 which is a catch-all bug for new tests in 2.7 that are broken. You can search the test dirs for these but here's the ones which looked like they could be easy with a couple more difficult ones mixed in. It also might be something good to pursue or triage away before 2.7 RTM. Modules: http://ironpython.codeplex.com/workitem/28315 test_functools: Couple of issues in here, first one might be easily fixed by adding setters which throw the correct exception, 2nd one might be implementing __reduce_ex__ directly on partial objects or maybe the stack trace will make the issue obvious. Test_struct: these look fairly straight forward, and will just be dealing w/ one module implementation in IronPython. Runtime libraries: Test_repeat in test_index.py (in the CPython test repro) Test_float_to_string in test_types.py Could be hard or easy but it's certainly easy to investigate - you just need to look at the string formatter code and see what it turns %g into. There's more string formatting failures in here as well which could be fairly easy Test_format.py has more string formatting bugs which could be fairly straight forward Test_xrange: this one even mentions the function which is broken Runtime types (these may be a little more difficult): Test_descr.py and test_collections.py both have some interesting failures around the type system and descriptors. Some of these may be easier (e.g. test_classmethods in test_descr.py) than others but might be interesting to look at for someone more interested into the type system side of things. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Which modules collection to use?
Daniel wrote: Pulled src from github. The devel set up instructions (http://ironpython.codeplex.com/wikipage?title=Respository%20Instructions) and all the script magic already in place is just great as things compile and run. Very cool. However, need help figuring some things out, please: 1. Neither the release, nor the debug deployment copies the standard module files into Lib. Is there magic in place for that already, like a project file that has the deployment paths spelled out? We have a copy of the std lib in External.LCA_RESTRICTED\Languages\IronPython\27\Lib. I generally just set IRONPYTHONPATH at that directory which is much better than copying it on every build. For releases the MSI builder will pick it up out External.LCA_RESTRICTED\Languages\CPython\27\Lib. The difference between those two directories is the tests - the IronPython dir has various changes to disable failing tests, occasionally adds some extra tests, etc... The 2 dirs are also useful for doing 3 way merges when updating the standard library. That way you know what the last version we pulled was. 2. There are two copies of modules sets. One in cPython/Lib, there other is in IronPython/27/Lib. The answer is probably obvious, but which set of modules do I need to copy? [conveniently answered above] 3. Before I found the bundled module collections, I tried modules from 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] and saw code in modules blowing up left and right. It's obvious that the modules collection in IronLanguages is stale, but i wonder how stale it is... Are they from 2.5/2.6 time? If the next IPY release is 2.7 do we need to go and update the modules bundled with 2.7? These are all from the 2.7 timeframe and should be from 2.7.0 at the very earliest. If you windiff the CPython lib dir w/ your 2.7.1 install Lib dir you should be able to see the differences. I'm surprised that things are blowing up - maybe there's some site packages breaking things in your install? ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Which modules collection to use?
Daniel wrote: Thx on the IRONPYTHONPATH hint. Regarding what blows up: copy'n'paste Lib folder from cPython 2.7.1 into /Debug/.., followed by bdc 6 Warning(s) 0 Error(s) Time Elapsed 00:00:37.34 C:\workipy IronPython 2.7 Beta 1 DEBUG (2.7.0.10) on .NET 4.0.30319.1 Type help, copyright, credits or license for more information. import os Traceback (most recent call last): File stdin, line 1, in module File C:\work\ironlang\Bin\Debug\Lib\os.py, line 398, in module File C:\work\ironlang\Bin\Debug\Lib\UserDict.py, line 84, in module File C:\work\ironlang\Bin\Debug\Lib\abc.py, line 109, in register File C:\work\ironlang\Bin\Debug\Lib\abc.py, line 151, in __subclasscheck__ File C:\work\ironlang\Bin\Debug\Lib\_weakrefset.py, line 69, in __contains__ TypeError: cannot create weak reference to 'classobj' object This is a bug in IronPython, here's the simple repro: class C: pass import weakref weakref.ref(C) OldClass just needs to have an IWeakReferencable implementation added to it. Looks like this is new in 2.7.0 and I'm guessing something in 2.7.1 now depends upon it. Maybe there just wasn't a test case for it or we have it disabled in the IronPython dir. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Issue Triage
My general attitude has been that CPython is always more correct, even when it's not. :) We usually have our own tests for things like this (which we run against CPython too) and when CPython fixes it we'll fix it too. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Brian Curtin Sent: Sunday, January 16, 2011 3:13 PM To: Discussion of IronPython Subject: Re: [IronPython] Issue Triage On Sun, Jan 16, 2011 at 16:06, Richard Nienaber rjniena...@gmail.commailto:rjniena...@gmail.com wrote: Having said that, I'm still looking for a guideline about what to do in the scenario where the behaviour of IronPython is more 'correct' than CPython. Richard I would suggest creating issues on the CPython bug tracker for those cases, and feel free to add me to the nosy list of any of them (tracker ID: brian.curtin). ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Referenced Assemblies with DLR languages
Doug wrote: On Tue, Jan 11, 2011 at 8:13 AM, Doug Blank doug.bl...@gmail.com wrote: Two questions about referenced assemblies (which are really perhaps DLR questions): 1) I'd like to be able to use different names than are used in a DLL. For example, say I have a Library.dll, and it has a class ReallyBadName. Is there an easy way that I can rename or alias ReallyBadName after I add a reference to Library? I'd like this to work for all of my DLR languages, so I'd like to do it right after I add the reference, rather than, say, doing it in Python with import ReallyBadName as GoodName---but that is the effect I want. Ok, maybe if I ask this a slightly different way: when IronPython says import ReallyBadName where does that name need to match in order to import? I presume that I could change it somewhere in clr.References, and could import the objects via another name. Would that work? ReallyBadName needs to match a namespace name or a top-level class name (a class w/ no namespace). Unfortunately there's no way to publish this under a different name. The best thing I can think of would be if you had a .py file like: BetterNames.py: import ReallyBadName as GoodName then you could do: from BetterNames import * Another possibility which might work but is a little crazy would be to implement your own Assembly object and do a clr.AddReference(yourAssembly). You'll then need to override things like GetTypes() / GetExportedTypes() and then you'd also need to subclass Type to return a different name. And that's where things will start getting difficult because now we don't have a real type object to create instances from. It might be possible to override enough of the mebers that it'll work but I wouldn't be surprised if it wasn't possible. I'm trying to make generic DLLs that could be loaded directly from the DLR languages, and would be appropriate for the IP users. 2) Is there a way that I could have a Library.dll bring in other assemblies so that they would be available to DLR languages? Of course, one could load an assembly in an assembly that you clr.AddReference, but that wouldn't make it available to all of the DLR languages right? It seems that one would need a callback where the clr was passed into the assembly which was clr.AddReference-ed, so that it could add references too. Could I overload the clr importer to do that? Or is there a better way? Likewise, I'd like so that when I import Library (where Library is a DLL), it will include other DLLs to be available for DLR language access. To load the additional assemblies ultimately you'll need a ScriptRuntime/ScriptDomainManager to add the assemblies to. Unfortunately how you get ahold of those is dependent upon the language. For IronPython you can have a method which takes a CodeContext object as the 1st param and it'll let you get back to the SDM - but the user will need to call that method at some point. Another possibility would be implementing a built-in module which is IronPython specific. That'll give you a PerformModuleReload method which is called to initialize the module and that can load additional assemblies. And you could then expose the types under different names as well. But it's again completely IronPython specific. -Doug Thanks for any pointers, -Doug ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exception Model for modules implemented in C#
There's this: http://www.mail-archive.com/users@lists.ironpython.com/msg10503.html That originally came from the .rst files used to generate docs (External.LCA_RESTRICTED\Languages\IronPython\27\Doc\IronPythonDocs) but I can't find it in there now... I'm not quite sure how that happened. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Slide Sent: Tuesday, January 11, 2011 8:05 AM To: Discussion of IronPython Subject: Re: [IronPython] Exception Model for modules implemented in C# Thanks, I think that will help out a lot! slide On Tue, Jan 11, 2011 at 8:54 AM, Jeff Hardy jdha...@gmail.commailto:jdha...@gmail.com wrote: On Tue, Jan 11, 2011 at 7:14 AM, Slide slide.o@gmail.commailto:slide.o@gmail.com wrote: Is there a document that describes how to implement a Python exception in a C# module? In looking through the code, the exception stuff is seemingly in about 20 different places and bringing it all together is not easy, at least to the casual observer :-) I don't think there is. It's not too bad once you figure it out, but figuring it out is tricky, to say the least. You could look at https://bitbucket.org/jdhardy/ironpython.sqlite/src/95894443fffe/src/Exceptions.cs, which has it all in one place for a fairly deep exception hierarchy. (`InitModuleExceptions` is called from `PerformModuleReload` in _sqlite.cs.) I just figured that out from reading the existing modules, but I'm thinking I should write a module implementer's guide with those sorts of lore in it. I thought there was one started, but now I can't find it. - Jeff ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- slide-o-blog http://slide-o-blog.blogspot.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Adding Unit Tests
Jeff wrote: On Tue, Jan 11, 2011 at 10:22 AM, Tomas Matousek tomas.matou...@microsoft.com wrote: IronRuby doesn't use the test runner. IronRuby's harness is written in Ruby (Languages\Ruby\Tests\Scripts\irtests.rb). It's run by a previous IronRuby version checked in to Util\IronRuby. So is there any value whatsoever in keeping the TestRunner around? If there isn't, I'll look into porting the IronPython test infrastructure to use unittest. As long as all of the tests we want to run keep running there's no reason to keep TestRunner - it was just a way to run all of the same tests we ran before w/o relying upon internal MS infrastructure. I'm not sure how many of the DLR tests we'll still want to run but I imagine we can just wrap them in unittest and have it run the EXEs. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] What is a good way to determine OS platform with IronPython?
Doug wrote: On Mon, Jan 10, 2011 at 3:37 PM, Douglas Blank dbl...@brynmawr.edu wrote: Now that IronPython runs on other operating systems, what is the recommended way to determine the os when running IP? `os.name` is probably what you want. There was some discussion on python-dev about a module (or extension to sys?) that would have a lot more information, but I can't remember what it was going to be called. Thanks. FYI, under Mono: IP on mac: os.name == 'posix' IP on linux: os.name == 'posix' IP on windows 7: os.name == 'nt' I'll have to figure out a different way to distinguish between mac and linux. Even sys.getwindowsversion() gives a platform of 4 for Mac and Linux under Mono. Another option is to import System and then System.Environment.OSVersion should have detailed information. The Platform attribute would give you a difference between Unix and Mac OS/X and depending on what Mono does w/ the value you might get a useful ToString on the OperatingSystem object its self. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Adding Unit Tests
To add a new test you can modify the %DLR_Root%\Test\IronPython.tests file and add something like: Test Nametest_csv_cpy/Name Filename%DLR_ROOT%\Languages\IronPython\Internal\ipy.bat/Filename Arguments Test\test_csv.py/Arguments MaxDuration60/MaxDuration LongRunningfalse/LongRunning Disabledfalse/Disabled RequiresAdminfalse/RequiresAdmin NotParallelSafefalse/NotParallelSafe WorkingDirectory%DLR_ROOT%\External.LCA_RESTRICTED\Languages\IronPython\27\Lib/WorkingDirectory /Test The test runner will then include running those tests. If you want to add new tests beyond what CPython has you could either add them directly to CPython's test_csv.py or you could create a new test_csv.py in %DLR_ROOT%\Languages\IronPython\Tests. If you put them in CPython's test_csv I would suggest adding a comment which says it's an additional test as well as submitting the test back to CPython. The comment is just there so we know what's going on whenever the next merge from CPython has to happen. We don't have to stick to this test runner BTW - it was just an easy way to export what we were running in our internal gated checkin system which we couldn't publish. We could export the data to something else or we could update it to something more Linux and OS/X friendly (as they probably don't have cmd.exe to run bat files :)). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Slide Sent: Monday, January 10, 2011 6:42 PM To: Discussion of IronPython Subject: [IronPython] Adding Unit Tests As I am developing an implementation of the _csv module that I would eventually like to contribute to the community, what is the best way to add unit tests to the current suite? I have been using the unit test in the CPython sources for the csv module to test my _csv implementation. Is there an easy way to incorporate that into the current unit test setup? Thanks, slide -- slide-o-blog http://slide-o-blog.blogspot.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Issue Triage
Jeff wrote: I think the following needs some further scrutiny before closing: module globals are reported incorrectly to sys.settrace (http://ironpython.codeplex.com/workitem/26243) Finish FunctionEnvironment cleanup (http://ironpython.codeplex.com/workitem/23992) Unable to set value type's field even with the help of StrongBox (http://ironpython.codeplex.com/workitem/23998) Dino, can you look at these? They look fixed to me, but I'm not sure. I've closed 26243 and 23992, I need to look at 23998 a little deeper to make sure it's fixed. One issue that I think should be fixed for 2.7 is this one: binder failed to make the choice when non-generic/generic methods have the same signature (http://ironpython.codeplex.com/workitem/23999) Since Python doesn't deal with generics I would think the least-surprise outcome would be for the C# spec to be followed for overload resolution. This would be a good task for anyone who really wants to learn the guts of IronPython. Sadly, I don't have the time :( I've added a comment to this one. Personally my vote is (and has been for some Time) to move all method binder bugs to IronPython 3k. Method binding is subtle enough and changing it could break existing code that we should tread carefully. Also this bug has been there since 2007 and no one seems to have run into it in the real world. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Issue Triage
Jeff wrote: On Fri, Jan 7, 2011 at 11:12 AM, Dino Viehland di...@microsoft.com wrote: I've added a comment to this one. Personally my vote is (and has been for some Time) to move all method binder bugs to IronPython 3k. Method binding is subtle enough and changing it could break existing code that we should tread carefully. Also this bug has been there since 2007 and no one seems to have run into it in the real world. Works for me. There's a 3k release already, so I've just used that. Was there a difference in intent between 3k and Future? If not, I'll collapse them into one or the other (so far, Future has more, so I'm leaning that way). Yep, there's a difference. 3k is things that we do actually think we'll do in 3k. Future represents issues which are effectively intractable right now - it's kind of a mix between Won't Fix (yeah, that's a problem, but it doesn't really seem to matter), Can't Fix (it's simply impossible - maybe just right now, maybe forever) or Crazy Hard To Fix (maybe if we re-write the CLR or something we could fix this). In general we would put bugs there so that A) We didn't have to consider them all of the time but B) people could continue to vote on them and/or if a solution became available we could implement. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] autocompletion (intellisense) for clr.AddReference
Piotr wrote: I have a feeling that getting autocompletion/intellisense for CLR libraries referenced that way is not a trivial task, though it's probably not impossible. What we ended up doing is writing a Python 'pretend' module for our CLR assembly and importing that, but doing trickery so that the names actually resolve to the CLR assembly at runtime, so the Python module is only used to assist in the autocompletion. If you want I can get the specific details on how you can 'trick' the IDE into looking at the Python script but actually reference the assembly. Yes I would like to learn the trick Just to give you some ideas on how you can do this w/ just your assembly. The way we load the assembly is by calling into IronPython's clr module to Load the assembly the same way it normally does (we call clr.LoadAssemblyByName). If that fails we then try clr.LoadAssemblyByPartialName. Those should turn into clr calls to do Assembly.Load(name) and Assembly.LoadWithPartialName(name). So the question then becomes what do you need to do to make sure we can find your assembly. One option would be to put the assembly in the GAC but that'll require that it's strong named. Another option would be to put your assembly in the CLR's loader path. That probably means putting the assembly where devenv.exe lives or some similar location. You could find a definite location by running fuslogvw (which is part of the .NET framework SDK), click on settings, enable logging bind failures, and then loading up VS and opening up your file. We should try loading the assembly and you should see the assembly name in the list of bind failures when you refresh in fuslogvw. You should also see a list of paths where we looked. Probably what should really happen is that we should support looking in some location within the project. If someone wanted to make this change it would be in ProjectState.cs in the AddReference(CallExpression node, Funcstring, Assembly partialLoader) method. You'd just need to flow where to look into the ProjectState object. BTW: do you know the explanation for the behavior below? import System.Text as text text.TAB produces autocompletion list whereas import System.Text System.Text.TAB does not Does Text. give you completions? We could just be misanalysing the import statement. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] autocompletion (intellisense) for clr.AddReference
Piotr wrote: Dino: thank for the explanation for the clr.Reference. import System.Text as text text.TAB produces autocompletion list whereas import System.Text System.Text.TAB does not Does Text. give you completions? We could just be misanalysing the import statement. import System.Text Text.TAB no autocompletion from System import Text Text.TAB autocompletion present Ok, one more question, does System. give you completions and if so does it include anything like ASCIIEncoding ? ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] autocompletion (intellisense) for clr.AddReference
Piotr wrote:
import System.TAB - works
import System
System.TAB works too. There's no ASCIIEncoding) but there's AppDomain
for example and the list starts with AccessViolationException and ends with
{} Web System.TABText.TABASCIIEncoding does work
but again
import System.Text
System.TAB does not work
System.Text.TAB does not work either
(Can one debug it somehow?)
Yep, it can be debugged :) You need to download the tools sources and install
the VS SDK though. Then you can build,set the IronPythonTools project as the
startup project and tell it to launch devenv.exe using:
/rootsuffix Exp
As the command line option. Then set a breakpoint in DDG.cs in the
public override bool Walk(ImportStatement node)
method and launch. We'll call that when we're analyzing the import. In Walk
we'll do:
var builtinRefs = ProjectState.GetReflectedNamespaces(impNode.Names,
impNode.Names.Count 1 !String.IsNullOrEmpty(newName));
And this is around where something's going wrong, but I can't quite tell what
and I'm not setup for debugging this at work anymore.
Basically we should be trying to get the namespace object associated with
System and dotting through it to get each addition member. But in the end
we should just return the System namespace back.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] how to build ironpython on ubuntu from sources?
Jeff wrote: Ok, I've switched to 'false' and now I get: 21 Warning(s) 13 Error(s) - Some errors still sound like warnings to me. Looks like that's set to true in all of the csproj files, so you'll have to change it in all of them. - most of the errors throws a ' Type of ... is not CLS-compliant' message I think these are meant to be warnings as well, so see what happens after changing all of the TreatWarningsAsErrors sections. For those we can probably add a [assembly: ClsCompliant(false)] attribute somewhere and have those go away (there may also be a project setting). ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Converting IronPython file object to .NET Stream object
Can wrote:
Is there an easy way to convert an IronPython file-like object to a .NET
Stream? The reverse can be done in IronPython using like this:
net_stream = File.OpenRead('file.txt')
python_file = file(net_stream)
I wonder if there is an easy way of doing the reverse? Or do you have to
write a wrapper that will inherit from Stream and implement all the
methods?
The stream is not currently accessible - it also doesn't actually always exist
because
when we're writing to the console we use a different object (I actually don't
remember why this is - maybe we could wrap that object in a stream and always
have a stream).
We could easily expose the Stream has a PythonHidden property (so it requires
import
clr) or add something like clr.FileToStream() to get the stream for normal
files though.
Or given that we're all consenting adults you could use reflection to get the
stream:
import System
f = file('abc.txt', 'w+')
f.GetType().GetField('_stream', System.Reflection.BindingFlags.Instance |
System.Reflection.BindingFlags.NonPublic).GetValue(f)
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Passing arguments to C#
Mark wrote:
I had tried the IListdouble, and it works fine if I send in a list that is
full of
doubles, Using something like mylist = map(float,range(10))
That was an awkwardness I wanted to avoid. I wanted to be able to pass in
mylist = range(10) just as easily.
My C# routine will accept the argument as an IList (no type), but I'm unable
to cast it afterwards.
I finally solved the problem by accepting an IList, copying it element my
element to a new list of the correct type. If a typecast is required, I
assign it
to a temporary variable of the same type first, then cast the temporary
variable.
This is the function I use for my conversion of each element. I settled on
using the IronPython.Runtime.List instead of IList because that's what I'm
really passing in, but they seem to act exactly the same in this context.
static private double pToDouble(IronPython.Runtime.List pList, int
index)
{
string type = pList[index].GetType().FullName;
if (type == System.Int32)
{
int tmp = (int)pList[index];
return (double)tmp;
}
else if (type == System.Double)
{
return (double)pList[index];
}
else
throw (new ApplicationException(Can't convert Python list to
Double));
}
It's a little clumsy, but I'd rather push this down into the C# where I can
hide
it from my Python users.
I'd suggest Converter.ConvertToDouble(...) instead of doing the type checks
yourself (Converter is in IronPython.Runtime). That'll work on anything the
user
can throw at you and it'll use call site caching as well. At the very least
I'd suggest:
if(pList[index] is int) {
}else if(pList[index] is double) {
}
Which will be much, much more efficient and is a little easier on the eyes too.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] How to break in the debugger in IP when script lauched from a hosting C# process
Chuck wrote: I have a SharePoint app (Commerce Server to be exact) that is launching an IronPython script. What is the best way to be able to step into or break into the debugger within the IronPython script? You should enable debug mode for the script runtime to make the code debuggable. There's a DebugMode property on ScriptRuntimeSetup that you can set that will enable that. Then if the code you're compiling is all on disk w/ filenames we should emit debugging information for it (if you're creating script sources from strings you'll need to write them out to disk and create them from files). From there you should be able to attach VS and step, set break points, etc... You don't want to do this all the time though because debuggable code is not collectible code so you could end up leaking memory. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] SciPy
Enthought has been working on getting numpy/scipy ported over to work w/ IronPython. I believe numpy is working but I'm not sure of how far along SciPy is. There's a separate mailing list for this at: https://mail.enthought.com/mailman/listinfo/scipy4dotnet It's very low traffic - it's usually just working through issues Enthought has run into and either workarounds or suggested changes to IronPython. I'd suggest sending a mail there - they might have something you can try. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Mark Senko Sent: Thursday, December 16, 2010 11:49 AM To: users@lists.ironpython.com Subject: [IronPython] SciPy I've been searching for the current state of support for C based libraries, specifically SciPy (I'm just looking for a decent numerical analysis package). The responses I've seen on various websites are somewhat dated. What is the latest status, or is there no effort towards accommodating the C API? Is IronClad still the best option? Any info, suggestions and warnings would be appreciated before I start to invest a lot of time into installing and learning these packages. Mark Senko Complete Genomics, Inc. 2071 Stierlin Court Mountain View, CA 94043 The contents of this e-mail and any attachments are confidential and only for use by the intended recipient. Any unauthorized use, distribution or copying of this message is strictly prohibited. If you are not the intended recipient please inform the sender immediately by reply e-mail and delete this message from your system. Thank you for your co-operation. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Thread Locking
Lock is just syntactic sugar for doing Monitor.Enter/Monitor.Exit calls on the object and setting up the try/finally. Here's the IronPython equivalent: from System.Threading import Monitor class Locker(object): def __init__(self, obj): self.obj = obj def __enter__(self): Monitor.Enter(self.obj) def __exit__(self, exc_type, exc_value, exc_tb): Monitor.Exit(self.obj) with Locker(object()): print 'hello' (I thought we had considered putting something like this in the clr module at one point in time so you wouldn't have to define the Locker class but it looks like that never made it in but it'd be an easy thing to add if someone wanted to give it a try). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Sam Dozor Sent: Monday, December 13, 2010 9:18 AM To: Discussion of IronPython Subject: [IronPython] Thread Locking Hello All, I'm trying to use IronPython to lock a thread and have not been able to import the correct modules. I have IronPython.modules.dll in the same directory as IronPython.dll, and yet when I try the line import threading I get something like threading module does not exist. I'm basically trying to use the lock() keyword from .NET, but if I can use Python's locking capabilities I'd do that too. Any ideas? Thanks, Sam ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] XNA 4.0
Mauricio wrote:
Hi all.
I'm trying to run the XNA example posted here:
http://www.ironpython.info/index.php/XNA_Example_-_Luminance
But i'm trying that with XNA and .NET 4.0 on IronPython 2.6.
After changing some imports that seems to be different in XNA 4.0 version,
the program gives me this error:
Traceback (most recent call last):
File xna_test.py, line 33, in module
File xna_test.py, line 13, in __init__
File xna_test.py, line 17, in initializeComponent
SystemError: The invoked member is not supported in a dynamic assembly.
The line 17 is this one:
self.graphics = GraphicsDeviceManager(self)
I would suggest compiling a small C# assembly which is just something
like:
public class Maker {
public static object MakeGraphicsDeviceManager() {
return new GraphicsDeviceManager();
}
}
And then call this instead of calling GraphicsDeviceManager directly. There's
occasionally a type which disallows being created via reflection/dynamic methods
(for whatever reason) and this is one work around.
Another possibility is that we're calling it via reflection because it hasn't
been called enough but it'll work if called via a dynamic method. In that case
you
can actually call it in a loop until we optimize the creation to a call from
a dynamic method. I doubt this is the case this time though because of the
error message is specifically calling out the dynamic assembly.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython memory usage
What task manager reports I believe depends on what version of Windows you're on. You might want to right click on the columns and add some of the Memory columns. By default Win7 seems to have private working set selected (which would be what each additional copy requires). But there's also a Working Set option which should be private + shared bytes. Also, one way to reduce the memory usage would be to pre-compile your app and ngen it if you're not already doing so. This will cause the Python code (at least the code which isn't eval'd/exec'd/compile'd) to be shared between processes. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Ken MacDonald Sent: Thursday, December 09, 2010 6:50 AM To: Discussion of IronPython Subject: [IronPython] IronPython memory usage Hi, We're trying to figure out the usage of overall system memory by our IronPython/WPF app. I've been looking at various memory profilers, but they seem to be concerned with memory leaks within the app itself, etc. What we'd like to be able to find out is something like this: 1) How much memory does my app use? This is pretty straightforward, check task manager. 2) How much memory does a second (third, fourth...) copy of the app use? Task manager does not appear to show this correctly. It seems as if .NET should be shared among different instances of the application, so that if the first instance of an app uses up 600M of system memory (say, 400M of .NET and 200M of application code) then a second, third... instance of the app should only add each an incremental 200M to the total system memory usage. Task manager appears to show each instance as independently using 600M, inflating the apparent memory used. Anyone know how to properly determine the system load for multiple instances of a .NET app? Again, most of the memory profilers don't really appear to address this. Thanks, Ken ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Issue Triage
Thanks for doing this! I've gone ahead and closed the first three. I'm going to leave the compile() one open so it can get the right exception. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Richard Nienaber Sent: Thursday, December 09, 2010 12:32 AM To: Discussion of IronPython Subject: Re: [IronPython] Issue Triage I've identified the following issues that I think are fixed: PEP 342 broken -- generator.send() causes IPy exceptionhttp://ironpython.codeplex.com/workitem/25574 socket.gethostbyaddr(broadcast) broken under .NET 4.0 Betahttp://ironpython.codeplex.com/workitem/24495 (It looks like the correct behavior but the error message is different) codecs.lookup errors with uppercase encoding nameshttp://ironpython.codeplex.com/workitem/20302 And with this: compile() incompatibility with CPythonhttp://ironpython.codeplex.com/workitem/22692 It seems mostly fixed but a SyntaxError is thrown instead of an IndentationError Richard On Wed, Nov 24, 2010 at 4:54 AM, Jeff Hardy jdha...@gmail.commailto:jdha...@gmail.com wrote: There are over 1000 open issues on CodePlex (http://ironpython.codeplex.com/workitem/list/basic), many of them dating back to IronPython 1.0. A few people have wondered what they can do to help IronPython without being familiar with the project. If you're one of those people, then triaging issues would be a great place to start - those issues should be checked against a modern version of IronPython (preferably 2.7b1) to see if they are still valid. Also, I'd like to start getting a list of issues that are blockers for releasing 2.7. If you have an issue that is blocking you in IronPython 2.7b1, report it on this list - I'll bump the priority up to high to make sure it doesn't get missed. Finally, if everyone could vote for this CodePlex issue (http://codeplex.codeplex.com/workitem/25398) it would make it much easier to share the list of blocking bugs. For now, Status = Open, Impact = High, Release = 2.7. The ones already in the list are the ones I plan on fixing myself. - Jeff ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Jit leak in defaultdict for Ipy 2.6.2
CompilerHelpers.CompileToMethod is probably where we'll usually go through whenever we need to compile anything. You might also look for other calls to LambdaExpression.Compile as there could be a few of those lurking. Any repeated jiting is probably being caused due to the failure of caching rather than caching its self. All of that caching should basically be in our call site bindings but they'll all age out over time so while methods may be getting JITed they should also be getting freed. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Idan Zaltzberg Sent: Thursday, December 02, 2010 8:22 AM To: Discussion of IronPython Subject: Re: [IronPython] Jit leak in defaultdict for Ipy 2.6.2 After further testing I find very weird behaviors of the Jit. For instance, looks like if use some pattern too many times, The Jit counter goes to infinity, while otherwise it stabilizes. It would be very helpful to get printouts from ipy whenever it creates an a object that requires jitting. Are there a few places I can Console.writeline in the IronPython code that should cover most of these cases? Is there any cache mechanism you are aware of, that might cause this behavior where over usage generates infinite Jitting? From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, November 29, 2010 8:23 PM To: Discussion of IronPython Subject: Re: [IronPython] Jit leak in defaultdict for Ipy 2.6.2 The closest non-windbg solution I could think of might be CLR Profiler which can probably report the number of dynamic method objects which are alive. Windbg can also do this when you dump the heap and is probably over all actually easier to use in this case as you can attach, do !DumpHeap -stat, and then detach. Just one more data point which might help you understand what's going on - the JITed methods in this case are probably adding 4k of memory to the cost of each defaultdict instance as long as the defaultdict is alive. From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com] On Behalf Of Idan Zaltzberg Sent: Monday, November 29, 2010 9:59 AM To: Discussion of IronPython Subject: Re: [IronPython] Jit leak in defaultdict for Ipy 2.6.2 Thanks. How I suspect there is a leak in the JIT of my application, up until now I thought that if the performance counter for # of methods jitted is constantly rising then that means exactly that. From your reply I understand that this is not the case. Can you tell how can I know how many uncollectible JIT objects I have so that I can trace them (preferably without using windbg) Thanks again... From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, November 29, 2010 7:41 PM To: Discussion of IronPython Subject: Re: [IronPython] Jit leak in defaultdict for Ipy 2.6.2 Defaultdict is creating a new invoke binder - it should be getting the binder from PythonContext using the Invoke(CallSignature) method. Because it creates a new binder each time we are getting no caching of the rules across defaultdict instances and it'll end up generating a new method to handle the missing call. It is collectible (so not really a leak) but it is really bad from a performance perspective. From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com] On Behalf Of Idan Zaltzberg Sent: Monday, November 29, 2010 4:10 AM To: Discussion of IronPython Subject: [IronPython] Jit leak in defaultdict for Ipy 2.6.2 Hi, I have noticed the following method always adds a jitted method (looking at the .NET CLR Jit performance counter) when it is run: def f(): d = defaultdict(int) d[0] I created my own implementation of defaultdict (in ipy): class defaultdict(dict): def __init__(self, cls): super(defaultdict, self).__init__() self.cls = cls def __getitem__(self, key): if key not in self: self[key] = self.cls() return super(defaultdict, self).__getitem__(key) And I noticed that it does not leak JIT and it works 200 times faster when running the method f(). Can you please look why this happens in the current implementation? Also I was wondering if there are any other utility methods that use similar code and probably will have the same problem. Thanks, Idan zalzberg ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] __delattr__ in .NET class
Slide wrote: I am currently implementing a module in C#. I need to be able to override the __delattr__ method for one of my objects. I've put in a __delattr__ method that takes a string, but it never gets called. I also tried DeleteMember because I saw that around too. Is there a way to do this? Did DeleteMember have [SpecialName] attribute on it? It should work if it's got that attribute. The ideal way to do this is to implement IDynamicMetaObjectProvider so that it'll work from all languages (DeleteMember is more of a IronPython-ism). ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython source code
Wow, you must still be using IronPython 1.1 or IronPython 1.0. The conditional expression was added in Python 2.5 so it's in IronPython 2.0 (which maps to Python 2.5). I'm guessing the VS 2008 support you're using is IronPythonStudio which I believe is still at 1.0/1.1 as well. We did release the code for the ASP.Net integration (see Jimmy's announcement here http://blog.jimmy.schementi.com/2010/07/aspnet-dynamic-language-support-is-open.html) but I don't remember if we included / re-built it for the 2.7B1 release. The reason I bring this up is I think the best possible upgrade path if you want both ASP.NET + VS support would be to move to IronPython 2.7 and VS 2010. If that's not too big of a jump for you I think you'd find it's a much better experience than 1.1 and the VS 2008 integration which is a little lacking in some aspects. But if the conditional expression was the one extra thing you wanted you could also consider back porting it to IronPython 1.1 - it shouldn't be very difficult. The parser side of things won't be much different between 1.1 and 2.7 but the code gen side will require some IL generation which will also give it more of a traditional compiler feel. 1.1 is also a little simpler in some aspects so it might be easier to get a feel of things there and then when you look at 2.x you can see how the DLR has been added in on top of that. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Pablo Dalmazzo Sent: Saturday, November 20, 2010 8:23 AM To: IronPython Mailing list Subject: Re: [IronPython] IronPython source code Thanks Dino for the info, Jimmy for the tip and Jeff for the Twitter answer. I'm interested in certain things but I need to read more to make any question understandable :) Also I would like to understand/understand better the reasons behind the important differences certain cool languages have among them, but that doesnt have to do with Python alone BTW, we arent working with the last version of IronPython, because we are working with the one we feel more secure for compatibility/integration issues with Visual Studio 2008 and asp.net, and I havent read all the sourcecode changes report yet, but it would seem IronPython in Visual Studio 2008 Professional doesnt take as valid sentences of this kind: (in fact they are marked as invalid by Visual Studio) variable = value1 if condition is None else value2. Unless it's a change in the syntax from one Python version to another version? We arent aware of all the Python changes from a version to another. When we use some IronPython modules we get errors in lines like that so we translate them to the verbose version of the sentence for them to work. We move the modules from the IronPython installation to the App_script folder May be we are using IronPython modules from a version with another version of IronPython where that kind of syntax rule was invalid? From: di...@microsoft.com To: users@lists.ironpython.com Date: Fri, 19 Nov 2010 17:12:44 + Subject: Re: [IronPython] IronPython source code Yeah, there's no good comprehensive docs. There's some stuff in the CHM but it's more oriented towards people wanting to extend IronPython than work on it. If there's something particular you're interested in someone can probably chime in on the list. IronPython it's self is pretty abstracted away from generating code now (we generally just generate expression trees everywhere). So if you're interested purely in the compiler side of things you can look at the Tokenizer-Parser-AST transformations but then we're basically done w/ code gen at that point. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jimmy Schementi Sent: Friday, November 19, 2010 8:08 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython source code You'll have an easier time understanding Sympl, a sample programming language built on the DLR, which is at http://dlr.codeplex.com. The documentation for Sympl and the DLR itself is at http://dlr.codeplex.com/wikipage?title=Docs%20and%20specsreferringTitle=Documentation. From there you can upgrade to IronPython, but then hopefully you'll feel comfortable with just the source code. There are some old docs at http://ironpython.codeplex.com/wikipage?title=More%20Information, but really the source is your best bet. ~Jimmy On Fri, Nov 19, 2010 at 10:52 AM, Jeff Hardy jdha...@gmail.commailto:jdha...@gmail.com wrote: Hi Pablo, As far as I know there isn't any detailed documentation, but Dino would know for sure. - Jeff On Mon, Nov 15, 2010 at 2:59 PM, Pablo Dalmazzo pablodalm...@hotmail.commailto:pablodalm...@hotmail.com wrote: Hi, I was taken a look at the IronPython sourcecode. Is there any aditional resource/documentation/chart to help understand it? I've only coded in an educational compiler, you know, those made
