Re: [IronPython] IronPython kills CLR
Hi,
Did you receive my last email? Have you been able to reproduce this
issue? Please let me know how to avoid this bug (I don't want to blow up
my application with some script by incident).
Szymon.
Szymon Kobalczyk wrote:
>I finally found why my NUnit suite doesnt work anymore. It occurs that
>its caused by following test case:
>
>string script = @"
>class Rectangle1(object):
>
>def __init__(self, width, height):
>self.width = width
>self.height = height
>
>def getArea(self):
>return self.width * self.height
>
>area = property(getArea, None, None, None)
>
>r = Rectangle1(10, 100)
>print r.area";
>
>PythonEngine engine = new PythonEngine();
>
>object code = engine.Compile(script);
>engine.Execute(code);
>
>
>Executing this in NUnit just kills the process with no error. When I
>execute it with debugger I get following exception:
>
> >IronPython.dll!IronPython.Runtime.Frame.TryGetLocal(string name =
>"property", out object ret = null) Line 65 + 0x12 bytesC#
> IronPython.dll!IronPython.Runtime.Frame.GetGlobal(string name =
>"property") Line 90 + 0xe bytesC#
> snippets.dll!moduleHolder_0.Rectangle1$maker0() + 0x158 bytes
> snippets.dll!moduleHolder_0.input() + 0xb6 bytes
>
>IronPython.dll!IronPython.Runtime.FrameCode.Run(IronPython.Runtime.Frame
>frame = {IronPython.Runtime.Frame}) Line 165 + 0xd bytesC#
>...
>
>FatalExecutionEngineError was detected
>Message: The runtime has encountered a fatal error. The address of the
>error was at 0x79e7bd7e, on thread 0xc04. The error code is 0xc005.
>This error may be a bug in the CLR or in the unsafe or non-verifiable
>portions of user code. Common sources of this bug include user
>marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
>
>If I execute the same script using IronPythonConsole it works fine.
>Please confirm if this issue would occur only when we use python
>properties (hopefully we don't have any yet in production code) or there
>are other cases to avoid.
>
>Szymon Kobalczyk.
>___
>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] Trying to set methods on "built-in" classes failssilently
Standard practice or not, this begs the question of whether it should be allowed at all. I would argue against it: * security issue * silent fails mask unexpected behavior However, adding *new* members doesn't, to my knowledge, present a security risk. As a comparison, MSH allows new members and aliases to be overlayed on top of existing types, but I don't know whether or not it chokes when attempting to override an existing member. It may be worthwhile to agree with the MSH team on a strategy. From: [EMAIL PROTECTED] on behalf of Giles Thomas Sent: Thu 1/12/2006 1:35 PM I suspect it's not something anyone's likely to come across often, but if you try to rebind a method on a built-in class, no exception will be thrown but it will not be changed. An example: <>___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Trying to set methods on "built-in" classes fails silently
Hi, I suspect it's not something anyone's likely to come across often, but if you try to rebind a method on a built-in class, no exception will be thrown but it will not be changed. An example: You can rebind methods on regular classes easily: --- >>> class C: ... def m(self): ... return 2 ... >>> c = C() >>> c.m() 2 >>> def n(): ... return 3 ... >>> c.m = n >>> c.m() 3 --- However, when you try to do this with a CLR class there's no warning, but it doesn't work: --- >>> f = Form() >>> f.ToString() 'System.Windows.Forms.Form, Text: ' >>> def newToString(): ... return "Hello, world!" ... >>> f.ToString = newToString >>> f.ToString() 'System.Windows.Forms.Form, Text: ' >>> f.ToString == newToString False --- The behaviour when you try to set arbitrary attributes on the built-in classes is nicer, I think: --- >>> f.foobar = 23 Traceback (most recent call last): at TypeError: can't set arbitrary attributes on built-in type System.Windows.Forms.Form --- I've confirmed this in the beta and in 0.9.5 (I hasten to add that I'm not recommending rebinding methods as standard practive...) Cheers, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] We're hiring! http://www.resolversystems.com/jobs/ ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Answers not added to the thread
I'm pretty sure that the right answer depends on what software is being used to determine the threading. Every mail (and Usenet newsgroup) message includes (in the header) a Message-Id: header. This is the one from Detlef's original message: Message-Id: <[EMAIL PROTECTED]> and when you Reply to a message, your email program "should" include, in the header of your reply message, an In-Reply-To: header that refers to it: In-Reply-To: <[EMAIL PROTECTED]> as well as having its own Message-Id: header. That IRT header was in Waylan's reply, and it of course has its own Message-Id: Message-ID: <[EMAIL PROTECTED]> My response to Waylan's message will include In-Reply-To: <[EMAIL PROTECTED]> and any reply to this message will have an In-Reply-To: with the Message-ID: of this message (I don't know what it is, as it's not created until I send it). There are also References: headers that can list multiple other message ids, but the mechanism is a bit less obvious than the In-Reply-To: mechanism. So, Detlef, it's possible that your email program is not producing an In-Reply-To: header when you use the program's Reply feature; that would be a bug. It's possible that you're not using the Reply feature of your email program, but are instead starting a new message when replying -- so your email program doesn't know to include an In-Reply-To: header. It's possible that the threading mechanism whose result you're seeing relies at least as much on References: headers as on In-Reply-To: headers, and that your email program doesn't send what's expected. Finally, it's possible that the position / presence of the Re: is relevant, but that's a very non-robust way of doing threading. After all, how many sets of unrelated messages have had subjects like these over time? Is this a bug? Newbie question ADO.NET so that using just the subject is not going to produce accurate threading, while using In-Reply-To: (and/or References:) would not incorrectly intermingle those unrelated threads. Good luck... At 12:02 PM 1/12/2006, Waylan Limberg wrote >The reply subject to this message should be: > Re: [IronPython] Answers not added to the thread >but not >[IronPython] Re: Answers not added to the thread > >In other words, the "Re:" can only be added to the very begining of >the subject including the [list label] added by the list system. As >an alternative, you could just never include "Re:" in your subject. >Then the subject would always be the same - and that should work as >well. > >On 1/12/06, Stute, Detlef ALRT/EEG4 <[EMAIL PROTECTED]> wrote: >> Hi all, >> A short non IronPython question. >> What must be the subject line of an answer to be integrated into the message >> thread? >> My answers to any questions are not added to the thread, the occur as a new >> independent message. >> >> Mit freundlichen Grüßen/ kind regards/ Cordiali Saluti >> SEATEC GmbH >> Detlef Stute >> www.seatec-gmbh.com >-- > >Waylan Limberg >[EMAIL PROTECTED] J. Merrill / Analytical Software Corp ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Answers not added to the thread
The reply subject to this message should be: Re: [IronPython] Answers not added to the thread but not [IronPython] Re: Answers not added to the thread In other words, the "Re:" can only be added to the very begining of the subject including the [list label] added by the list system. As an alternative, you could just never include "Re:" in your subject. Then the subject would always be the same - and that should work as well. On 1/12/06, Stute, Detlef ALRT/EEG4 <[EMAIL PROTECTED]> wrote: > Hi all, > A short non IronPython question. > What must be the subject line of an answer to be integrated into the message > thread? > My answers to any questions are not added to the thread, the occur as a new > independent message. > > Mit freundlichen Grüßen/ kind regards/ Cordiali Saluti > SEATEC GmbH > Detlef Stute > www.seatec-gmbh.com > ___ > users mailing list > users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Waylan Limberg [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Answers not added to the thread
Hi all, A short non IronPython question. What must be the subject line of an answer to be integrated into the message thread? My answers to any questions are not added to the thread, the occur as a new independent message. Mit freundlichen Grüßen/ kind regards/ Cordiali Saluti SEATEC GmbH Detlef Stute www.seatec-gmbh.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Run a script without a console to pop up?
Hi stax, I integrated IronPython in my C# application. There the user may select a python file and start the script. The program will transfer the script lines like a console line by line to the python engine and the output is redirected to a list box ( the list box is a control interface). I do this in this way to get access to the current line number and I may pause or cancel the script at each line. When the program is up ( which will take your 3 seconds) and the user use the start button, the script starts immediately. Mit freundlichen Grüßen/ kind regards/ Cordiali Saluti SEATEC GmbH Detlef Stute www.seatec-gmbh.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
