Re: [IronPython] Security of DLR host

[Jimmy Schementi]

Curt, that's how the previous beta worked, so things haven't really changed. I 
think what Paval means is that there's a child PAL, in SL's case a BrowserPAL, 
which inherits from PlatformAdaptationLayer. In Silverlight we also had a 
BrowserScriptHost, which inherited from ScriptHost, and 
ScriptRuntimeSetup.HostType is set to that BrowserScriptHost instance.

Anyway, things are the same ... =P

~js

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher
Sent: Monday, August 04, 2008 9:01 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Security of DLR host

On Sun, Aug 3, 2008 at 8:39 AM, Pavel Šavara <[EMAIL PROTECTED]> wrote:
> With Silverlight you can use the Platform Adaptation Layer to control
> imports though. The DLR hosting specs has some details on this (Silverlight
> uses the PAL so that imports are resolved by searching inside the xap file -
> a modified PAL could ban imports altogether).
I looked at your articles about that on voidspace. Unfortunately in
last sdl-sdk things look different.
There is no direct way how to change PAL anymore.

In what will be released shortly as the next beta of IronPython, you replace 
the PAL by deriving a custom class from ScriptHost and overriding the 
PlatformAdaptationLayer property.  When you create a ScriptRuntime, you specify 
the host by setting ScriptRuntimeSetup.HostType to equal the type of your 
derived class.  That's exactly what the Microsoft.Scripting.Silverlight project 
does.

It's quite possible that this was already how it worked in the previous beta, 
but I don't have those sources handy.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Security of DLR host

[Curt Hagenlocher]

On Sun, Aug 3, 2008 at 8:39 AM, Pavel Šavara <[EMAIL PROTECTED]> wrote:

> > With Silverlight you can use the Platform Adaptation Layer to control
> > imports though. The DLR hosting specs has some details on this
> (Silverlight
> > uses the PAL so that imports are resolved by searching inside the xap
> file -
> > a modified PAL could ban imports altogether).
>
> I looked at your articles about that on voidspace. Unfortunately in
> last sdl-sdk things look different.
> There is no direct way how to change PAL anymore.


In what will be released shortly as the next beta of IronPython, you replace
the PAL by deriving a custom class from ScriptHost and overriding the
PlatformAdaptationLayer property.  When you create a ScriptRuntime, you
specify the host by setting ScriptRuntimeSetup.HostType to equal the type of
your derived class.  That's exactly what the Microsoft.Scripting.Silverlight
project does.

It's quite possible that this was already how it worked in the previous
beta, but I don't have those sources handy.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Roadmap and updates

[Douglas Blank]

- "Curt Hagenlocher" <[EMAIL PROTECTED]> wrote:

> The initialization code is so generic and predictable
> that you don't have to do much more than lop the semicolons off the
> ends of the lines.

Of course, you don't even have to do that as Python allows semicolons on the 
ends :)

Another way to answer your question, Max, is that Mono supports WinForms too.

We are working on a similar project, but I think IronPython + WinForms is where 
we will be for a few years. But, we aren't writing our base libraries in Python 
anymore, but C#. That way it still looks the same in Python, but the the other 
DLR languages can use them too. And you can use other alternate operating 
systems.

I predict that there will be a huge number of DLR languages in the next few 
years, and your uses can switch languages while keeping the base libraries, if 
you write in C#.

-Doug

