Re: [IronPython] Callstack inspection
It's most likely that inspect won't work. But we certainly don't implement
sys._getframe which will be necessary to crawl the stack. In the future we're
going to look at both what we can do from our side and what could be done from
the CLR side to make it easier to implement this feature - in other words this
may be one of those features it takes us a while to get to.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Stephenson
Sent: Tuesday, August 15, 2006 3:51 PM
To: Discussion of IronPython
Subject: [IronPython] Callstack inspection
I would like to adapt the following code to IronPython, but there appears to be
no inspect module available.
Any clues on how I might proceed?
many tias,
gary
# code begins
# a hack to support something like dynamically scoped variables
import inspect
class _gsDynamicVars( object ):
def __init__( self ):
self._publics = {}
def setPublic( self, nm, x = None ):
self._publics[nm] = x
def __getattribute__( self, nm ):
for f in inspect.stack():
if f[0].f_locals.has_key( '_privates' ):
if f[0].f_locals[ '_privates' ].has_key( nm ):
return f[0].f_locals['_privates'][nm]
return self._publics.get(nm)
def __setattr__( self, nm, x = None ):
for f in inspect.stack():
if f[0].f_locals.has_key( '_privates' ) :
if f[0].f_locals[ '_privates' ].has_key( nm ) :
f[0].f_locals['_privates'][nm] = x
return x
if self._publics.has_key( nm ) :
self._publics[nm] = x
raise NameError
___
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] dynamic types
Hi,
I havea C# class with the following design
public interface IDynamicProperty
{
/// ...
}
public class DynamicPropertiesContainer
{
IDynamicProperty GetDynamicProperty (string name)
}
and I have embedded IP as an internal scripting langauge.
what I would like is to expose the DynamicProperties of my class as actual properties in IP, which is logical since IP is dynamic.
example:
I want the following IP code to be equivalent (assuming that 'container' is an object of type DynamicPropertiesContainer)
print container.GetDynamicProperty (name)
print container.name
-- or --
print container.GetDynamicProperty (phone_number)
print container.phone_number
is there an easy way to achieve this?
thanks
A.
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] expose some namespaces of own application
Could you use mark the types as internal and public depending on whether you
wanted to prevent or allow access from IronPython? IronPython code will not be
able to access types or methods marked as internal in your C# code.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Tuesday, August 15, 2006 8:09 AM
To: Discussion of IronPython
Subject: Re: [IronPython] expose some namespaces of own application
It is currently an all-or-nothing situation. As a work around you could create
your own module (import imp.new_module('modulename')) and then you could add
the namespaces onto the new module, then publish the module in sys.modules:
import imp
import sys
mod = imp.new_module('test')
mod.abc = 'xyz'
sys.modules['test'] = mod
import test
print test.abc
You can do this w/o giving IronPython the reference to your assembly. Just
load the assembly, and from Python you can access the namespaces/types directly
off the assembly object.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stanislas Pinte
Sent: Tuesday, August 15, 2006 12:34 AM
To: Discussion of IronPython
Subject: [IronPython] expose some namespaces of own application
Hello,
We are using IP as a scripting engine, embedded in one of our products.
I would like to be able to expose a subset of the namespaces present in my
application assembly (MyApp.exe) to the scripting engine...but hide the rest:
i.e. when a user does an from a.b.c import Bar, if a.b.c is hidden, then it
fails:
from a.b.c import Bar
Traceback (most recent call last):
File stdin, line 1, in ?
ImportError: No module named a.b.c
whereas if a.b.pub has been exposed to the scripting engine, then the user
can import it.
Is this currently possible? I have the impression that it is an all-or-nothing
situation...and I would like to avoid having to split my classes in several
assemblies.
Thanks for all input,
Kind regards,
Stan.
--
-
Stanislas Pinte e-mail: [EMAIL PROTECTED]
ERTMS Solutions http://www.ertmssolutions.com
Rue de l'Autonomie, 1 Tel:+ 322 - 522.06.63
1070Bruxelles Fax: + 322 - 522.09.30
-
Skype (http://www.skype.com) id: stanpinte
-
___
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] dynamic types
Aviad Rozenhek wrote: what I would like is to expose the DynamicProperties of my class as actual properties in IP, which is logical since IP is dynamic. I'm not sure if there is a way you can implement __getattr__ in your C# class (and have IronPython Do The Right Thing,) but you could do something like the following IronPython code: import YourAssembly class DynamicPropertiesContainer(YourAssembly.DynamicPropertiesContainer): def __getattr__(self, attr): try: return self.GetDynamicProperty(attr) except NoSuchDynamicProperty: raise AttributeError, '%s' object has no attribute '%s' % (type(self).__name__, attr) Assuming of course your GetDynamicProperty method throws an exception when trying to get a property that doesn't exist, otherwise modify accordingly. -- Jonathan When you meet a master swordsman, show him your sword. When you meet a man who is not a poet, do not show him your poem. -- Rinzai, ninth century Zen master ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] dynamic types
You can implement ICustomAttributes interface on your class (defined
in IronPython\Runtime\Interfaces.cs) and IronPython will do the right thing.
Martin
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Aviad Rozenhek
Sent: Tuesday, August 15, 2006 7:14 PM
To: users@lists.ironpython.com
Subject: [IronPython] dynamic types
Hi,
I havea C# class with the following design
public interface IDynamicProperty
{
/// ...
}
public class DynamicPropertiesContainer
{
IDynamicProperty GetDynamicProperty (string
name)
}
and I have embedded IP as an internal scripting langauge.
what I would like is to expose the DynamicProperties
of my class as actual properties in IP, which is logical since IP
is dynamic.
example:
I want the following IP code to be equivalent (assuming that
'container' is an object of type DynamicPropertiesContainer)
print container.GetDynamicProperty (name)
print container.name
-- or --
print container.GetDynamicProperty
(phone_number)
print container.phone_number
is there an easy way to achieve this?
thanks
A.
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] expose some namespaces of own application
This is actually a bug - ReflectedPackage.TryGetAttr is looking at all types,
not just exported types. I've opened CodePlex bug 2199 to track this.
I've tentatively set it for 1.01 but we'll need to triage the bug properly to
decide what release it goes in.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stanislas Pinte
Sent: Wednesday, August 16, 2006 7:37 AM
To: Discussion of IronPython
Subject: Re: [IronPython] expose some namespaces of own application
Stanislas Pinte a écrit :
Shri Borde a écrit :
Could you use mark the types as internal and public depending on whether you
wanted to prevent or allow access from IronPython? IronPython code will not
be able to access types or methods marked as internal in your C# code.
Hello,
the following code demonstrates that importing internal types in own Assembly
works, while it shouldn't (according to what we think).
Any ideas?
Kind regards,
Stan.
namespace Test
{
[TestFixture]
public class EngineIntegrationTests
{
[Test]
public void TestPublicVsInternalImports()
{
PythonEngine engine = new PythonEngine();
//import self assembly
//try to import public type. should pass
//try to import internal type. should fail
engine.LoadAssembly(this.GetType().Assembly);
engine.Execute(from testnamespace.test import Foo);
engine.Execute(foo = Foo());
engine.Execute(from testnamespace.test import Bar);
engine.Execute(bar = Bar());
}
}
}
namespace testnamespace.test
{
public class Foo
{
//
}
internal class Bar
{
//
}
}
Is this true? Because that is exactly what I want...I can then give
the reference of my own assembly to the python engine, and then the
user will only be able to use public types!!
Great,
thanks.
Stan.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dino
Viehland
Sent: Tuesday, August 15, 2006 8:09 AM
To: Discussion of IronPython
Subject: Re: [IronPython] expose some namespaces of own application
It is currently an all-or-nothing situation. As a work around you could
create your own module (import imp.new_module('modulename')) and then you
could add the namespaces onto the new module, then publish the module in
sysmodules:
import imp
import sys
mod = imp.new_module('test')
mod.abc = 'xyz'
sys.modules['test'] = mod
import test
print test.abc
You can do this w/o giving IronPython the reference to your assembly. Just
load the assembly, and from Python you can access the namespaces/types
directly off the assembly object.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stanislas
Pinte
Sent: Tuesday, August 15, 2006 12:34 AM
To: Discussion of IronPython
Subject: [IronPython] expose some namespaces of own application
Hello,
We are using IP as a scripting engine, embedded in one of our products.
I would like to be able to expose a subset of the namespaces present in my
application assembly (MyApp.exe) to the scripting engine...but hide the rest:
i.e. when a user does an from a.b.c import Bar, if a.b.c is hidden, then
it fails:
from a.b.c import Bar
Traceback (most recent call last):
File stdin, line 1, in ?
ImportError: No module named a.b.c
whereas if a.b.pub has been exposed to the scripting engine, then the user
can import it.
Is this currently possible? I have the impression that it is an
all-or-nothing situation...and I would like to avoid having to split my
classes in several assemblies.
Thanks for all input,
Kind regards,
Stan.
--
-
Stanislas Pinte e-mail: [EMAIL PROTECTED]
ERTMS Solutions http://www.ertmssolutions.com
Rue de l'Autonomie, 1 Tel:+ 322 - 522.06.63
1070Bruxelles Fax: + 322 - 522.09.30
-
Skype (http://www.skype.com) id: stanpinte
-
___
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
--
-
Stanislas Pinte e-mail: [EMAIL PROTECTED]
ERTMS Solutions http://www.ertmssolutions.com
Rue de l'Autonomie, 1 Tel:+ 322 - 522.06.63
1070Bruxelles Fax: + 322 - 522.09.30
Re: [IronPython] expose some namespaces of own application
FYI we're going to fix this in 1.0 RC2 which should be out this week. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stanislas Pinte Sent: Wednesday, August 16, 2006 8:45 AM To: Discussion of IronPython Subject: Re: [IronPython] expose some namespaces of own application Dino Viehland a écrit : This is actually a bug - ReflectedPackage.TryGetAttr is looking at all types, not just exported types. I've opened CodePlex bug 2199 to track this. I've tentatively set it for 1.01 but we'll need to triage the bug properly to decide what release it goes in. great, thanks for the followup!! Stan. ___ 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] expose some namespaces of own application
Dino Viehland a écrit : FYI we're going to fix this in 1.0 RC2 which should be out this week. Damn cool. Thanks a lot. Stan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stanislas Pinte Sent: Wednesday, August 16, 2006 8:45 AM To: Discussion of IronPython Subject: Re: [IronPython] expose some namespaces of own application Dino Viehland a écrit : This is actually a bug - ReflectedPackage.TryGetAttr is looking at all types, not just exported types. I've opened CodePlex bug 2199 to track this. I've tentatively set it for 1.01 but we'll need to triage the bug properly to decide what release it goes in. great, thanks for the followup!! Stan. ___ 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 -- - Stanislas Pinte e-mail: [EMAIL PROTECTED] ERTMS Solutions http://www.ertmssolutions.com Rue de l'Autonomie, 1 Tel:+ 322 - 522.06.63 1070Bruxelles Fax: + 322 - 522.09.30 - Skype (http://www.skype.com) id: stanpinte - ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Debugging support PythonEngine
We have started doing some work for improving debugging as shown by the VSIP sample (http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx). However, it still needs more work for it to be production-quality. By tools support, I was referring more to VSIP sample. We dont have a concrete timeline for when we will be able to improve it further. Btw, using your sample script below, in most cases, I am able to step from Python code into C# code in IronPython.dll if I hit F11 in VS. However, when IronPython.dll calls the method Add, we step into native code for a while before actually reaching the source code for Add. This looks like something we can fix by changing the debug information we generate. After doing this fix, it would be possible to mark IronPython.dll as library code (either using DebuggerNonUserCodeAttribute or through some other scheme), and be able to step from Python code into a Python method. x = 1 y = 2 def Add(a, b): return a + b z = Add(x, y) Stepping in here takes you to IronPython.dll source code, then native code, and then the source code for Add print z From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Saturday, August 12, 2006 1:38 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Thanks for the info. Its good to hear that there will be improvement possible in this area in the future. Although, the way I interpret your explanation, its not going to be anytime soon (or even this year), because you need enhancements to the underlying platform to make this possible. Ive experimented a bit with System.Diagnostics.DebuggerNonUserCodeAttribute to see if it wasnt possible to skip stepping into IronPython code. Unfortunately, the point where I get stuck in the assembly instructions is in generated code. I dont understand this part of the code well enough to know if its possible to make the debugger skip these lines. Maybe this is why you need the changes to the platform? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Friday 11 August 2006 21:04 To: Discussion of IronPython Subject: Re: [IronPython] Debugging support PythonEngine Yes, we will definitely be working on improving the debugging support as it is a critical part of the development process. However, full support will need work in all parts of the tool chain including VS. Python local variables are implemented as normal MSIL variables (except in cases like closures). Hence, VS is able to display them. Currently, the best way to debug Python functions in VS while using PythonEngine would be to enable EngineOptions.ClrDebuggingEnable, open the PY file in VS and put a breakpoint where you want. Stepping in and out of Python functions will step you through methods in IronPython.dll . From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Friday, August 11, 2006 12:36 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Are there plans to improve the debugging experience in the future or are you at a point where it is as good as it gets? Being able to debug makes writing and using python scripts a lot easier. Inside functions I can see not only the function parameters but also the newly defined local variables. Are these different from the global variables? I would have expected that the function locals are also stored inside a dictionary. Is it possible to step into python functions without getting into assembly instructions? This is very frustrating and degrades the debugging experience a lot. This is the more important issue for me. Im not going to be using global variables frequently, but mostly functions loaded in the PythonEngine that are called from C#. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Friday 11 August 2006 0:30 To: Discussion of IronPython Cc: Glenn Hackney Subject: Re: [IronPython] Debugging support PythonEngine If EngineOptions.ClrDebuggingEnabled is set, we use AssemblyBuilder, TypeBuilder, etc for PythonEngine.Executed. The code generated by AssemblyBuilder, TypeBuilder, etc supports PDB debug information tracking for the methods, and so you will be able to set breakpoints in the code. However, it does not guarantee a perfect debugging experience. PythonEngine.ExecuteFile will use a dictionary for storing global variables, and these will not be visible because VS does not know about the dictionary. If you use PythonEngine.CreateOptimizedModule, most global variables are implemented using CLR statics, and so VS may be able to display them for you. Global variables added using an exec statement will still not be visible. If EngineOptions.ClrDebuggingEnabled is false, we will use System.Reflection.Emit.DynamicMethod. This does not support debug information tracking at all, and you will not even be able
[IronPython] VS2005 Iron Python
Hi, A question for anyone using the VS2005 IronPython IDE. I start a python console app, but when I attempt to run it within VS2005 it just shows an empty console window. I can run the py program fine if I use the command line IronPython. I am wondering if/how one can run the program within the IDE. Thanks Jeff Although this e-mail and any attachments are believed to be free of any virus or other defect which might affect any computer system, it is the responsibility of the recipient to check that it is virus-free and the sender accepts no responsibility or liability for any loss, injury, damage, cost or expense arising in any way from receipt or use thereof by the recipient. The information contained in this electronic mail message is confidential information and intended only for the use of the individual or entity named above, and may be privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please contact the sender immediately, delete this material from your computer and destroy all related paper media. Please note that the documents transmitted are not intended to be binding until a hard copy has been manually signed by all parties. Thank you. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] IronPython 1.0 RC2
Hello IronPython Community, We have just released IronPython 1.0 RC2.This build includes fixes for all known blocking issues against RC1, and we’re anticipating that this build will be the same as 1.0 final unless we hear otherwise.We’re looking for any feedback, but in particular we’d like to know of any blocking issues discovered against this build or fundamental language incompatibilities.Please try out the latest build over the next 2 weeks and let us know if you encounter any issues as soon as possible. We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: Kevin Bjorke, Kevin Chu, Mark Rees, Stanislas Pinte, and Timothy Fitz. Thanks and keep in touch, The IronPython Team More complete list of changes and bug fixes: CodePlex bug 2199: ReflectedPackage exposes internal types Several exception handling fixes including issue with break in except block CodePlex 2014 - __getitem__ on old style classes cannot be called as x[1,2] CodePlex 2015 - list.__rmul__ returns Ops.NotImplemented for subclass of long CodePlex 2016 - Power with module on classes with __pow__ throws CodePlex 2023 - Cannot convert class whose __int__ returns long to int CodeDom reports file line numbers based upon External Source information CodeDom auto-adds unknown namespaces to import list CodePlex 1752 - Issue with yield in finally Bugfix: CodePlex 1388 - TypeError when calling __init__ with keyword argument 'args' Bugfix: CodePlex 1886 - Powmod throws ValueError for large numbers BugFix: CodePlex 1887 - powmod is very slow for large numbers Bugfix: 1357 - MD5.Create call raises TypeError - multiple overloads conflict for static methods with same name in type hierarchy Bugfix: CodePlex 1393 - get_DefaultFont() takes exactly -1 arguments (-1 given) when accessing static property with self (now a better error message) Bugfix: CodePlex 1361 - help() function in ironpython shows incorrect behavior Bugfix: CodePlex 1399 -Accessing generic methods requires use of explicit tuple syntax Bugfix: CodePlex 1694 -Issue with yield in finally Bugfix: CodePlex 1728 - ipy shows different output when we use __new__ Bugfix: CodePlex 1731 - __init__ replaces the dictionary Static type Compiler produces overflow exception with following script code in the web project integration with Visual Studio Winforms tutorial tweaks Bugfix: CodePlex 1417 - True division behaves differently for Execute and Evaluate on PythonEngine Bugfix: CodePlex 1468 - List items are different when i use the htmlparser Bugfix: CodePlex 1732 - ipy throws error instead of returning complex number ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
