Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-21 Thread Dody Gunawinata
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

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-21 Thread Dody Gunawinata
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

[IronPython] Ironclad v0.5 released

2008-08-21 Thread William Reade
(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

Re: [IronPython] Ironclad v0.5 released

2008-08-21 Thread Michael Foord
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

Re: [IronPython] Ironclad v0.5 released

2008-08-21 Thread Seo Sanghyeon
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

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-21 Thread Fernando Correia
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

[IronPython] importing on different threads

2008-08-21 Thread Kamil Dworakowski
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.

Re: [IronPython] importing on different threads

2008-08-21 Thread Curt Hagenlocher
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

Re: [IronPython] How do I determine whether a database supports transactions?

2008-08-21 Thread Curt Hagenlocher
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

Re: [IronPython] importing on different threads

2008-08-21 Thread Seo Sanghyeon
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

Re: [IronPython] importing on different threads

2008-08-21 Thread Kamil Dworakowski
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

Re: [IronPython] importing on different threads

2008-08-21 Thread Curt Hagenlocher
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

Re: [IronPython] importing on different threads

2008-08-21 Thread Curt Hagenlocher
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

[IronPython] CustomSymbolDictionary and conversions

2008-08-21 Thread Christian Schmidt
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

[IronPython] Determine used SymbolIds in an expression

2008-08-21 Thread Christian Schmidt
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

[IronPython] Process.GetProcessById error

2008-08-21 Thread cephire
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 =

Re: [IronPython] CustomSymbolDictionary and conversions

2008-08-21 Thread Seshadri Pillailokam Vijayaraghavan
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

Re: [IronPython] importing on different threads

2008-08-21 Thread Kamil Dworakowski
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,

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-21 Thread Fernando Correia
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

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-21 Thread Dody Gunawinata
*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

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-21 Thread Fernando Correia
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

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-21 Thread Dody Gunawinata
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

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-21 Thread Fernando Correia
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

[IronPython] IP 2 B5 and Thread.Sleep Warning

2008-08-21 Thread Michael Foord
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/

Re: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes

2008-08-21 Thread Dave Fugate
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

Re: [IronPython] How do I determine whether a database supports transactions?

2008-08-21 Thread Shri Borde
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.

Re: [IronPython] IP 2 B5 and Thread.Sleep Warning

2008-08-21 Thread Michael Foord
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

Re: [IronPython] IP 2 B5 and Thread.Sleep Warning

2008-08-21 Thread Michael Foord
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

Re: [IronPython] CustomSymbolDictionary and conversions

2008-08-21 Thread Christian Schmidt
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