Re: [IronPython] defined in multiple assemblies (framework 3.5)
This is the source with modified Microsoft.Scripting.Core. http://www.yousendit.com/transfer.php?action=batch_statusbatch_id=Q01IYUl1YStxRTJ4dnc9PQ This has minimalist changes only to that dll. I have another working version with a IronPython2 namespaces and dll across the four core project(IronPython2.dll, IronPython2.Modules.dll, Microsoft.Scripting2.dll, Microsoft.Scripting2.Core.dll) that I need for my IronPython for ASP.Net based project. Dody G. On Wed, Aug 20, 2008 at 10:56 PM, Fernando Correia [EMAIL PROTECTED] wrote: I spent some time trying to create a version of Microsoft.Scripting.Core that is compatible with the framework 3.5. But I gave up because it is a huge job and in ambiguous cases I can't be sure if I should use the original classes in System.Core or the new duplicated classes in Microsoft.Scripting.Core. I'm amazed that Microsoft is releasing an assembly like this, even in beta. I must be missing something. Dody, if you have a version of Microsoft.Scripting.Core that is compatible with the 3.5 framework I'd like to give it a try. 2008/8/20 Dody Gunawinata [EMAIL PROTECTED] I can confirm that this works, one just have to kiss intellisense support goodbye though. Thanks for the effort. If anyone interested, I have a copy of refactored namespace for IP Beta 4 (It compiles and runs on a test site, but I haven't tried it =on my product application yet) -- nomadlife.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] defined in multiple assemblies (framework 3.5)
Hi Curt, I hope your team talk to the ASP.Net MVC/IronPython for ASP.Net guys that are working on putting dynamic support language for ASP.Net. If this namespace collision does not retard those projects and its users to be able to utilize .Net 3.5 framework library, then this problem is only a PITA but not a deal breaker. The issue that affects the current .Net 3.5 websites are two folds: 1. The presence of Microsoft.Scripting.Core wreak havoc on the .Net 3.5 code behind code by preventing people using standard System.Core libraries (Dino's workaround will work on this, but that's why suggestion No.1 does not work) 2. This eliminates an XCOPY deployment scenario because we have to install Microsoft.Scripting.dll to the GAC and you have to specify an absolute path in the /reference: compiler options to make it work. *This namespace collision only affects those who are using both the hosting interfaces and System.Core features in the same project. We believe this to be a fairly small percentage of all IronPython users. * If you are planning for the future, this fact is going to change pretty soon. .Net 3.5 was released 6 months ago and the new adopter of DLR will be .Net 3.5 guys. Dody G. On Thu, Aug 21, 2008 at 8:43 AM, Curt Hagenlocher [EMAIL PROTECTED]wrote: I know that to the outside, Microsoft looks like a big company with a lot of people. And of course, it is! But the number of people working on dynamic languages is pretty small, and we have to carefully decide where our resources will serve the largest number of users and potential users. There are two kinds of changes that have been made to the DLR over the past months. The bulk of the work involves features -- including ironing out the hosting interfaces and finding the right balance between parts that belong in the shared DLR and parts that belong in the individual languages. But the other type of changes have been more forward-looking -- they're there to support future releases of other Microsoft projects. It's one of those changes that is causing this namespace collision between Microsoft.Scripting.Core.dll and System.Core.dll. Now, the DLR team can't just tell those other projects that sorry, you'll have to wait for the changes you need because they've already made a commitment with dates and deadlines. IronPython could have chosen to fork the DLR code at a point before these changes were made. But this would mean that someone would have to regularly review the changes and fixes made on the main line of DLR development and integrate those back into IronPython's private copy. We do not believe that the benefit to our users justifies the level of effort required to do this. We think that most of our users would prefer us to focus our resources on more tangible benefits like improving performance and compatibility with CPython. This namespace collision only affects those who are using both the hosting interfaces and System.Core features in the same project. We believe this to be a fairly small percentage of all IronPython users. And for most such projects, the workaround is fairly simple -- if it weren't, we probably wouldn't have gone down this route. But what you've identified is that we did not realize that the solution for Web Site projects would be both different and more complicated than the workaround for other project types. The situation is almost certainly not going to change by the time IronPython 2.0 is released. In order to use both System.Core and the DLR in the same Web Site project, you will have to do one of two things: 1) Keep the DLR hosting pieces in a separate Class Library project and incorporate the output .DLL of this project into your Web Site project, or 2) Use the workaround that Dino posted. I assume your comment about loss of Intellisense is strictly for the DLR; I would guess that it's because the language service doesn't know that it needs to extract the DLR alias information from web.config. In a more ideal world, we wouldn't need these workarounds. Nonetheless, neither seems particularly onerous to me. If you feel strongly that this is something which needs to be changed, please add a item to CodePlex to track the request. We use the number of votes that each item gets in order to track the level of support it has in the community. This, in turn, helps us to gauge how our efforts can best serve our users. Thanks, -Curt On Wed, Aug 20, 2008 at 12:56 PM, Fernando Correia [EMAIL PROTECTED] wrote: I spent some time trying to create a version of Microsoft.Scripting.Core that is compatible with the framework 3.5. But I gave up because it is a huge job and in ambiguous cases I can't be sure if I should use the original classes in System.Core or the new duplicated classes in Microsoft.Scripting.Core. I'm amazed that Microsoft is releasing an assembly like this, even in beta. I must be missing something. Dody, if you have a
[IronPython] Ironclad v0.5 released
(Cross-posted from the c-extensions-for-ironpython google group -- I
thought a few people here might be interested too :))
Hi all
Our original goal for 0.5 was to import numpy, from IronPython, and do
something with it. With one monstrous caveat, we have reached that goal;
the problem is that you need to comment out line 532 of
numpy.core.numerictypes.py before it'll import. That line reads
_unicodesize = array('u','U1').itemsize, and fails trying to construct
a unicode array; however, since _unicodesize appears to be unreferenced,
we feel reasonably comfortable ignoring it for now.
Once numpy is imported, you can create integer arrays and do a few
things with them; of course, the number of things you can do is still
dwarfed by the number of things you can't do. You can add, subtract and
multiply integer arrays, and raise them to integer powers... and that's
about it.
We will continue to work on numpy; immediate goals include getting
floating-point arrays to print out as numbers instead of NaNs, hooking
up the many missing PyTypeObject fields, and implementing more API
functions as we encounter them. I don't have a very clear goal in mind
for v0.6 as yet; making floating-point arrays work properly is obviously
critical, but further steps are not yet clear. If anyone is
particularly keen to start using numpy with IronPython, please get in
touch; I'm keen to know what you want to do with it, so I can focus on
features I know are valuable :).
Best
William
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Ironclad v0.5 released
Hello Will,
Congratulations!
It may be still too early - but a useful test for Ironclad might be to get
matplotlib to import and generate a simple chart.
That would require being able to import numpy *and* PIL (so would exercise
Ironclad fairly thoroughly) and allow you to do something practical with it.
Michael
2008/8/21 William Reade [EMAIL PROTECTED]
(Cross-posted from the c-extensions-for-ironpython google group -- I
thought a few people here might be interested too :))
Hi all
Our original goal for 0.5 was to import numpy, from IronPython, and do
something with it. With one monstrous caveat, we have reached that goal; the
problem is that you need to comment out line 532 of
numpy.core.numerictypes.py before it'll import. That line reads
_unicodesize = array('u','U1').itemsize, and fails trying to construct a
unicode array; however, since _unicodesize appears to be unreferenced, we
feel reasonably comfortable ignoring it for now.
Once numpy is imported, you can create integer arrays and do a few things
with them; of course, the number of things you can do is still dwarfed by
the number of things you can't do. You can add, subtract and multiply
integer arrays, and raise them to integer powers... and that's about it.
We will continue to work on numpy; immediate goals include getting
floating-point arrays to print out as numbers instead of NaNs, hooking up
the many missing PyTypeObject fields, and implementing more API functions as
we encounter them. I don't have a very clear goal in mind for v0.6 as yet;
making floating-point arrays work properly is obviously critical, but
further steps are not yet clear. If anyone is
particularly keen to start using numpy with IronPython, please get in
touch; I'm keen to know what you want to do with it, so I can focus on
features I know are valuable :).
Best
William
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.ironpython.info/
http://www.resolverhacks.net/
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Ironclad v0.5 released
2008/8/21 Michael Foord [EMAIL PROTECTED]: It may be still too early - but a useful test for Ironclad might be to get matplotlib to import and generate a simple chart. That would require being able to import numpy *and* PIL (so would exercise Ironclad fairly thoroughly) and allow you to do something practical with it. Not to speak of huge amount of pure Python codes in matplotlib, which I assume is bound to trigger some IronPython compat bug... (It's just a lot of codes. No offense intended to IronPython team.) -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] defined in multiple assemblies (framework 3.5)
Curt, believe me, we all appreciate very much what the dynamic language teams are doing. It is just great to see such a movement going on. But I second Dody's remarks. He said it very well. The first solution does not work (that's my problem scenario exactly) and the second one may be too unwieldy. Well, if the first release of IronPython 2 won't work with .Net 3.5 websites that use the latest language enhancements, then I guess I will have to reevaluate my options for scripting. Maybe the community can create a fork of Microsoft.Scripting.Core that would be compatible with the latest runtime libraries. 2008/8/21 Dody Gunawinata [EMAIL PROTECTED]: Hi Curt, I hope your team talk to the ASP.Net MVC/IronPython for ASP.Net guys that are working on putting dynamic support language for ASP.Net. If this namespace collision does not retard those projects and its users to be able to utilize .Net 3.5 framework library, then this problem is only a PITA but not a deal breaker. The issue that affects the current .Net 3.5 websites are two folds: 1. The presence of Microsoft.Scripting.Core wreak havoc on the .Net 3.5 code behind code by preventing people using standard System.Core libraries (Dino's workaround will work on this, but that's why suggestion No.1 does not work) 2. This eliminates an XCOPY deployment scenario because we have to install Microsoft.Scripting.dll to the GAC and you have to specify an absolute path in the /reference: compiler options to make it work. This namespace collision only affects those who are using both the hosting interfaces and System.Core features in the same project. We believe this to be a fairly small percentage of all IronPython users. If you are planning for the future, this fact is going to change pretty soon. .Net 3.5 was released 6 months ago and the new adopter of DLR will be .Net 3.5 guys. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] importing on different threads
We are trying parallel imports, which somtimes fail with ImportError (ipy 1.1.1). This happens when one thread attempts to import a module which is being imported on a different thread. The number of such risky imports is not high, and we deal with this by catching the exception and retrying. What do you think? Is it a wrong thing to do? I would like to avoid locking. I have just glimpsed over the IronPython source. Does the problem here is that when one thread starts to import a module it inserts an emty entry into sys.modules, thus other threads get None (or ImportError when using import from statement) until the module is fully imported? Kamil Dworakowski Resolver Systems Ltd ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] importing on different threads
What's the scenario under which you want to do this? Is there a fixed set of modules being imported by your application or is the list not known until runtime? The behavior you describe with respect to sys.modules is identical to that in CPython. In fact, it's required in order to resolve circular imports. Without it, if module A were to import module B and module B imported module A, you'd end up with infinite recursion. Where IronPython is worse than CPython in this regard is that it takes us longer to import a module. This increases the chance for a collision in an application where modules may be imported from multiple threads. On Thu, Aug 21, 2008 at 5:11 AM, Kamil Dworakowski [EMAIL PROTECTED]wrote: We are trying parallel imports, which somtimes fail with ImportError (ipy 1.1.1). This happens when one thread attempts to import a module which is being imported on a different thread. The number of such risky imports is not high, and we deal with this by catching the exception and retrying. What do you think? Is it a wrong thing to do? I would like to avoid locking. I have just glimpsed over the IronPython source. Does the problem here is that when one thread starts to import a module it inserts an emty entry into sys.modules, thus other threads get None (or ImportError when using import from statement) until the module is fully imported? Kamil Dworakowski Resolver Systems Ltd ___ 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 do I determine whether a database supports transactions?
On Wed, Aug 20, 2008 at 10:55 PM, Seo Sanghyeon [EMAIL PROTECTED] wrote: 2008/8/21 Curt Hagenlocher [EMAIL PROTECTED]: In the long term, I think you're definitely better off rewriting against ADO.NET, but I can certainly see the attraction in getting something to work more quickly if you can continue to use the COM ADO objects. Especially, when it seems to me that interface provided by CPython/win32com is almost compatible with IronPython/.NET COM interop. Definitely. No doubt I'm just bitter as a result of bad experiences with classic ADO at my previous job. :) -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] importing on different threads
2008/8/21 Curt Hagenlocher [EMAIL PROTECTED]: Where IronPython is worse than CPython in this regard is that it takes us longer to import a module. This increases the chance for a collision in an application where modules may be imported from multiple threads. No, IronPython is worse in that its importer is not locked. CPython has (in addition to Global Interpreter Lock, since imported module can be a C extension) a lock around its importer: see imp.acquire_lock and imp.release_lock. Since import can cause another import, this is a reentrant lock. -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] importing on different threads
We want Resolve One to start quicker. We have found large speedups by delaying importing of some modules. This is implemented by moving some import statements into bodies of methods and function, so that the modules are imported lazily when they are actually needed. Since Resolver One runs many threads clashes happen. Kamil On Thu, Aug 21, 2008 at 1:53 PM, Curt Hagenlocher [EMAIL PROTECTED]wrote: What's the scenario under which you want to do this? Is there a fixed set of modules being imported by your application or is the list not known until runtime? The behavior you describe with respect to sys.modules is identical to that in CPython. In fact, it's required in order to resolve circular imports. Without it, if module A were to import module B and module B imported module A, you'd end up with infinite recursion. Where IronPython is worse than CPython in this regard is that it takes us longer to import a module. This increases the chance for a collision in an application where modules may be imported from multiple threads. On Thu, Aug 21, 2008 at 5:11 AM, Kamil Dworakowski [EMAIL PROTECTED] wrote: We are trying parallel imports, which somtimes fail with ImportError (ipy 1.1.1). This happens when one thread attempts to import a module which is being imported on a different thread. The number of such risky imports is not high, and we deal with this by catching the exception and retrying. What do you think? Is it a wrong thing to do? I would like to avoid locking. I have just glimpsed over the IronPython source. Does the problem here is that when one thread starts to import a module it inserts an emty entry into sys.modules, thus other threads get None (or ImportError when using import from statement) until the module is fully imported? Kamil Dworakowski Resolver Systems Ltd ___ 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] importing on different threads
On Thu, Aug 21, 2008 at 5:59 AM, Seo Sanghyeon [EMAIL PROTECTED] wrote: No, IronPython is worse in that its importer is not locked. CPython has (in addition to Global Interpreter Lock, since imported module can be a C extension) a lock around its importer: see imp.acquire_lock and imp.release_lock. Since import can cause another import, this is a reentrant lock. I see that we've implemented these functions, but I don't think they're actually being used to guard an import. I'll look into that. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] importing on different threads
As things stand now, I think you'll need either some kind of manual locking or you'll need a different heuristic to tell you whether or not the module has finished loading. On Thu, Aug 21, 2008 at 7:20 AM, Kamil Dworakowski [EMAIL PROTECTED]wrote: We want Resolve One to start quicker. We have found large speedups by delaying importing of some modules. This is implemented by moving some import statements into bodies of methods and function, so that the modules are imported lazily when they are actually needed. Since Resolver One runs many threads clashes happen. Kamil On Thu, Aug 21, 2008 at 1:53 PM, Curt Hagenlocher [EMAIL PROTECTED]wrote: What's the scenario under which you want to do this? Is there a fixed set of modules being imported by your application or is the list not known until runtime? The behavior you describe with respect to sys.modules is identical to that in CPython. In fact, it's required in order to resolve circular imports. Without it, if module A were to import module B and module B imported module A, you'd end up with infinite recursion. Where IronPython is worse than CPython in this regard is that it takes us longer to import a module. This increases the chance for a collision in an application where modules may be imported from multiple threads. On Thu, Aug 21, 2008 at 5:11 AM, Kamil Dworakowski [EMAIL PROTECTED] wrote: We are trying parallel imports, which somtimes fail with ImportError (ipy 1.1.1). This happens when one thread attempts to import a module which is being imported on a different thread. The number of such risky imports is not high, and we deal with this by catching the exception and retrying. What do you think? Is it a wrong thing to do? I would like to avoid locking. I have just glimpsed over the IronPython source. Does the problem here is that when one thread starts to import a module it inserts an emty entry into sys.modules, thus other threads get None (or ImportError when using import from statement) until the module is fully imported? Kamil Dworakowski Resolver Systems Ltd ___ 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
[IronPython] CustomSymbolDictionary and conversions
Hi,
I've derived from CustomSymbolDictionary to add specific variables to a
scope (see seshadripv's blog). What I would expect from a method called
TryGetExtraValue is that only if the scope (where the
IAttributesCollection was added in the constructor) cannot find the
SymbolId, the ExtraValue-method is called. But it seems that this method
is called on each request.
Therefore one needs to have a base scope, which is given to the
SymbolDictionary and evaluations take place in an additional scope
created with the IAttributesCollection in the constructor.
protected override bool TryGetExtraValue(SymbolId key, out object value)
{
if (baseScope.TryGetVariable(SymbolTable.IdToString(key), out value))
return true;
// ...
}
As the baseScope only has TryGetVariable(string), I need to convert the
SymbolId to a string and baseScope probably converts the string back
again to SymbolId.
Is there a way to work more directly with the IAttributesCollection?
Thanks,
Christian
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Determine used SymbolIds in an expression
Hi, how can I determine the Symbols or SymbolIds that are used in an (IP2-)expression? Obviously I need to parse the expression. Where can I find a small sample or tutorial on parsing in IP2? Thanks, Christian ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Process.GetProcessById error
Hi, Using ironpython I'm trying to get the active window details. Refering to voidspace (http://www.voidspace.org.uk/ironpython/winforms/ part10.shtml), I've created a user32 dll. I'm using the below code. if User32.GetWindowText(hd, txt, WndTitleChars): pid = clr.Reference[Int32](0) User32.GetWindowThreadProcessId(hd, pid) Process.GetProcessById(pid) However the process.getprocessbyid line is generating an error: Cannot convert Reference[int](Reference(2872)) to Int32. Can someone please help me to fix this? Thank you, Joseph ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] CustomSymbolDictionary and conversions
The TryGetExtraValue and TrySetExtraValue methods can return a false for
SymbolIDs that they don't maintain. Those values will be looked up in the
actual scope.
For ex, if you have a script snippet like - someVar = 1+2 the variable access
for 'someVar' will result in a call to TryGetExtraValue. But if you can return
a false, the value will be fetched from the scope and it will correctly lookup
the value as '3'.
So, instead of calling the TryGet* method when the scope cannot find the
symbolID, it calls this method for all symbolIDs and whenever the TryGet*
returns a false, it looks the value up in its own storage.
Hope this helps.
Sesh
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Schmidt
Sent: Thursday, August 21, 2008 8:36 AM
To: Discussion of IronPython
Subject: [IronPython] CustomSymbolDictionary and conversions
Hi,
I've derived from CustomSymbolDictionary to add specific variables to a
scope (see seshadripv's blog). What I would expect from a method called
TryGetExtraValue is that only if the scope (where the
IAttributesCollection was added in the constructor) cannot find the
SymbolId, the ExtraValue-method is called. But it seems that this method
is called on each request.
Therefore one needs to have a base scope, which is given to the
SymbolDictionary and evaluations take place in an additional scope
created with the IAttributesCollection in the constructor.
protected override bool TryGetExtraValue(SymbolId key, out object value)
{
if (baseScope.TryGetVariable(SymbolTable.IdToString(key), out value))
return true;
// ...
}
As the baseScope only has TryGetVariable(string), I need to convert the
SymbolId to a string and baseScope probably converts the string back
again to SymbolId.
Is there a way to work more directly with the IAttributesCollection?
Thanks,
Christian
___
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] importing on different threads
Thanks, we will try manual locking. On Thu, Aug 21, 2008 at 3:42 PM, Curt Hagenlocher [EMAIL PROTECTED]wrote: As things stand now, I think you'll need either some kind of manual locking or you'll need a different heuristic to tell you whether or not the module has finished loading. On Thu, Aug 21, 2008 at 7:20 AM, Kamil Dworakowski [EMAIL PROTECTED] wrote: We want Resolve One to start quicker. We have found large speedups by delaying importing of some modules. This is implemented by moving some import statements into bodies of methods and function, so that the modules are imported lazily when they are actually needed. Since Resolver One runs many threads clashes happen. Kamil On Thu, Aug 21, 2008 at 1:53 PM, Curt Hagenlocher [EMAIL PROTECTED]wrote: What's the scenario under which you want to do this? Is there a fixed set of modules being imported by your application or is the list not known until runtime? The behavior you describe with respect to sys.modules is identical to that in CPython. In fact, it's required in order to resolve circular imports. Without it, if module A were to import module B and module B imported module A, you'd end up with infinite recursion. Where IronPython is worse than CPython in this regard is that it takes us longer to import a module. This increases the chance for a collision in an application where modules may be imported from multiple threads. On Thu, Aug 21, 2008 at 5:11 AM, Kamil Dworakowski [EMAIL PROTECTED] wrote: We are trying parallel imports, which somtimes fail with ImportError (ipy 1.1.1). This happens when one thread attempts to import a module which is being imported on a different thread. The number of such risky imports is not high, and we deal with this by catching the exception and retrying. What do you think? Is it a wrong thing to do? I would like to avoid locking. I have just glimpsed over the IronPython source. Does the problem here is that when one thread starts to import a module it inserts an emty entry into sys.modules, thus other threads get None (or ImportError when using import from statement) until the module is fully imported? Kamil Dworakowski Resolver Systems Ltd ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] defined in multiple assemblies (framework 3.5)
Dody, I am checking out if a fork of IronPython can work with the 3.5
framework inside a website. I tried your version and it seems to
eliminate almost all the warnings and errors I had. But there is one
left.
In your sample website I get this:
The predefined type
'System.Runtime.CompilerServices.ExtensionAttribute' is defined in
multiple assemblies in the global alias
On my website using your DLL I also get this:
Error 16 'ExtensionAttribute' is ambiguous in the namespace
'System.Runtime.CompilerServices'. InternalXmlHelper.vb
I tried to change the namespace of the ExtensionAttribute class but
then I get errors in Extension.cs and CollectionUtils.cs in code like
this:
internal static ReadOnlyCollectionT ToReadOnlyT(this
IEnumerableT enumerable) { ...
Then I tried (again) to convert Microsoft.Scripting.Core and
Microsoft.Scripting to the 3.5 framework but the impact seems too
great. I fixed hundreds of compile errors that were raised but gave
up.
I'm also worried that this namespace changing in
Microsoft.Scripting.Core may never end, as future DLLs that are
incorporated in the website may raise other duplications between
Microsoft.Scripting.Core and System.Core.
Any hint?
2008/8/21 Dody Gunawinata [EMAIL PROTECTED]:
This is the source with modified Microsoft.Scripting.Core.
http://www.yousendit.com/transfer.php?action=batch_statusbatch_id=Q01IYUl1YStxRTJ4dnc9PQ
This has minimalist changes only to that dll.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] defined in multiple assemblies (framework 3.5)
*Error 16 'ExtensionAttribute' is ambiguous in the namespace
'System.Runtime.* *CompilerServices'. InternalXmlHelper.vb*
Change your setting from treating warning as error to None.
*The predefined type
'System.Runtime.**CompilerServices.**ExtensionAttribute' is defined in
multiple assemblies in the global alias
*
Yup. *This is the only namespace that I cannot change without blowing stuff
up.* I went through the same cycle as you. Tried everything and this is the
best I can do for now, a compiler warning for one single attribute class.
It's fine for now. My CMS backend is now on Beta 4.
But yeah, this makes it hard to recommend people to use IronPython in their
web application right now. Too much caveat. I think this will get fixed
eventually because the MVC ASP.Net guys will have to deal with the same
thing as well.
For your scripting choice, DLR still has the best hosting interface so far.
I've tried phallanger, boo and Lua integration integration before - too much
work.
Dody G.
On Thu, Aug 21, 2008 at 8:28 PM, Fernando Correia
[EMAIL PROTECTED] wrote:
Dody, I am checking out if a fork of IronPython can work with the 3.5
framework inside a website. I tried your version and it seems to
eliminate almost all the warnings and errors I had. But there is one
left.
In your sample website I get this:
The predefined type
'System.Runtime.CompilerServices.ExtensionAttribute' is defined in
multiple assemblies in the global alias
On my website using your DLL I also get this:
Error 16 'ExtensionAttribute' is ambiguous in the namespace
'System.Runtime.CompilerServices'. InternalXmlHelper.vb
I tried to change the namespace of the ExtensionAttribute class but
then I get errors in Extension.cs and CollectionUtils.cs in code like
this:
internal static ReadOnlyCollectionT ToReadOnlyT(this
IEnumerableT enumerable) { ...
Then I tried (again) to convert Microsoft.Scripting.Core and
Microsoft.Scripting to the 3.5 framework but the impact seems too
great. I fixed hundreds of compile errors that were raised but gave
up.
I'm also worried that this namespace changing in
Microsoft.Scripting.Core may never end, as future DLLs that are
incorporated in the website may raise other duplications between
Microsoft.Scripting.Core and System.Core.
Any hint?
2008/8/21 Dody Gunawinata [EMAIL PROTECTED]:
This is the source with modified Microsoft.Scripting.Core.
http://www.yousendit.com/transfer.php?action=batch_statusbatch_id=Q01IYUl1YStxRTJ4dnc9PQ
This has minimalist changes only to that dll.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
nomadlife.org
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] defined in multiple assemblies (framework 3.5)
Dody, thanks for your feedback. It's encouraging to know it is possible to make this work, at least in some circunstances. In my case, I am getting an actual error, not a warning. It seems it has something to do with new VB XML features. I will try and see if I can dig the problem. But I don't feel so confident about deploying such a hack in production. I'm building an open application that can be extended and some DLL that is deployed in Bin may run into some other incompatibility with the new DLR. 2008/8/21 Dody Gunawinata [EMAIL PROTECTED]: Error 16 'ExtensionAttribute' is ambiguous in the namespace 'System.Runtime. CompilerServices'. InternalXmlHelper.vb Change your setting from treating warning as error to None. The predefined type 'System.Runtime. CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias Yup. This is the only namespace that I cannot change without blowing stuff up. I went through the same cycle as you. Tried everything and this is the best I can do for now, a compiler warning for one single attribute class. It's fine for now. My CMS backend is now on Beta 4. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] defined in multiple assemblies (framework 3.5)
OK. Good luck with making the decision. My project is already married to IronPython for 16 months now. For better or worse .. :) Dody G. On Thu, Aug 21, 2008 at 9:15 PM, Fernando Correia [EMAIL PROTECTED] wrote: Dody, thanks for your feedback. It's encouraging to know it is possible to make this work, at least in some circunstances. In my case, I am getting an actual error, not a warning. It seems it has something to do with new VB XML features. I will try and see if I can dig the problem. But I don't feel so confident about deploying such a hack in production. I'm building an open application that can be extended and some DLL that is deployed in Bin may run into some other incompatibility with the new DLR. 2008/8/21 Dody Gunawinata [EMAIL PROTECTED]: Error 16 'ExtensionAttribute' is ambiguous in the namespace 'System.Runtime. CompilerServices'. InternalXmlHelper.vb Change your setting from treating warning as error to None. The predefined type 'System.Runtime. CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias Yup. This is the only namespace that I cannot change without blowing stuff up. I went through the same cycle as you. Tried everything and this is the best I can do for now, a compiler warning for one single attribute class. It's fine for now. My CMS backend is now on Beta 4. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- nomadlife.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] defined in multiple assemblies (framework 3.5)
Thanks for your support, Dody. It's really a difficult decision. I think the error about InternalXmlHelper.vb is being caused by some component, maybe something from Infragistics or something like that. I really can't run the risk of solving this problem and having another one pop up when another component is added that uses other of those duplicated classes. 2008/8/21 Dody Gunawinata [EMAIL PROTECTED]: OK. Good luck with making the decision. My project is already married to IronPython for 16 months now. For better or worse .. :) ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] IP 2 B5 and Thread.Sleep Warning
Hello all, In the latest code sync from codeplex I get a RuntimeWarning every time I call Thread.Sleep. Is this one of the overzealous warnings that will be fixed? (It is very annoying.) Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes
Hi Michael, I like your idea of publishing performance results for IronPython. A good start would be for us to do this with PyBench on major IronPython releases such as 2.0.0. Seems like there's enough x64 users out there to warrant doing this for x64 Vista as well. No, we don't run benchmarks on XP. It's just a matter of machine resources. As for running the benchmarks on x64 machines with every IronPython/DLR checkin...it's unlikely we'd miss any major perf degrades if we reimage these machines as 32-bit. I've been checking out our old perf reports and nearly every time we've had an x64 degrade, there was a corresponding x86 degrade of equal magnitude. Dave From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Tuesday, August 19, 2008 12:12 AM To: Discussion of IronPython Subject: Re: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes Hello guys, I run IronPython on Vista x64. Isn't 64bit supposed to be the future or something? :-) (I run Vista x64 in a virtual machine under Mac OS - but performance is very good. Visual Studio runs quite nicely.) I'd love to see more IronPython benchmarking (and the results published). Do you still benchmark with XP? (Still a phenomenally successful OS by all accounts). I'm not sure what the consequences of removing 64bit OSes from the benchmarks might be - .NET seems to nicely insulate programmers from the differences, except for things like P/Invoke of course. Performance is one area where it might make a difference though (it would be a shame to accidentally hose performance on 64bit machines and not realise - is this likely?) What about releasing the benchmark suite with a means to submit results including platform information - that way we can submit results back to you? (By email to the list I guess.) We could even setup some external 'buildbot' machines that automatically sync to codeplex. Anyway - I'd be happy to run benchmark suites occasionally. Michael 2008/8/19 Dave Fugate [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Hi everyone, one of the things the IronPython test team does daily is run a set of standardized benchmarks against the latest internal build of IronPython. We're in the process of reevaluating the platforms we measure these benchmarks on with the end goal of increasing the number of tests we can run. For example, if we could cut x64 Vista from the list of platforms, the x64 Vista machine(s) could be reimaged to run new benchmarks we wouldn't have had the resources for before. Alternatively, we might reimage the x64 Vista machine(s) as some other platform we don't currently test under. Of course in such a scenario we'd still run other classifications of tests under x64 Vista. I wanted to hear peoples' opinions on the importance of measuring IronPython performance under x64 Windows OSes before we make any decisions on this. First off, how many people out there are actually running IronPython under a 64-bit OS? Would it be sufficient for us to report news on IronPython performance in terms of 32-bit platforms? Thanks, The IronPython Team ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] How do I determine whether a database supports transactions?
IPy does intend to support COM well. See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx. If something does not work, please do report a bug. The following worked for me. So using the natural indexing syntax is what you need. c:\vsl\Merlin\Mainipyd import System t = System.Type.GetTypeFromProgID(ADODB.Connection) com = System.Activator.CreateInstance(t) com.Properties[com.Properties.Count - 1] System.__ComObject (Property) object at 0x002F com.Properties[com.Properties.Count] Traceback (most recent call last): File stdin, line 1, in module EnvironmentError: Item cannot be found in the collection corresponding to the requested name or ordinal. Thanks, Shri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Thursday, August 21, 2008 5:57 AM To: Discussion of IronPython Subject: Re: [IronPython] How do I determine whether a database supports transactions? On Wed, Aug 20, 2008 at 10:55 PM, Seo Sanghyeon [EMAIL PROTECTED] wrote: 2008/8/21 Curt Hagenlocher [EMAIL PROTECTED]: In the long term, I think you're definitely better off rewriting against ADO.NET, but I can certainly see the attraction in getting something to work more quickly if you can continue to use the COM ADO objects. Especially, when it seems to me that interface provided by CPython/win32com is almost compatible with IronPython/.NET COM interop. Definitely. No doubt I'm just bitter as a result of bad experiences with classic ADO at my previous job. :) -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] IP 2 B5 and Thread.Sleep Warning
2008/8/21 Curt Hagenlocher [EMAIL PROTECTED] It's a feature! http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=16249 There was a moderately long thread about this back in April. You can turn the warning off either through Python's normal warning-disabling mechanism or by running -X:MTA. Or by doing as the warning suggests and calling Thread.CurrentThread.Join(). Unfortunately, we don't have a reliable way to identify whether or not the situation that prompted this warning has occurred, or we'd take advantage of it. Given the potential for surprise effects -- such as the person who originally reported this problem and was seeing steadily climbing memory utilization in his process -- it seems to us like a good warning to have. As always, we're interested in hearing other points of view. I should have checked. Where is the warning coming from though - I don't get a warning using it from C# ? Michael On Thu, Aug 21, 2008 at 1:11 PM, Michael Foord [EMAIL PROTECTED]wrote: Hello all, In the latest code sync from codeplex I get a RuntimeWarning every time I call Thread.Sleep. Is this one of the overzealous warnings that will be fixed? (It is very annoying.) Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ ___ 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 -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IP 2 B5 and Thread.Sleep Warning
2008/8/22 Michael Foord [EMAIL PROTECTED] 2008/8/21 Curt Hagenlocher [EMAIL PROTECTED] It's a feature! http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=16249 There was a moderately long thread about this back in April. You can turn the warning off either through Python's normal warning-disabling mechanism or by running -X:MTA. Or by doing as the warning suggests and calling Thread.CurrentThread.Join(). Unfortunately, we don't have a reliable way to identify whether or not the situation that prompted this warning has occurred, or we'd take advantage of it. Given the potential for surprise effects -- such as the person who originally reported this problem and was seeing steadily climbing memory utilization in his process -- it seems to us like a good warning to have. As always, we're interested in hearing other points of view. I should have checked. Where is the warning coming from though - I don't get a warning using it from C# ? Ah. I see the issue - the warning was added deliberately (and I remember the discussion now). *sigh* Michael On Thu, Aug 21, 2008 at 1:11 PM, Michael Foord [EMAIL PROTECTED] wrote: Hello all, In the latest code sync from codeplex I get a RuntimeWarning every time I call Thread.Sleep. Is this one of the overzealous warnings that will be fixed? (It is very annoying.) Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ ___ 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 -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] CustomSymbolDictionary and conversions
Hi Seshadri, thanks for your answer. The TryGetExtraValue and TrySetExtraValue methods can return a false for SymbolIDs that they don't maintain. Those values will be looked up in the actual scope. I see, makes sense. When accessing the baseScope from your example, isn't SymbolTable.IdToString(key) for each access to the baseScope slow? I wonder, why there is no ScriptScope.GetVariable(SymbolId) method. What would be the approach to extend a ScriptScope by the properties of an object? Or in other words: How can I evaluate an expression in an object's scope? Regards, Christian ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
