Re: [Ironpython-users] SerializationException from IronPython.Runtime.Types.PythonType
Dino, Thanks for the response. I understand what you are saying. I have also realised that at the moment because I catch the exception and instantiate a new Exception using the formatted information string (so that calling code need know nothing about ScriptEngine formatting services). I can move that try catch into the actual execution method in the remote domain and then rethrow the formatted exception which is essentially string based. That works for now, but I'm not sure it's a very good approach. Changing unmarshallable objects into strings would essentially be I guess, a similar compromise. Thanks for your time and input. Alan On 12 January 2012 18:35, Dino Viehland wrote: > Are you creating the tracing delegate in the remote app domain? You > should be able to create a class which derives from MarshalByRefObject and > then create an instance of that object in the remote domain. You can then > call a method on that MBRO which does the ScriptEngine.SetTrace() call (you > can safely pass the script engine instance across when you create the > MBRO). If you want to marshal the results back to your main app domain you > can also create an MBRO in your local domain that you pass through when you > construct the remote MBRO and then you can call some method which passes > strings instead of unmarshallable objects. > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Alan > Macdonald > *Sent:* Thursday, January 12, 2012 1:34 AM > *To:* [email protected] > *Subject:* [Ironpython-users] SerializationException from > IronPython.Runtime.Types.PythonType > > ** ** > > Hello, > > I am experiencing an exception when tracing and would appreciate some > guidance. > > I am hosting IronPython 2.7.1 in a .Net 4 C# host. The host creates a new > app domain to run IronPython scripts in. At the moment due to some > security exceptions I've given the new app domain unrestricted permissions > (I will try and reduce this later). When the python script is executed it > runs via an asynchronous delegate and when complete catches any exceptions > during the running of the script. This was all working fine and if the > python script has an error in it then the exception is caught in the async > callback method. > > However I have since added tracing via a call to > ScriptEngine.SetTrace(myDelegate) so I can allow stepping through the > script one line at a time (based on http://devhawk.net/tag/debugger/). > When the script has no errors it executes fine with tracing enabled or > disabled. However if the script has an error in it and tracing is enabled > then trying to catch and format the exception in the async delegate > callback causes a SerializationException on > IronPython.Runtime.Types.PythonType. When tracing is not enabled the > exception is caught and formatted successfully. > > I tried to disable tracing in the catch block before formatting the > exception but this makes no difference. I understand that this is related > to sending the exception information from one app domain to another but I'm > not sure what I can do to get round it and what extra information it is > trying to send when tracing is enabled. My tracing delegate does nothing > with exceptions. > > Code that creates the new app domain and starts the async call to execute > the method for the object in the new app domain: > public void Run() > { > if (newDomainInstance == null) > NewAppDomain(); > > Execute method = newDomainInstance.ExecuteCode; > method.BeginInvoke(RunComplete, method); > > } > > > The async callback is the following code: > > private void RunComplete(IAsyncResult cookie) > { > Complete = true; > > Execute method = (Execute)cookie.AsyncState; > > > try > { > method.EndInvoke(cookie); > OnExecutionSuccess(); > } > catch (AppDomainUnloadedException adue) > { > //Do nothing because we've deliberately pulled the app > domain out from under it. > } > catch (Exception ex) > { > engine.Value.SetTrace(null); > String extractedMessage = > engine.Value.GetService().FormatException(ex); > OnExecutionError(new Exception(extractedMessage)); > } > > } > > The exception occurs on String extractedMessage = > engine.Value.GetService().FormatException(ex); > > Exception stacktrace: > System.Runtime.Serialization.SerializationException was unhandled > Message=Type 'IronPython.Runtime.Types.PythonType' in Assembly > 'IronPython, Version=2.7.0.40, Culture=neutral, > PublicKeyToken=7f709c5b713576e1' is not marked as serializable. > Source=mscorlib > StackTrace: > Server stack trace: >at
[Ironpython-users] IronPython, Daily Digest 1/12/2012
Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] (please cancel) System.Collections.Generic.HashSet Missing 2. [New issue] Add StackOverflow to website support page -- ISSUES 1. [New comment] (please cancel) System.Collections.Generic.HashSet Missing http://ironpython.codeplex.com/workitem/32066 User jdhardy has commented on the issue: "StackOverflow is a good option as well."- 2. [New issue] Add StackOverflow to website support page http://ironpython.codeplex.com/workitem/32070 User jdhardy has proposed the issue: "Add a link to StackOverflow on the website support page." -- -- You are receiving this email because you subscribed to notifications on CodePlex. To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
[Ironpython-users] logging.handlers.NTEventLogHandler not in IP?
Hi,
While trying the logging module, I've found this:
IronPython 2.7.1 (2.7.0.40) on .NET 4.0.30319.239
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import logging
>>> import logging.handlers
>>>
logging.getLogger().addHandler(logging.handlers.NTEventLogHandler("MyApp"))
The Python Win32 extensions for NT (service, event logging) appear not
to be available.
>>>
This handler uses Hammond's win32 dlls. Are there any .NET equivalent class?
An IP implementation might take less than a dozen of lines, I'd guess. What's
the best
practice when overriding Python std lib?
Regards,
-H.
___
Ironpython-users mailing list
[email protected]
http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] logging.handlers.NTEventLogHandler not in IP?
There's the EventLog class [http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog(v=vs.71).aspx] which you can get at using: from System.Diagnostics import EventLog I would think you could make your own NTEventLogHandler which wraps this, you could probably contribute it back to the std lib under an if sys.platform == 'cli': so that on IronPython you get the .NET NTEventLogHandler. > -Original Message- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Hernán Foffani > Sent: Friday, January 13, 2012 4:14 AM > To: [email protected] > Subject: [Ironpython-users] logging.handlers.NTEventLogHandler not in IP? > > Hi, > While trying the logging module, I've found this: > > IronPython 2.7.1 (2.7.0.40) on .NET 4.0.30319.239 > Type "help", "copyright", "credits" or "license" for more information. > >>> > >>> import logging > >>> import logging.handlers > >>> > logging.getLogger().addHandler(logging.handlers.NTEventLogHandler("MyApp" > )) > The Python Win32 extensions for NT (service, event logging) appear not > to be available. > >>> > > This handler uses Hammond's win32 dlls. Are there any .NET equivalent class? > An IP implementation might take less than a dozen of lines, I'd guess. What's > the best practice when overriding Python std lib? > > Regards, > -H. > > > > ___ > Ironpython-users mailing list > [email protected] > http://mail.python.org/mailman/listinfo/ironpython-users ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] logging.handlers.NTEventLogHandler not in IP?
On Fri, Jan 13, 2012 at 9:24 AM, Dino Viehland wrote: > I would think you could make your own NTEventLogHandler which wraps this, > you could probably contribute it back to the std lib under an if sys.platform > == 'cli': > so that on IronPython you get the .NET NTEventLogHandler. At the very list it could go into IronPython's stdlib. Until we can sync up with the 3.x branch I Don't know if we can push stdlib changes upstream. - Jeff ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] logging.handlers.NTEventLogHandler not in IP?
On Fri, Jan 13, 2012 at 9:54 AM, Hernán Foffani wrote: > > El 13/01/2012, a las 18:49, Jeff Hardy escribió: > >> On Fri, Jan 13, 2012 at 9:24 AM, Dino Viehland wrote: >>> I would think you could make your own NTEventLogHandler which wraps this, >>> you could probably contribute it back to the std lib under an if >>> sys.platform == 'cli': >>> so that on IronPython you get the .NET NTEventLogHandler. >> >> At the very list it could go into IronPython's stdlib. Until we can >> sync up with the 3.x branch I Don't know if we can push stdlib changes >> upstream. > > Beware that the file that contains the NTEventLogHandler has some several more > classes. Won't it add some hassle to merge future std lib changes back to IP? > We already have a bunch of changes like it. Any extra hassle it adds is minuscule compared to the giant pain in the butt it already is (hence why it's not done very often). For the 3.x branch I want to push as many changes as possible upstream to minimize that. - Jeff ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] logging.handlers.NTEventLogHandler not in IP?
El 13/01/2012, a las 19:05, Jeff Hardy escribió: > On Fri, Jan 13, 2012 at 9:54 AM, Hernán Foffani wrote: >> >> El 13/01/2012, a las 18:49, Jeff Hardy escribió: >> >>> On Fri, Jan 13, 2012 at 9:24 AM, Dino Viehland wrote: I would think you could make your own NTEventLogHandler which wraps this, you could probably contribute it back to the std lib under an if sys.platform == 'cli': so that on IronPython you get the .NET NTEventLogHandler. >>> >>> At the very list it could go into IronPython's stdlib. Until we can >>> sync up with the 3.x branch I Don't know if we can push stdlib changes >>> upstream. >> >> Beware that the file that contains the NTEventLogHandler has some several >> more >> classes. Won't it add some hassle to merge future std lib changes back to IP? >> > > We already have a bunch of changes like it. Any extra hassle it adds > is minuscule compared to the giant pain in the butt it already is > (hence why it's not done very often). > > For the 3.x branch I want to push as many changes as possible upstream > to minimize that. In that case I can provide a patch if you like. (Sorry for the personal replies, didn't pay attention to the addressee in my previous follow ups) ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] logging.handlers.NTEventLogHandler not in IP?
> On Fri, Jan 13, 2012 at 9:54 AM, Hernán Foffani > wrote: >> >> El 13/01/2012, a las 18:49, Jeff Hardy escribió: >> >>> On Fri, Jan 13, 2012 at 9:24 AM, Dino Viehland >>> wrote: I would think you could make your own NTEventLogHandler which wraps this, you could probably contribute it back to the std lib under an if sys.platform == 'cli': so that on IronPython you get the .NET NTEventLogHandler. >>> >>> At the very list it could go into IronPython's stdlib. Until we can >>> sync up with the 3.x branch I Don't know if we can push stdlib changes >>> upstream. >> >> Beware that the file that contains the NTEventLogHandler has some >> several more >> classes. Won't it add some hassle to merge future std lib changes back >> to IP? >> > > We already have a bunch of changes like it. Any extra hassle it adds > is minuscule compared to the giant pain in the butt it already is > (hence why it's not done very often). > > For the 3.x branch I want to push as many changes as possible upstream > to minimize that. > > - Jeff Speaking of IronPython's use of the standard Python Library, how does one go from IronPython source to an installation with Lib set up properly? I see that there are parts of the standard lib in github... a couple actually: some under External.LCS_RESTRICTED and another in Languages. Is the standard IP lib documented somewhere? Thanks, -Doug -- Douglas S. Blank Associate Professor, Computer Science, Bryn Mawr College http://cs.brynmawr.edu/~dblank (610)526-6501 ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] logging.handlers.NTEventLogHandler not in IP?
On Fri, Jan 13, 2012 at 11:24 AM, Dino Viehland wrote: > Douglas wrote: >> Speaking of IronPython's use of the standard Python Library, how does one go >> from IronPython source to an installation with Lib set up properly? >> >> I see that there are parts of the standard lib in github... a couple >> actually: some under External.LCS_RESTRICTED and another in Languages. Is >> the standard IP lib documented somewhere? > > I'm not sure if this has changed at all, but the std lib did indeed used to > live in the > External.LCA_RESTRICTED folder. The IronPython\27 one is the version that we > ship w/ Ipy. It's also the one which contains the tests that we run against > including > some tests which are disabled. The CPython\27 one is the baseline unmodified > CPython > stdlib and is there to make it easy to do a 3-way merge when updating the > standard > library. Yes, that's still the case. I'd like to move when bringing the 3.x library in (to Languages/IronPython/StdLib) but haven't got around to it. > > When generating the MSI the standard library is generated into the Wix using > IronPython\StdLib\StdLib.pyproj but for development purposes you can just set > IRONPYTHONPATH > To External.LCA_RESTRICTED\IronPython27\Lib or xcopy the std lib next to > CPython. The pyproj only needs to be updated when adding / removing files. You can also get it by running msbuild /t:Stage in the root of the checkout, and then looking in Stage\IronPython-2.7.2a0. That's what the zip packages are built from. - Jeff ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] logging.handlers.NTEventLogHandler not in IP?
Douglas wrote: > Speaking of IronPython's use of the standard Python Library, how does one go > from IronPython source to an installation with Lib set up properly? > > I see that there are parts of the standard lib in github... a couple > actually: some under External.LCS_RESTRICTED and another in Languages. Is > the standard IP lib documented somewhere? I'm not sure if this has changed at all, but the std lib did indeed used to live in the External.LCA_RESTRICTED folder. The IronPython\27 one is the version that we ship w/ Ipy. It's also the one which contains the tests that we run against including some tests which are disabled. The CPython\27 one is the baseline unmodified CPython stdlib and is there to make it easy to do a 3-way merge when updating the standard library. When generating the MSI the standard library is generated into the Wix using IronPython\StdLib\StdLib.pyproj but for development purposes you can just set IRONPYTHONPATH To External.LCA_RESTRICTED\IronPython27\Lib or xcopy the std lib next to CPython. The pyproj only needs to be updated when adding / removing files. ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
