[IronPython] Users Digest, Vol 40, Issue 28

Mahesh Prakriya Mahesh.Prakriya at microsoft.com
Mon Nov 26 02:41:36 CET 2007 

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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of users-request at lists.ironpython.com
Sent: Saturday, November 24, 2007 1:54 PM
To: users at lists.ironpython.com
Subject: Users Digest, Vol 40, Issue 28

Send Users mailing list submissions to
        users at lists.ironpython.com

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
        users-request at lists.ironpython.com

You can reach the person managing the list at
        users-owner at lists.ironpython.com

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" <cummings.michael at gmail.com>
Subject: Re: [IronPython] DLR Hosting Spec
To: "Discussion of IronPython" <users at lists.ironpython.com>
Message-ID:
        <d4e0938d0711231926j22e73190u5cd9b18b5217d4c4 at mail.gmail.com>
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 <dinov at exchange.microsoft.com> 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
> Users at lists.ironpython.com
> 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 <dinov at exchange.microsoft.com>
Subject: Re: [IronPython] TypeError: expected Tuple, got tuple
To: Discussion of IronPython <users at lists.ironpython.com>
Message-ID:
        <7AD436E4270DD54A94238001769C2227E45261D6CE at DF-GRTDANE-MSG.exchange.corp.microsoft.com>

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: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy [jdhardy at gmail.com]
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 <jdhardy at gmail.com> 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
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


------------------------------

Message: 3
Date: Sat, 24 Nov 2007 12:54:30 -0800
From: Dino Viehland <dinov at exchange.microsoft.com>
Subject: Re: [IronPython] Problems with 8-bit strings
To: Discussion of IronPython <users at lists.ironpython.com>
Message-ID:
        <7AD436E4270DD54A94238001769C2227E45261D6CF at DF-GRTDANE-MSG.exchange.corp.microsoft.com>

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: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Patrick Dubroy [pdubroy at gmail.com]
Sent: Wednesday, November 21, 2007 12:18 PM
To: users at lists.ironpython.com
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
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


------------------------------

_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


End of Users Digest, Vol 40, Issue 28
*************************************

More information about the Ironpython-users mailing list