> Disclaimer: I am a Microsoft employee, but I have absolutely no inside
> knowledge on any of the topics I've written on here other than those
> related directly to IronPython.
> 
> On Mon, Aug 4, 2008 at 7:06 PM, Max R. Yaffe < [EMAIL PROTECTED] >
> wrote:
> 
> 
> Note: I originally wrote this to Harry Pierson directly who asked that
> I
> post it publically. I hope it doesn't come off as too inflamatory.
> 
> Harry - Thanks for the roadmap and the latest update. It clarifies a
> particular issue that I'm having with deciding whether to adopt Iron
> Python
> and .Net for that matter. My particular application is a scientific
> instrument control and data analysis package. It runs on Windows now
> using
> various older MS technologies (dating back to Windows 2.3!). It will
> not
> need to run from a web browser, mainly because of the requirements for
> instrument control. The application is highly scripted using a dynamic
> language of my own devising derived from Smalltalk and remarkably
> similar to
> Python.
> 
> I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to
> updating my
> technology. However, I wanted to see what Microsoft had to offer.
> WinForms
> + Python seems to be the best fit for my technology because of the
> need to
> manipulate data tables and my desire to avoid the web. Silverlight
> just
> doesn't offer me any advantage and seems to be directed at pretty
> pictures
> and sounds. It also doesn't seem to handle the kinds of user/data
> interaction I need. XAML also doesn't seem to offer any advantage for
> my
> code, or if it does, it certainly isn't clear what it might be other
> than a
> YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap,
> however, seems to deprecate WinForms. I'm worried that IronPython and
> Microsoft are going to cut WinForms adrift just when I'm about to make
> a
> major investment in it. This might be the best approach for Microsoft
> because it seems the "community" is mainly interested in pictures,
> sounds,
> and the web. But I need something more classical.
> 
> I'd appreciate your comments and direction.
> 
> Max Yaffe
> Gamry Instruments, Inc.
> 
> ___
> 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
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Roadmap and updates

[Howard Hansen]

Max R. Yaffe wrote:

Note:  I originally wrote this to Harry Pierson directly who asked that I
post it publically. I hope it doesn't come off as too inflamatory.

Harry - Thanks for the roadmap and the latest update.  It clarifies a
particular issue that I'm having with deciding whether to adopt Iron Python
and .Net for that matter.  My particular application is a scientific
instrument control and data analysis package.  It runs on Windows now using
various older MS technologies (dating back to Windows 2.3!).  It will not
need to run from a web browser, mainly because of the requirements for
instrument control.  The application is highly scripted using a dynamic
language of my own devising derived from Smalltalk and remarkably similar to
Python.  


I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my
technology.  However, I wanted to see what Microsoft had to offer.  WinForms
+ Python seems to be the best fit for my technology because of the need to
manipulate data tables and my desire to avoid the web.  Silverlight just
doesn't offer me any advantage and seems to be directed at pretty pictures
and sounds.  It also doesn't seem to handle the kinds of user/data
interaction I need.  XAML also doesn't seem to offer any advantage for my
code, or if it does, it certainly isn't clear what it might be other than a
YAOUHD (yet another obese, unreadable HTML derivative).  Your roadmap,
however, seems to deprecate WinForms.  I'm worried that IronPython and
Microsoft are going to cut WinForms adrift just when I'm about to make a
major investment in it.  This might be the best approach for Microsoft
because it seems the "community" is mainly interested in pictures, sounds,
and the web. But I need something more classical.

I'd appreciate your comments and direction.

Max Yaffe
Gamry Instruments, Inc.
  
I am wondering why you haven't looked at WPF, Windows Presentation 
Foundation, and IronPython.  You can develop your interface in WPF 
without using XAML and IronPython  will eventually be compatible with 
Cpython 2.5.


Howard


___
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] Roadmap and updates

[Curt Hagenlocher]

XAML is really just an XML-based object persistence format.  It's not
directly tied to the display technology that it's mostly used for, which is
"WPF" or "Windows Presentation Foundation".  It's really WPF that should be
compared to Windows Forms -- you can use WPF without writing a single line
of XAML (or having the designer write it on your behalf).

If you're used to using the Win32 API or a thin wrapper over it like MFC,
then Windows Forms is a lot closer to what you know already.  That's because
Windows Forms itself is a (somewhat thicker) wrapper over the same Win32
API.  By contrast, WPF is a UI framework that's been redesigned from the
ground up.  Individual elements on a WPF window aren't represented by an
window handle; there's only one HWND at the top which effectively provides a
blank canvas for WPF to draw on.

There are probably hundreds of thousands of applications built on USER32.DLL
and/or Windows Forms.  The odds that Microsoft abandons all of these
applications are pretty low -- it is the applications, after all, that make
the platform what it is.  And although WPF is in many respects a much
better-to-develop-for architecture than Windows Forms, it also isn't perhaps
quite as mature -- and there are a few things that are still more easily
done using Windows Forms than WPF, particularly in a line-of-business-style
application.

With respect to IronPython, we don't have much to say about the platform as
a whole.  You can execute just about any .NET code from within IronPython --
whether that's Windows Forms, WPF, WCF, WF, Managed DirectX or the CLR-based
technologies that are just being invented now.  So as long as Windows Forms
exists, you'll be able to use it from IronPython.

