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
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,
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
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
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
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.
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
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
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
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
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
11 matches
Mail list logo
