[IronPython] .Net based script engine exception handling
I am developing a .net based script engine to execute python scripts. I want to handle exceptions and to track all errors related to script. What would be the best way to handle exceptions and to track line and column numbers etc. I am using scriptEngine.formatException(someException) method to format the exception but it throws some junk values as well with the formatted text. what would be the best way to achieve this functionality ? Yasir Godil -- View this message in context: http://www.nabble.com/.Net-based-script-engine-exception-handling-tp19052524p19052524.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
Re: [IronPython] defined in multiple assemblies (framework 3.5)
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)
Dody G.
On Wed, Aug 20, 2008 at 12:03 AM, Dino Viehland [EMAIL PROTECTED] wrote:
Ok, I believe I've gotten this to work.I know very little about
ASP.NET so I'm just going to walk through the steps to setup a new Web
Site which can use the DLR. The key limitation here is that if you're
referring to a type out of Microsoft.Scripting.Core.dll you'll need to do it
from a .CS file. If you like inline script tags you can still use them
but you'll need to add helpers to your .cs file for getting whatever you'd
want from the alternate namespace.
Let's get started. First you need to install the DLR IronPython (or
other DLR languages) into the GAC.
Next in VS create your web site - File-New-Web Site… Save it somewhere.
In the new project you need to make 2 updates to web.config:
First add the compiler options reference to
Microsoft.Scripting.Core.dll for whatever language you're using. Luckily
you don't need this very often so having the extra verbose syntax isn't too
bad. I'm using C# so this ends up looking like:
compiler language=c#;cs;csharp extension=.cs warningLevel=4
type=Microsoft.CSharp.CSharpCodeProvider, System,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
compilerOptions=quot;/reference:DLR=C:\Program
Files\IronPython 2.0Beta4\Microsoft.Scripting.Core.dllquot;
Second add a reference to Microsoft.Scripting.dll so you
have access to the hosting APIs:
assemblies
add assembly=System.Core, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=B77A5C561934E089/
add assembly=System.Web.Extensions, Version=3.5.0.0,
Culture=neutral, PublicKeyToken=31BF3856AD364E35/
add assembly=System.Data.DataSetExtensions, Version=3.5.0.0,
Culture=neutral, PublicKeyToken=B77A5C561934E089/
add assembly=System.Xml.Linq, Version=3.5.0.0,
Culture=neutral, PublicKeyToken=B77A5C561934E089/
add assembly=Microsoft.Scripting, Version=1.0.0.4000,
Culture=neutral, PublicKeyToken=31bf3856ad364e35,
processorArchitecture=MSIL/
/assemblies
Next let's drop in our code. The code needs to go into the .cs file
associated with the page. In the new site you have a Default.aspx.cs page
which is pre-created for you. At the top of that file you need to add
extern alias DLR; – or whatever alias you used when adding the
Microsoft.Scripting.Core.dll reference. Next add a using statement to bring
in Microsoft.Scripting.Hosting. Now let's write some code in this .cs file!
protected string RunSomeCode(string code) {
var sr = ScriptRuntime.Create();
var engine = sr.GetEngine(py);
var scope = engine.CreateScope();
var source = engine.CreateScriptSourceFromString(code,
DLR.System.Scripting.SourceCodeKind.Expression);
return source.Execute(scope).ToString();
}
protected void OnClickHandler(object sender, EventArgs args) {
result.Text = RunSomeCode(foo.Value);
}
Note the DLR.System.Scripting… when accessing code from
Microsoft.Scripting.Core. Most of the hosting APIs are in the
Microsoft.Scripting.dll so we usually don't need to use that.
Finally edit the default page so it has some space for us to experiment
with scripting. Mine ends up looking like:
%@ Page Language=C# AutoEventWireup=true CodeFile=Default.aspx.cs
Inherits=_Default %
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head id=Head1 runat=server
title/title
/head
body
form id=Form1 runat=server
textarea runat=server id = foo cols = 40 rows=1/
br /
asp:Button ID=Button1 runat=server text=Submit!
onclick=OnClickHandler/
/form
Results: asp:Label runat=server id = result/
/body
/html
Press F5, type 2+2 into the text box and hit submit. It's 4!
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Dody Gunawinata
*Sent:* Tuesday, August 19, 2008 12:01 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5)
OK. Thanks a lot. In the meantime, I'll proceed try to modifying the
namespaces in Microsoft.Scripting.Core (if it's actually possible. Hopefully
there's no internal classes being used)
Dody G.
On Tue, Aug 19, 2008 at 9:38 PM, Dino Viehland [EMAIL PROTECTED]
wrote:
I'm continuing to look into it... We're going to have conflicting names
because Microsoft.Scripting.Core includes a superset of
Re: [IronPython] .Net based script engine exception handling
http://www.nabble.com/how-to-convert-this-code-in-py-2.0-td18748830.html On Wed, Aug 20, 2008 at 10:55 AM, Yasir Godil [EMAIL PROTECTED]wrote: I am developing a .net based script engine to execute python scripts. I want to handle exceptions and to track all errors related to script. What would be the best way to handle exceptions and to track line and column numbers etc. I am using scriptEngine.formatException(someException) method to format the exception but it throws some junk values as well with the formatted text. what would be the best way to achieve this functionality ? Yasir Godil -- View this message in context: .Net based script engine exception handlinghttp://www.nabble.com/.Net-based-script-engine-exception-handling-tp19052524p19052524.html Sent from the IronPython mailing list archivehttp://www.nabble.com/IronPython-f14449.htmlat Nabble.com. ___ 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] Informal Poll: measuring IronPython performance under x64 OSes
From what I've seen on the mailing list and several emails sent directly to me there seems to be about a 50-50 split between x86/x64 interest. Anyone interested in x86 vs x64 IronPython performance might want to check out the following data points taken from two identical Vista machines that differ only in terms of OS bitted-ness: * MAY 2008 - IronPython startup performance is 25% slower on x64 than x86. * JUNE 2007 - IronPython startup performance was %32 slower on x64 than x86. * MAY 2008 - PyBench (Calls) is around 33% slower on x64 than x86. * JUNE 2007 - PyBench (Calls) was 34% slower on x64 than x86. * MAY 2008 - PyStone is 40% slower on x64 than x86. * JUNE 2007 - PyStone is %36 slower on x64 than x86. As you can see, although IronPython performance in given areas may change over the course of a year (PyBench Calls was about 10% faster in May 2008), the delta between IronPython on x86 and x64 platforms pretty much stays the same for a given benchmark. The principal reason behind this is IronPython has few (any?) x64 only code paths. Any differences in performance should be due to differences between the x86 and x64 CLRs. My disclaimer on this statement is that deltas can vary widely depending upon which benchmark we look at (e.g., the delta for PyBench Lists between x86/x64 is under 10%). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Fugate Sent: Monday, August 18, 2008 2:43 PM To: Discussion of IronPython Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes 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.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] [OT] x64 vs x86 (was: RE: Informal Poll: measuring IronPython performance under x64 OSes)
Slightly off-topic: I’m fascinated by x64 vs. x86 performance comparisons like these, especially when x64 lags (often significantly) behind x86. What’s going on here? Does the sheer size difference between x64 code and x86 code trump all other benefits offered by x64? What about all the extra registers available? (Or is that a non-issue given the prolific register re-naming an Intel x86 chip does these days?) Is it just that compilers generating x64 code just aren’t as mature as x86 compilers yet? Or do we incur a penalty from WoW64? Can we never expect the performance of x64 code to surpass x86 code? Surely the momentum towards x64 (try buy a non-x64 CPU these days) is sustained by something other than having access an addressable memory area greater than 2^32? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Fugate Sent: 20 August 2008 22:40 To: Discussion of IronPython Subject: Re: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes From what I’ve seen on the mailing list and several emails sent directly to me there seems to be about a 50-50 split between x86/x64 interest. Anyone interested in x86 vs x64 IronPython performance might want to check out the following data points taken from two identical Vista machines that differ only in terms of OS bitted-ness: · MAY 2008 - IronPython startup performance is 25% slower on x64 than x86. · JUNE 2007 - IronPython startup performance was %32 slower on x64 than x86. · MAY 2008 - PyBench (Calls) is around 33% slower on x64 than x86. · JUNE 2007 - PyBench (Calls) was 34% slower on x64 than x86. · MAY 2008 - PyStone is 40% slower on x64 than x86. · JUNE 2007 - PyStone is %36 slower on x64 than x86. As you can see, although IronPython performance in given areas may change over the course of a year (“PyBench Calls” was about 10% faster in May 2008), the delta between IronPython on x86 and x64 platforms pretty much stays the same for a given benchmark. The principal reason behind this is IronPython has few (any?) x64 only code paths. Any differences in performance should be due to differences between the x86 and x64 CLRs. My disclaimer on this statement is that deltas can vary widely depending upon which benchmark we look at (e.g., the delta for “PyBench Lists” between x86/x64 is under 10%). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Fugate Sent: Monday, August 18, 2008 2:43 PM To: Discussion of IronPython Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes 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.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [OT] x64 vs x86 (was: RE: Informal Poll: measuring IronPython performance under x64 OSes)
For throughput performance, the Just-in-time compilers used by the CLR on x86 and x64 are different code bases, and so have different perf characteristics So in this case, yes, the x64 compiler is not as mature for this environment (JIT compilation). It something that can change going forward. I do not what the specific plans are for improving the x64 JIT... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Trent Nelson Sent: Wednesday, August 20, 2008 3:56 PM To: Discussion of IronPython Subject: [IronPython] [OT] x64 vs x86 (was: RE: Informal Poll: measuring IronPython performance under x64 OSes) Slightly off-topic: I'm fascinated by x64 vs. x86 performance comparisons like these, especially when x64 lags (often significantly) behind x86. What's going on here? Does the sheer size difference between x64 code and x86 code trump all other benefits offered by x64? What about all the extra registers available? (Or is that a non-issue given the prolific register re-naming an Intel x86 chip does these days?) Is it just that compilers generating x64 code just aren't as mature as x86 compilers yet? Or do we incur a penalty from WoW64? Can we never expect the performance of x64 code to surpass x86 code? Surely the momentum towards x64 (try buy a non-x64 CPU these days) is sustained by something other than having access an addressable memory area greater than 2^32? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Fugate Sent: 20 August 2008 22:40 To: Discussion of IronPython Subject: Re: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes From what I've seen on the mailing list and several emails sent directly to me there seems to be about a 50-50 split between x86/x64 interest. Anyone interested in x86 vs x64 IronPython performance might want to check out the following data points taken from two identical Vista machines that differ only in terms of OS bitted-ness: * MAY 2008 - IronPython startup performance is 25% slower on x64 than x86. * JUNE 2007 - IronPython startup performance was %32 slower on x64 than x86. * MAY 2008 - PyBench (Calls) is around 33% slower on x64 than x86. * JUNE 2007 - PyBench (Calls) was 34% slower on x64 than x86. * MAY 2008 - PyStone is 40% slower on x64 than x86. * JUNE 2007 - PyStone is %36 slower on x64 than x86. As you can see, although IronPython performance in given areas may change over the course of a year (PyBench Calls was about 10% faster in May 2008), the delta between IronPython on x86 and x64 platforms pretty much stays the same for a given benchmark. The principal reason behind this is IronPython has few (any?) x64 only code paths. Any differences in performance should be due to differences between the x86 and x64 CLRs. My disclaimer on this statement is that deltas can vary widely depending upon which benchmark we look at (e.g., the delta for PyBench Lists between x86/x64 is under 10%). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Fugate Sent: Monday, August 18, 2008 2:43 PM To: Discussion of IronPython Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes 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.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [OT] x64 vs x86 (was: RE: Informal Poll: measuring IronPython performance under x64 OSes)
On Wed, 20 Aug 2008 23:55:36 +0100, Trent Nelson [EMAIL PROTECTED] wrote: Slightly off-topic: I?m fascinated by x64 vs. x86 performance comparisons like these, especially when x64 lags (often significantly) behind x86. What?s going on here? Does the sheer size difference between x64 code and x86 code trump all other benefits offered by x64? What about all the extra registers available? (Or is that a non-issue given the prolific register re-naming an Intel x86 chip does these days?) Is it just that compilers generating x64 code just aren?t as mature as x86 compilers yet? Or do we incur a penalty from WoW64? Can we never expect the performance of x64 code to surpass x86 code? I'm always surprised by people who expect big performance gains when moving from x86 to x64. The basic instruction set is about the same, and on a given CPU, the individual instructions take the same number of cycles. Pointers and instructions with address literals are twice as long, so you can fit fewer instructions in the cache. Also, remember that you have MSIL in there. The MSIL instruction set is not particularly well mated to CPUs with large register files. For many IronPython programs, you almost end up with an accumulator architecture. Overall, for a native program that is not memory-bound, I expect the x86 and the x64 versions to be pretty much equal in performance. WOW64 is only an issue in the other direction -- running 32-bit apps on a 64-bit operating system. Surely the momentum towards x64 (try buy a non-x64 CPU these days) is sustained by something other than having access an addressable memory area greater than 232? Nope, that really is the *primary* impetus behind x64. SQL Server, for one, runs substantially faster (unbelievably so, in many cases) on an x64 system, because of the reduced swapping. -- Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ 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)
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 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) ___ 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?
If Properties is a COM enumerator, then I seem to recall that indexing may
need to go through something like an Item method in Properties -- that is,
Properties.Item(index) instead of Properties(index). Alternatively,
have you tried doing Properties[index] instead?
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.
On Tue, Aug 19, 2008 at 5:58 PM, Vernon Cole [EMAIL PROTECTED] wrote:
Hello all.
I am the present maintainer of adodbapi, a pure python module which uses
ADO-DB to access SQL databases. (see adodbapi.sourceforge.net) It has been
my stated goal for some time to port the package to Iron Python, since it is
fully DB-API_2.0 compliant, and the existing SQL access library samples for
ipy are relatively light weight.
The present implementation works only in CPython and depends on pywin32 to
make COM calls to access ADO. I originally thought that I would replace all
of the COM interface with ADO.NET calls, but someone suggested that it
would be less rewriting to call COM from ipy, too.
comments about the wisdom of this are welcome.
I could use some help with my present snag.
In the snippet below (which works in CPython) the Properties attribute
of the dispatch object is completely different between the two
implementations. I notice, when I do a dir(adoConn), that ipy shows two
different attributes called Properties , so perhaps the other one has the
interface I want, if I knew how to get at it. I didn't write this code so I
don't know how or why it works, but it is used to see whether a particular
database supports rollback and commit.
What alternate code could I use to aviod calling adoConn.Properties(indx)
as a method?
#begin snippet .
try:
import win32com.client
def Dispatch(dispatch):
return win32com.client.Dispatch(dispatch)
win32 = True
except ImportError: #perhaps running on IronPython
from System import Activator, Type
def Dispatch(dispatch):
type = Type.GetTypeFromProgID(dispatch)
return Activator.CreateInstance(type)
win32 = False#implies IronPython
def connect(connstr, timeout=30):
Connection string as in the ADO documentation, SQL timeout in seconds
conn=Dispatch('ADODB.Connection')
conn.CommandTimeout=timeout
conn.ConnectionString=connstr
conn.Open()
return Connection(conn)
class Connection:
def __init__(self,adoConn):
self.adoConn=adoConn
self.supportsTransactions=False
for indx in range(adoConn.Properties.Count): ### iron py errors on
the next line
if adoConn.Properties(indx).Name == 'Transaction DDL' \
and adoConn.Properties(indx).Value != 0:
self.supportsTransactions=True
self.adoConn.CursorLocation = defaultCursorLocation
if self.supportsTransactions:
self.adoConn.IsolationLevel=defaultIsolationLevel
self.adoConn.BeginTrans() #Disables autocommit
self.messages=[]
#end snippet ..
My resulting stack trace ends with:
File C:\Program Files\IronPython 2.0
Beta4\lib\site-packages\adodbapi\adodbapi.py, line 264, in connect
File C:\Program Files\IronPython 2.0
Beta4\lib\site-packages\adodbapi\adodbapi.py, line 317, in __init__
TypeError: __ComObject is not callable
---
Any suggestions are welcome.
--
Vernon Cole
___
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] Resolver One 1.2 released
Awesome. Congratulations! On Tue, Aug 19, 2008 at 5:25 AM, Giles Thomas [EMAIL PROTECTED] wrote: We are proud to announce the release of Resolver One, version 1.2 - still (we think) the largest IronPython application in the world, now running at 38,000 lines of production code backed up by 150,000 lines of unit and functional tests. Resolver One is a Rapid Application Development tool for analysing and presenting business data, using a familiar spreadsheet interface but with a powerful IronPython-based scripting capability that allows you to insert your own code directly into the recalculation loop. This version's headline feature is a new function called RunWorkbook that allows you to call one spreadsheet from another, passing in parameters and pulling out results - just like functions, but without having to code the function by hand. We've also added a whole bunch of usability enhancements - the full (long!) changelist is up on our website, or you can see a screencast: http://www.resolversystems.com/screencasts/release-1.2 It's free for non-commercial use, so if you would like to take a look, you can download it from our website: http://www.resolversystems.com/get-it/ (registration no longer required). Best regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ 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?
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. -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