If your specific concern is related solely to Harry's comment about the
Visual Studio integration work being more difficult for the Windows Forms
designer than for the WPF designer, then I think you've read a little too
much into what he said.  Our intent is to support the Windows Forms
designer.  It may be that -- due to its quirks -- we're not able to do so in
the early previews of the work, but I don't think that any of us would
consider the integration done if it was WPF-only.

Until then, you can always do what I understand Resolver Systems did: save
your forms as C# and manually copy the generated code into your Python
classes.  The initialization code is so generic and predictable that you
don't have to do much more than lop the semicolons off the ends of the
lines.


Disclaimer: I am a Microsoft employee, but I have absolutely no inside
knowledge on any of the topics I've written on here other than those related
directly to IronPython.

On Mon, Aug 4, 2008 at 7:06 PM, Max R. Yaffe <[EMAIL PROTECTED]> wrote:

> Note:  I originally wrote this to Harry Pierson directly who asked that I
> post it publically. I hope it doesn't come off as too inflamatory.
>
> Harry - Thanks for the roadmap and the latest update.  It clarifies a
> particular issue that I'm having with deciding whether to adopt Iron Python
> and .Net for that matter.  My particular application is a scientific
> instrument control and data analysis package.  It runs on Windows now using
> various older MS technologies (dating back to Windows 2.3!).  It will not
> need to run from a web browser, mainly because of the requirements for
> instrument control.  The application is highly scripted using a dynamic
> language of my own devising derived from Smalltalk and remarkably similar
> to
> Python.
>
> I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my
> technology.  However, I wanted to see what Microsoft had to offer.
>  WinForms
> + Python seems to be the best fit for my technology because of the need to
> manipulate data tables and my desire to avoid the web.  Silverlight just
> doesn't offer me any advantage and seems to be directed at pretty pictures
> and sounds.  It also doesn't seem to handle the kinds of user/data
> interaction I need.  XAML also doesn't seem to offer any advantage for my
> code, or if it does, it certainly isn't clear what it might be other than a
> YAOUHD (yet another obese, unreadable HTML derivative).  Your roadmap,
> however, seems to deprecate WinForms.  I'm worried that IronPython and
> Microsoft are going to cut WinForms adrift just when I'm about to make a
> major investment in it.  This might be the best approach for Microsoft
> because it seems the "community" is mainly interested in pictures, sounds,
> and the web. But I need something more classical.
>
> I'd appreciate your comments and direction.
>
> Max Yaffe
> Gamry Instruments, Inc.
>
> ___
> 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] Roadmap and updates

[Keith J. Farmer]

The question of Python + ? aside, I think your assessment of Silverlight is 
missing a couple points.
 
Yes, Silverlight has been demoed with lots of pretty pictures, but the truth is 
that Silverlight is, fundamentally, a mini-CLR that runs in the browser (at 
least, Silverlight 2 certainly is -- I tend to ignore Silverlight 1).  You can 
use it to write full-blown applications that run client-side, which can 
retrieve data from a back end.  Don't let the sexy graphical displays obscure 
that simple, powerful fact.  Consider a web page that has javascript making 
calls into a GUI-less Silverlight app -- Silverlight then becomes something of 
a high-speed resource (that is much more useful and powerful than 
random-ajax-toolkit).
 
Yes, Silverlight is currently lacking in some basic controls, but those are 
currently being worked on both by Microsoft as well as third parties.  See, for 
example:
 
http://wpfwonderland.wordpress.com/2008/06/06/silverlight-2-beta-2-now-with-more-controls/
 
http://www.c-sharpcorner.com/UploadFile/nipuntomar/DataBindingSilverlightWCFService07152008011652AM/DataBindingSilverlightWCFService.aspx
 
http://www.infragistics.com/hot/silverlight.aspx#InfragisticsandSilverlight
 
I feel your pain on XAML -- I'm not the happiest with it, but you don't have to 
work in XAML if you don't want to.  I'm pretty certain you could (as Petzold's 
book demonstrates for WPF) work XAML-free.  You could also use the Silverlight 
tooling available in, for example, Expression.
 
 



