The only way to limit the assemblies loaded is by hosting CLR2.0 (or later) directly - e.g. SQL does this today.
A good book to read to get at the details of this is "Customizing the Microsoft .NET Framework Common Language Runtime" by Steven Pratschner. http://www.amazon.com/Customizing-Microsoft-Framework-Language-Runtime/dp/0735619883/ref=sr_1_1?ie=UTF8&s=books&qid=1196041016&sr=1-1 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, November 24, 2007 1:54 PM To: [email protected] Subject: Users Digest, Vol 40, Issue 28 Send Users mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.ironpython.com/listinfo.cgi/users-ironpython.com or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. Re: DLR Hosting Spec (Michael Cummings) 2. Re: TypeError: expected Tuple, got tuple (Dino Viehland) 3. Re: Problems with 8-bit strings (Dino Viehland) ---------------------------------------------------------------------- Message: 1 Date: Fri, 23 Nov 2007 22:26:24 -0500 From: "Michael Cummings" <[EMAIL PROTECTED]> Subject: Re: [IronPython] DLR Hosting Spec To: "Discussion of IronPython" <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" I have a question more than feedback right now. How can I limit which assemblies can be loaded into the hosted environment? I know I can set the script path, but what if I don't want any scripts to load the System.Remoting assembly? Michael Cummings On Nov 19, 2007 7:15 PM, Dino Viehland <[EMAIL PROTECTED]> wrote: > As I mentioned a couple of weeks ago we've been wrapping up work on > designing the hosting APIs and just this past week we've started > implementing the new hosting APIs. We'll be continuing this work off-and-on > over the next few months so now is a great time to start collecting feedback > on the design of the new APIs. > > One thing worth mentioning is the spec is incomplete, and the text that is > there is not final. The conceptual introduction and the direction we're > going is pretty solid. However, as we review the API reference sections in > detail, as implementation feeds back on the design, and as we gather > external feedback, we're updating the spec and code. The reason we're > releasing this so early is to gather feedback on the design and > functionality of the APIs. Any feedback you have would be appreciated. > > The new APIs will also start showing up incrementally in the next few > releases of IronPython and the regular source drops of IronRuby. So soon > you'll also be test out and experiment with the bits directly. This should > give us plenty of time to take any feedback into consideration and update > both the spec and code for the final DLR APIs. > > We look forward to any feedback you might have! > > You can grab the spec here: > http://www.iunknown.com/files/dlr-spec-hosting.pdf > > If anyone would like a version in Word format we can send that so you can > mark it up w/ track changes enabled :). > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ironpython.com/pipermail/users-ironpython.com/attachments/20071123/a861851e/attachment-0001.html ------------------------------ Message: 2 Date: Sat, 24 Nov 2007 12:52:35 -0800 From: Dino Viehland <[EMAIL PROTECTED]> Subject: Re: [IronPython] TypeError: expected Tuple, got tuple To: Discussion of IronPython <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" They're actually two rather distinct data types and there's no plans to merge them right now. Tuple is used for creating strongly-typed fixed-sized collections and is used internally by the DLR. We use it for creating our FunctionEnvironment's (for closures), for creating storage which back modules in collectible form, and in a couple of other places. Basically it's a faster alternative to an array. And of course PythonTuple is just Python's standard tuple type. ________________________________________ From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Jeff Hardy [EMAIL PROTECTED] Sent: Wednesday, November 21, 2007 7:12 PM To: Discussion of IronPython Subject: Re: [IronPython] TypeError: expected Tuple, got tuple Hi, Well, I found (or rather rediscovered :)) PythonTuple, but I'm still curious as to whether they will be unified in the future. -Jeff On Nov 21, 2007 7:00 PM, Jeff Hardy <[EMAIL PROTECTED]> wrote: > Hi, > If I have the following C# library: > nunified in the futureamespace TestLib > { > public class Foo > { > public string Bar(Microsoft.Scripting.Tuple t) > { > return t.ToString(); > } > } > } > > Calling Bar from IronPython results in "TypeError: expected Tuple, got > tuple". Why are the Python tuple and Microsoft.Scripting.Tuple > different? And what is the proper type to use for Python tuples? > > -Jeff > > Python code: > IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReference("TestLib") > >>> import TestLib > >>> TestLib.Foo().Bar((1, 2, 3)) > Traceback (most recent call last): > File , line 0, in ##235 > TypeError: expected Tuple, got tuple > > > With -X:ExceptionDetail: > IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReference("TestLib") > >>> import TestLib > >>> TestLib.Foo().Bar((1, 2, 3)) > expected Tuple, got tuple > at IronPython.Runtime.Converter.Convert(Object value, Type to) > at IronPython.Runtime.Converter.ConvertToReferenceType(Object fromObject, > Run > timeTypeHandle typeHandle) > at Microsoft.Scripting.Utils.InvokeHelper`3.Invoke(Object arg0, Object arg1) > at Microsoft.Scripting.Utils.ReflectedCaller.Invoke(Object[] args) > at Microsoft.Scripting.Ast.MethodCallExpression.InvokeMethod(Object > instance, > Object[] parameters) > at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext > contex > t) > at Microsoft.Scripting.Ast.UnaryExpression.DoEvaluate(CodeContext context) > at Microsoft.Scripting.Ast.ConditionalExpression.DoEvaluate(CodeContext > conte > xt) > at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext > contex > t) > at Microsoft.Scripting.Ast.ReturnStatement.DoExecute(CodeContext context) > at Microsoft.Scripting.Ast.Statement.Execute(CodeContext context) > at > Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeConte > xt callerContext, DynamicAction action, Object[] args, Object site, T& > target, R > uleSet`1& rules) > at > Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeConte > xt context, T0 arg0, T1 arg1) > at > Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7 > .Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1) > at Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 > a > rg0, T1 arg1) > at ##235(Object[] , CodeContext ) > at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean > tryEva > luate) > at Microsoft.Scripting.ScriptCode.Run(ScriptModule module) > at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module) > at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, > IScri > ptModule module) > at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction() > at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction() > at IronPython.Hosting.PythonCommandLine.TryInteractiveAction() > at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop() > TypeError: expected Tuple, got tuple > _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ------------------------------ Message: 3 Date: Sat, 24 Nov 2007 12:54:30 -0800 From: Dino Viehland <[EMAIL PROTECTED]> Subject: Re: [IronPython] Problems with 8-bit strings To: Discussion of IronPython <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" I think the construction w/ characters > 0x80 is a bug. But the returning of unicode vs. 8-bit strings is just a display issue. IronPython only has unicode strings and is one of the big differences between CPython and IronPython. If you haven't already I'll open a bug when I'm back after Thanksgiving. ________________________________________ From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Patrick Dubroy [EMAIL PROTECTED] Sent: Wednesday, November 21, 2007 12:18 PM To: [email protected] Subject: [IronPython] Problems with 8-bit strings Hi, I've noticed that in the latest version of IronPython (2.0A6), I noticed some weird behaviour with 8-bit strings: IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.1378 Copyright (c) Microsoft Corporation. All rights reserved. >>> str("\x7e") '~' >>> str("\x7f") u'\x7f' >>> str("\x80") u'\x80' >>> str("\x81") Traceback (most recent call last): File , line 0, in ##23 File mscorlib, line unknown, in GetString File mscorlib, line unknown, in GetChars File mscorlib, line unknown, in Fallback File mscorlib, line unknown, in Throw UnicodeDecodeError: Unable to translate bytes [81] at index 0 from specified code page to Unicode. The first problem is that if the string contains characters 127 (0x7F) or 128 (0x80), str() will return a Unicode string rather than an 8-bit string. CPython, on the other hand, returns a standard 8-bit string for both of those cases. Then, if the string contains any bytes greater than 128, it throws an exception. CPython, on the other hand, is happy to have bytes up to 0xFF in an 8-bit string. Is this a known issue? Should I open a bug? Pat _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ------------------------------ _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com End of Users Digest, Vol 40, Issue 28 ************************************* _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