From: [EMAIL PROTECTED] on behalf of Max R. Yaffe
Sent: Mon 8/4/2008 7:06 PM
To: users@lists.ironpython.com
Subject: [IronPython] Roadmap and updates



Note:  I originally wrote this to Harry Pierson directly who asked that I
post it publically. I hope it doesn't come off as too inflamatory.

Harry - Thanks for the roadmap and the latest update.  It clarifies a
particular issue that I'm having with deciding whether to adopt Iron Python
and .Net for that matter.  My particular application is a scientific
instrument control and data analysis package.  It runs on Windows now using
various older MS technologies (dating back to Windows 2.3!).  It will not
need to run from a web browser, mainly because of the requirements for
instrument control.  The application is highly scripted using a dynamic
language of my own devising derived from Smalltalk and remarkably similar to
Python. 

I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my
technology.  However, I wanted to see what Microsoft had to offer.  WinForms
+ Python seems to be the best fit for my technology because of the need to
manipulate data tables and my desire to avoid the web.  Silverlight just
doesn't offer me any advantage and seems to be directed at pretty pictures
and sounds.  It also doesn't seem to handle the kinds of user/data
interaction I need.  XAML also doesn't seem to offer any advantage for my
code, or if it does, it certainly isn't clear what it might be other than a
YAOUHD (yet another obese, unreadable HTML derivative).  Your roadmap,
however, seems to deprecate WinForms.  I'm worried that IronPython and
Microsoft are going to cut WinForms adrift just when I'm about to make a
major investment in it.  This might be the best approach for Microsoft
because it seems the "community" is mainly interested in pictures, sounds,
and the web. But I need something more classical.

I'd appreciate your comments and direction.

Max Yaffe
Gamry Instruments, Inc.

___
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

[IronPython] Roadmap and updates

[Max R. Yaffe]

Note:  I originally wrote this to Harry Pierson directly who asked that I
post it publically. I hope it doesn't come off as too inflamatory.

Harry - Thanks for the roadmap and the latest update.  It clarifies a
particular issue that I'm having with deciding whether to adopt Iron Python
and .Net for that matter.  My particular application is a scientific
instrument control and data analysis package.  It runs on Windows now using
various older MS technologies (dating back to Windows 2.3!).  It will not
need to run from a web browser, mainly because of the requirements for
instrument control.  The application is highly scripted using a dynamic
language of my own devising derived from Smalltalk and remarkably similar to
Python.  

I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my
technology.  However, I wanted to see what Microsoft had to offer.  WinForms
+ Python seems to be the best fit for my technology because of the need to
manipulate data tables and my desire to avoid the web.  Silverlight just
doesn't offer me any advantage and seems to be directed at pretty pictures
and sounds.  It also doesn't seem to handle the kinds of user/data
interaction I need.  XAML also doesn't seem to offer any advantage for my
code, or if it does, it certainly isn't clear what it might be other than a
YAOUHD (yet another obese, unreadable HTML derivative).  Your roadmap,
however, seems to deprecate WinForms.  I'm worried that IronPython and
Microsoft are going to cut WinForms adrift just when I'm about to make a
major investment in it.  This might be the best approach for Microsoft
because it seems the "community" is mainly interested in pictures, sounds,
and the web. But I need something more classical.

I'd appreciate your comments and direction.

Max Yaffe
Gamry Instruments, Inc.

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] loading an image in silverlight, in xaml, from the .xap

[Jimmy Schementi]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:users-
> [EMAIL PROTECTED] On Behalf Of Dan Eloff
> Sent: Sunday, August 03, 2008 2:13 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] loading an image in silverlight, in xaml,
> from the .xap
>
> It loads the image in IE7 just fine, which is better than I ever got
> it to do. It must be the use of LoadComponent?

Yep, LoadComponent actually has knowledge of the XAP file and looks in there to 
resolve URLs first. XamlReader.Load doesn't know about the XAP, so it never 
looks in there.

> Does that mean that it never works when using XamlReader.Load ?
> Because I could never get that to work, and that's a major problem.
> Everything in my interface except the root element is either created
> in code or with XamlReader.Load. From what I gather, that means I
> cannot put images, fonts, etc in my xap file.

It does seem like a stupid limitation, so let me poke around and see if there's 
a solution.

> Thanks for taking the time to look into this.
>
> -Dan

FYI, I make a C# app that works fine in FF3, so it may be my fault. Again, I'll 
put this on my todo list. Even better, if you make sure to log a bug on 
codeplex.com/sdlsdk, I'll be sure to get to it.

~js

> On Thu, Jul 31, 2008 at 3:39 AM, Jimmy Schementi
> <[EMAIL PROTECTED]> wrote:
> > Dan,
> >
> > http://silverlight.net/forums/p/17003/76203.aspx#76203
> >
> > You're definitely not doing anything wrong. Here's a repro of your
> issue:
> >
> > http://jimmy.schementi.com/silverlight/xaml-image-bug/
> >
> > The crazy thing is this only repros in Firefox3, and is perfectly
> fine in IE8! Even crazier, I just made a C# project with the
> Silverlight VS tools, and it worked both in FF3 and IE8, ugh. There's
> nothing fundamentally different about the 2, so I'm a little confused.
> I'm trying to make a minimal C# repro and figure out who to blame, me
> or the SL team. =P
> >
> > ~js
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:users-
> >> [EMAIL PROTECTED] On Behalf Of Dan Eloff
> >> Sent: Friday, July 11, 2008 11:53 PM
> >> To: Discussion of IronPython
> >> Subject: [IronPython] loading an image in silverlight, in xaml, from
> >> the .xap
> >>
> >> I cannot load an image from in the xap file via uri.
> >>
> >> This one has been bugging me for a long time now. I think it must
> have
> >> something to do with a difference between a Chiron xap and a VS
> built
> >> xap.
> >>
> >> Could someone on the silverlight team (Jimmy!) please take a look at
> >> the demo project and tell me what I'm doing wrong?
> >>
> >> http://silverlight.net/forums/t/17003.aspx
> >>
> >> Thanks,
> >> -Dan
> >> ___
> >> 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
> >
> ___
> 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] Performance issue when calling a function with **kw

[Curt Hagenlocher]

There is a bit of extra code that's run when there are keyword arguments,
but I don't think it should make this kind of difference.  Please file a bug
report in CodePlex at http://www.codeplex.com/IronPython/WorkItem/List.aspx.

On Sun, Aug 3, 2008 at 3:31 AM, Asaf Kleinbort <[EMAIL PROTECTED]>wrote:

>  Hi all,
>
> I am new to this list, so I'll first introduce myself.
>
> I am working at *IT Structures* (www.itstructures.com)  in Israel. Our
> service Is written in C#, but most of the backend implementation is written
> in IronPython.
>
> While doing performance analysis of our application, I came across the
> following interesting bug (?):
>
>
>
> Calling a function with **kw takes about 10 times more time than calling a
> function with a simple dictionary.  The difference exists also in cpython
> but there the differences is hardly noticed.
>
>
>
> Here is a code snippet to clarify:
>
> …
>
> *def func_kw(kw):*
>
> *return sum(kw.itervalues())*
>
> * *
>
> *def func(**kw):*
>
> *return sum(kw.itervalues())*
>
> **
>
> *def measure(n):*
>
> *dct = {'1':2,'2':2,'3':2,'4':2,'5':2,'6':2}*
>
> *start = time.clock()*
>
> *for i in xrange(n):*
>
> *func_kw(dct)*
>
> *duration_without = time.clock()-start*
>
> *start = time.clock()*
>
> *for i in xrange(n):*
>
> *func(**dct)*
>
> *duration_with = time.clock()-start*
>
> *return (duration_without,duration_with)*
>
> *…*
>
>
>
> Running measure(10**6) 10 times in a loop and calculating the mean we get
> the following results (in seconds):
>
>
>
> *In IronPython:*
>
> *WITH **KW: mean=5.56493157650, stddev=0.0649572929575.*
>
> *WITHOUT: mean=0.86113346808, stddev=0.0142532589459.*
>
>
>
> *In Python:*
>
> * WITH **KW: mean=1.70669562131, stddev=0.0230977726849.*
>
> * WITHOUT: mean=0.782945815118, stddev=0.00572116553432. *
>
> * *
>
> *(*IronPython version: IronPython 1.1.1 (1.1.1) on .NET 2.0.50727.1433
>
> Python version: Python 2.5.1)
>
>
>
> Does anyone know if this is going to improve in version 2.0?
>
> ___
> 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