Re: [IronPython] Thread local storage in IronPython 2.6

[Dino Viehland]

Michael wrote:
> Well, yes leaking memory when frames are on would definitely be a
> problem. We tried but failed to create  a minimal repro.

Do you know how big the lists of FunctionStack's were?  In theory
they should have all been empty lists by the time the threads 
exited.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Thread local storage in IronPython 2.6

[Dino Viehland]

Are you using thread abort for anything?

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, October 05, 2009 1:39 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Thread local storage in IronPython 2.6
> 
> Dino Viehland wrote:
> > Michael wrote:
> >
> >> Well, yes leaking memory when frames are on would definitely be a
> >> problem. We tried but failed to create  a minimal repro.
> >>
> >
> > Do you know how big the lists of FunctionStack's were?  In theory
> > they should have all been empty lists by the time the threads
> > exited.
> >
> It had 6 entries.
> 
> Michael
> 
> > ___
> > Users mailing list
> > Users@lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> 
> 
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
> 
> 
> ___
> 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] Thread local storage in IronPython 2.6

[Dino Viehland]

> Yes. Recalculations can be interrupted which uses Thread.Abort (the
> interrupt can happen during arbitrary user code so it is essentially
> asynchronous).

Ok, that could be the source of the leaks.  At least it's the only
thing that pops out at me while reviewing the code.  I'm not sure that
we'll actually harden the code against thread abort for 2.6.0 (this is
really tricky to do) but I can certainly make it so that it won't leak 
when it actually happens and open a bug to harden it later.


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

Re: [IronPython] Thread local storage in IronPython 2.6

[Dino Viehland]

Michael wrote:
> Cool. If it becomes a problem then we'll get in touch and see how we can
> mitigate against it.
> 
> At the top level you could put all the cleanup code inside a finally
> block so that thread aborts can't interrupt it. :-)

Somehow I guess I'd quickly get a bug report that Ctrl-C no longer works 
too :)  But there's a kernel of a good idea there - it's certainly 
easier than using Constrained Execution Regions which was my longer 
term plan (and also has trouble w/ partial trust unlike a normal
try/finally).


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

Re: [IronPython] Thread local storage in IronPython 2.6

[Dino Viehland]

Michael wrote:
> >> At the top level you could put all the cleanup code inside a finally
> >> block so that thread aborts can't interrupt it. :-)
> >>
> >
> > Somehow I guess I'd quickly get a bug report that Ctrl-C no longer works
> > too :)  But there's a kernel of a good idea there - it's certainly
> > easier than using Constrained Execution Regions which was my longer
> > term plan (and also has trouble w/ partial trust unlike a normal
> > try/finally).
> >
> 
> Well, it would only postpone the ctrl-c whilst the cleanup code ran, right?

Oh, I misread that...  I skipped over "cleanup" in "cleanup code" :) I was 
thinking of putting all of the code in a finally for some reason :)

But the cleanup code is already in a finally.  But sometimes it's structured as:

stack = PushFrame(...);
try {
} finally {
stack.RemoveAt(stack.Count - 1);
}

In this case there's a small window of opportunity where the abort could happen
after the push frame and before we enter the try block.  

Elsewhere it's actually structured like this:

try {
stack = PushFrame(...);
} finally {
stack.RemoveAt(stack.Count - 1);
}

Here there's the possibility of aborting before the push frame but after we 
enter the try which leads to popping too many frames.  Worse still both of
these have the possibility in aborting during the list.Add() call which may
corrupt the underlying list.

So really we need something like:

bool pushedFrame = false;
try {
try {
} finally {
stack = PushFrame(...);
pushedFrame = true;
}
} finally {
if (pushedFrame) {
stack.RemoveAt(stack.Count - 1);
}
}

But this code would be broken in the face of Rude Thread Aborts (luckily they're
not much of a concern for us).  Fixing this one is where the CERs come into 
play.






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

Re: [IronPython] Thread local storage in IronPython 2.6

[Dino Viehland]

Michael wrote:
> The first result when searching for rude thread aborts was a blog entry
> from you in 2004.
> 
> http://blogs.msdn.com/dinoviehland/archive/2004/09/30/236417.aspx

Not too surprising, I used to be the CLR reliability guy.  And to think 
that knowledge finally was useful when implementing ctypes.

Also I think Bing wins on this search by not returning me as the 1st 
result :)
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Dino Viehland]

Michael wrote:
> I don't have an obvious solution (per user site-packages perhaps?) but
> present the problem. Python circumvents this problem by *not* installing
> into "Program Files".

I would actually say that CPython seems to circumvent this by allowing
users to write to its installation directory.  Interestingly it does not 
allow modifying the existing files (e.g. I can't modify site.py w/ out
elevating to admin, just as I can't create files at C:\ w/o elevating
to admin).


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

Re: [IronPython] Default install location and site-packages

[Dino Viehland]

Michael wrote:
> Curt Hagenlocher wrote:
> > In principle, allowing unprivileged users to install code into a
> > location where it can unknowingly be accessed by privileged users is a
> > security problem. A "per-user" approach is the right one.
> 
> Unknowingly?

I've just installed some software.  Installing that software required that
I elevate to admin and left that software in a typically global location
on my machine (either C:\... or C:\Program Files\...) where my normal user 
account does not have writes to access.  

What's the least surprising - that the global location is now suddenly
writable or that the global location remains writable only be 
administrators?



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

Re: [IronPython] Default install location and site-packages

[Dino Viehland]

Michael wrote:
> Dino Viehland wrote:
> > Michael wrote:
> >
> >> Curt Hagenlocher wrote:
> >>
> >>> In principle, allowing unprivileged users to install code into a
> >>> location where it can unknowingly be accessed by privileged users is a
> >>> security problem. A "per-user" approach is the right one.
> >>>
> >> Unknowingly?
> >>
> >
> > I've just installed some software.  Installing that software required that
> > I elevate to admin and left that software in a typically global location
> > on my machine (either C:\... or C:\Program Files\...) where my normal user
> > account does not have writes to access.
> >
> > What's the least surprising - that the global location is now suddenly
> > writable or that the global location remains writable only be
> > administrators?
> >
> 
> Your answer seems orthogonal to the question I asked.
> 
> As you answered my question with a question perhaps I can do the same:
> 
> A user has an installed version of Python and an installed version of
> IronPython. He wishes to install a library for both IronPython and
> Python so he runs:
> 
> python setup.py install
> ipy.exe setup.py install
> 
> The first succeeds, naturally. Are you saying that it would be *more*
> surprising if the second succeeded?
> 
> Unfortunately at the moment it fails silently, but an "access denied"
> error would not be much more helpful.

My point is simply that if a user is surprised by the fact that we've created
a globally writable place that effects the code they're running then they have
unknowingly done this.  Or another way to put this is any decision which leads 
to less security shouldn't ever be a surprise to the user.

I'll agree that the difference between CPython and IronPython may be 
surprising to someone who is used to CPython.  But it seems like CPython is
the one who's doing something wrong here.  I just checked on a Linux machine
and there CPython is behaving like we are:

di...@sh0:/usr/lib/python2.5/site-packages$ ls
apt  aptsources  python-support.pth
apt_inst.so  debconf.py  README
apt_pkg.so   python_apt-0.6.17.egg-info  unattended_upgrades-0.1.egg-info
di...@sh0:/usr/lib/python2.5/site-packages$ cp apt_inst.so xx
cp: cannot create regular file `xx': Permission denied
di...@sh0:/usr/lib/python2.5/site-packages$


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

[IronPython] E: Default install location and site-packages

[Dino Viehland]

Michael wrote:
> I still see it as a question of usability rather than security. (I'm
> honestly not sure how creating a writable directory is a security
> issue?) If the default install location of IronPython makes installing
> and using Python packages with IronPython impossible for non-elevated
> users then that is an extreme misfeature.

This is the security problem.  Let's say I, a normal user, goes into 
C:\Python26\Lib\site-packages and creates or modifies sitecustomize.py.  
In sitecustomize.py I add some code like:

import os
if os.environ['USERNAME'] == 'Administrator':
# install malware here, set myself as an administrator, format C, 
# etc...
pass

Now I just sit back and wait for an administrator to start some program
which relies on Python.  I now have full control of a machine which I was
originally only granted normal user access on.





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

Re: [IronPython] E: Default install location and site-packages

[Dino Viehland]

Michael wrote:
> Well, fair enough [1]. :-)
> 
> Except it may *still* leave distutils / package management basically
> unusable for many people. That would still seem to be bad. I'd like to
> work on making Distribute (the successor to setuptools) compatible with
> IronPython but it is going to require a working distutils system.
> 
> Can PEP 370 style site-packages be made the default for IronPython?
> 
> Michael
> 
> [1] I don't have this problem on the Mac. I have a system installed
> Python that I must sudo to modify and a user installed one that I don't.
> Even a user installed IronPython wouldn't have write permissions in the
> normal site-packages folder on Windows, right?

>From the IronPython side of things I think we should make our installer
have an option to install into a per-user directory.  That is certainly
missing today and would allow us to even have an elevation free installer
(although we couldn't ngen in that case but we might be able to offer the
user an opportunity to ngen even if they do a per-user install if they're
willing to elevate).

Do you have an idea of how to go about making it the default?  It looks
like PEP 370 style site-packages work today - although there might be 
some tweaking we want to do.  It looks like if you create 
%APPDATA%\Python\Python26\site-packages that site.py will pick it up even 
on IronPython.  The only downside to this seems to  be that we share the 
same directory as CPython per-user site packages.  But I'm not sure how
we would make that the default location to install to.

We should probably make the "Python" part of the directory be Python, 
IronPython, Jython, etc... depending upon what implementation you're
running on.

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

Re: [IronPython] Issue with using multiple forms in IronPython

[Dino Viehland]

The problem here is really that IronPython Studio is really weird and is
trying to create namespaces where none exist.  So if you removed the class 
WindowsApplication... everywhere or if you changed the namespace names
so the 2 files had distinct "namespaces" it would work.  But you won't get
the two separate classes to be merged into one namespace.

I personally would suggest going w/ Michael Foord's recommendation of 
making a base winforms class in the designer w/ C# and then just
inheriting from that in IronPython rather than using IronPython Studio's
forms support.

Alternately I think XAML is probably the future as far as IronPython IDEs
go.  W/ XAML none of the UI needs to be represented with code.


> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Leonides Saguisag
> Sent: Wednesday, October 07, 2009 1:36 PM
> To: 'users@lists.ironpython.com'
> Subject: [IronPython] Issue with using multiple forms in IronPython
> 
> I am trying to create a simple app which has two forms.  Form1 contains a
> button which, when clicked, should display Form2 as a dialog.  Here is the
> source code (developed using IronPython Studio):
> 
> ### Program.py ###
> from System import *
> from System.Windows.Forms import *
> from Form1 import *
> 
> class WindowsApplication80: # namespace
> 
> @staticmethod
> def RealEntryPoint():
> Application.EnableVisualStyles()
> Application.Run(WindowsApplication8.Form1())
> 
> if __name__ == "Program":
> WindowsApplication80.RealEntryPoint();
> ### end of Program.py ###
> 
> ### Form1.py ###
> import System
> from System.Windows.Forms import *
> from System.ComponentModel import *
> from System.Drawing import *
> from clr import *
> from Form2 import *
> class WindowsApplication8: # namespace
> 
> class Form1(System.Windows.Forms.Form):
> """type(_button1) == System.Windows.Forms.Button, type(_form2) ==
> System.Windows.Forms.Form"""
> __slots__ = ['_button1', '_form2']
> def __init__(self):
> self.InitializeComponent()
> 
> @accepts(Self(), bool)
> @returns(None)
> def Dispose(self, disposing):
> 
> 
> 
> super(type(self), self).Dispose(disposing)
> 
> @returns(None)
> def InitializeComponent(self):
> self._button1 = System.Windows.Forms.Button()
> self.SuspendLayout()
> #
> # button1
> #
> self._button1.Location = System.Drawing.Point(96, 78)
> self._button1.Name = 'button1'
> self._button1.Size = System.Drawing.Size(75, 23)
> self._button1.TabIndex = 0
> self._button1.Text = 'button1'
> self._button1.UseVisualStyleBackColor = True
> self._button1.Click += self._button1_Click
> #
> # Form1
> #
> self.ClientSize = System.Drawing.Size(292, 273)
> self.Controls.Add(self._button1)
> self.Name = 'Form1'
> self.Text = 'Form1'
> self.ResumeLayout(False)
> 
> @accepts(Self(), System.Object, System.EventArgs)
> @returns(None)
> def _button1_Click(self, sender, e):
> self._form2 = WindowsApplication8.Form2()
> ShowDialog(self._form2)
> ### end of Form1.py ###
> 
> ### Form2.py ###
> import System
> from System.Windows.Forms import *
> from System.ComponentModel import *
> from System.Drawing import *
> from clr import *
> class WindowsApplication8: # namespace
> 
> class Form2(System.Windows.Forms.Form):
> __slots__ = []
> def __init__(self):
> 
> self.InitializeComponent()
> 
> @accepts(Self(), bool)
> @returns(None)
> def Dispose(self, disposing):
> 
> 
> 
> super(type(self), self).Dispose(disposing)
> 
> @returns(None)
> def InitializeComponent(self):
> self.SuspendLayout()
> #
> # Form2
> #
> self.ClientSize = System.Drawing.Size(292, 273)
> self.Name = 'Form2'
> self.Text = 'Form2'
> self.Load += self._Form2_Load
> self.ResumeLayout(False)
> ### end of Form2.py ###
> 
> The issue is that when I click on button1 on Form1, the debugger stops in the
> _button1_Click method, on the following line:
> 
>   self._form2 = WindowsApplication8.Form2()
> 
> Here is the exception detail:
> ### Start of exception detail ###
> IronPython.Runtime.Exceptions.PythonNameErrorException was unhandled by user
> code
>   Message="name 'Form2' not defined"
>   Source="IronPython"
>   StackTrace:
>at IronPython.Runtime.Operations.Ops.CheckInitializedOrBuiltin(Object
> o, ICallerContext context, String name)
>at Form1._button1_Click$f630(FunctionEnvironment8Dictionary $env,
> Object self, Object sender, Object e) in Form1.

Re: [IronPython] E: Default install location and site-packages

[Dino Viehland]

Michael wrote:
> http://ironpython-urls.blogspot.com/2009/10/distributing-ironpython-
> packages.html
> 
> I hope to get committed to Python 2.6, as a compatibility fix, a
> separate PEP 370 site-packages folder for IronPython - both in site.py
> and distutils, plus get distutils compatible with IronPython.
> 
> Not sure if I can get this done before IronPython 2.6 RTM, but assuming
> I succeed the IronPython installer could create this directory if it
> doesn't exist.

I'll look at making sure our WiX scripts create the directory during
install.  

For the "implementation specific folder to the path" are you thinking
"IronPython\Python26\site-packages" or "Python\IronPython26\site-packages"?

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

Re: [IronPython] Trouble with 2.6 RC1

[Dino Viehland]

Is the object in the set a user-defined object of some sort (or say a tuple of 
a user defined object)?  And if there is a user defined object does it override 
__hash__ / __eq__ and in particular is __hash__ stable over time?

Also can you see what _items._hashFunc and _items._eqFunc are (in particular 
what the method is)?

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Glenn Jones
Sent: Wednesday, October 14, 2009 8:49 AM
To: users@lists.ironpython.com
Subject: [IronPython] Trouble with 2.6 RC1

Hi guys,

I have just run across a problem with sets and iteration. I haven't managed to 
make a repo that doesn't include most of our source, but a little investigation 
has shown that in SetIterator.Current, there is a test to see whether the 
current element is still in the enumerator 
(!_items.Contains(_enumerator.Current)). This is failing when I believe it 
shouldn't. I have thrown in some debugging code to compare the elements of 
_items against _enumerator.Current using == and that returns true for one of 
the elements when .Contains is returning False.

This is a blocker for us at Resolver because a workaround would require quite a 
lot of work.

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

Re: [IronPython] Curious about the development cycle and community involvement

[Dino Viehland]

> That said, if relative imports are borked, you don't really meet the
> "2.6 compatibility" bullet on the roadmap ;)

This is a bug w/ relating to PEP 366 (Main module explicit relative 
imports).  I've added a simple repro to the bug and will look at fixing
it for RC2.

That being said json isn't going to work w/ IronPython 2.6  The reason
is that the json module relies upon CPython's sre_* modules instead of 
relying upon just the normal re module.  We'll presumably need to 
re-implement all of json in order to make this work as we have no plans
to implement sre as it's been deprecated in favor of re which we already
implement.


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

Re: [IronPython] Curious about the development cycle and community involvement

[Dino Viehland]

Tyler wrote:
> Less than awesome. but a fair point. Do issues like this get logged back to
> bugs.python.org? (IMHO that's a bug with Python, no reason to use
> sre)

It depends upon the issue.  In this case I haven't logged something yet as
I just realized this last week and haven't investigated it very thoroughly.
I've gone ahead and opened a bug (http://bugs.python.org/issue7130).  It
looks like Jython actually implements _sre so we'll see how this goes.

> 
> That said, is there a fairly straightforward means of bridging collections
> like Dictionary and List to their python equivalent types? If so, than
> wrapping System.Web.Script.Serialization.JavaScriptSerializer would be a
> decent enough workaround for now IMHO.

Ok, after getting a fix for the relative imports it appears I have spoken too
soon.   Encoding to json works just fine w/ the json module, only decoding 
doesn't work.  I guess that makes sense - you wouldn't use regexes for 
encoding :)

So if you just need to encode you're good to go.

As far as a bridge we do already bridge our dictionaries and lists w/ normal
.NET dictionaries and lists in a variety of ways.  For starters they are 
IDictionary/IDictionary and IList/IList.  
Also if we're calling a method which takes an IDictionary or an 
IList we'll create a wrapper which converts the objects on the fly.
Apparently neither of those help with the JavaScript serializer though!

It does look like you can do:

dict(a.Deserialize[Dictionary[object, object]](a.Serialize(Dictionary[object, 
object]({"foo":42}

so you just need to convert the python objects to their .NET equivalents
on the way in and out which isn't too bad.

I don't think there's much else we can do directly other than asking the 
team that owns that to support IDictionary and IList in addition to 
the concrete types.

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

Re: [IronPython] I can't install the MSI for IP2.6 RC1

[Dino Viehland]

Does ngen work if you run it on the binaries in the zip file?

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jonathan Hartley
> Sent: Friday, October 16, 2009 5:16 AM
> To: users@lists.ironpython.com
> Subject: [IronPython] I can't install the MSI for IP2.6 RC1
> 
> Hey there.
> 
> I can't install the IP2.6 RC1 msi. When the install is mostly done, it
> suddenly fails and rolls back. I can use the binary zip file instead of
> the msi, but wanted to ask if this is a problem anyone else was having.
> 
> At the end of the failed install and roll-back it produces a dialog:
> 
>IromPython 2.6 Setup Wizard ended prematurely
>because of an error.
> 
> So I got a logfile of the install:
> 
>msiexec /i IronPython-2.6.msi /log install.log
> 
> which produces verbose output, including:
> 
> ...
> Action 15:50:17: RollbackCleanup. Removing backup files
> ExecNetFx:  Error 0x80070005: Command failed to execute.
> ExecNetFx:  Error 0x80070005: failed to execute Ngen command:
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe install
> "C:\Program Files\IronPython 2.6\Microsoft.Scripting.dll" /queue:1
> Action 15:50:17: Rollback. Rolling back action:
> Rollback: Publishing product information
> ...
> Action ended 15:50:25: InstallFinalize. Return value 3.
> Action ended 15:50:25: INSTALL. Return value 3.
> ...
> Action ended 15:50:25: ExecuteAction. Return value 3.
> Action 15:50:25: FatalError.
> ...
> Action ended 15:59:24: FatalError. Return value 2.
> Action ended 15:59:24: INSTALL. Return value 3.
> ...
> MSI (c) (28:6C) [15:59:24:453]: Product: IronPython 2.6 -- Installation
> failed.
> 
> 
> I'd like to try running the allegedly failing ngen command from a prompt:
> 
>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe install
> "C:\Program Files\IronPython 2.6\Microsoft.Scripting.dll" /queue:1
> 
> but of course since the install rolls back, the file
> "Microsoft.Scripting.dll" no longer exists, so I can't. However, I can
> manually ngen *other* assemblies using a command exactly like this. The
> path to ngen.exe is correct, and the parameters to the command are
> correct, so I don't understand why this ngen might be failing.
> 
> Upon further investigation, trying to *un*install the IP2.0.2 msi also
> fails and does the same thing. I currently don't know how I'm going to
> get that uninstalled except by some sort of 'rm -rf' style extreme
> prejudice.
> 
> Install and uninstall of other programs seems to work ok.
> 
> Is it just me? Thoughts very welcome.
> 
>Jonathan
> 
> --
> Jonathan Hartley  Made of meat.  http://tartley.com
> tart...@tartley.com   +44 7737 062 225   twitter/skype: tartley
> 
> 
> ___
> 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] I can't install the MSI for IP2.6 RC1

[Dino Viehland]

What OS is this on?  0x80070005 is accessed denied.  Can you explicitly
run the MSI as administrator and see if that works? I'm just guessing here
because I'd expect if you were on XP you'd already be on administrator and
Vista should auto-elevate the installer but it might be worth a shot.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jonathan Hartley
> Sent: Friday, October 16, 2009 10:00 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] I can't install the MSI for IP2.6 RC1
> 
> Ah, excellent question.
> Yes, after copying the binary zip contents to C:\Program
> Files\IronPython-2.6, I can cut and past the ngen command below (but
> change the space in that command before '2.6' into a hyphen) and it
> works fine.
> Puzzled.
> 
> 
> Dino Viehland wrote:
> > Does ngen work if you run it on the binaries in the zip file?
> >
> >
> >> -Original Message-
> >> From: users-boun...@lists.ironpython.com [mailto:users-
> >> boun...@lists.ironpython.com] On Behalf Of Jonathan Hartley
> >> Sent: Friday, October 16, 2009 5:16 AM
> >> To: users@lists.ironpython.com
> >> Subject: [IronPython] I can't install the MSI for IP2.6 RC1
> >>
> >> Hey there.
> >>
> >> I can't install the IP2.6 RC1 msi. When the install is mostly done, it
> >> suddenly fails and rolls back. I can use the binary zip file instead of
> >> the msi, but wanted to ask if this is a problem anyone else was having.
> >>
> >> At the end of the failed install and roll-back it produces a dialog:
> >>
> >>IromPython 2.6 Setup Wizard ended prematurely
> >>because of an error.
> >>
> >> So I got a logfile of the install:
> >>
> >>msiexec /i IronPython-2.6.msi /log install.log
> >>
> >> which produces verbose output, including:
> >>
> >> ...
> >> Action 15:50:17: RollbackCleanup. Removing backup files
> >> ExecNetFx:  Error 0x80070005: Command failed to execute.
> >> ExecNetFx:  Error 0x80070005: failed to execute Ngen command:
> >> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe install
> >> "C:\Program Files\IronPython 2.6\Microsoft.Scripting.dll" /queue:1
> >> Action 15:50:17: Rollback. Rolling back action:
> >> Rollback: Publishing product information
> >> ...
> >> Action ended 15:50:25: InstallFinalize. Return value 3.
> >> Action ended 15:50:25: INSTALL. Return value 3.
> >> ...
> >> Action ended 15:50:25: ExecuteAction. Return value 3.
> >> Action 15:50:25: FatalError.
> >> ...
> >> Action ended 15:59:24: FatalError. Return value 2.
> >> Action ended 15:59:24: INSTALL. Return value 3.
> >> ...
> >> MSI (c) (28:6C) [15:59:24:453]: Product: IronPython 2.6 -- Installation
> >> failed.
> >>
> >>
> >> I'd like to try running the allegedly failing ngen command from a prompt:
> >>
> >>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe install
> >> "C:\Program Files\IronPython 2.6\Microsoft.Scripting.dll" /queue:1
> >>
> >> but of course since the install rolls back, the file
> >> "Microsoft.Scripting.dll" no longer exists, so I can't. However, I can
> >> manually ngen *other* assemblies using a command exactly like this. The
> >> path to ngen.exe is correct, and the parameters to the command are
> >> correct, so I don't understand why this ngen might be failing.
> >>
> >> Upon further investigation, trying to *un*install the IP2.0.2 msi also
> >> fails and does the same thing. I currently don't know how I'm going to
> >> get that uninstalled except by some sort of 'rm -rf' style extreme
> >> prejudice.
> >>
> >> Install and uninstall of other programs seems to work ok.
> >>
> >> Is it just me? Thoughts very welcome.
> >>
> >>Jonathan
> >>
> >> --
> >> Jonathan Hartley  Made of meat.  http://tartley.com
> >> tart...@tartley.com   +44 7737 062 225   twitter/skype: tartley
> >>
> >>
> >> ___
> >> 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
> >
> >
> 
> --
> Jonathan Hartley  Made of meat.  http://tartley.com
> tart...@tartley.com   +44 7737 062 225   twitter/skype: tartley
> 
> 
> ___
> 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] I can't install the MSI for IP2.6 RC1

[Dino Viehland]

Weird, I don't know why this would happen then :(

Maybe going to %WINDIR%\assembly\GAC_MSIL and clearing out the 
Microsoft.Scripting, Microsoft.Dynamic, IronPython, etc... directories 
would help?

Alternately you could run process explorer while the setup is running
and see if you can find where the access is denied is coming from.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jonathan Hartley
> Sent: Friday, October 16, 2009 10:42 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] I can't install the MSI for IP2.6 RC1
> 
> Hey. Thanks for the responses Dino.
> 
> This is Windows XP. I was running as a domain user which does have
> administrative privs.
> 
> I just tried running msiexec as THE local Administrator user. Same
> behaviour, and the only diffs to the logfile are timestamps and user ID.
> 
> Jonathan
> 
> 
> Dino Viehland wrote:
> > What OS is this on?  0x80070005 is accessed denied.  Can you explicitly
> > run the MSI as administrator and see if that works? I'm just guessing here
> > because I'd expect if you were on XP you'd already be on administrator and
> > Vista should auto-elevate the installer but it might be worth a shot.
> >
> >
> >> -Original Message-
> >> From: users-boun...@lists.ironpython.com [mailto:users-
> >> boun...@lists.ironpython.com] On Behalf Of Jonathan Hartley
> >> Sent: Friday, October 16, 2009 10:00 AM
> >> To: Discussion of IronPython
> >> Subject: Re: [IronPython] I can't install the MSI for IP2.6 RC1
> >>
> >> Ah, excellent question.
> >> Yes, after copying the binary zip contents to C:\Program
> >> Files\IronPython-2.6, I can cut and past the ngen command below (but
> >> change the space in that command before '2.6' into a hyphen) and it
> >> works fine.
> >> Puzzled.
> >>
> >>
> >> Dino Viehland wrote:
> >>
> >>> Does ngen work if you run it on the binaries in the zip file?
> >>>
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: users-boun...@lists.ironpython.com [mailto:users-
> >>>> boun...@lists.ironpython.com] On Behalf Of Jonathan Hartley
> >>>> Sent: Friday, October 16, 2009 5:16 AM
> >>>> To: users@lists.ironpython.com
> >>>> Subject: [IronPython] I can't install the MSI for IP2.6 RC1
> >>>>
> >>>> Hey there.
> >>>>
> >>>> I can't install the IP2.6 RC1 msi. When the install is mostly done, it
> >>>> suddenly fails and rolls back. I can use the binary zip file instead of
> >>>> the msi, but wanted to ask if this is a problem anyone else was having.
> >>>>
> >>>> At the end of the failed install and roll-back it produces a dialog:
> >>>>
> >>>>IromPython 2.6 Setup Wizard ended prematurely
> >>>>because of an error.
> >>>>
> >>>> So I got a logfile of the install:
> >>>>
> >>>>msiexec /i IronPython-2.6.msi /log install.log
> >>>>
> >>>> which produces verbose output, including:
> >>>>
> >>>> ...
> >>>> Action 15:50:17: RollbackCleanup. Removing backup files
> >>>> ExecNetFx:  Error 0x80070005: Command failed to execute.
> >>>> ExecNetFx:  Error 0x80070005: failed to execute Ngen command:
> >>>> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe install
> >>>> "C:\Program Files\IronPython 2.6\Microsoft.Scripting.dll" /queue:1
> >>>> Action 15:50:17: Rollback. Rolling back action:
> >>>> Rollback: Publishing product information
> >>>> ...
> >>>> Action ended 15:50:25: InstallFinalize. Return value 3.
> >>>> Action ended 15:50:25: INSTALL. Return value 3.
> >>>> ...
> >>>> Action ended 15:50:25: ExecuteAction. Return value 3.
> >>>> Action 15:50:25: FatalError.
> >>>> ...
> >>>> Action ended 15:59:24: FatalError. Return value 2.
> >>>> Action ended 15:59:24: INSTALL. Return value 3.
> >>>> ...
> >>>> MSI (c) (28:6C) [15:59:24:453]: Product: IronPython 2.6 -- Installation
> >>>> failed.
> >>>>
> >>>>
> >>>> I'd like to try running the allegedly failing ngen command from a prompt:
&g

Re: [IronPython] IMAP4_SSL in 2.0.2 and 2.6

[Dino Viehland]

You can give a little more information on how it is failing?  It looks like we 
are missing the ssl module (implemented in Python but not included in 
IronPython because we don't implement _ssl) which is new in 2.6 but we still 
have all the old SSL support that previously existed in the socket module.  I 
don't think we'll slip in _ssl for 2.6.0 but it's something we can probably fix 
for 2.6.1.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Severin
Sent: Tuesday, October 20, 2009 12:26 AM
To: Discussion of IronPython
Subject: [IronPython] IMAP4_SSL in 2.0.2 and 2.6

Hi,

I use IronPython to send e-mails with imap4.

It seems that version 2.0.2 has SSL support whereas 2.6 doesn't.
Why is that?

My understanding would be that SSL should or shouldn't work with both 
versions...

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

Re: [IronPython] IronPython 2.6 for .NET 4.0 Beta 2

[Dino Viehland]

We're planning on releasing a CTP tomorrow when the beta is publicly 
available.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Tuesday, October 20, 2009 11:33 AM
> To: Discussion of IronPython
> Subject: [IronPython] IronPython 2.6 for .NET 4.0 Beta 2
> 
> I know, I know, it's not even publicly available yet, but I'm
> impatient :). Is it going to be available soon-ish, or are you guys
> busy enough as it is?
> 
> - Jeff
> ___
> 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] Announcing IronPython 2.6 CTP for .NET 4.0 Beta 2

[Dino Viehland]

Hello Python Community,

We're quite pleased to announce the release of "IronPython 2.6 CTP for .NET 4.0 
Beta 2".  This is our third preview of IronPython running under the Dynamic 
Language Runtime that is built directly into a .NET 4.0 release!  As before, 
this release allows you to use IronPython objects and types as .NET 4.0 dynamic 
objects from within C# and Visual Basic code.  This release is extremely 
similar to IronPython 2.6 RC 1.  Please also note that "IronPython 2.6 CTP for 
.NET 4.0 Beta 2" will run only under .NET 4.0 Beta 2.

Here's a small example showing just how powerful the new dynamic feature is for 
taking advantage of dynamic language functionality in statically typed 
languages:
    
    import random, math
    
    class Mock(object): 
    def __getattr__(self, key):
    """Mock objects of this type will dynamically implement any 
requested member"""
    return random.choice(["hello world", math.pi])
     

    
    using System;
    using IronPython.Hosting;
    using Microsoft.Scripting.Hosting;
    
    public class dynamic_demo {
    static void Main() {  
   var ipy = Python.CreateRuntime();
       dynamic mock = ipy.UseFile("mock.py");
       dynamic m = mock.Mock();
   //The Python Mock type dynamically implements any member that is 
requested of it
   
System.Console.WriteLine(m.the_csharp_compiler_cannot_possbily_know_this_member_exists_at_compile_time);
    }
    }
    


To try out this preview release:
1. Install some variant of .NET 4.0 Beta 2 or Visual Studio 2010 Beta 2.  E.g., 
http://www.microsoft.com/downloads/details.aspx?FamilyID=9f5e8774-c8dc-4ff6-8285-03a4c387c0db&displaylang=en
 
2. Install  IronPython 2.6 CTP for .NET 4.0 Beta 2.msi from 
http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28125 
3. Follow any of the many dynamic walkthroughs online.  
http://blogs.msdn.com/vbteam/archive/2008/12/17/walkthrough-dynamic-programming-in-visual-basic-10-0-and-c-4-0-lisa-feigenbaum.aspx
 would be a good start

Have fun!

The IronPython Team



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

Re: [IronPython] SystemError while compiling PIL.Image

[Dino Viehland]

Is there a parameter with a default value that is a name?  If so what is the
scope of the name in relation to the function definition?

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of William Reade
> Sent: Thursday, October 22, 2009 6:37 AM
> To: Discussion of IronPython
> Subject: [IronPython] SystemError while compiling PIL.Image
> 
> Transcript follows. The contents of the file don't look obviously
> weird.
> Does anyone have any idea what the problem might be?
> 
> Cheers
> William
> 
> ---
> --
> 
> C:\dev\ironclad>ipy -X:ExceptionDetail
> C:\Python26\Lib\site-packages\PIL\Image.py
> Object reference not set to an instance of an object.
> at IronPython.Compiler.Ast.GlobalAllocator.GetVariable(AstGenerator
> ag, PythonVariable variable)
> at IronPython.Compiler.Ast.NameExpression.Transform(AstGenerator
> ag,
> Type type)
> at
> IronPython.Compiler.Ast.FunctionDefinition.TransformParameters(AstGener
> ator
> outer, AstGenerator inner, List`1 defaults, List`1 names, Boolean
> needsWrapperMethod, List`1 init)
> at
> IronPython.Compiler.Ast.FunctionDefinition.TransformToFunctionExpressio
> n(AstGenerator
> ag)
> at
> IronPython.Compiler.Ast.FunctionDefinition.Transform(AstGenerator ag)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformWithLineNumberUpdate(Stat
> ement
> fromStmt)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformMaybeSingleLineSuite(Stat
> ement
> body, SourceLocation prevStart)
> at IronPython.Compiler.Ast.AstGenerator.Transform(Statement[] from)
> at IronPython.Compiler.Ast.SuiteStatement.Transform(AstGenerator
> ag)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformWithLineNumberUpdate(Stat
> ement
> fromStmt)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformMaybeSingleLineSuite(Stat
> ement
> body, SourceLocation prevStart)
> at IronPython.Compiler.Ast.IfStatement.Transform(AstGenerator ag)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformWithLineNumberUpdate(Stat
> ement
> fromStmt)
> at
> IronPython.Compiler.Ast.FunctionDefinition.TryTransformBody(AstGenerato
> r
> ag, List`1 statements)
> at
> IronPython.Compiler.Ast.FunctionDefinition.TransformToFunctionExpressio
> n(AstGenerator
> ag)
> at
> IronPython.Compiler.Ast.FunctionDefinition.Transform(AstGenerator ag)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformWithLineNumberUpdate(Stat
> ement
> fromStmt)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformMaybeSingleLineSuite(Stat
> ement
> body, SourceLocation prevStart)
> at IronPython.Compiler.Ast.AstGenerator.Transform(Statement[] from)
> at IronPython.Compiler.Ast.SuiteStatement.Transform(AstGenerator
> ag)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformWithLineNumberUpdate(Stat
> ement
> fromStmt)
> at IronPython.Compiler.Ast.ClassDefinition.Transform(AstGenerator
> ag)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformWithLineNumberUpdate(Stat
> ement
> fromStmt)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformMaybeSingleLineSuite(Stat
> ement
> body, SourceLocation prevStart)
> at IronPython.Compiler.Ast.AstGenerator.Transform(Statement[] from)
> at IronPython.Compiler.Ast.SuiteStatement.Transform(AstGenerator
> ag)
> at
> IronPython.Compiler.Ast.AstGenerator.TransformWithLineNumberUpdate(Stat
> ement
> fromStmt)
> at IronPython.Compiler.Ast.PythonAst.Transform(AstGenerator ag)
> at IronPython.Compiler.Ast.PythonAst.TransformToAst(CompilationMode
> mode, CompilerContext context)
> at IronPython.Runtime.PythonContext.CompilePythonCode(Nullable`1
> compilationMode, SourceUnit sourceUnit, CompilerOptions options,
> ErrorSink errorSink)
> at IronPython.Runtime.PythonContext.GetScriptCode(SourceUnit
> sourceCode, String moduleName, ModuleOptions options, Nullable`1 mode)
> at IronPython.Runtime.PythonContext.GetScriptCode(SourceUnit
> sourceCode, String moduleName, ModuleOptions options)
> at IronPython.Runtime.PythonContext.CompileModule(String fileName,
> String moduleName, SourceUnit sourceCode, ModuleOptions options,
> ScriptCode& scriptCode)
> at IronPython.Hosting.PythonCommandLine.RunFileWorker(String
> fileName)
> at IronPython.Hosting.PythonCommandLine.RunFile(String fileName)
> SystemError: Object reference not set to an instance of an object.
> 
> ---
> --
> ___
> 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] The tale of a full HybridMapping and a not so tempfile

[Dino Viehland]

Thanks for the great detail here.  As you said the fix is easy and I believe
I have it ready to go.  We're already kicking off our RC2 build so I don't
know that it'll make it until that build (or 2.6.0 for that matter) but it'll
be fixed by 2.6.1 at the latest.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Martin (gzlist)
> Sent: Thursday, October 22, 2009 2:50 PM
> To: users@lists.ironpython.com
> Subject: [IronPython] The tale of a full HybridMapping and a not so tempfile
> 
> I'm trying to complete some work getting a big project running on
> IronPython, but hit an issue where everything in the test suite would
> start failing after a certain point with errors along the lines of:
> 
> Traceback (most recent call last):
> ...
>   File "C:\Program Files\IronPython 2.6\Lib\tempfile.py", line 444, in
> NamedTemporaryFile
> (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags)
>   File "C:\Program Files\IronPython 2.6\Lib\tempfile.py", line 228, in
> _mkstemp_inner
> fd = _os.open(file, flags, 0600)
> OSError: [Errno -2146233079] HybridMapping is full
> 
> After a long boring trek over the hills of ignorance that may have
> been shorter if I'd seen that traceback first rather than other more
> obscure ones, the root cause turned out to be a failure to clean up
> temporary files. After IronPython has created 4096 of them and not
> removed any afterwards everything involving filenos starts to
> throwing. (As an aside, I wonder if using non-integer unique tokens
> like Jython mightn't be a better approach).
> 
> The following issue tracker entry covers the tempfile issue:
> 
> 
> 
> However the bug report gets it a little wrong, the problem is not that
> sys.platform == "win32" is false under IronPython, but rather that
> os.name == "nt" is still true, but IronPython silently ignores the
> os.O_TEMPORARY flag.
> 
> A trivial work around is:
> 
> if sys.platform == "cli":
> os.name = "nty"
> import tempfile
> os.name = "nt"
> 
> However fixing this properly is also pretty simple, in
> Src/IronPython.Modules/nt.cs the open function just needs to make sure
> that File.Open gets passed DeleteOnClose. There may as well be a
> FileOptionsFromFlags as per the existing FileModeFromFlags and
> FileAccessFromFlags so that the following mappings are correct as
> well:
> 
> os.O_SHORT_LIVED -> ? -> FILE_ATTRIBUTE_TEMPORARY
> os.O_TEMPORARY -> FileOptions.DeleteOnClose -> FILE_FLAG_DELETE_ON_CLOSE
> os.O_RANDOM -> FileOptions.RandomAccess -> FILE_FLAG_RANDOM_ACCESS
> os.O_SEQUENTIAL -> FileOptions.SequentialScan -> FILE_FLAG_SEQUENTIAL_SCAN
> 
> Martin
> ___
> 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] SystemError while compiling PIL.Image

[Dino Viehland]

This seems to be the simple repro:

X = (42, 43)
class Y:
def outer_f(self):
def f((a,b)=X): 
return a, b
return f


The fix for this probably won't make it into RC2 and I'm not sure about
2.6.0 either but it'll definitely make it into 2.6.1 at the latest.

Interestingly while this certainly regressed since 2.0 our name binding
here has been subtly broken and other changes just exposed it.  I actually
have another set of changes I've been working on which unbreak it but
it's best to fix the name binding :)

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of William Reade
> Sent: Friday, October 23, 2009 2:41 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] SystemError while compiling PIL.Image
> 
> Hi Dino
> 
> If I comment out 2 methods, the file parses fine. Uncommenting either is
> enough to cause it to fail.
> 
>  def convert(self, mode=None, data=None, dither=None, palette=WEB,
> colors=256):
> 
>  def rotate(self, angle, resample=NEAREST, expand=0):
> 
> WEB and NEAREST are both set to 0 at module level; convert and rotate
> are both methods on the module-level old-style class Image. The only
> obvious common feature is that both have a non-name default parameter
> following a name default parameter, but I haven't managed to produce a
> minimal repro.
> 
> If you're allowed to just look at other people's code willy-nilly, the
> file is Image.py in PIL 1.16 :).
> 
> Cheers
> william
> 
> 
> 
> 
> Dino Viehland wrote:
> > Is there a parameter with a default value that is a name?  If so what is the
> > scope of the name in relation to the function definition?
> >
> >> -Original Message-
> >> From: users-boun...@lists.ironpython.com [mailto:users-
> >> boun...@lists.ironpython.com] On Behalf Of William Reade
> >> Sent: Thursday, October 22, 2009 6:37 AM
> >> To: Discussion of IronPython
> >> Subject: [IronPython] SystemError while compiling PIL.Image
> >>
> >> Transcript follows. The contents of the file don't look obviously
> >> weird.
> >> Does anyone have any idea what the problem might be?
> >>
> >> Cheers
> >> William
> >>
> >> ---
> >> --
> >>
> >> C:\dev\ironclad>ipy -X:ExceptionDetail
> >> C:\Python26\Lib\site-packages\PIL\Image.py
> >> Object reference not set to an instance of an object.
> >> at IronPython.Compiler.Ast.GlobalAllocator.GetVariable(AstGenerator
> >> ag, PythonVariable variable)
> >> at IronPython.Compiler.Ast.NameExpression.Transform(AstGenerator
> >> ag,
> >> Type type)
> >> at
> >> IronPython.Compiler.Ast.FunctionDefinition.TransformParameters(AstGener
> >> ator
> >> outer, AstGenerator inner, List`1 defaults, List`1 names, Boolean
> >> needsWrapperMethod, List`1 init)
> >> at
> >> IronPython.Compiler.Ast.FunctionDefinition.TransformToFunctionExpressio
> >> n(AstGenerator
> >> ag)
> >> at
> >> IronPython.Compiler.Ast.FunctionDefinition.Transform(AstGenerator ag)
> >> at
> >> IronPython.Compiler.Ast.AstGenerator.TransformWithLineNumberUpdate(Stat
> >> ement
> >> fromStmt)
> >> at
> >> IronPython.Compiler.Ast.AstGenerator.TransformMaybeSingleLineSuite(Stat
> >> ement
> >> body, SourceLocation prevStart)
> >> at IronPython.Compiler.Ast.AstGenerator.Transform(Statement[] from)
> >> at IronPython.Compiler.Ast.SuiteStatement.Transform(AstGenerator
> >> ag)
> >> at
> >> IronPython.Compiler.Ast.AstGenerator.TransformWithLineNumberUpdate(Stat
> >> ement
> >> fromStmt)
> >> at
> >> IronPython.Compiler.Ast.AstGenerator.TransformMaybeSingleLineSuite(Stat
> >> ement
> >> body, SourceLocation prevStart)
> >> at IronPython.Compiler.Ast.IfStatement.Transform(AstGenerator ag)
> >> at
> >> IronPython.Compiler.Ast.AstGenerator.TransformWithLineNumberUpdate(Stat
> >> ement
> >> fromStmt)
> >> at
> >> IronPython.Compiler.Ast.FunctionDefinition.TryTransformBody(AstGenerato
> >> r
> >> ag, List`1 statements)
> >> at
> >> IronPython.Compiler.Ast.FunctionDefinition.TransformToFunctionExpressio
> >> n(AstGenerator
> >> ag)
> >> at
> >> IronPython.C

Re: [IronPython] ANN: Resolver One version 1.7 released

[Dino Viehland]

Congratulations on another release!  Just out of curiosity did you move 
to 2.0.3 for this release or is it still 2.0.2 based?

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Giles Thomas
> Sent: Tuesday, October 27, 2009 11:06 AM
> To: Discussion of IronPython
> Subject: [IronPython] ANN: Resolver One version 1.7 released
> 
> We are proud to announce the release of Resolver One, version 1.7.
> 
> Resolver One is a Windows-based spreadsheet that integrates IronPython
> deeply into its recalculation loop, making the models you build more
> reliable and more maintainable.  It's also still (we think) the largest
> IronPython application in the world, with 57,000 lines of code backed up
> by 177,000 lines of unit and functional tests.
> 
> Version 1.7 is the last version we're intending to produce before we
> move our codebase over to IronPython 2.6.  In it, we've made the code
> that you add to buttons on your worksheets execute in the background.
> This means that you can interrupt them easily if they run for too long,
> and also stops the rest of the application from pausing -- so you can
> keep working on other spreadsheets.
> 
> You can read more about Resolver One here:
> 
> 
> 
> We have a 31-day free trial version, so if you would like to take a
> look, you can download it from our website:
> 
> 
> 
> If you want to use Resolver One in an Open Source project, we offer free
> licenses for that:
> 
> 
> 
> Best regards,
> 
> Giles
> --
> Giles Thomas
> giles.tho...@resolversystems.com
> +44 (0) 20 7253 6372
> 
> 17a Clerkenwell Road, London EC1M 5RD, UK
> VAT No.: GB 893 5643 79
> Registered in England and Wales as company number 5467329.
> Registered address: 843 Finchley Road, London NW11 8NA, UK
> ___
> 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] Iron Python NewB questions . . .

[Dino Viehland]

Frank wrote:
> So I've been reading the Iron Python docs plus installed and played
> with it a little bit . . . it doesn't look like Iron Python does
> quite what I need.
> 
> If I have a Python script . . . and I want to access a C# assembly .
> . . it looks like I am Golden.  (I have yet to actually get it to
> work, but it looks like the pieces are there.)
> 
> However, if I want to create a Python .NET assembly so I can call an
> existing Python class set from C# . . . it looks to me like that
> direction doesn't exist.

There's a couple of ways to do this.  You can define an interface or base
class on the C# side and implement it on the Python side.  Then you can 
cast the Python object to the interface or base class and use it that way.

Also w/ .NET 4.0 C# is getting the new static type "dynamic" which can
be used for interoperating with Python and other objects which respond
dynamically.  VB.NET, while already having dynamic support, also gets
updated so that it can consume IronPython and IronRuby objects.

> 
> The other thing that I see here, is that even if I adopt the "Python
> on top" philosophy . . . since I cannot create an assembly . . . I
> cannot create an executable file and I think also that things like
> Py2EXE and PyInstaller won't work either.
>
> That is . . . to run the resulting scripts, I have to install Iron
> Python on every target system.  (Currently we wrap our application
> using PyInstaller and so the customer does not have to have Python
> installed to run it.)

In the Tools\Scripts directory of the installation is a script called
pyc.py which can be used to compile Python code into a DLL or an EXE.
The resulting code still needs the IronPython libraries but it provides
a way to pre-compile the code (including down to native code using ngen)
and to not distribute the actual Python code.

> Lastly, I'm wondering is any of this is runnable under Unix Mono . .
> . I'm guessing the answer is "no".

IronPython does run on Mono under Unix.  Occasionally we break them but
the Mono team is usually pretty fast to respond to issues reported and
fix them.  I'm not sure what the current status is so you may need to
use the latest SVN for it to work.


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

Re: [IronPython] Safe execution of python scripts on my .net application

[Dino Viehland]

After creating your app domain you can do:

ScriptEngine engine = Python.CreateEngine(someAppDomain);

And then the rest of your code should work as it's written.


From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Nicolás Buttarelli
Sent: Monday, November 02, 2009 12:39 PM
To: users@lists.ironpython.com
Subject: [IronPython] Safe execution of python scripts on my .net application

Sorry, I don't know if my previous message have arrived. So, here it is:


Hello all,

I am starting with python and I would like to add to my web application some 
web services. This services will allow the different clients of my application 
to execute some python scripts.

I would like to know if someone did this before and how can I do this in a 
secure way. I mean, how can I do to restrict the environment where the scripts 
will be executed.

In .net I can do this using the AppDoman and setting the permission set.

AppDomain.CreateDomain( string friendlyName,
Evidence securityInfo,
AppDomainSetup info,
PermissionSet grantSet,
params StrongName[] fullTrustAssemblies);


Is there a way to do the same with my python scripts?

I am running them using this:

ScriptEngine engine = Python.CreateEngine();
ScriptSource source = engine.CreateScriptSourceFromString(scriptAsString);
ScriptScope scope = engine.CreateScope();
source.Execute(scope);

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

Re: [IronPython] Safe execution of python scripts on my .net application

[Dino Viehland]

Assuming the app domain is setup properly then there's no way for the Python 
code to elevate permissions (modulo CLR security bugs which are few and far 
between).  This is because IronPython its self is 100% security transparent and 
does not affect any security decisions or assert any form of trust - so it's 
all up to the CLR to limit permissions.  So for example while you can access 
the file object, or import ctypes, or call various other Python APIs which 
would require trust you'll get a security exception from the CLR when you don't 
have permissions to do something.

For more complex scenarios you might also have an object model which you expose 
to the application and inject in via its scope.  Once you've done that you'll 
want to make sure that the object model is also secure.


From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Nicolás Buttarelli
Sent: Monday, November 02, 2009 1:20 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Safe execution of python scripts on my .net 
application

Thanks for your response.

But what happens with the python code? Does not exist a way to write some 
scripts that can do some damage to my app, the server, the database, etc?

Thanks again,
Nicolas

On Mon, Nov 2, 2009 at 9:41 PM, Dino Viehland 
mailto:di...@microsoft.com>> wrote:
After creating your app domain you can do:

ScriptEngine engine = Python.CreateEngine(someAppDomain);

And then the rest of your code should work as it's written.


From: 
users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> 
[mailto:users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com>]
 On Behalf Of Nicolás Buttarelli
Sent: Monday, November 02, 2009 12:39 PM
To: users@lists.ironpython.com<mailto:users@lists.ironpython.com>
Subject: [IronPython] Safe execution of python scripts on my .net application

Sorry, I don't know if my previous message have arrived. So, here it is:


Hello all,

I am starting with python and I would like to add to my web application some 
web services. This services will allow the different clients of my application 
to execute some python scripts.

I would like to know if someone did this before and how can I do this in a 
secure way. I mean, how can I do to restrict the environment where the scripts 
will be executed.

In .net I can do this using the AppDoman and setting the permission set.

AppDomain.CreateDomain( string friendlyName,
Evidence securityInfo,
AppDomainSetup info,
PermissionSet grantSet,
params StrongName[] fullTrustAssemblies);


Is there a way to do the same with my python scripts?

I am running them using this:

ScriptEngine engine = Python.CreateEngine();
ScriptSource source = engine.CreateScriptSourceFromString(scriptAsString);
ScriptScope scope = engine.CreateScope();
source.Execute(scope);

Thanks in advance.
Nicolas

___
Users mailing list
Users@lists.ironpython.com<mailto: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] Safe execution of python scripts on my .net application

[Dino Viehland]

Test projects are weird and somehow you don't end up inheriting the application 
base.  This seems to work though:

AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory;
AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed 
Domain", null, setup);
ScriptEngine engine = Python.CreateEngine(aSandboxedDomain);
ScriptSource source = engine.CreateScriptSourceFromString("2+2");
ScriptScope scope = engine.CreateScope();
Console.WriteLine(source.Execute(scope));

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Nicolás Buttarelli
Sent: Tuesday, November 03, 2009 1:30 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Safe execution of python scripts on my .net 
application

I have create a new "Test Project" and an Unit Test class in order to test the 
following code inside:

AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed Domain");
ScriptEngine engine = Python.CreateEngine(aSandboxedDomain);
ScriptSource source = engine.CreateScriptSourceFromString(pythonScript);
ScriptScope scope = engine.CreateScope();
source.Execute(scope);


I have add the references:

- IronPython
- Microsoft.Scripting
- Microsoft.ScriptingCore

But it still not working and throwing the same 
System.Runtime.Serialization.SerializationException: Type is not resolved for 
member 'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting.

Any ideas?


2009/11/3 Nicolás Buttarelli 
mailto:nbuttare...@gmail.com>>
Thanks Shri, I will try.

In addition, I found this open issue: 
http://dlr.codeplex.com/WorkItem/View.aspx?WorkItemId=2816. I think that it is 
related.

On Tue, Nov 3, 2009 at 9:29 PM, Shri Borde 
mailto:shri.bo...@microsoft.com>> wrote:
I think this happens if the new appdomain cannot load the required assembly. By 
default, the new appdomain should inherit its BaseDirectory property from the 
creating domain and should be able to load Microsoft.Scripting.dll. Is your exe 
and all the dlls in the same folder? If not, can you try to put all assemblies 
in the same folder (or in the GAC) to see if it works? If that works, you can 
then figure out how to configure the new appdomain such that it can load 
Microsoft.Scripting.dll. There may be some setting in AppDomainSetup, or you 
could hook the AssemblyResolve event...

From: 
users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> 
[mailto:users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com>]
 On Behalf Of Nicolás Buttarelli
Sent: Tuesday, November 03, 2009 12:08 PM

To: Discussion of IronPython
Subject: Re: [IronPython] Safe execution of python scripts on my .net 
application

Hi again, thanks for your clear response.

I was trying to do what you proposed but it is not working. I am receiving an 
exception:

Test method 
CadworX3WCFRestTest.IronPython.SafeScriptExecutionTest.writingAFileTest threw 
exception:  System.Runtime.Serialization.SerializationException: Type is not 
resolved for member 
'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting, 
Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'..
I tried to find a solution but I couldn't. This is the minimal code that I am 
running to get this exception (I have removed all the security stuff but 
apparently that does not resolve the problem):

AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed Domain");

ScriptEngine engine = Python.CreateEngine(aSandboxedDomain);
ScriptSource source = engine.CreateScriptSourceFromString(pythonScript);
SriptScope scope = engine.CreateScope();
source.Execute(scope);

The exception is thronged in this line:
ScriptEngine engine = Python.CreateEngine(aSandboxedDomain);


Do you have any idea which could be the problem?

Thanks again,
Nicolas

On Mon, Nov 2, 2009 at 10:25 PM, Dino Viehland 
mailto:di...@microsoft.com>> wrote:
Assuming the app domain is setup properly then there's no way for the Python 
code to elevate permissions (modulo CLR security bugs which are few and far 
between).  This is because IronPython its self is 100% security transparent and 
does not affect any security decisions or assert any form of trust - so it's 
all up to the CLR to limit permissions.  So for example while you can access 
the file object, or import ctypes, or call various other Python APIs which 
would require trust you'll get a security exception from the CLR when you don't 
have permissions to do something.

For more complex scenarios you might also have an object model which you expose 
to the application and inject in via its scope.  Once you've done that you'll 
want to make sure that the object model is also secure.


From: 
users-boun...@lists.ironpython.com

Re: [IronPython] Adding imports?

[Dino Viehland]

You can do:

scope.SetVariable("name", engine.ImportModule("module_name"));

Where ImportModule is an extension method defined in IronPython.Hosting.Python.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Slide
Sent: Wednesday, November 04, 2009 9:05 AM
To: Discussion of IronPython
Subject: [IronPython] Adding imports?

Is it possible to add imports to a script without just adding text to the 
source code before compilation?

Maybe something on the script scope or something?

Thanks

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

Re: [IronPython] Reproducing an C# array of floats

[Dino Viehland]

float in Python is actually double in C#.  You probably want:

from System import Single

System.Array.CreateInstance(Single, ...)

And so on.


From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel D.
Sent: Wednesday, November 04, 2009 12:12 PM
To: users@lists.ironpython.com
Subject: [IronPython] Reproducing an C# array of floats

Hi all,

Sorry for the silly question. I'm quite new to ironpython and I've been trying 
to solve this issue for the last 3 hours.

I'm not able to reproduce this code in IronPython.

float[] sample = new float[8192/sizeof(float)]

I've tried the following but nothing seems to work in my specific case:

System.Array.CreateInstance(float, (8192/4))
clr.Reference[System.Array[float]](8192/4)
System.Array[float]([(8192/4)])

I'm trying to use the SlimDX to capture the microphone input, and pass it to 
NumPy to do same FFT stuff.

The original C# code is here: 
http://crsouza.blogspot.com/2009/08/capturing-sound-from-microphone-using.html

And here my modified version

import clr

clr.AddReference('SlimDX')
from SlimDX import *
from System import *

captureDevice = DirectSound.DirectSoundCapture()
waveFormat = Multimedia.WaveFormat()

waveFormat.FormatTag = Multimedia.WaveFormatTag.IeeeFloat # For Int16, change 
to Pcm
waveFormat.BitsPerSample = 32 # Floats are 32 bits
waveFormat.BlockAlignment = (waveFormat.BitsPerSample/8)
waveFormat.Channels = 1

waveFormat.SamplesPerSecond = 44100
waveFormat.AverageBytesPerSecond = 
waveFormat.SamplesPerSecond*waveFormat.BlockAlignment*waveFormat.Channels


bufferDescription = DirectSound.CaptureBufferDescription()
bufferDescription.BufferBytes = 8192
bufferDescription.Format = waveFormat
bufferDescription.WaveMapped = False

buffer = DirectSound.CaptureBuffer(captureDevice,bufferDescription)
buffer.Start(True)

#float[] sample = new float[8192/sizeof(float)];
#sample = Array.CreateInstance(float, (8192/4))
#sample = clr.Reference[Array[float]](8192/4)
sample = Array[float]([(8192/4)])

while (True):
#print sample
print buffer.Read(sample, 0, True);


 which is generating the following error


C:\Documents and Settings\Administrator\My Documents>ipy sound_capture_test.py
Traceback (most recent call last):
  File "sound_capture_test.py", line 34, in sound_capture_test.py
TypeError: Read() takes at least 2147483647 arguments (3 given)



Any help will be very appreciated.

Thanks,
Daniel



Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail 
you.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Reproducing an C# array of floats

[Dino Viehland]

Ahh, read is a generic method and you're getting type inference from C# but not 
IronPython.  IronPython 2.6 includes type inference on generic methods so this 
might just work there, but otherwise I think you can do:

print buffer.Read[Single](sample, 0, True)

The square brackets are how we specifiy generic type parameters.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel D.
Sent: Wednesday, November 04, 2009 12:48 PM
To: users@lists.ironpython.com
Subject: Re: [IronPython] Reproducing an C# array of floats

Hi Dino, thanks for the quick reply.

Now I'm using System.Single instead float but the error persists.

For some reason the Read (ref. http://is.gd/4Ngjt) method of 
SlimDX.DirectSound.CaptureBuffer isn't accepting the array reference properly.

Maybe I should try the Microsoft.DirextX.DirectSound lib, but it's been a 
little bit difficult to find good references about IronPython+DirectSound 
(probably by own  fault).


From: di...@microsoft.com
To: users@lists.ironpython.com
Date: Wed, 4 Nov 2009 20:20:35 +
Subject: Re: [IronPython] Reproducing an C# array of floats
float in Python is actually double in C#.  You probably want:

from System import Single

System.Array.CreateInstance(Single, ...)

And so on.


From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Daniel D.
Sent: Wednesday, November 04, 2009 12:12 PM
To: users@lists.ironpython.com
Subject: [IronPython] Reproducing an C# array of floats

Hi all,

Sorry for the silly question. I'm quite new to ironpython and I've been trying 
to solve this issue for the last 3 hours.

I'm not able to reproduce this code in IronPython.

float[] sample = new float[8192/sizeof(float)]

I've tried the following but nothing seems to work in my specific case:

System.Array.CreateInstance(float, (8192/4))
clr.Reference[System.Array[float]](8192/4)
System.Array[float]([(8192/4)])

I'm trying to use the SlimDX to capture the microphone input, and pass it to 
NumPy to do same FFT stuff.

The original C# code is here: 
http://crsouza.blogspot.com/2009/08/capturing-sound-from-microphone-using.html

And here my modified version

import clr

clr.AddReference('SlimDX')
from SlimDX import *
from System import *

captureDevice = DirectSound.DirectSoundCapture()
waveFormat = Multimedia.WaveFormat()

waveFormat.FormatTag = Multimedia.WaveFormatTag.IeeeFloat # For Int16, change 
to Pcm
waveFormat.BitsPerSample = 32 # Floats are 32 bits
waveFormat.BlockAlignment = (waveFormat.BitsPerSample/8)
waveFormat.Channels = 1

waveFormat.SamplesPerSecond = 44100
waveFormat.AverageBytesPerSecond = 
waveFormat.SamplesPerSecond*waveFormat.BlockAlignment*waveFormat.Channels


bufferDescription = DirectSound.CaptureBufferDescription()
bufferDescription.BufferBytes = 8192
bufferDescription.Format = waveFormat
bufferDescription.WaveMapped = False

buffer = DirectSound.CaptureBuffer(captureDevice,bufferDescription)
buffer.Start(True)

#float[] sample = new float[8192/sizeof(float)];
#sample = Array.CreateInstance(float, (8192/4))
#sample = clr.Reference[Array[float]](8192/4)
sample = Array[float]([(8192/4)])

while (True):
#print sample
print buffer.Read(sample, 0, True);


 which is generating the following error


C:\Documents and Settings\Administrator\My Documents>ipy sound_capture_test.py
Traceback (most recent call last):
  File "sound_capture_test.py", line 34, in sound_capture_test.py
TypeError: Read() takes at least 2147483647 arguments (3 given)



Any help will be very appreciated.

Thanks,
Daniel


Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail 
you.


Windows Live Hotmail: Your friends can get your Facebook updates, right from 
Hotmail(r).
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] clr.CompileSubclassTypes restrictions on list of types

[Dino Viehland]

The only restrictions are the normal restrictions that Python has regarding
inheritance.  In this case it looks like you're hitting that you cannot 
inherit from more than one base type w/ a different layout.

Basically it looks like you're trying to pre-compile the equivalent of:

class c(float, set): pass

Which isn't legal in Python so my guess is there is an issue w/ the way you
split them up.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Tom Wright
> Sent: Tuesday, November 10, 2009 9:39 AM
> To: Discussion of IronPython
> Subject: [IronPython] clr.CompileSubclassTypes restrictions on list of types
> 
> Hi,
> 
> Are there any restrictions placed on the list of types that can be
> passed to CompileSubclassTypes?
> 
> We are having issues with a clr.AddReference(DllContainingSubclasses)
> being very slow, so are trying to split the compiled subclasses across
> multiple dlls to indicate progress between the loading of these dlls.
> 
> However, when trying to compile a partial list of types we get the
> following error:
> 
> Traceback (most recent call last):
>   File "c:\buildshare\gitrepo\precompile_subclasses.py", line 40, in
> c:\buildsha
> re\gitrepo\precompile_subclasses.py
> TypeError: : can only extend one CLI or builtin type, not both
> Microsoft.Scripti
> ng.Runtime.Extensible`1[[System.Double, mscorlib, Version=2.0.0.0,
> Culture=neutr
> al, PublicKeyToken=b77a5c561934e089]] (for
> IronPython.Runtime.Types.PythonType)
> and IronPython.Runtime.SetCollection (for
> IronPython.Runtime.Types.PythonType)
> 
> 
> Any help is much appreciated,
> Tom
> ___
> 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] clr.CompileSubclassTypes restrictions on list of types

[Dino Viehland]

The restrictions are per-subclass so for example you cannot inherit
from both a list and tuple.  The reason here is that list and tuple both
have their own independent layout in memory and there's no relationship
between them.  Or in your case it's set and float.

CompileSubclassTypes takes an arbitrary number of parameters and those
can be either a type (which gets compiled) or they can be a tuple of types
which specify the collection of base types.  The latter form is generally 
useful 
for  including .NET interfaces.

So clr.CompileSubclassTypes("foo", (set, float)) will fail as this is
specifying that you want 1 class which inherits from both set and float. 

But you can do clr.CompileSubclassTypes("foo", set, float) and this specifies
what you want 2 types, one that inherits from set and float.

Or you can do:

clr.CompileSubclassTypes("foo", (set, ), (float, )) 

and again that'll work because it's specifying 2 different base types.


> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Tom Wright
> Sent: Tuesday, November 10, 2009 10:08 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] clr.CompileSubclassTypes restrictions on list of
> types
> 
> Thanks the reply,
> 
> Could you clarify slightly what you mean by the Python's normal
> restrictions. I was guessing the restriction might be something like:
> 
> "When compiling a list of types, if the list contains a class B which
> inherits from A then A must be contained in the list."
> 
> The interesting thing here is that the call to CompileSubclassTypes
> works when we pass it one huge list of types, but not when we call if
> repeatedly with smaller lists.
> 
> Thanks
> Tom
> 
> Dino Viehland wrote:
> > The only restrictions are the normal restrictions that Python has regarding
> > inheritance.  In this case it looks like you're hitting that you cannot
> > inherit from more than one base type w/ a different layout.
> >
> > Basically it looks like you're trying to pre-compile the equivalent of:
> >
> > class c(float, set): pass
> >
> > Which isn't legal in Python so my guess is there is an issue w/ the way you
> > split them up.
> >
> >
> >> -Original Message-
> >> From: users-boun...@lists.ironpython.com [mailto:users-
> >> boun...@lists.ironpython.com] On Behalf Of Tom Wright
> >> Sent: Tuesday, November 10, 2009 9:39 AM
> >> To: Discussion of IronPython
> >> Subject: [IronPython] clr.CompileSubclassTypes restrictions on list of
> types
> >>
> >> Hi,
> >>
> >> Are there any restrictions placed on the list of types that can be
> >> passed to CompileSubclassTypes?
> >>
> >> We are having issues with a clr.AddReference(DllContainingSubclasses)
> >> being very slow, so are trying to split the compiled subclasses across
> >> multiple dlls to indicate progress between the loading of these dlls.
> >>
> >> However, when trying to compile a partial list of types we get the
> >> following error:
> >>
> >> Traceback (most recent call last):
> >>   File "c:\buildshare\gitrepo\precompile_subclasses.py", line 40, in
> >> c:\buildsha
> >> re\gitrepo\precompile_subclasses.py
> >> TypeError: : can only extend one CLI or builtin type, not both
> >> Microsoft.Scripti
> >> ng.Runtime.Extensible`1[[System.Double, mscorlib, Version=2.0.0.0,
> >> Culture=neutr
> >> al, PublicKeyToken=b77a5c561934e089]] (for
> >> IronPython.Runtime.Types.PythonType)
> >> and IronPython.Runtime.SetCollection (for
> >> IronPython.Runtime.Types.PythonType)
> >>
> >>
> >> Any help is much appreciated,
> >> Tom
> >> ___
> >> 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] IPY and multitasking

[Dino Viehland]

You're only using 1 ScriptEngine class?  That should be fine based upon 
the code below but I just want to make sure I understand the scenario.

Is citypay.utils being ran multiple times when you run the code in the
multi-threaded scenario?  If you have a console app you could put a 
print statement in utils.py to see if it's getting executed multiple
times.  If it's not a console app you could put some other logging
into it.  Executing Struct's definition multiple times might cause 
the exceptions you're seeing but I don't know why it would get executed
multiple times.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Pavel Suhotyuk
> Sent: Thursday, November 12, 2009 7:23 AM
> To: Discussion of IronPython
> Subject: [IronPython] IPY and multitasking
> 
> I have this collection of methods:
> ---
> ---
> public static class IronPythonHelper
> {
>  public static ScriptEngine
> CreateScriptEngine(IEnumerable paths)
>  {
>  var langSetup = ScriptRuntimeSetup.ReadConfiguration();
>  var engine = new
> ScriptRuntime(langSetup).GetEngine("IronPython");
>  var path = engine.GetSearchPaths();
>  path.Extend(paths);
>  engine.SetSearchPaths(path);
>  engine.Execute("import citypay", engine.Runtime.Globals);
>  engine.Execute("import cPickle", engine.Runtime.Globals);
>  engine.Execute("from citypay.utils import Struct",
> engine.Runtime.Globals);
>  return engine;
>  }
> 
>  public static object PackParams(ScriptEngine engine,
> IDictionary param)
>  {
>  var scope = engine.CreateScope();
>  engine.Execute("from citypay.utils import Struct", scope);
>  engine.Execute("def pack( params ) : return
> Struct(**dict(params))", scope);
>  var pack = scope.GetVariable object>, object>>("pack");
>  return pack(param);
>  }
> 
>  public static byte[] CPickleSerialize(ScriptEngine engine,
> object obj)
>  {
>  var scope = engine.CreateScope();
>  engine.Execute("import cPickle", scope);
>  engine.Execute("def serialize( obj ) : return
> cPickle.dumps( obj )", scope);
>  var serialize = scope.GetVariable string>>("serialize");
>  return Encoding.Unicode.GetBytes(serialize(obj));
>  }
> }
> ---
> ---
> I have base class used for create needed Engine and Scope as:
> ---
> ---
> public absract class SripterBase {
>  private static readonly ScriptEngine engine =
> IronPythonHelper.CreateScriptEngine(Settings.Default.PythonLibPaths.Cas
> t());
> 
>  ...
> }
> ---
> ---
> My problem in next: Scripter based classes can be created in many
> threads in one time.
> Scripter class used for get pickle'd data by CPickleSerialize(), from
> something like:
> ---
> ---
> class Struct ( object ) :
> 
>  def __init__ ( self, **kwds ) :
>  for name, val in kwds.iteritems() :
>  setattr( self, name, val )
> 
>  def _update ( self, **kwds ) :
>  for name, val in kwds.iteritems() :
>  setattr( self, name, val )
> 
>  def _enum ( self ) :
>  return [( a, getattr( self, a ) ) for a in dir( self ) if
> a.find( '__' ) == -1 and not a.startswith( '_' )]
> 
>  def __repr__ ( self ) :
>  return '' % ' '.join( [ '%s=%s' % ( str(
> n
> ), repr( v ) ) for n, v in self._enum() ] )
> 
>  def __eq__ ( self, other ) :
>  if not isinstance( other, type( self ) ) :
>  return NotImplemented
>  return self._enum() == other._enum()
> ---
> ---
> 
> Multithread code in some (not stable) cases throws 'strange'
> exceptions.
> This problem exists only in multithreaded environment and not exist in
> single thread.
> 
> How I can fix or avoid this problem ?
> 
> 
> usmpsrv1 :: FATAL :: CityPay.Core.Utils.RecursiveException: Recursive
> ended. ---> IronPython.Runtime.Exceptions.ImportException: Cannot
> import
> name Struct
> in IronPython.Runtime.Importer.ImportFrom(CodeContext context,
> Object from, String name)
> in Microsoft.Scripting.Utils.InvokeHelper`4.Invoke(Object arg0,
> Object arg1, Object arg2)
> in
> Microsoft.Scripting.Interpreter.CallInstruction.Run(InterpretedFrame
> frame)
> in
> Microsoft.Scripting.Interpreter.

Re: [IronPython] DLR Hosting, IronPython Engine shutdown issues

[Dino Viehland]

pyEngine.Runtime.Shutdown() is the equivalent.  As far as Python is concerned 
the only interesting thing this does is run sys.exitfunc if it's been set - 
there's some other stuff that happens but it's logging and some cleanup which 
will happen on its own.  So there's no need to really call a Dispose type 
method.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of matan keret
Sent: Friday, November 13, 2009 6:09 AM
To: Discussion of IronPython
Subject: [IronPython] DLR Hosting, IronPython Engine shutdown issues

Hi everyone,

In the old IronPython hosting API there used to be a simple pyEngine.Shutdown() 
command.
And then for cleanup we used: pyEngine.Dispose()

What is the equivalent in the new hosting API's? (am using IronPython 2.0.3)
I found that there is something like: pyEngine.Runtime.Shutdown();

Does that do the same as the old Shutdown() method?
And what can I use instead of the Dispose() command that doesn't seem to exist 
anymore?

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

Re: [IronPython] Embedded IronPython 2.6 Module Name

[Dino Viehland]

I think you now want to do:

  PythonModule pm = new PythonModule();
ScriptEngine se = Python.CreateEngine();
PythonContext pc = (PythonContext) 
HostingHelpers.GetLanguageContext(se);
pc.PublishModule("__main__", pm);

  var modContext = new ModuleContext(pm, pc);

ScriptScope ss = HostingHelpers.CreateScriptScope(se, 
modContext.GlobalScope);
ss.SetVariable("__name__", "__ main__");
ss.SetVariable("__doc__", "");


The change here is to create a ModuleContext which will let you then get the 
Scope.

I agree this has gotten worse in 2.6 - I opened a bug a while ago to make 
working with
modules easier - 
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25190.


> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of jhow...@drawloop.com
> Sent: Tuesday, November 17, 2009 2:02 PM
> To: users@lists.ironpython.com
> Subject: Re: [IronPython] Embedded IronPython 2.6 Module Name
> 
> I realize I'm replying rather late, but I just got to trying this
> again.  This is something that really should be simple.  Anytime a
> module is run from the ScriptEngine directly, I would expect the
> behavior to be running as "__main__" just as if I was running it from
> the command line using "ipy" or "python".  Unfortunately, trying to
> create a module directly doesn't work as far as naming the module.
> Using the following code:
> 
> PythonModule pm = new PythonModule();
> ScriptEngine se = Python.CreateEngine();
> PythonContext pc = (PythonContext)
> HostingHelpers.GetLanguageContext(se);
> pc.PublishModule("__main__", pm);
> ScriptScope ss = HostingHelpers.CreateScriptScope(se, new
> Microsoft.Scripting.Runtime.Scope(pm.Get__dict__()));
> ss.SetVariable("__name__", "__main__");
> ss.SetVariable("__doc__", "");
> 
> doesn't work.  There's no way to directly get the Scope from the
> PythonModule when working this way, as it's been marked as internal.
> Looking through the debugger, the _scope variable that actually holds
> the scope on the PythonModule object is null.  I believe the old
> CreateModule way of doing this would have worked, but there's no way
> to that I've found to do this now.
> 
> At this point, I'm really not sure how 2.6 is being marked as a
> release candidate.
> 
> On an unrelated note, I could, in IronPython 1.1.2 do the following
> code:
> 
> _pyEngine.Execute("python code", _pyEngine.DefaultModule,
> args);
> 
> where "args" is a Dictionary and have those arguments
> passed in to a function call or the like.  Is there any way to do this
> using the new hosting engine?
> 
> Thanks again.
> 
> 
> On Nov 6, 2:18 pm, Curt Hagenlocher  wrote:
> > It looks like you can just create the PythonModule directly now --
> it's a
> > public class with a public constructor.
> >
> > On Thu, Nov 5, 2009 at 12:14 PM, Jonathan Howard
> wrote:
> >
> > > Thanks for the help, Curt.  Perhaps it's a problem with the latest,
> RC?
> > >  There is no "CreateModule" function on the PythonContext object.
> >
> > > ~Jonathan
> >
> > > ___
> > > Users mailing list
> > > us...@lists.ironpython.com
> > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >
> >
> > ___
> > Users mailing list
> >
> us...@lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/user
> s-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] Ability to use CPython csv module

[Dino Viehland]

You could try using CPython's _csv w/ IronClad but other than that we still 
need to implement _csv.

If you, or anyone else, would like to see us hurry up and implement this  
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21395 is the bug 
to vote for.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of William Clifford
Sent: Wednesday, November 18, 2009 10:27 AM
To: users@lists.ironpython.com
Subject: [IronPython] Ability to use CPython csv module

Just curious if anyone has been able to get the CPython csv module to work with 
IronPython (2.6 rc2)? I use csv regularly for my regular python scripts, and I 
am exploring the ability to switch over to IronPython, simply for the ability 
to put together decent GUIs. Not being able to use it throws a major monkey 
wrench into the works.

I have tried doing the following:

C:> set IRONPYTHONPATH=C:\Python26\Lib
C:> ipy
IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.3603
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python26\Lib\csv.py", line 8, in C:\Python26\Lib\csv.py
ImportError: No module named _csv
>>>

Same thing happens with the bsddb module. Now I have looked for anything named 
_csv.* in my python installation and have not found anything like _csv.pyd, 
_csv.dll, etc, so I am assuming that it is not something that should be in the 
PATH / PYTHONPATH / IRONPYTHONPATH folder(s).

Anyone have any idea how to get this to work? Is it something that is simply 
not supported by IronPython?

Thanks in advance

--
William M. Clifford, M.I.T.
william.clifford@gmail.com
Mobile: 954-347-8037
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Embedded IronPython 2.6 Module Name

[Dino Viehland]

The logic for assigning these is definitely a little bit weird.

The theory is that we only assign __name__ if we believe the code
being executed is a module.  This is to mimic the behavior of 
exec/eval which doesn't set __name__:

>>> x = {'__name__':'foo'}
>>> exec 'print "hi"' in x
hi
>>> x['__name__']
'foo'
>>>

So in the 1st two cases the theory is that we're not setting it all.
I suspect in the 1st case though we are actually setting it somewhere
when we create the default scope for executing the code.

The last 2 we believe are modules but we don't have a path for the
source code.  When that happens we set the name to .  I 
believe this is an attempt to match some behavior of CPython but
I can't quite figure out what behavior it is replicating right now.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of jhow...@drawloop.com
> Sent: Tuesday, November 17, 2009 2:31 PM
> To: users@lists.ironpython.com
> Subject: Re: [IronPython] Embedded IronPython 2.6 Module Name
> 
> More specifically, there seems to be four easy ways to execute a
> string of python code.  The following code has the output listed
> below:
> 
> Console.WriteLine(ss.Engine.CreateScriptSourceFromString
> ("__name__", SourceCodeKind.Expression).Execute(ss));
> Console.WriteLine(ss.Engine.CreateScriptSourceFromString
> ("__name__", SourceCodeKind.Expression).Execute());
> Console.WriteLine(ss.Engine.Execute("__name__"));
> Console.WriteLine(ss.Engine.Execute("__name__", ss));
> 
> Output:
> 
> __main__
> __builtin__
> 
> 
> 
> On Nov 17, 2:26 pm, "jhow...@drawloop.com" 
> wrote:
> > Thanks, that gives me at least something.  Any idea why:
> >
> >     ss.Engine.Execute("__name__", ss);
> >
> > returns "" but:
> >
> >     ss.Engine.CreateScriptSourceFromString("__name__",
> > SourceCodeKind.Expression).Execute(ss);
> >
> > returns "__main__"?
> >
> > On Nov 17, 2:12 pm, Dino Viehland  wrote:
> >
> > > I think you now want to do:
> >
> > >               PythonModule pm = new PythonModule();
> > >             ScriptEngine se = Python.CreateEngine();
> > >             PythonContext pc = (PythonContext)
> HostingHelpers.GetLanguageContext(se);
> > >             pc.PublishModule("__main__", pm);
> >
> > >               var modContext = new ModuleContext(pm, pc);
> >
> > >             ScriptScope ss = HostingHelpers.CreateScriptScope(se,
> modContext.GlobalScope);
> > >             ss.SetVariable("__name__", "__ main__");
> > >             ss.SetVariable("__doc__", "");
> >
> > > The change here is to create a ModuleContext which will let you
> then get the Scope.
> >
> > > I agree this has gotten worse in 2.6 - I opened a bug a while ago
> to make working with
> > > modules easier -
> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25190.
> >
> > > > -Original Message-
> > > > From: users-boun...@lists.ironpython.com [mailto:users-
> > > > boun...@lists.ironpython.com] On Behalf Of jhow...@drawloop.com
> > > > Sent: Tuesday, November 17, 2009 2:02 PM
> > > > To: us...@lists.ironpython.com
> > > > Subject: Re: [IronPython] Embedded IronPython 2.6 Module Name
> >
> > > > I realize I'm replying rather late, but I just got to trying this
> > > > again.  This is something that really should be simple.  Anytime
> a
> > > > module is run from the ScriptEngine directly, I would expect the
> > > > behavior to be running as "__main__" just as if I was running it
> from
> > > > the command line using "ipy" or "python".  Unfortunately, trying
> to
> > > > create a module directly doesn't work as far as naming the
> module.
> > > > Using the following code:
> >
> > > >             PythonModule pm = new PythonModule();
> > > >             ScriptEngine se = Python.CreateEngine();
> > > >             PythonContext pc = (PythonContext)
> > > > HostingHelpers.GetLanguageContext(se);
> > > >             pc.PublishModule("__main__", pm);
> > > >             ScriptScope ss = HostingHelpers.CreateScriptScope(se,
> new
> > > > Microsoft.Scripting.Runtime.Scop

Re: [IronPython] poplib.POP3_SSL OutOfMemory Issue

[Dino Viehland]

It might be interesting to run w/ -X:ExceptionDetail to see where the OOM is 
actually coming from.  It could be that there's one giant allocation which is 
failing or it could be that something's broken and causing a big loop which 
allocates forever.  -X:ExceptionDetail might given an indication of which one 
it is.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of matan keret
Sent: Sunday, November 15, 2009 8:34 AM
To: Discussion of IronPython
Subject: [IronPython] poplib.POP3_SSL OutOfMemory Issue

Hi everyone!

i wrote the next code which suppose to go to my hotmail account, fetch the last 
email's image attachment and save it to a file:


import email, poplib, os, string
def get_messages_id(message_list):
items = []
for message in message_list[1]:
message_parts = string.split(message,' ')
message_id = message_parts[0]
items.append(message_id)
#print 'message id is: %s\n' % message_id
#print 'done getting ids'
return items

host = "pop3.live.com"
detach_dir = 'D:\\test-attachments\\'  # directory where to save attachments 
(default: current)
user = "matan...@hotmail.com"
pwd = "0okmnji9"
server = poplib.POP3_SSL(host)
server.user(user)
server.pass_(pwd)

numMessages = len(server.list()[1])
#print numMessages
# server.list() returns messages info from server in
# form of response, message_list, size where message_list
# is. a list of messages in form of 'message_id size'
message_list = server.list()
# get the list of items id
items = get_messages_id(message_list)
items.reverse() # puts the last received mail's id in the first place in list
is_image = False
# find the first mail in items that has an attachment and get the attachment
for emailid in items:
# if we found an email with an image we break
if is_image:
break

total_email_message = server.retr(emailid)[1]
messageText = string.join(total_email_message, "\n")

mail = email.message_from_string(messageText) # parsing the mail content to 
get a mail object

# Check if there are any attachments at all
if mail.get_content_maintype() != 'multipart':
continue

# we use walk to create a generator so we can iterate on the parts
for part in mail.walk():

# skip any attachment which is not an image
if part.get_content_maintype() != 'image':
continue

# is this part an attachment ?
if part.get('Content-Disposition') is None:
continue

filename = part.get_filename()
is_image = True

# if there is no filename, we create one with a counter to avoid 
duplicates
if not filename:
filename = 'part-%03d%s' % (1, 'bin')

att_path = os.path.join(detach_dir, filename)

# Check if its not already there and finally write the file
if not os.path.isfile(att_path) :
fp = open(att_path, 'wb')
fp.write(part.get_payload(decode=True))
fp.close()

# if we found an email with an image we break after first image 
downloaded
if is_image:
break
server.quit()
print 'Finished fetching the image'
# THE END

also available at: http://pastebin.org/53873


This works fine on Cpython but on IronPython 2.0.3 I get:

Traceback (most recent call last):
  File "get_first_attachment.py", line 21, in get_first_attachment.py
  File "D:\IronPython 2.0.3\Lib\poplib.py", line 361, in __init__
  File "D:\IronPython 2.0.3\Lib\poplib.py", line 137, in _getresp
  File "D:\IronPython 2.0.3\Lib\poplib.py", line 374, in _getline
  File "D:\IronPython 2.0.3\Lib\poplib.py", line 364, in _fillBuffer
MemoryError: Exception of type 'System.OutOfMemoryException' was thrown.

this comes out from line 21:

server = poplib.POP3_SSL(host)

Any ideas why is that? How to fix it? Is it a known issue (tried to look but 
couldn't find)?

Thanks,

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

Re: [IronPython] built-in modules

[Dino Viehland]

I started writing up some documentation around this as part of our push to 
actually have useful documentation :)  Here's the current version of that - if 
you have any feedback or additional questions it'd be great to hear to improve 
the docs.

1. Implementing new modules in .NET
When creating a new module usually you would just implement it in IronPython 
its self. But sometimes you may have requirements that preclude implementing it 
in IronPython. These could be due to needing a .NET library which IronPython 
cannot fully or easily consume (because it requires attributes, for example), 
due to performance, or other reasons. When you run into this road block you 
have one of two options.
First, you can simply expose this functionality as a normal .NET library and 
allow the user to interact with it through the normal IronPython .NET interop 
mechanisms. Alternately you can implement a Python module in your favorite .NET 
language. If you're not entirely sure which one to choose you're lucky because 
there's not much difference between the two - but in this section we'll cover 
how to implement a Python module.
The first thing to do is to create a new project, or open an existing one, and 
add a reference to IronPython.dll.
The next step is to define a new class and add an assembly level 
PythonModuleAttribute which points at the class giving the module name and 
type. After doing this you should have a file which looks like:
C# example:
using System;
using IronPython.Runtime;

[assembly: PythonModule("my_module", typeof(MyModule))]

public static class MyModule {
}
VB.NET example:
Imports System
Imports IronPython.Runtime



Public Module MyModule

End Module
Consuming from Python:
>>> import clr
>>> clr.AddReference('test')
>>> import my_module
>From here you just need to start implementing the functionality of your 
>module. You can start to add methods, fields, properties, or types. All the 
>member must be static as there will not be an instance of the module created.
Here's an example where we define a method, a property, and a couple of fields. 
One of the fields is a literal and the other is a static field. One important 
detail to note is that modules are entirely read-only. Even if you implement a 
property or a mutable field IronPython will never set a value into the property 
or field. Instead the updated field will always be stored in the modules 
dictionary.
C# example:
using System;
using IronPython.Runtime;

[assembly: PythonModule("my_module", typeof(MyModule))]

public static class MyModule {
public static void hello_world() {
Console.WriteLine("hello world");
}

public static string foo {
get {
return "foo";
}
}

public const string bar = "bar";

public static readonly string baz = "baz";
}
VB.NET example:
Imports System
Imports IronPython.Runtime



Public Module MyModule
Public Sub hello_world()
Console.WriteLine("Hello World")
End Sub

Public ReadOnly Property foo As String
Get
Return "foo"
End Get
End Property

Public Const bar As String = "bar"

Public ReadOnly baz As String = "baz"
End Module
Consuming from Python:
>>> import clr
>>> clr.AddReference('test')
>>> import my_module
>>> my_module.hello_world()
hello world
>>> my_module.foo
'foo'
>>> my_module.bar
'bar'
>>> my_module.baz
'baz'
1.1. Initialization / Reloading
If your module requires to run specific code to be initialized you can provide 
a method marked with SpecialNameAttribute which receives the PythonContext the 
module is running in as well as the PythonDictionary where the module members 
will live.
This example will make "some_name" available in the module and it will have the 
value "Hello World".
C# example:
using System;
using System.Runtime.CompilerServices;
using IronPython.Runtime;

[assembly: PythonModule("my_module", typeof(MyModule))]

public static class MyModule {
[SpecialName]
public static void PerformModuleReload(PythonContext context, 
PythonDictionary dict) {
dict["some_name"] = "Hello World";
}
}
VB.NET example:
Imports System
Imports IronPython.Runtime
Imports System.Runtime.CompilerServices



Public Module MyModule
 _
Public Sub PerformModuleReload(ByVal context As PythonContext, ByVal dict 
As PythonDictionary)
dict("some_name") = "Hello World"
End Sub
End Module
Consuming from Python:
>>> import clr
>>> clr.AddReference('test')
>>> import my_module
>>> my_module.some_value
'Hello World'
>>>
1.2. Per-Runtime State
Because modules are static classes you need to have somewhere you can store 
state for the current IronPython runtime instance. If you were to store it in a 
static field this state would bleed between IronPython runtimes in the same app 
domain. To accomodate this the PythonContext has a set of APIs which are 
specifically designed for storing state for Python modules. These APIs can be 
used either in the PerformModuleRelo

Re: [IronPython] Memory Leak in IronPython 2.6 RC3

[Dino Viehland]

My guess here (I'm on vacation so I haven't tried this) is that some exception 
info 
is not getting cleared - 

ExceptionHelpers.DynamicStackFrames = null; 

In the catch block will probably fix it although we should probably
do this ourselves.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jonathan Howard
> Sent: Tuesday, November 24, 2009 4:45 PM
> To: users@lists.ironpython.com
> Cc: jfelk...@drawloop.com
> Subject: [IronPython] Memory Leak in IronPython 2.6 RC3
> 
> I'm trying to track down a memory leak in our hosted IronPython
> application as we upgrade to 2.6 from 1.1.2.  I saw a post at
> stackoverflow ( http://stackoverflow.com/questions/1664567/embedded-
> ironpython-memory-leak
> ) showing how to set up the environment to avoid leaking memory, but
> we're still having a memory leak.  If I take our identical setup code,
> and use it on very simple code, there's no problem, but we have
> thousands of lines of Python at this point.
> 
> Below is a minimum way to introduce a memory leak inside a hosted
> IronPython application.  I don't know if it's the only way, or if it's
> what's affecting us, but it does cause a leak:  (Obviously it needs
> the appropriate DLLs etc.)
> 
> #
> 
> using System;
> using System.Threading;
> using IronPython.Hosting;
> using IronPython.Runtime;
> using IronPython.Compiler;
> using System.Collections.Generic;
> using Microsoft.Scripting.Hosting;
> 
> namespace IPyTest
> {
> class Program
> {
> static void Main(string[] args)
> {
> bool cont = true;
> while (cont)
> {
> var ipy = new IPy();
> try
> {
> // Set the below boolean to "false" to run without
> a memory leak
> // Set it to "true" to run with a memory leak.
> ipy.run(true);
> }
> catch { }
> }
> }
> }
> 
> class IPy
> {
> private string scriptWithoutLeak = "import random;
> random.randint(1,10)";
> private string scriptWithLeak = "raise Exception(), 'error'";
> 
> public IPy()
> {
> }
> 
> public void run(bool withLeak)
> {
> //set up script environment
> Dictionary options = new
> Dictionary();
> options["LightweightScopes"] = true;
> ScriptEngine engine = Python.CreateEngine(options);
> PythonCompilerOptions pco = (PythonCompilerOptions)
> engine.GetCompilerOptions();
> pco.Module &= ~ModuleOptions.Optimized;
> engine.SetSearchPaths(new string[]{
> @"C:\Program Files\IronPython 2.6\Lib"
> });
> ScriptRuntime runtime = engine.Runtime;
> ScriptScope scope = runtime.CreateScope();
> var source = engine.CreateScriptSourceFromString(
> withLeak ? scriptWithLeak : scriptWithoutLeak
> );
> var comped = source.Compile();
> comped.Execute(scope);
> runtime.Shutdown();
> }
> }
> }
> ___
> 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] Treat struct as tuple

[Dino Viehland]

You could do something like the code below.  This is an example of an extension 
method on DateTime which enables indexing for read-only access to a couple of 
attributes.  You could also define methods like __iter__ so the iteration will 
work (although it should work w/ just __getitem__), __repr__ so that print will 
work more reasonable, and you should be able to do define "PythonTuple 
ConvertToPythonTuple(Point3D point)" w/ [SpecialName, ImplicitConversionMethod] 
attributes to get the ability to pass to something which expects a tuple.  The 
last one may not work as consistently as one would like though.

using System;
using IronPython.Hosting;
using IronPython.Runtime;
using IronPython.Runtime.Operations;
using Microsoft.Scripting;
using Microsoft.Scripting.Hosting;
using IronPython.Runtime.Exceptions;
using System.Runtime.CompilerServices;
using Microsoft.Scripting.Runtime;

[assembly: ExtensionType(typeof(DateTime), typeof(DateTimeExtensions))]
public class DateTimeExtensions {
[SpecialName, ImplicitConversionMethodAttribute]
public static object __getitem__(DateTime dt, int index) {
switch(index) {
   case 0:
return dt.Hour;
   case 1:
return dt.Second;
   default:
 throw new NotImplementedException();   
}
}
}

class Foo {

private static ScriptEngine pe;
private static ScriptScope scope;

public static void Main(string[] args){

pe = Python.CreateEngine();
pe.Runtime.LoadAssembly(typeof(DateTimeExtensions).Assembly);

scope = pe.CreateScope();
scope.SetVariable("test", DateTime.Now);
pe.Execute(@"print test[0]", scope);

}


}

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Steve Baer
> Sent: Monday, November 30, 2009 10:08 AM
> To: Users@lists.ironpython.com
> Subject: [IronPython] Treat struct as tuple
> 
> Say you have a .NET struct for something like a 3D point
> public struct Point3d
> {
>   private double m_x, m_y, m_z;
>   public double X{ get {return m_x;} set {m_x = value;} }
>   public double Y{ get {return m_y;} set {m_y = value;} }
>   public double Z{ get {return m_z;} set {m_z = value;} }
>   // more functions...
> }
> 
> We have a user that wants to treat this struct like a tuple of 3 values in
> IronPython so he can do things like
> pt = Point3d(1,2,3)
> for a in pt:
>   print a
> -or-
> pass pt to a function that expects a tuple.
> 
> I recommended that the user write a function to coerce the struct to a tuple
> def coerceTuple( pt ):
>   return [pt.X, pt.Y, pt.Z]
> 
> The user said this works, but would like to have something a bit cleaner. Do
> any of you guys suggestions about what I could do to make our Point3d struct
> more "python friendly"?
> 
> Thanks,
> -Steve
> 
> Steve Baer
> Robert McNeel & Associates
> www.rhino3d.com
> www.mcneel.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] v1.1 IronPython.CodeDom.PythonProvider

[Dino Viehland]

Just to comment on this - pyc has always behaved quite differently then how the 
CodeDom compilation support worked.  The CodeCom compilation support in 
particular was a hack so that we could support ASP.NET as it usually behaves.  
It was also fairly buggy and we didn't bring it forward to 2.6.  The big 
difference between the two is that pyc produces code which IronPython can load 
while CodeDom produced a .NET assembly with specific types declared in specific 
namespaces based upon how the code was laid out.  You could then load this 
assembly and instantiate those types and they'd still behave like Python types.

If we brought this back I think we'd want to do a better job on it then we did 
in 1.x and it'd be a fair amount of work.  Feel free to file a feature request 
on CodePlex and have people vote on it if there's general interest in seeing it 
again.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Aravin
Sent: Wednesday, November 25, 2009 8:37 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] v1.1 IronPython.CodeDom.PythonProvider

Hi Owen,
As far as I know if you want to compile a python code you could use: 
clr.CompileModules(...). Or you could use the pyc.py provided in the 
IronPython2.0 Samples download.

ipy.exe pyc.py /main:winforms_hw.py /target:winexe which will produce a 
winforms_hw.dll as well. I'm not sure if you could use these compiles 
assemblies from C# or VB but with Ironpython it should be possible. I'm not 
sure if this is what you were looking for but hope it helps.

Aravin

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Owen Sigurdson
Sent: Wednesday, November 25, 2009 11:23 PM
To: users@lists.ironpython.com
Subject: [IronPython] v1.1 IronPython.CodeDom.PythonProvider

I am attempting to upgrade a component from iron python 1.1 to 2.6 that was 
previously using the PythonProvider to compile python code into a .NET 
assembly.  It looks like this is no longer present in 2.6.  Is this correct?  
Are their any plans to resurrect it?  The biggest difficulty I am facing is not 
that we require the code to be compiled in an assembly but that reflection used 
to return methods in an python class.  Now reflecting on a python class (that 
subclasses a given .NET class) only returns the .NET class members.

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

Re: [IronPython] Memory Leak in IronPython 2.6 RC3

[Dino Viehland]

Glad that worked, I've opened this bug to track fixing this:

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25478


> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jonathan Howard
> Sent: Wednesday, November 25, 2009 9:45 AM
> To: users@lists.ironpython.com
> Subject: Re: [IronPython] Memory Leak in IronPython 2.6 RC3
> 
> That looks like it's removing that memory leak.  I'm not positive
> that's the one we're having in our production code, but it certainly
> can't hurt.
> 
> On Nov 25, 5:37 am, Dino Viehland  wrote:
> > My guess here (I'm on vacation so I haven't tried this) is that some
> exception info
> > is not getting cleared -
> >
> > ExceptionHelpers.DynamicStackFrames = null;
> >
> > In the catch block will probably fix it although we should probably
> > do this ourselves.
> >
> >
> >
> >
> >
> > > -Original Message-
> > > From: users-boun...@lists.ironpython.com [mailto:users-
> > > boun...@lists.ironpython.com] On Behalf Of Jonathan Howard
> > > Sent: Tuesday, November 24, 2009 4:45 PM
> > > To: us...@lists.ironpython.com
> > > Cc: jfelk...@drawloop.com
> > > Subject: [IronPython] Memory Leak in IronPython 2.6 RC3
> >
> > > I'm trying to track down a memory leak in our hosted IronPython
> > > application as we upgrade to 2.6 from 1.1.2.  I saw a post at
> > > stackoverflow (http://stackoverflow.com/questions/1664567/embedded-
> > > ironpython-memory-leak
> > > ) showing how to set up the environment to avoid leaking memory, but
> > > we're still having a memory leak.  If I take our identical setup code,
> > > and use it on very simple code, there's no problem, but we have
> > > thousands of lines of Python at this point.
> >
> > > Below is a minimum way to introduce a memory leak inside a hosted
> > > IronPython application.  I don't know if it's the only way, or if it's
> > > what's affecting us, but it does cause a leak:  (Obviously it needs
> > > the appropriate DLLs etc.)
> >
> > > #
> >
> > > using System;
> > > using System.Threading;
> > > using IronPython.Hosting;
> > > using IronPython.Runtime;
> > > using IronPython.Compiler;
> > > using System.Collections.Generic;
> > > using Microsoft.Scripting.Hosting;
> >
> > > namespace IPyTest
> > > {
> > >     class Program
> > >     {
> > >         static void Main(string[] args)
> > >         {
> > >             bool cont = true;
> > >             while (cont)
> > >             {
> > >                 var ipy = new IPy();
> > >                 try
> > >                 {
> > >                     // Set the below boolean to "false" to run without
> > > a memory leak
> > >                     // Set it to "true" to run with a memory leak.
> > >                     ipy.run(true);
> > >                 }
> > >                 catch { }
> > >             }
> > >         }
> > >     }
> >
> > >     class IPy
> > >     {
> > >         private string scriptWithoutLeak = "import random;
> > > random.randint(1,10)";
> > >         private string scriptWithLeak = "raise Exception(), 'error'";
> >
> > >         public IPy()
> > >         {
> > >         }
> >
> > >         public void run(bool withLeak)
> > >         {
> > >             //set up script environment
> > >             Dictionary options = new
> > > Dictionary();
> > >             options["LightweightScopes"] = true;
> > >             ScriptEngine engine = Python.CreateEngine(options);
> > >             PythonCompilerOptions pco = (PythonCompilerOptions)
> > > engine.GetCompilerOptions();
> > >             pco.Module &= ~ModuleOptions.Optimized;
> > >             engine.SetSearchPaths(new string[]{
> > >                 @"C:\Program Files\IronPython 2.6\Lib"
> > >             });
> > >             ScriptRuntime runtime = engine.Runtime;
> > >             ScriptScope scope = runtime.CreateScope();
> > >             var source = engine.CreateScriptSourceFromString(
> > >                 withLeak ? scriptWithLeak : scriptWithoutLeak
> > >             );
> > >             var comped = source.Compile();
> > >             comped.Execute(scope);
> > >             runtime.Shutdown();
> > >         }
> > >     }
> > > }
> > > ___
> > > Users mailing list
> > > us...@lists.ironpython.com
> > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> > ___
> > Users mailing list
> > us...@lists.ironpython.comhttp://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] Re the The Fifth Assembly post (http://devhawk.net/2008/10/21/The+Fifth+Assembly.aspx)

[Dino Viehland]

How are the assemblies getting loaded here?  Given the error message it seems 
like IronPython or some other DLL is getting loaded in a reflection only 
context.  IronPython and the DLR doesn't ever do that it's probably your own 
code which is doing that.  I would expect if you simply load the 
ExtensionAttribute assembly first (also as reflection only) then you'd be fine.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Owen Sigurdson
Sent: Wednesday, November 25, 2009 7:03 AM
To: users@lists.ironpython.com
Subject: [IronPython] Re the The Fifth Assembly post 
(http://devhawk.net/2008/10/21/The+Fifth+Assembly.aspx)

Hello,

We are experiencing the problem that is mentioned in this post using IronPython 
2.6 RC 2 but are un-able to un-reference the associated assembly.  I am getting 
the following error:

Error  2  Unknown build error, 'Cannot resolve dependency to 
assembly 'Microsoft.Scripting.ExtensionAttribute, Version=2.0.0.0, 
Culture=neutral, PublicKeyToken=null' because it has not been preloaded. When 
using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or 
loaded on demand through the ReflectionOnlyAssemblyResolve event.'

Would anyone have any insight into what is going on here?


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

Re: [IronPython] Compiling .py to .dll to use with Silverlight

[Dino Viehland]

I'm not aware of any working example of this.  In theory you can do it by
hand by just taking the resulting DLL that gets compiled on the desktop
and updating all of the assembly versions to be the Silverlight assembly
versions.  That can be done by sending it through ildasm/ilasm.  You'd
need to update all of the IronPython and DLR assemblies as well as 
mscorlib and System all of which have different versions on Silverlight
vs the desktop CLR.


> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
> Sent: Sunday, November 22, 2009 1:27 PM
> To: Discussion of IronPython
> Subject: [IronPython] Compiling .py to .dll to use with Silverlight
> 
> Hi,
> I'd like to know status of the $subj. I have found some discussions
> (e.g. Michael tried to use pyc or
> http://sdlsdk.codeplex.com/Thread/View.aspx?ThreadId=52207&ANCHOR
> ) but
> no working example - is there any? And if not will be any? :-)
> Thanks.
> 
> --
> -- Lukáš
> 
> ___
> 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] Is it possible to get the DLR's AST when it fails to parse?

[Dino Viehland]

Tokenization would save some work but he could also just use the IronPython
parser.  It's unfortunately a small pain to create (it's overly tied to the
DLR APIs right now) but it's:

return Parser.CreateParser(
new CompilerContext(sourceUnit, new PythonCompilerOptions(), 
ErrorSink.Null),
new PythonOptions()
);

And to get that SourceUnit you can do HostingHelpers.GetSourceUnit on the 
ScriptSource.

The resulting parsed expression will include ErrorExpression's where 
we encounter invalid code.  You may also find that things like class and
function definitions can be missing their names if you are parsing 
incomplete code like "def ".  Then you'll be working on the IronPython AST
instead of the DLR AST (but the two will be the same likely in 
IronPython 2.6.1 - the ASTs are now reducible DLR ASTs).


> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Tuesday, December 01, 2009 4:07 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Is it possible to get the DLR's AST when it fails to
> parse?
> 
> No time for a longer reply, but you probably want to tokenize rather
> than parse.
> 
> Michael
> 
> Lee Culver wrote:
> >
> > I have been playing with an implementation of a simple GUI console for
> > IronPython (similar to IDLE, without it's text-editor IDE). I've
> > mostly brought it up to rough feature parity with IDLE, but I'd like
> > to add a rudimentary itellisense such that when you type something on
> > the order of "foo.", the interpreter can pop up a menu containing the
> > contents of foo (assuming it's something already defined in the local
> > scope). However, I'd really rather not get in the business of parsing
> > Python code. (That's what the DLR is for!)
> >
> > Is there any way I can use DLR to give me the AST up to the point at
> > which it failed to parse so that I can walk that and see if we are in
> > a valid place to look up the fields of an object? I looked at using
> > the ErrorListener class with ScriptSource.Compile, but it only gives
> > me "unexpected  found" at the point where the "." is...which I
> > already knew.
> >
> > Basically, whenever the user presses the "." key in the console what I
> > would like to do is roughly this code:
> >
> > ScriptEngine engine = Python.CreateEngine();
> >
> > ScriptScope scope = engine.CreateScope();
> >
> > ScriptSource source = engine.CreateScriptSourceFromString("if foo.",
> > Microsoft.Scripting.SourceCodeKind.InteractiveCode);
> >
> > source.Compile(); // <-- This *should* fail. I want the AST when it does.
> >
> > Primarily, I'm trying to find chains of identifiers to walk so that I
> > can display the Nth identifier's fields:
> >
> > identifier1 . identifier2 . identifier3 . ...
> >
> > I need to distinguish this from things like this, because there's
> > nothing you can reasonably do to have intellisense in this case:
> >
> > Function(args) . identifier1 . identifier2
> >
> > (Yes, I realize that walking this chain can execute code and have side
> > effects, I'm willing to live with that for my purposes.) Is there any
> > mechanism through which I can have the DLR parse this for me and give
> > me the resulting AST that I can walk so I can see if we can pop up an
> > intellisense-like view?
> >
> > Can anyone recommend a better way to do this outside of simply writing
> > my own mini-parser?
> >
> > Thanks,
> >
> > -Lee Culver
> >
> > 
> >
> > ___
> > Users mailing list
> > Users@lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> 
> 
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
> 
> 
> ___
> 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] Magic methods on CLR types

[Dino Viehland]

If you want IronPython to recognize them you just need to create an assembly w/ 
ExtensionTypeAttribute and have it point at the extended and extending types.  
Then the assembly needs to be loaded into the ScriptRuntime using 
ScriptRuntime.LoadAssembly.

We still need to figure out our story for recognizing and importing normal .NET 
extension methods that C# supports.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeffrey Sax
Sent: Tuesday, December 01, 2009 5:27 PM
To: 'Discussion of IronPython'
Subject: [IronPython] Magic methods on CLR types

Is there a way to add magic methods like __repr__, __call__, etc. to CLR types?


1.   Can it be done in the external CLR assembly without polluting the API 
for other languages? If so, how?

2.   Can it be done using F# style type augmentations by redefining such 
methods on the Python type corresponding to the CLR type? If so, how?

3.   If neither of these alternatives is possible, is there a third way?

Thanks!

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

Re: [IronPython] Magic methods on CLR types

[Dino Viehland]

The reason we don't pick up your __repr__ is we don't expect it to be defined 
on types which aren't marked w/ PythonTypeAttribute.  Therefore we go w/ our 
default implementation.  If you put [PythonType] on it we'll pick it up though. 
 There's 6 other methods which are a little magical like this where we do 
something special before going to reflection (__str__, __new__, __repr__, 
__hash__, __iter__, and __reduce_ex__).  Ideally we should probably hit 
reflection first or make the early resolution something we internally opt-in to.

There's no extensible way to change the type names by extension currently - we 
just have a hard coded table for the 15 types we rename right now.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeffrey Sax
Sent: Wednesday, December 02, 2009 3:14 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Magic methods on CLR types

That works, even for generic types! Thank you.

I did notice that __repr__ (and possibly others) is not picked up unless I add 
ExtensionType attributes for each public subtype of a base type that I'm 
extending. My guess is that IronPython already supplies a default 
implementation for these, so there is no need to look up in the hierarchy. This 
is understandable but somewhat unexpected.

Is there a way to assign Python-friendly names to CLR types by extension? I.e. 
get the same effect as if a PythonTypeAttribute was applied to the original 
class?

Thanks,

Jeffrey

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Tuesday, December 01, 2009 8:57 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Magic methods on CLR types

If you want IronPython to recognize them you just need to create an assembly w/ 
ExtensionTypeAttribute and have it point at the extended and extending types.  
Then the assembly needs to be loaded into the ScriptRuntime using 
ScriptRuntime.LoadAssembly.

We still need to figure out our story for recognizing and importing normal .NET 
extension methods that C# supports.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeffrey Sax
Sent: Tuesday, December 01, 2009 5:27 PM
To: 'Discussion of IronPython'
Subject: [IronPython] Magic methods on CLR types

Is there a way to add magic methods like __repr__, __call__, etc. to CLR types?


1.   Can it be done in the external CLR assembly without polluting the API 
for other languages? If so, how?

2.   Can it be done using F# style type augmentations by redefining such 
methods on the Python type corresponding to the CLR type? If so, how?

3.   If neither of these alternatives is possible, is there a third way?

Thanks!

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

Re: [IronPython] Magic methods on CLR types

[Dino Viehland]

#1 is definitely correct behavior, consider:

IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> class c(object):
... def __getitem__(self, index):
... return index
...
>>> c()[0:1.2]
slice(0, 1.2, None)

It's Python's list implementation which is converting indexes to integers so 
you'll need to do that as well.  You can do that via 
IronPython.Runtime.Converter.ConvertToIndex though.

On #2 in theory we don't let you override existing members w/ extension 
members.  But __getitem__ is taking precedence here because we pick up the 
List version later in resolution via a .NET mapping than looking up members 
by name.  But you can define the integer overload for __getitem__ and forward 
it to the real implementation.

We could also consider just adding slicing support for List to IronPython 
natively :) We probably can't do that for all IList's though in case there's 
one that accepts negative or out of range indexes.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeffrey Sax
Sent: Wednesday, December 02, 2009 5:39 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Magic methods on CLR types

I found 2 issues:

1. It looks like __index__ is not called for slice arguments of non-Python 
objects (like List's). Reading PEP 357 (which introduced __index__), I would 
expect __index__ to always be called, so that I can be sure that the slice 
components are either int, long, or NULL. (I haven't verified this in CPython.)

2. If I supply a  __getitem__ method in my extension type (in my case with a 
strongly typed ISlice parameter), the underlying CLR indexers are no longer 
picked up.

Extender assembly:

[assembly: ExtensionType(typeof(List<>), typeof(ListExtensions<>))]
namespace Compatibility.Python {
public static class ListExtensions {
public static T __getitem__(List a, ISlice slice) {
return a[(int)slice.Start]; // Dummy
}
}
}

IP session 1:
IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> from System.Collections.Generic import List
>>> a=List[int]()
>>> a.Add(55)
>>> a[0]
55
>>> a[0:1.2]
55
>>> b=[1,2,3,4]
>>> b[0:1.2]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: expected index value, got float
>>>

IP session 2:
IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> clr.AddReferenceToFile("Compatibility.Python")
>>> from System.Collections.Generic import List
>>> a=List[int]()
>>> a.Add(55)
>>> a[0]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: expected ISlice, got int
>>>

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Tuesday, December 01, 2009 8:57 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Magic methods on CLR types

If you want IronPython to recognize them you just need to create an assembly w/ 
ExtensionTypeAttribute and have it point at the extended and extending types.  
Then the assembly needs to be loaded into the ScriptRuntime using 
ScriptRuntime.LoadAssembly.

We still need to figure out our story for recognizing and importing normal .NET 
extension methods that C# supports.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeffrey Sax
Sent: Tuesday, December 01, 2009 5:27 PM
To: 'Discussion of IronPython'
Subject: [IronPython] Magic methods on CLR types

Is there a way to add magic methods like __repr__, __call__, etc. to CLR types?


1.   Can it be done in the external CLR assembly without polluting the API 
for other languages? If so, how?

2.   Can it be done using F# style type augmentations by redefining such 
methods on the Python type corresponding to the CLR type? If so, how?

3.   If neither of these alternatives is possible, is there a third way?

Thanks!

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

Re: [IronPython] Magic methods on CLR types

[Dino Viehland]

Yeah, I think I buy your argument on #2.  We'll need to change the way we do 
resolution to make that happen which is a little scary - I'm inclined to say 
it'll have to wait until we either figure out exactly how we support normal 
extension methods or until IronPython 3k when we can make some breaking changes.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeffrey Sax
Sent: Wednesday, December 02, 2009 9:19 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Magic methods on CLR types

#1: Ok. And I just found Converter.ConvertToIndex so it's easy enough to do. 
Great! Thanks.

#2: I think something else is going on. An extension type should not remove 
functionality, which is what is happening here. Consider this:

[assembly: ExtensionType(typeof(Sliceable), typeof(SliceableExtensions))]
namespace Compatibility.Python {
public class Sliceable {
public int this[int index] { get { return index; } }
}
public static class SliceableExtensions {
public static ISlice __getitem__(Sliceable a, ISlice b) { return b; }
}
}

IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> clr.AddReferenceToFile("Compatibility.Python")
>>> from Compatibility.Python import *
>>> s = Sliceable()
>>> s[1]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: expected ISlice, got int
>>> s.Item[2]
2
>>> s.Item[10]
10

There is no IList or anything enumerable, just the indexer method. And it's 
basically hidden by the __getitem__ in the extension type. Item still works, 
because that's a direct reflection of the CLR type.

Adding an extension type to enable standard Python functionality like slicing 
for CLR objects seems like a common scenario that, IMHO, should be properly 
supported, eventually. F# has something similar with type augmentations. Yes, I 
can just create pass-through methods, but in my view that shouldn't be 
necessary. (In F#, it isn't, but then there are other limitations.)

Thanks,

Jeffrey

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Wednesday, December 02, 2009 10:02 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Magic methods on CLR types

#1 is definitely correct behavior, consider:

IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> class c(object):
... def __getitem__(self, index):
... return index
...
>>> c()[0:1.2]
slice(0, 1.2, None)

It's Python's list implementation which is converting indexes to integers so 
you'll need to do that as well.  You can do that via 
IronPython.Runtime.Converter.ConvertToIndex though.

On #2 in theory we don't let you override existing members w/ extension 
members.  But __getitem__ is taking precedence here because we pick up the 
List version later in resolution via a .NET mapping than looking up members 
by name.  But you can define the integer overload for __getitem__ and forward 
it to the real implementation.

We could also consider just adding slicing support for List to IronPython 
natively :) We probably can't do that for all IList's though in case there's 
one that accepts negative or out of range indexes.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeffrey Sax
Sent: Wednesday, December 02, 2009 5:39 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Magic methods on CLR types

I found 2 issues:

1. It looks like __index__ is not called for slice arguments of non-Python 
objects (like List's). Reading PEP 357 (which introduced __index__), I would 
expect __index__ to always be called, so that I can be sure that the slice 
components are either int, long, or NULL. (I haven't verified this in CPython.)

2. If I supply a  __getitem__ method in my extension type (in my case with a 
strongly typed ISlice parameter), the underlying CLR indexers are no longer 
picked up.

Extender assembly:

[assembly: ExtensionType(typeof(List<>), typeof(ListExtensions<>))]
namespace Compatibility.Python {
public static class ListExtensions {
public static T __getitem__(List a, ISlice slice) {
return a[(int)slice.Start]; // Dummy
}
}
}

IP session 1:
IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927
Type "help", "copyright", "credits" or "license" for more information.
>>> from System.Collections.Generic import List
>>> a=List[int]()
>>> a.Add(55)
>>&

Re: [IronPython] Mail archive

[Dino Viehland]

There were some issues w/ DNS over the weekend.  It should be back up now but 
you might need to flush your DNS cache to get up to date info.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Seo Sanghyeon
> Sent: Sunday, December 06, 2009 7:38 PM
> To: Discussion of IronPython
> Subject: [IronPython] Mail archive
> 
> Hi, I can't access the mail archive of this list. URL redirects to
> Bing's search result page. Is it only me? Any idea?
> 
> --
> Seo Sanghyeon
> ___
> 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] [ANN]: IronPython 2.6 final

[Dino Viehland]

Hello Python Community,
We're proud to announce the release of IronPython 2.6 final.  This is a major 
release with improvements across all areas of IronPython and can be downloaded 
from 
http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482.  
Significant changes include:

* Updating the language and standard library to match CPython 2.6

* Improved .NET integration

* Updating to the latest version of the DLR

* Adding previously missing CPython features and fixing bugs

* Performance improvements in particular startup time improvements
Python 2.6 support includes a large number of new features which include 
support for the new bytes and byte array types (PEP 
3112), decorators for classes (PEP 
3129), advanced string formatting 
(PEP 3101) which will feel familiar 
to .NET users and integrates nicely with IFormattable, print as a function (PEP 
3105), Abstract Base Classes (PEP 
3119), support for binary literals, 
along with lots of other minor features and changes.
IronPython also continues to improve .NET integration in this release.  We've 
added the __clrtype__ 
method
 to types which enables deep integration via meta-classes with the .NET type 
system.  There are also a number of smaller changes such as supporting 
IDisposable in for 
loops 
matching the behavior of other .NET languages.  This release also includes the 
latest version of the DLR and fixes a number of issues related to 
cross-language dynamic interop.  Not to be left out there's improvements in 
Silverlight integration by supporting Python code in HTML script 
tags.
We've also continued to improve Python compatibility by adding missing features 
and fixing bugs.  In this release we've added support for the 
ctypes module which provides 
interop with native code in a compatible way across Python implementations.  
We've also implemented sys.settrace to provide support for the 
pdb module and other Python debuggers. 
 This release also changes how we support sys._getframe: a fully working 
version is now available by a command line option;  when not enabled 
sys._getframe doesn't exist at all. This release also fixes over 400 bugs 
removing a large number of smaller incompatibilities.
As always we've also continued to improve performance, and this release 
primarily focuses on improving startup time.  The IronPython installer now 
pre-compiles (ngens) IronPython during installation on both 32-bit and 64-bit 
platforms.  Modules are now interpreted initially and hot functions are 
compiled for faster import times.  A number of other code paths that used to 
involve runtime code generation have been optimized to be contained within the 
pre-compiled IronPython binaries.  We've also made a number of smaller changes 
which improve performance in other areas such as adding constant folding.
Finally we'd like to thank everyone who reported issues and helped make this a 
better release:  Anders M. Mikkelsen, Dan Eloff, Zachc, yamakox, vernondcole, 
VAks, tscottw, tonyandrewmeyer, tomwright, TomasMatousek, tkamiya, timers, 
srivatsn, sopeajw, saveenr, sanxiyn, rridge, ronniemaor, quirogaco, pythonfoo, 
pysunil, pm100, pl6306, paulfelix, orestis, olegt, oldman, NDHUMuscle, mycall, 
mmaly, mmacdonaldssfcu, maplpro, luntain, llaske, lbaker, Lawouach, laurionb, 
laughingboy, kurhan, kuno, kowenswp, klrohe, kevgu, jmesserly, jlunder, 
jdhardy, jbevain, jackeyoo, hhonisch, gz, gjones, fwereade, deadalusai, 
daveremy, Seo Sanghyeon, CurtHagenlocher, chaghi, cgravill, cartman, bobarnso, 
atifaziz, ashcor, alvanet, Helmut, fuzzyman, fabiofz, Eloff, RuiDC, Kevin Chu, 
Kyle Howland-Rose egonw, davec, dungen, dsblank, cjacobs, dmajnemer, leppie, 
Mark Rees, soulfry, tatwright, ufechner and wilberforce.
Thank you for your continued support of IronPython.
The IronPython Team

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

Re: [IronPython] IronPython 2.6 final: Debugging not working?

[Dino Viehland]

There were no changes between RC3 & the final version - the files are
all exactly the same, just now at a new link.  I just ran fc.exe on
both the MSI and the ZIP as downloaded from CodePlex to make sure 
and they're identical.

When you say "re-installed 2.6" do you mean "re-installed 2.6RC3"?  And
that fixed the problem?  What happens if you try installing 2.6 final
again? :)

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Joshua Kramer
> Sent: Saturday, December 12, 2009 1:31 PM
> To: users@lists.ironpython.com
> Subject: [IronPython] IronPython 2.6 final: Debugging not working?
> 
> 
> Hello,
> 
> First - thanks for all the hard work going into 2.6!
> 
> But something appears to have broken between 2.6rc3 and 2.6 final.  In
> Eclipse, using either CPython 2.6.4 or IronPython 2.6rc3, I can debug a
> simple program.  Basically, with a series of 'print' statements I can
> set
> a breakpoint on one in the middle and the program will stop on the
> breakpoint.
> 
> With 2.6 final, the program does not stop on the breakpoints.  I have
> tried setting the Debug perspective manually, and removing the option
> '-X:noframes'.  At first I simply updated 2.6rc3 to 2.6, but after
> seeing
> this I completely un-installed 2.6 and re-installed 2.6.
> 
> Any ideas which bit flipped between 2.6rc3 and 2.6 final?
> 
> Thanks,
> -JK
> 
> ___
> 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] IronPython 2.6 final and net 4

[Dino Viehland]

Do you have .NET 2.0 installed as well as .NET 4.0?  .NET 2.0 and .NET 4.0 are 
side by side releases.  While IronPython built for .NET 2.0 would probably run 
fine on .NET 4.0 we haven't done any testing to make sure that's the case.  
Additionally it would cause a lot of confusion because we have been putting out 
.NET 4.0 compatible releases which use new functionality that we usually ship 
as part of IronPython (Microsoft.Scripting.Core - the portions of the DLR 
shipping in .NET 4.0). Therefore lots of people would probably try and use 
C#/VB.NET's new dynamic support to talk to IronPython and it would fail but it 
wouldn't be entirely obvious why it's not working.

You should just be able to install .NET 2.0 SP1 in addition to 4.0 and things 
should work.

.NET 4.0 is certainly a later version and that's why the message explicitly 
calls out that .NET 4.0 isn't supported :)  It means later in the 2.0/3.0/3.5 
series of runtimes which are all in place upgrades.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of David Waller
Sent: Monday, December 14, 2009 9:47 AM
To: users@lists.ironpython.com
Subject: [IronPython] IronPython 2.6 final and net 4

Hello,
I have been using earlier versions of IronPython 2.6 (not sure exactly which 
version) without any major issues. I have recently tried to install the latest 
2.6 final and it complains about "requires .NET Framework 2.0 SP1 or later. NET 
4.0 is not supported". I have installed .NET 4.0 as part of the Visual express 
2010 software. Is there any way I can convince IronPython to update itself 
without uninstalling the visual express software.
Also isn't .NET 4.0 a later version of .NET 2.0

Thanks
David Waller

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

Re: [IronPython] Users Digest, Vol 65, Issue 16

[Dino Viehland]

Unfortunately it didn't get fixed for 2.6 but we're planning on fixing that for 
2.6.1.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of David Welden
Sent: Monday, December 14, 2009 9:00 AM
To: users@lists.ironpython.com
Subject: Re: [IronPython] Users Digest, Vol 65, Issue 16

Any news on work item 25106: ctypes: no support for Union? ctypes is not really 
done if unions are unsupported.

  1.  [ANN]: IronPython 2.6 final (Dino Viehland)

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

Re: [IronPython] IronPython 2.6 final: Debugging not working?

[Dino Viehland]

I'll have to look into this and get back to you - hopefully I can figure
it out on my side.  There were some threading issues in Beta 2 I believe 
and I thought they were all fixed but maybe there's still something 
lingering.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Joshua Kramer
> Sent: Sunday, December 13, 2009 8:32 PM
> To: users@lists.ironpython.com
> Subject: Re: [IronPython] IronPython 2.6 final: Debugging not working?
> 
> 
> Dino,
> 
> This actually appears to be a threading issue.  While I was filing a bug
> report for PyDev I did further testing.  In three debugging sessions, two
> sessions worked fine with full debugging and one session skipped the
> breakpoints.  Here's a relevant debug log:
> 
> This is where it DOES work:
> 
> pydev debugger: starting
> ('Executing file ', 'C:\\Documents and
> Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py')
> ('arguments:', "['C:Documents and
> SettingsJoshua.KramerworkspaceDebugTestsrcProgram.py']")
> ('Connecting to ', 'localhost', ':', '3416')
> ('Connected.',)
> ('received command ', '501\t1\t1.1')
> ('received command ', '111\t3\tC:\\Documents and
> Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py\t10\t**FUNC**\t
> None')
> sending cmd: CMD_THREAD_CREATE 1032name="pydevd.reader" id="-1"/>
> 
> sending cmd: CMD_VERSION 501  1   1.1
> 
> sending cmd: CMD_THREAD_CREATE 1034name="pydevd.writer" id="-1"/>
> 
> Added breakpoint:c:\documents and
> settings\joshua.kramer\workspace\debugtest\src\program.py - line:10 -
> func_name:
> ('received command ', '101\t5\t')
> hello
> lightbulb
> ('found a new thread ', 'pid264_seq1')
> sending cmd: CMD_THREAD_CREATE 1036name="MainThread" id="pid264_seq1" />
> 
> sending cmd: CMD_THREAD_SUSPEND 105   8id="pid264_seq1" stop_reason="111"> name="%26lt%3Bmodule%26gt%3B" file="c%253A%255Cdocuments and
> settings%255Cjoshua.kramer%255Cworkspace%255Cdebugtest%255Csrc%255Cprogram.py"
> line="10">"
> 
> ('received command ', '114\t7\tpid264_seq1\t43\tFRAME')
> ('processing internal command ', ' at 0x002C>')
> sending cmd: CMD_GET_FRAME 1147name="%24globalContext"
> type="CodeContext" value="CodeContext%253A
> %253CIronPython.Runtime.CodeContext object at 0x002D
> %255BIronPython.Runtime.CodeContext%255D%26gt%3B" isContainer="True"
> />%0A%0A name="functionCode" type="code" value="code%253A %253Ccode object at
> 0x002E%26gt%3B" isContainer="True" />%0A
> 
> This is where it does NOT work:
> 
> pydev debugger: starting
> ('Executing file ', 'C:\\Documents and
> Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py')
> ('arguments:', "['C:Documents and
> SettingsJoshua.KramerworkspaceDebugTestsrcProgram.py']")
> ('Connecting to ', 'localhost', ':', '3422')
> ('Connected.',)
> ('received command ', '501\t1\t1.1')
> ('received command ', '111\t3\tC:\\Documents and
> Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py\t10\t**FUNC**\t
> None')
> sending cmd: CMD_THREAD_CREATE 1032name="pydevd.reader" id="-1"/>
> 
> sending cmd: CMD_VERSION 501  1   1.1
> 
> sending cmd: CMD_THREAD_CREATE 1034name="pydevd.writer" id="-1"/>
> 
> Added breakpoint:c:\documents and
> settings\joshua.kramer\workspace\debugtest\src\program.py - line:10 -
> func_name:
> ('received command ', '101\t5\t')
> hello
> lightbulb
> goodbye
> gobble
> done testing
> 
> How can I further assist?
> 
> Thanks,
> -Josh
> 
> --
> 
> -
> http://www.globalherald.net/jb01
> GlobalHerald.NET, the Smarter Social Network! (tm)
> ___
> 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] IronPython 2.6 final and net 4

[Dino Viehland]

Yes - we've got previews of this already in the form of our IronPython 2.6 CTP 
for .NET 4.0 Beta 2 (and previously beta 1 release).  We are continuing to 
update 2.6 for better .NET 4.0 compatbility and the plan is to ship a 2.6.x 
release in both .NET 2.0 and .NET 4.0 flavors around when .NET 4.0 ships.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Keith J. Farmer
Sent: Monday, December 14, 2009 10:45 AM
To: Discussion of IronPython; Discussion of IronPython
Subject: Re: [IronPython] IronPython 2.6 final and net 4

Is a refresh planned for .NET 4 RTM that won't require the 2.x CLR be installed?


From: users-boun...@lists.ironpython.com on behalf of Dino Viehland
Sent: Mon 12/14/2009 9:57 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 2.6 final and net 4
Do you have .NET 2.0 installed as well as .NET 4.0?  .NET 2.0 and .NET 4.0 are 
side by side releases.  While IronPython built for .NET 2.0 would probably run 
fine on .NET 4.0 we haven't done any testing to make sure that's the case.  
Additionally it would cause a lot of confusion because we have been putting out 
.NET 4.0 compatible releases which use new functionality that we usually ship 
as part of IronPython (Microsoft.Scripting.Core - the portions of the DLR 
shipping in .NET 4.0). Therefore lots of people would probably try and use 
C#/VB.NET's new dynamic support to talk to IronPython and it would fail but it 
wouldn't be entirely obvious why it's not working.

You should just be able to install .NET 2.0 SP1 in addition to 4.0 and things 
should work.

.NET 4.0 is certainly a later version and that's why the message explicitly 
calls out that .NET 4.0 isn't supported :)  It means later in the 2.0/3.0/3.5 
series of runtimes which are all in place upgrades.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of David Waller
Sent: Monday, December 14, 2009 9:47 AM
To: users@lists.ironpython.com
Subject: [IronPython] IronPython 2.6 final and net 4

Hello,
I have been using earlier versions of IronPython 2.6 (not sure exactly which 
version) without any major issues. I have recently tried to install the latest 
2.6 final and it complains about "requires .NET Framework 2.0 SP1 or later. NET 
4.0 is not supported". I have installed .NET 4.0 as part of the Visual express 
2010 software. Is there any way I can convince IronPython to update itself 
without uninstalling the visual express software.
Also isn't .NET 4.0 a later version of .NET 2.0

Thanks
David Waller

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

Re: [IronPython] codecs module in Silverlight

[Dino Viehland]

You could do:

import _codecs
def lookup_error(name):
raise LookupError('unknown error handler')
_codecs.lookup_error = lookup_error


This looks like we've just overly aggressively disabled some functionality
in Silverlight.  Maybe it used to depend upon something that wasn't available
but it doesn't look like it does anymore.  I've opened a bug:

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25673

It should be trivial to fix.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
> Sent: Monday, December 14, 2009 4:56 PM
> To: Discussion of IronPython
> Subject: [IronPython] codecs module in Silverlight
> 
> Hi all,
> I cannot import codecs module in Silverligh IronPython - it throws
> NameError for lookup_error method. The reason is this method is not in
> the _codecs module of Silverlight IronPython:
> 
> dir(_codecs) - Silverlight
> ['__doc__', '__name__', '__package__', 'ascii_decode', 'ascii_encode',
> 'charbuffer_encode', 'charmap_decode', 'charmap_encode', 'decode', 'encode',
> 'escape_decode', 'escape_encode', 'lookup', 'raw_unicode_escape_decode',
> 'raw_unicode_escape_encode', 'readbuffer_encode', 'register',
> 'unicode_escape_decode', 'unicode_escape_encode', 'unicode_internal_decode',
> 'unicode_internal_encode', 'utf_16_be_decode', 'utf_16_be_encode',
> 'utf_16_decode', 'utf_16_encode', 'utf_16_ex_decode', 'utf_16_le_decode',
> 'utf_16_le_encode', 'utf_8_decode', 'utf_8_encode']
> 
> dir(_codecs) - IronPython
> ['__doc__', '__name__', '__package__', 'ascii_decode', 'ascii_encode',
> 'charbuffer_encode', 'charmap_decode', 'charmap_encode', 'decode', 'encode',
> 'escape_decode', 'escape_encode', 'latin_1_decode', 'latin_1_encode',
> 'lookup',
> 'lookup_error', 'mbcs_decode', 'mbcs_encode', 'raw_unicode_escape_decode',
> 'raw_unicode_escape_encode', 'readbuffer_encode', 'register',
> 'register_error',
> 'unicode_escape_decode', 'unicode_escape_encode', 'unicode_internal_decode',
> 'unicode_internal_encode', 'utf_16_be_decode', 'utf_16_be_encode',
> 'utf_16_decode', 'utf_16_encode', 'utf_16_ex_decode', 'utf_16_le_decode',
> 'utf_16_le_encode', 'utf_32_decode', 'utf_32_encode', 'utf_32_ex_decode',
> 'utf_32_le_decode', 'utf_32_le_encode', 'utf_7_decode', 'utf_7_encode',
> 'utf_8_decode', 'utf_8_encode']
> 
> Any idea how to make it work? Thanks.
> 
> --
> -- Lukáš
> 
> ___
> 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] Ironpython 2.6 final and net 4

[Dino Viehland]

Can you look at the value in the registry for HKLM\Software\Microsoft\NET 
Framework Setup\NDP\v2.0.50727 for "Install"?Is it 1?

Also is it 64-bit or 32-bit Vista?

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of David Waller
Sent: Tuesday, December 15, 2009 6:58 AM
To: users@lists.ironpython.com
Subject: Re: [IronPython] Ironpython 2.6 final and net 4

Sorry I wasn't explain enough last time.
I am running Vista and already have .NET 3.5 SP1 installed, as well as the 
current .NET 4.
When I try and install the latest Iron python 2.6 final it complains "requires 
.NET Framework 2.0 SP1 or later. NET 4.0 is not supported".
As I am running Vista I can't install .NET 2.0 SP1 as it is already part of 
Vista.
I already have an earlier version of Iron Python 2.6 and this is what it 
reports when starting up "IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4200"

Thanks
David Waller

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

Re: [IronPython] IPY and multitasking

[Dino Viehland]

Sorry for taking so long on getting back to you on this - PDC and 
Thanksgiving caused this to fall off my radar.

I've taken a look at the repro and ultimately the issues come down
to the fact that we don't have any kind of module importing lock
which is causing things to get imported multiple times.  I'm really
inclined not to fix this the way CPython has (a big importing lock) 
for user defined modules as our users want the ability to import these 
in parallel.  But in your case the problem isn't limited to just user 
defined modules, built in modules are also a problem.  Clearly we 
should make sure each built-in module is only getting loaded once.  
I also think we should probably have some sort of per-file lock so 
that each individual .py file will have its own importing be 
serialized.  

But anyway I was able to make your program work by modifying 
IronPythonHelper.CreateScriptEngine so that it will eagerly import
The things that it needs and then everything else works by adding
this code:

var scope = scriptEngine.CreateScope();
scriptEngine.Execute("from utils import Struct", scope);
scriptEngine.Execute("import cPickle", scope);
scriptEngine.Execute("import copy_reg", scope);

I realize you've opened a DLR bug for this but because this is an
IronPython bug I've gone ahead and opened an issue in our tracker:

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25700

The DLR issue will probably get closed soon.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Pavel Suhotyuk
> Sent: Friday, November 13, 2009 1:01 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IPY and multitasking
> 
> I'm prepare simple test for problem demonstration.
> http://files.roinet.net/DLRTest.zip
> 
> Module utils imported 6-7 times on 2x Dual-Core Opteron 2216 machine,
> but method IronPythonHelper.CreateScript() called one time. On Core 2
> Quad this problem has detected 4 times. On Core 2 Duo problem has not
> detected.
> 
> In file out.txt console output with exceptions and logging information.
> 
> Dino Viehland wrote:
> > You're only using 1 ScriptEngine class?  That should be fine based upon
> > the code below but I just want to make sure I understand the scenario.
> >
> > Is citypay.utils being ran multiple times when you run the code in the
> > multi-threaded scenario?  If you have a console app you could put a
> > print statement in utils.py to see if it's getting executed multiple
> > times.  If it's not a console app you could put some other logging
> > into it.  Executing Struct's definition multiple times might cause
> > the exceptions you're seeing but I don't know why it would get executed
> > multiple times.
> >
> > ___
> > 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] Disappointed

[Dino Viehland]

I've opened bugs for both of these issues:

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25708
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25709

These are both just oversights.  The tests for ctypes and winreg
both aren't exhaustive so the more real world use cases and tests
we can get to throw at these the better they'll get over time.

As for a non-trivial working program it certainly is possible. But
Python and its libraries are large and sometimes it requires some
iteration to either fix bugs in IronPython or make changes to the
program for things like Unicode-only strings.  We do try to be
extremely responsive on fixing bugs that block real world programs
from working unmodified.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Thomas Heller
> Sent: Thursday, December 17, 2009 1:13 AM
> To: Discussion of IronPython
> Subject: [IronPython] Disappointed
> 
> I was excited to see that the latest IronPython release contains
> ctypes, so I was
> tempted to try it out.  This is the first time I use IronPython.
> 
> However, soon came frustration.
> 
> ctypes.wintypes is missing, copying the Python 2.6 ctypes\wintypes.py
> into place
> doesn't make it work either:
> 
> c:\>ipy -c "import ctypes.wintypes"
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "c:\Programme\IronPython 2.6\Lib\ctypes\wintypes.py", line 23,
> in c:\Programme\IronPython 2.6\Lib\ctypes\wintypes.py
> NotImplementedError: simple type v
> c:\>
> 
> The same NotImplementedError is raised when I try to import comtypes,
> which uses this code:
> 
> class BSTR(_SimpleCData):
> "The windows BSTR data type"
> _type_ = "X"
> ...
> 
> Ok.  Gave up trying out ctypes.  Tried to run other scripts that I have
> written.  Snippet from that:
> 
> """
> import _winreg
> 
> def QueryValue(hkey, valuename, default=0):
> if hkey is None:
> return default
> try:
> return _winreg.QueryValue(hkey, valuename)
> except WindowsError, detail:
> if detail.errno == 2:
> return default
> raise
> """
> 
> Doesn't work either.  WindowsError is raised, but detail.errno is None,
> detail.winerror also.
> 
> 
> Is there any chance of running a working, nontrivial CPython program
> with
> IronPython?
> 
> Are the above problems oversights? Missing features?
> 
> --
> Thanks,
> Thomas
> ___
> 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] x = unicode(someExtendedUnicodeString) fails.

[Dino Viehland]

This is one of those bugs that it's simply not clear that it can be fixed at 
all.  The problem is that we have four different things to try and be 
compatible with:

unicode(some_unicode_string)
unicode(some_ascii_string)
str(some_unicode_string)
str(some_ascii_string)

But in IronPython we don't know whether some_*_string is Unicode or ASCII 
because they're always Unicode.  We also don't know if we're calling unicode or 
str because they're also the same thing.   So we have 4 possible behaviors in 
CPython but there can only be 1 behavior in IronPython.  Ultimately we need to 
pick which behaviors we want to be incompatible with :(  Maybe now that we have 
bytes we should look at changing which one we picked so that if you replace str 
with bytes we could match CPython.  But most likely this problem, and other 
subtle Unicode issues like it, won't be completely solvable until IronPython 3k.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Vernon Cole
Sent: Thursday, December 17, 2009 11:06 AM
To: Discussion of IronPython
Subject: [IronPython] x = unicode(someExtendedUnicodeString) fails.

I just tripped over this one and it took some time to figure out what in blazes 
was going on. You may want to watch for it when porting CPython code.

I was cleaning up an input argument using
 s = unicode(S.strip().upper())
where S is the argument supplying the value I need to convert.

When I handed the function a genuine unicode string, such as in:
 assert Roman(u'\u217b') == 12 #unicode Roman number 'xii' as a single 
charactor
IronPython complains with:
UnicodeEncodeError: ('unknown', '\x00', 0, 1, '')

The Python manual says:
If no optional parameters are given, unicode() will mimic the behaviour of 
str() except that it returns Unicode strings instead of 8-bit strings. More 
precisely, if object is a Unicode string or subclass it will return that 
Unicode string without any additional decoding applied.

It turns out that this was already reported on codeplex as:
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=15372
but the reporting party did not catch the fact that he had located an 
incompatibility with documented behavior.
It has been setting on a back burner for some time.

Others may want to join me in voting this up.  Meanwhile I will add an unneeded 
exception handler to my own code.
--
Vernon Cole
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] How to convert from byte[] to str ?

[Dino Viehland]

We have helpers in PythonOps called MakeByteArray and MakeString which
do the conversion.  To use these from Python you can do:

import clr
clr.AddReference('IronPython')
from IronPython.Runtime.Operations import PythonOps
pickled = PythonOps.MakeString(record.data)


> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of KATO Kanryu
> Sent: Thursday, December 17, 2009 6:30 PM
> To: Discussion of IronPython
> Subject: [IronPython] How to convert from byte[] to str ?
> 
> Hi,
> 
> How to convert from byte[] to str without converted ?
> 
> I'm saveing datas as records to System.Data.SQLite with using cPickle.
> There are defined pickled data column as 'blob' type.
> The cPickle.dumps() outputs as str type.
> When we read 'blob' column as byte[] type.
> cPickle.loads() gets str type, and I must convert from byte[] to str.
> 
> Now I call the following:
> 
> pickled = Encoding.UTF8.GetString(record.data)
> data = cPickle.loads(pickled)
> 
> But, GetString sometimes failed :(
> 
> 
> KATO Kanryu
> ___
> 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] How to convert from byte[] to str ?

[Dino Viehland]

The best reference is probably going to be IronPython.xml which contains 
all of the doc comments pulled out.  Other than that there's not really a 
good reference for these.

And unfortunately it's further complicated  by the fact that some things 
in PythonOps are really pretty static and meant are fine for consumption 
by anyone.  Other things are really just calls that we need to emit from 
generated code and so they need to be somewhere and public.  

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of David McWright
> Sent: Friday, December 18, 2009 9:01 AM
> To: users@lists.ironpython.com
> Subject: Re: [IronPython] How to convert from byte[] to str ?
> 
> Dino,
>Is there somewhere I can find a reference for the other helpers in
> PythonOps?
> 
> Thanks,
> David
> 
> On Dec 17, 9:33 pm, Dino Viehland  wrote:
> > We have helpers in PythonOps called MakeByteArray and MakeString which
> > do the conversion.  To use these from Python you can do:
> >
> > import clr
> > clr.AddReference('IronPython')
> > from IronPython.Runtime.Operations import PythonOps
> > pickled = PythonOps.MakeString(record.data)
> >
> >
> >
> > > -Original Message-
> > > From: users-boun...@lists.ironpython.com [mailto:users-
> > > boun...@lists.ironpython.com] On Behalf Of KATO Kanryu
> > > Sent: Thursday, December 17, 2009 6:30 PM
> > > To: Discussion of IronPython
> > > Subject: [IronPython] How to convert from byte[] to str ?
> >
> > > Hi,
> >
> > > How to convert from byte[] to str without converted ?
> >
> > > I'm saveing datas as records to System.Data.SQLite with using cPickle.
> > > There are defined pickled data column as 'blob' type.
> > > The cPickle.dumps() outputs as str type.
> > > When we read 'blob' column as byte[] type.
> > > cPickle.loads() gets str type, and I must convert from byte[] to str.
> >
> > > Now I call the following:
> >
> > > pickled = Encoding.UTF8.GetString(record.data)
> > > data = cPickle.loads(pickled)
> >
> > > But, GetString sometimes failed :(
> >
> > > KATO Kanryu
> > > ___
> > > Users mailing list
> > > us...@lists.ironpython.com
> > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> > ___
> > Users mailing list
> > us...@lists.ironpython.comhttp://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] Timer constructor fails on float

[Dino Viehland]

There's no overload that takes a float - just overloads that take int, int64, 
and uint32 and TimeSpan objects.  Because there are multiple numeric types we 
can't pick which one is better to call - we lose precision either way.  I would 
recommend:

timer = System.Threading.Timer(_callback, None, int(100.1), 0) # Throws 
exception

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Idan Zaltzberg
Sent: Saturday, December 19, 2009 10:20 PM
To: users@lists.ironpython.com
Subject: [IronPython] Timer constructor fails on float

Hi,
I recently encountered a problem when creating timers.
It seems that creating a timer with a floating point interval or delay throws 
an exception:

>>> def _callback(n): pass
...
>>> timer = System.Threading.Timer(_callback, None, 100, 0) # Works fine
>>> timer = System.Threading.Timer(_callback, None, 100.1, 0) # Throws exception
Traceback (most recent call last):
  File "", line 1, in 
TypeError: expected TimerCallback, got function

How can I solve this?
Thanks.

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

Re: [IronPython] Bug in Ipy 2.6 when pickling exceptions

[Dino Viehland]

CPython does the exact same thing:

Python 2.6.3 (r263rc1:75186, Oct  2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] 
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class my_exc(Exception):
... def __init__(self, message, param):
... super(my_exc, self).__init__(message)
... self.param = param
...
>>>
>>> e = my_exc('message','param')
>>> import pickle
>>> pickle.loads(pickle.dumps(e))
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python26\lib\pickle.py", line 1374, in loads
return Unpickler(file).load()
  File "C:\Python26\lib\pickle.py", line 858, in load
dispatch[key](self)
  File "C:\Python26\lib\pickle.py", line 1133, in load_reduce
value = func(*args)
TypeError: __init__() takes exactly 3 arguments (2 given)
>>>

You can override __reduce_ex__ so that it'll match up with your __init__ method:

class my_exc(Exception):
def __init__(self, message, param):
super(my_exc, self).__init__(message)
self.param = param
def __reduce_ex__(self, protocol):
   return (my_exc, (self.message, self.param))

e = my_exc('message','param')
import pickle
pickle.loads(pickle.dumps(e))

It looks like you should be able to just override __reduce__ but it looks like 
IronPython calls __reduce_ex__ where CPython calls __reduce__ for some reason.  
I've filed that as bug 25731 
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25731



From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Idan Zaltzberg
Sent: Sunday, December 20, 2009 2:57 AM
To: users@lists.ironpython.com
Subject: [IronPython] Bug in Ipy 2.6 when pickling exceptions

Hi,
I'm using IronPython 2.6 final.
When deriving from Exception class, and creating a constructor with a different 
signature (not 1 argument), I get an exception when pickling and unpickling.
Seems like the pickling process "neglects" some of the information so the 
unpickling fails.
This can be reproduced with:

>>> class my_exc(Exception):
... def __init__(self, message, param):
... super(my_exc, self).__init__(message)
... self.param = param
...
>>> e = my_exc('message','param')
>>> import pickle
>>> pickle.loads(pickle.dumps(e))
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Systems\3rd_party\IronPython\2.6\Lib\pickle.py", line 1374, in loads
  File "C:\Systems\3rd_party\IronPython\2.6\Lib\pickle.py", line 858, in load
  File "C:\Systems\3rd_party\IronPython\2.6\Lib\pickle.py", line 1133, in 
load_reduce
TypeError: __init__() takes exactly 3 arguments (2 given)


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

Re: [IronPython] LINQ from IronPython

[Dino Viehland]

Jeff wrote:
> This is one of those things that I've been pondering for a while, so I
> thougt I'd throw it out there and see what everyone else thinks (I
> fully expect to hear that I'm crazy...). I'd like to be able to query
> an existing data model (Entity Framework in this case, but that's not
> important) from IronPython without pulling all of the data to the
> client. By my read there are two necessary things and one nice-to-have
> to enable this.

I'd say this is a pretty good write up of the issues and potential 
solutions.  Not really crazy at all.

> 
> This is just a bunch of random thoughts about how to get LINQ support
> into IronPython; I know nothing about the details of the IronPython
> compiler, so I'm making no assumptions about the difficulty of any of
> this.
> 
> Extension Methods
> --
> The biggest hurdle (but probably the most fruitful) is enabling
> extension methods. Unfortunately, I don't know enough about how
> IronPython looks up methods on .NET classes to know how easy this is,
> so I'll just ramble about possible syntaxes and assume the lookups
> will work.
> 
> The first option is identical to C#:
>from System import Linq# or...
>import System.Linq
> 
> Either form pulls in all extension methods in all public, static types
> in that namespace.
> 
> The second option is similar to C#, but requires knowing the extension
> class as well:
>from System.Linq import Queryable
> 
> This form would only pull in extension methods defined in the Queryable
> class.
> 
> I prefer the second option over the first ('explicit is better than
> implicit'), but both have problems in not being completely clear what
> is happening.
> 
> Another option is to be completely explicit:
>clr.Extend(myObj, System.Linq.Queryable)

Personally I like the 2nd option.  I think only the 2nd and 3rd are
really viable.  The one important thing to keep in mind here is that
importlib may become the default importer in the future.  So any hooks
here need to be based off of the processing of what the import machinery
brings back - not something buried deep in the import machinery.  The 2nd
form means we only need to check the type going back vs. it's entire 
namespace which will be more expensive.

The 3rd option could also be done w/o myObj, e.g. you just say bring
in this type or namespace.  It could also be global (not very nice) or
it could be local to the module like the other forms presumably are.

>From an implementation perspective the real difficulty here is making
our get members be isolated across modules while still enabling sharing
of our cached rules. 

> 
> It's nice and explicit about what is happening, but could get tedious
> quickly.
> 
> Expression Trees (C# lambdas)
> --
> Trying to do
>Queryable.Where(entities.Customers, lambda c: c.Id % 2 == 0))
> gives (not surprisingly)
>The type arguments for method 'Where' cannot be inferred from the
> usage.
> 
> Putting in the generic argument manually
>Queryable.Where[Customer](entities.Customers, lambda c: c.Id % 2 ==
> 0))
> I get (again, not surprisingly)
>`expected Expression[Func[Course, int, bool]], got function`
> 
> So, at the very least lambdas would have to be convertible to
> Expression<> objects. I know the DLR uses expression trees internally,
> but I don't know if they're available at the proper time for that
> conversion to be possible. The type inference doesn't seem anymore
> difficult than what's already done, but who knows...

We certainly have the raw AST available to us at all times except for
when we've pre-compiled code.  We don't expose this directly today just
because it's a big implementation detail to bleed out.  Exposing a 
conversion of functions to Experssion though might be a really good
way to expose it w/o exposing all of the implementation details.

The biggest problem w/ exposing our AST though is can anyone else do
something useful with it?  If they're just going to compile the AST
and run it then that's fine.  But if they want to take the AST and
send it off to the database as a query things aren't going to work
so well at this point simply because they won't recognize the dynamic
nodes.  There's also some situations where we open code to the dynamic
nodes as call sites then things are really confusing.  This may
be fine for this case where the conversion is explicit and the user
can make sure it works.

> 
> Generator Expressions as LINQ exprssions
> --
> With extension methods and expression trees, the Q in LINQ is handled;
> now the LIN ('Language INtegrated') needs to be filled in.
> 
> Most of the LINQ queries I do are of the form:
>from customer in entities.Customers
>where customer.Name == name
>select customer
> 
> This just so happens to look a lot like
>customer for customer in entities.Customers if customer.Name == name
> 
> i.e. a generator expression.
> 
> Generator expressions and LINQ queries have a lot in common - chief
> amongst them is that they're 

Re: [IronPython] LINQ from IronPython

[Dino Viehland]

Keith wrote:
> I greatly prefer the C#-ish import rather than "clr.Extend".  Beyond
> that, explicitly importing the extending class could have benefits that
> were noted back when LINQ was introduced:  it's possible for a single
> namespace to have conflicting extension methods.  The moment there's
> conflict, you lose the extension method syntax.  Therefore, my
> suggestion is for the second method (and not for the IMHO-abused
> "explicit better than implicit" reason people give).
> 
> As for expression trees:  I wouldn't expose the DLR's AST.  Instead, I
> would expose the same trees that C# and VB expose.  The reason being,
> of course, is that these would be what mainstream LINQ implementations
> would target, LINQ to SQL in particular.  For the most part, that
> should be a simple transformation, and could be performed at runtime.
> That is, implicitly replace a call:
> 
>   MethodExpectingExpressionOfFunc(lambda x: x.Foo + x.Bar)
> 
> with
> 
>   MethodExpectingExpressionOfFunc(DlrToClrExpressionConverter(lambd
> a x: x.Foo + x.Bar))

Assuming this is DlrToClrExpressionConverter is converting the expression
tree and not a call in the produced expression tree the difficulty is
performing the type inference of the expression tree.  In this case 
presumably the conversion to Expression informs us of the type of
x.  From there we could know that it did indeed have Foo and Bar properties
and those were of some addable type.  And so we could probably produce
a valid expression tree.  Not exactly a "simple transformation" but 
we could probably usually pull it off for code like this.  I'm not sure
how predictable it would be when we could or couldn't pull it off though.




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

Re: [IronPython] LINQ from IronPython

[Dino Viehland]

Jeff wrote:
> I would guess that most of those lambdas are going to be fairly
> simple, and hopefully easy to type-infer. For ones that aren't
> inferable, the best option would be to give an error.
> 
> Given:
> id = 1
> customers.Where(lambda c: c.Id == id)
> 
> Would IronPython be able to know that the type of `id` is `int` at the
> appropriate stage of the compiler? Presumably, because it would have
> to know the type of `customers` (and thus `c`) to even apply the
> extension methods. Would it even have to know the type of `id` to
> construct the proper expression tree, given that it knows the type of
> `c`?
> 
> This rabbit hole goes surprisingly deep! No wonder you haven't tackled
> it yet.

We would know customers when we bind the GetMember and find the extension
method.  That'd give us a method Where which is actually:

Queryable.Where[Customer](IQueryable[Customer], Expression>)

Then when we invoke that we would know what we're converting the lambda to and 
that its signature needs to take a Customer.  That's when any type inference 
over
the lambda would kick in.  I think our existing type inference would be pretty 
close
to getting that right, we just need to look for Expression in addition to
delegate types.  

So that gives us c.Id's type and you could imagine that we then require the 
LHS & RHS types for equality to line up.  Another option is that we might 
be able to generate code that looks something like:

if (id is int) {
return c.Id == (int)id;
} else {
return Expression.Equal(c.Id, id, PythonOps.EqualRetBool(c.Id, 
id));
}

The equality here is something that might pass over the wire fine as this is
a pattern that existed in expression trees V1.  All of the dynamic stuff would
be hidden in the EqualRetBool call and hopefully we'd just never hit that
code path.  But even if we did it might just get interpreted as equality instead
of a method call.

The really interesting thing to me is that this is a closure - either id is in
a nested function scope or it's in a global scope.  I'm not sure how that gets
transmitted across the wire.  Do closures work in LINQ in C# going across to
a database?
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Memory leaks in Ipy 2.6

[Dino Viehland]

This is definitely a bug - we're leaking our stack frames on the CLR's 
finalizer thread when we swallow exceptions while closing the generator.  I 
think this is the correct fix but I haven't fully tested it yet, in our 
generator we have the code below but it's missing the assignment of null to 
DynamicStackFrames:

try {
@throw(new GeneratorExitException());

// Generator should not have exited normally.
throw new RuntimeException("generator ignored GeneratorExit");
} catch (StopIterationException) {
// Ignore
ExceptionHelpers.DynamicStackFrames = null;  // adding this 
fixes it
} catch (GeneratorExitException) {
// Ignore
ExceptionHelpers.DynamicStackFrames = null; // adding this 
fixes it
}

This definitely fixes 1 and 2.  After running this 3 doesn't actually seem to 
leak memory when running repeatedly for me but after-before > 10 is True.  I'll 
take a closer look and make sure this is the correct fix after the new year 
when I'm back in the office.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Idan Zaltzberg
Sent: Monday, December 28, 2009 10:33 AM
To: users@lists.ironpython.com
Subject: [IronPython] Memory leaks in Ipy 2.6

Hi,
Working with the new version I have encountered some problems which look like 
memory leaks to me.
I've written 3 test methods that reproduce the problems, and would appreciate 
your response.
Thanks
Problem 1
Occurs when you do the all of the  following

1.   Define a generator method

2.   Insert a try/except clause in the method

3.   define an inner method that uses some local variable

4.   Call the generator method without reaching the "StopIteration"
Looks like the local variable used by the inner method is never cleared.
This code reproduces the problem:
def test_generator_memory_leak(self):
"""
   Ipy 2.6 This test reproduces a memory leak when calling a 
generator method without reaching the end.
"""
def coroutine():
try: pass
except: pass
just_numbers = range(1,1000)
def inner_method():
return just_numbers
yield None
yield None

from System import GC
def get_memory():
for _ in xrange(4):
GC.Collect()
GC.WaitForPendingFinalizers()
return GC.GetTotalMemory(True)/1e6
before = get_memory()
for j in xrange(1):
crt = coroutine()
crt.next()
after = get_memory()
self.assert_(after-before > 10,'There should be a memory leak 
in this case.before=%s after=%s' % (before,after))

Problem 2
The same as problem, just instead of defining an inner method, just call "eval" 
with any string
 def test_generator_memory_leak2(self):
"""
   Ipy 2.6 This test reproduces a memory leak when calling a 
generator method without reaching the end.
"""
def coroutine(b_bool):
try: pass
except: pass
if False: eval("")

just_numbers = range(1,1000)
yield None
yield None

from System import GC
def get_memory():
for _ in xrange(4):
GC.Collect()
GC.WaitForPendingFinalizers()
return GC.GetTotalMemory(True)/1e6
before = get_memory()
for j in xrange(1):
crt = coroutine(False)
crt.next()

after = get_memory()
self.assert_(after-before > 10,'There should be a memory leak 
in this case.before=%s after=%s' % (before,after))

Problem 3
This is actually a our solution to problems 1,2. We noticed that if we end the 
iteration by using "throw" then the memory doesn't rise on subsequent 
instances. Still there some memory increase that depends on the size of the 
local variable which doesn't seem to go away:

 def test_generator_memory_leak2(self):
"""
   Ipy 2.6 when exiting a generator method with an exception, 
some objects are never collected
   This seems to be static to the type (the leak does not grow 
if we repeat the experiment
"""
def coroutine():
just_numbers = range(1,100)
def inner_method():
return just_numbers
yield

Re: [IronPython] Memory leaks in Ipy 2.6

[Dino Viehland]

2.6.1 is when it should be fixed which should be sometime early next year.  A 
better workaround might be to avoid try/except in the generator if you can 
refactor that out into its own function.  But if that doesn't work then I also 
think calling close explicitly should avoid it and do so without the cost of 
throwing the exception.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Idan Zaltzberg
Sent: Monday, December 28, 2009 11:52 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Memory leaks in Ipy 2.6

Thanks for the fast reply.
Could you estimate when and how (in what version) the fix will be deployed?
Regardless, our current fix is to "throw" exception when we want the generator 
to be disposed and catch it ourselves, is that the right way to go?

From: 
users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> 
[mailto:users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com>]
 On Behalf Of Dino Viehland
Sent: Monday, December 28, 2009 9:47 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Memory leaks in Ipy 2.6

This is definitely a bug - we're leaking our stack frames on the CLR's 
finalizer thread when we swallow exceptions while closing the generator.  I 
think this is the correct fix but I haven't fully tested it yet, in our 
generator we have the code below but it's missing the assignment of null to 
DynamicStackFrames:

try {
@throw(new GeneratorExitException());

// Generator should not have exited normally.
throw new RuntimeException("generator ignored GeneratorExit");
} catch (StopIterationException) {
// Ignore
ExceptionHelpers.DynamicStackFrames = null;  // adding this 
fixes it
} catch (GeneratorExitException) {
// Ignore
ExceptionHelpers.DynamicStackFrames = null; // adding this 
fixes it
}

This definitely fixes 1 and 2.  After running this 3 doesn't actually seem to 
leak memory when running repeatedly for me but after-before > 10 is True.  I'll 
take a closer look and make sure this is the correct fix after the new year 
when I'm back in the office.

From: 
users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> 
[mailto:users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com>]
 On Behalf Of Idan Zaltzberg
Sent: Monday, December 28, 2009 10:33 AM
To: users@lists.ironpython.com<mailto:users@lists.ironpython.com>
Subject: [IronPython] Memory leaks in Ipy 2.6

Hi,
Working with the new version I have encountered some problems which look like 
memory leaks to me.
I've written 3 test methods that reproduce the problems, and would appreciate 
your response.
Thanks
Problem 1
Occurs when you do the all of the  following

1.   Define a generator method

2.   Insert a try/except clause in the method

3.   define an inner method that uses some local variable

4.   Call the generator method without reaching the "StopIteration"
Looks like the local variable used by the inner method is never cleared.
This code reproduces the problem:
def test_generator_memory_leak(self):
"""
   Ipy 2.6 This test reproduces a memory leak when calling a 
generator method without reaching the end.
"""
def coroutine():
try: pass
except: pass
just_numbers = range(1,1000)
def inner_method():
return just_numbers
yield None
yield None

from System import GC
def get_memory():
for _ in xrange(4):
GC.Collect()
GC.WaitForPendingFinalizers()
return GC.GetTotalMemory(True)/1e6
before = get_memory()
for j in xrange(1):
crt = coroutine()
crt.next()
after = get_memory()
self.assert_(after-before > 10,'There should be a memory leak 
in this case.before=%s after=%s' % (before,after))

Problem 2
The same as problem, just instead of defining an inner method, just call "eval" 
with any string
 def test_generator_memory_leak2(self):
"""
   Ipy 2.6 This test reproduces a memory leak when calling a 
generator method without reaching the end.
"""
def coroutine(b_bool):
try: pass
except: pass
if False: eval("")

Re: [IronPython] can't execute method in globals

[Dino Viehland]

What is "gs" in InitDbUtils, should that be gl?

Also can you include the line of code where you're actually executing 
the code from your host?  Are you setting ScriptRuntime.Globals to 
_scriptScope?  Because I think Globals may have changed meaning between 
1.1 and 2.0/2.6.  In 2.x Globals is made available via imports but I don't
remember how it was exposed in 1.1.  I think what you want to do is call the 
Execute overload that takes a ScriptScope and pass in _scriptScope.   
Alternately you want to create a ScriptSource, Compile it, and then Execute 
it against the _scriptScope.  But it's hard to tell w/o the full context.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Ernesto Cullen
> Sent: Tuesday, January 05, 2010 11:25 AM
> To: users@lists.ironpython.com
> Subject: [IronPython] can't execute method in globals
> 
> hi all
>  I have problems trying to update (from Ipy 1.1) code which uses
> IronPython scripts from an app in C#. If someone can shed a light on why
> this does not work, please...
> 
> Ernesto Cullen
> 
> 
> I have this code in Ipy 1.1:
> 
> EngineOptions engineOptions = new EngineOptions();
> engineOptions.ExceptionDetail = true;
> engineOptions.ClrDebuggingEnabled = true;
> engineOptions.ShowClrExceptions = true;
> _pythonEngine = new PythonEngine(engineOptions);
> 
> _pythonEngine.Globals["DbUtils"] = new DbUtils(); //class with db
> methods like ExecuteQuery
> ...
> 
> Then I execute a script like this
> 
> MSSqlServerUtils.py
> def InitDbUtils():
>gl = globals()
>dbu = gs["DbUtils"]
>gl["ExecuteQuery"] = lambda q: dbu.ExecuteQuery(q)
> ...
> InitDbUtils()
> 
> dbInfo = ExecuteQuery("SELECT ISNULL(SERVERPROPERTY('InstanceName'),'')
> instanceName")  # (*)
> ...
> 
> This works in Ipy 1.1, the query is executed, and returns a DataTable
> from the ExecuteQuery method of DbUtils class.
> 
> In Ipy 2.6 I changed the initialization:
> _scriptEngine = Python.CreateEngine(options); //options is a
> Dictionary
> _scriptScope = _scriptEngine.CreateScope();
> _scriptScope.SetVariable("DbUtils", new DbUtils());
> ...
> and when the (*) line is reached, an exception is thrown:
> 
> 'MSSqlServerUtils' object has no attribute 'ExecuteQuery'
> at
> IronPython.Runtime.Binding.PythonGetMemberBinder.FastErrorGet`1.GetError(CallS
> ite
> site, TSelfType target, CodeContext context)
> at
> System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite
> site, T0 arg0, T1 arg1)
> at $3.$1204(PythonFunction $function, Object
> q) in DbUtils.py:line 11
> at IronPython.Runtime.PythonFunction.FunctionCaller`1.Call1(CallSite
> site, CodeContext context, Object func, T0 arg0)
> at
> System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite
> site, T0 arg0, T1 arg1, T2 arg2)
> at $4.__init__$1243(PythonFunction $function, Object self)
> in MSSQLServer.py:line 157
> at IronPython.Runtime.PythonFunction.FunctionCaller`1.Call1(CallSite
> site, CodeContext context, Object func, T0 arg0)
> at
> System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite
> site, T0 arg0, T1 arg1, T2 arg2)
> at CallSite.Target(Closure , CallSite , CodeContext , Object )
> at
> System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite
> site, T0 arg0, T1 arg1)
> at CallSite.Target(Closure , CallSite , CodeContext , Object )
> at
> System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite
> site, T0 arg0, T1 arg1)
> at $4.Start$1244(PythonFunction $function) in
> MSSQLServer.py:line 162
> at IronPython.Runtime.PythonFunction.FunctionCaller.Call0(CallSite
> site, CodeContext context, Object func)
> at
> System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite
> site, T0 arg0, T1 arg1)
> at
> Microsoft.Scripting.Interpreter.DynamicInstruction`3.Run(InterpretedFrameframe
> )
> at
> Microsoft.Scripting.Interpreter.Interpreter.RunInstructions(InterpretedFrame
> frame)
> at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
> frame)
> at Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0
> arg0, T1 arg1)
> at IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx)
> at IronPython.Compiler.PythonScriptCode.Run(Scope scope)
> at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope)
> at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope)
> at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink
> errorSink)
> at Microsoft.Scripting.SourceUnit.Execute(Scope scope)
> at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope)
> at Microsoft.Scripting.Hosting.ScriptEngine.Execute(String
> expression, ScriptScope scope)
> 
> --
> Tell me and I forget. Teach me and I remember. Involve me and I learn.
> Benjamin Franklin
> 
> ___
> Users mailing list
> Users@list

Re: [IronPython] can't execute method in globals

[Dino Viehland]

Is there anything different from the code below vs. what you're trying to do?  
Because
this works for me in 2.6.  It would seem like the only possible difference 
(based upon
the error) is that there's some access ExecuteQuery on an MSSqlServerUtils 
object 
which I'm not seeing.  If that's the case it may be that the type is internal or
ExecuteQuery is not a public method on it.  I seem to recall that we've 
tightened up
some member access rules between 1.1 and 2.6.

using System;
using IronPython.Hosting;
using IronPython.Runtime;
using IronPython.Runtime.Operations;
using Microsoft.Scripting;
using Microsoft.Scripting.Hosting;
using IronPython.Runtime.Exceptions;
using System.Runtime.CompilerServices;
using Microsoft.Scripting.Runtime;

public class Foo {
public static void Main(string[] args){

var pe = Python.CreateEngine();

var scope = pe.CreateScope();
scope.SetVariable("test", new Foo());
pe.Execute(@"
def f():
x = globals()
x[""foo""] = lambda : x[""test""].X()

f()
foo()
", scope);

}

public void X() {
Console.WriteLine("Called");
}   
}


> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Ernesto Cullen
> Sent: Tuesday, January 05, 2010 11:58 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] can't execute method in globals
> 
>  > What is "gs" in InitDbUtils, should that be gl?
> 
> yes, sorry
> 
> > Also can you include the line of code where you're actually executing
> > the code from your host?
> The main code (the lambda definitions etc) is executed like this:
> 
> ScriptSource source =
> _scriptEngine.CreateScriptSourceFromString(script_string, file_path,
> SourceCodeKind.Statements);
> source.Execute(_scriptScope);
> 
> then, the main entry point is executed separately:
> 
> _scriptEngine.Execute("Start()", _scriptScope)
> 
> where Start() is a function in MSSqlServerUtils.py.
> 
> > Are you setting ScriptRuntime.Globals to
> > _scriptScope?
> I've tested with and without it, same result
> 
> > Because I think Globals may have changed meaning between
> > 1.1 and 2.0/2.6.  In 2.x Globals is made available via imports but I don't
> > remember how it was exposed in 1.1.  I think what you want to do is call the
> > Execute overload that takes a ScriptScope and pass in _scriptScope.
> > Alternately you want to create a ScriptSource, Compile it, and then Execute
> > it against the _scriptScope.  But it's hard to tell w/o the full context.
> >
> Hope it is clear now. The actual code is pretty big, and it is part of a
> company project so I can't send it fully.
> In essence, what I am trying to do is execute some c# methods from
> python scripts -but don't want to expose the whole class to the scripts,
> only the methods as functions.
> 
> Ernesto
> 
> 
> >> -Original Message-
> >> From: users-boun...@lists.ironpython.com [mailto:users-
> >> boun...@lists.ironpython.com] On Behalf Of Ernesto Cullen
> >> Sent: Tuesday, January 05, 2010 11:25 AM
> >> To: users@lists.ironpython.com
> >> Subject: [IronPython] can't execute method in globals
> >>
> >> hi all
> >>   I have problems trying to update (from Ipy 1.1) code which uses
> >> IronPython scripts from an app in C#. If someone can shed a light on why
> >> this does not work, please...
> >>
> >> Ernesto Cullen
> >>
> >>
> >> I have this code in Ipy 1.1:
> >>
> >> EngineOptions engineOptions = new EngineOptions();
> >> engineOptions.ExceptionDetail = true;
> >> engineOptions.ClrDebuggingEnabled = true;
> >> engineOptions.ShowClrExceptions = true;
> >> _pythonEngine = new PythonEngine(engineOptions);
> >>
> >> _pythonEngine.Globals["DbUtils"] = new DbUtils(); //class with db
> >> methods like ExecuteQuery
> >> ...
> >>
> >> Then I execute a script like this
> >>
> >> MSSqlServerUtils.py
> >> def InitDbUtils():
> >> gl = globals()
> >> dbu = gs["DbUtils"]
> >> gl["ExecuteQuery"] = lambda q: dbu.ExecuteQuery(q)
> >> ...
> >> InitDbUtils()
> >>
> >> dbInfo = ExecuteQuery("SELECT ISNULL(SERVERPROPERTY('InstanceName'),'')
> >> instanceName")  # (*)
> >> ...
> >>
> >> This works in Ipy 1.1, the query is executed, and returns a DataTable
> >> from the ExecuteQuery method of DbUtils class.
> >>
> >> In Ipy 2.6 I changed the initialization:
> >> _scriptEngine = Python.CreateEngine(options); //options is a
> >> Dictionary
> >> _scriptScope = _scriptEngine.CreateScope();
> >> _scriptScope.SetVariable("DbUtils", new DbUtils());
> >> ...
> >> and when the (*) line is reached, an exception is thrown:
> >>
> >> 'MSSqlServerUtils' object has no attribute 'ExecuteQuery'
> >>  at
> >>
> IronPython.Runtime.Binding.PythonGetMemberBinder.FastErrorGet`1.GetError(CallS
> >> ite
> >> site, TSelfType target, CodeContext context)
> >>  at
> >> System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](Ca

Re: [IronPython] can't execute method in globals

[Dino Viehland]

There's no way to do internals visible to w/ dynamic code because we
need to create the assembly at runtime.  You could use the PrivateBinding
option but it'll allow access to any members on all types and also
requires full trust.  I'd suggest just making the type public or alternately
you could inject delegates to private functions into the scope instead.


> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Ernesto Cullen
> Sent: Wednesday, January 06, 2010 5:27 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] can't execute method in globals
> 
> Thanks for the prompt answer! I finally found that the MSSqlServerUtils
> class is internal... changed to public and all worked ok!
> Now I am trying to make the internals visible to the scripts. I tried with
> 
> [assembly:
> InternalsVisibleToAttribute("MyDemoProject,PublicKey=blahblahblah")]
> and
> [assembly:
> InternalsVisibleToAttribute("IronPython,PublicKey=blahblahblah")]
> 
> but it did not succeed... is there a way to make the internals visible
> to the scripts?
> 
> Ernesto
> 
> 
> El 05/01/2010 17:29, Dino Viehland escribió:
> > Is there anything different from the code below vs. what you're trying to
> do?  Because
> > this works for me in 2.6.  It would seem like the only possible difference
> (based upon
> > the error) is that there's some access ExecuteQuery on an MSSqlServerUtils
> object
> > which I'm not seeing.  If that's the case it may be that the type is
> internal or
> > ExecuteQuery is not a public method on it.  I seem to recall that we've
> tightened up
> > some member access rules between 1.1 and 2.6.
> >
> > using System;
> > using IronPython.Hosting;
> > using IronPython.Runtime;
> > using IronPython.Runtime.Operations;
> > using Microsoft.Scripting;
> > using Microsoft.Scripting.Hosting;
> > using IronPython.Runtime.Exceptions;
> > using System.Runtime.CompilerServices;
> > using Microsoft.Scripting.Runtime;
> >
> > public class Foo {
> > public static void Main(string[] args){
> >
> > var pe = Python.CreateEngine();
> >
> > var scope = pe.CreateScope();
> > scope.SetVariable("test", new Foo());
> > pe.Execute(@"
> > def f():
> >  x = globals()
> >  x[""foo""] = lambda : x[""test""].X()
> >
> > f()
> > foo()
> > ", scope);
> >
> > }
> >
> > public void X() {
> > Console.WriteLine("Called");
> > }
> > }
> >
> >
> >
> >> -Original Message-
> >> From: users-boun...@lists.ironpython.com [mailto:users-
> >> boun...@lists.ironpython.com] On Behalf Of Ernesto Cullen
> >> Sent: Tuesday, January 05, 2010 11:58 AM
> >> To: Discussion of IronPython
> >> Subject: Re: [IronPython] can't execute method in globals
> >>
> >>   >  What is "gs" in InitDbUtils, should that be gl?
> >>
> >> yes, sorry
> >>
> >>
> >>> Also can you include the line of code where you're actually executing
> >>> the code from your host?
> >>>
> >> The main code (the lambda definitions etc) is executed like this:
> >>
> >> ScriptSource source =
> >> _scriptEngine.CreateScriptSourceFromString(script_string, file_path,
> >> SourceCodeKind.Statements);
> >> source.Execute(_scriptScope);
> >>
> >> then, the main entry point is executed separately:
> >>
> >> _scriptEngine.Execute("Start()", _scriptScope)
> >>
> >> where Start() is a function in MSSqlServerUtils.py.
> >>
> >>
> >>> Are you setting ScriptRuntime.Globals to
> >>> _scriptScope?
> >>>
> >> I've tested with and without it, same result
> >>
> >>
> >>> Because I think Globals may have changed meaning between
> >>> 1.1 and 2.0/2.6.  In 2.x Globals is made available via imports but I don't
> >>> remember how it was exposed in 1.1.  I think what you want to do is call
> the
> >>> Execute overload that takes a ScriptScope and pass in _scriptScope.
> >>> Alternately you want to create a ScriptSource, Compile it, and then
> Execute
> >>> it against the _scriptScope.  But it's hard to tell w/o the full context.
> >>>

Re: [IronPython] IronPython 2.0.3

[Dino Viehland]

Yep, 2.0.3 is the right version to target for 2.5 compatibility.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Perez, Justin
> Sent: Wednesday, January 06, 2010 6:48 AM
> To: users@lists.ironpython.com
> Subject: [IronPython] IronPython 2.0.3
> 
> Hi.
> 
> I am seemingly locked into Python 2.5 for compatibility with
> requirements from ESRI based products. I am wanting to write some C#
> code (very new to it) and call it from Python.  Should I use IronPython
> 2.0.3?
> 
> The C# interfaces are from GPS Pathfinder Office application.  Hopefully
> I detailed the question sufficiently.  Thanks.
> ___
> 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] IronPython 2.0.3

[Dino Viehland]

Keith wrote:
> I was wondering if it might not be better (even possible) to merge the version
> compatibility into a switch, so people would optionally use a targetVersion
> flag or some-such.
> 
> Part of the difference between versions isn't simply language, it's outright
> bug corrections and compatibility with the base DLR, neh?

To a certain extent this is possible - for example it's not too hard to control
the parser based upon version and enable/disable new features.  Also 
controlling what methods are available and a small subset of behaviors is 
pretty easy and  we've done that in the past when we've had options which 
enable a subset of the  next version - 2.6 for example has a -X:Python30 option
which enables some  3.0 features / compatibility.  

But to do this for an entire versions worth of features might be too many 
random checks spread throughout the code base - usually there are plenty of 
small changes in each release which we need to match.  Things like deprecation 
of various features, object.__new__/__init__ changed in 2.6, methods sometimes 
get new arguments, and other little changes like that.  Dealing with all of 
those 
will be difficult and clutter up the code base making it more difficult to 
maintain.  In some cases we might need to add new features to fully emulate
the old version.

There's also the matter of our own compatibility at the .NET level - we 
constantly need to balance advancing IronPython w/ maintaining compatibility 
w/ existing apps.  Would users upgrade a 2.0.3 app to 2.6 w/ 2.5 compat if 
there are some breaking changes they need to deal with from the C# side?  I 
think a lot of the value in already released versions is their stability
so I'm not sure that having an evolving target which from the Python side
works mostly like the previous version has much value.

Not to mention that it's just plain more work and we already have plenty
to do :)
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IronPython 2.0.3

[Dino Viehland]

The other thing is it's not quite n * m as m for 2.5 is only 1, and it's only
2 for 2.6.  Eventually it'll go back down to 1 again.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Dave Fugate
> Sent: Wednesday, January 06, 2010 11:43 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython 2.0.3
> 
> There's one major benefit of n different IronPython versions though - testing.
> Right now, we run all CPy 2.6 tests for every IronPython (2.6) check-in.  If
> IP 2.6 were to support CPy 2.5 as well, we'd also need to run all CPy 2.5
> tests => the check-in times would nearly double.  Don't even get me started on
> the week of automated tests each major public release of IronPython
> undergoes:)
> 
> Dave
> 
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Keith J. Farmer
> Sent: Wednesday, January 06, 2010 11:21 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython 2.0.3
> 
> Yet you end up (worst case)maintaining nm different versions of the entire
> source, n CPython compats by m NetFX compats?  That's not a great space to be
> in, and then end-users have to hunt for the IronPython version to use, as seen
> here.
> 
> -Original Message-
> From: Dino Viehland 
> Sent: Wednesday, January 06, 2010 10:23
> To: Discussion of IronPython 
> Subject: Re: [IronPython] IronPython 2.0.3
> 
> Keith wrote:
> > I was wondering if it might not be better (even possible) to merge the
> version
> > compatibility into a switch, so people would optionally use a targetVersion
> > flag or some-such.
> >
> > Part of the difference between versions isn't simply language, it's outright
> > bug corrections and compatibility with the base DLR, neh?
> 
> To a certain extent this is possible - for example it's not too hard to
> control
> the parser based upon version and enable/disable new features.  Also
> controlling what methods are available and a small subset of behaviors is
> pretty easy and  we've done that in the past when we've had options which
> enable a subset of the  next version - 2.6 for example has a -X:Python30
> option
> which enables some  3.0 features / compatibility.
> 
> But to do this for an entire versions worth of features might be too many
> random checks spread throughout the code base - usually there are plenty of
> small changes in each release which we need to match.  Things like deprecation
> of various features, object.__new__/__init__ changed in 2.6, methods sometimes
> get new arguments, and other little changes like that.  Dealing with all of
> those
> will be difficult and clutter up the code base making it more difficult to
> maintain.  In some cases we might need to add new features to fully emulate
> the old version.
> 
> There's also the matter of our own compatibility at the .NET level - we
> constantly need to balance advancing IronPython w/ maintaining compatibility
> w/ existing apps.  Would users upgrade a 2.0.3 app to 2.6 w/ 2.5 compat if
> there are some breaking changes they need to deal with from the C# side?  I
> think a lot of the value in already released versions is their stability
> so I'm not sure that having an evolving target which from the Python side
> works mostly like the previous version has much value.
> 
> Not to mention that it's just plain more work and we already have plenty
> to do :)
> ___
> 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] Apparent bug with redirecting output in IronPython 2.6

[Dino Viehland]

It's a bug - thanks for reporting it! I've opened CodePlex issue 25861: 
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25861

It'll be fixed for 2.6.1, we're just grabbing our code context from the wrong 
spot.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Lepisto, Stephen P
Sent: Wednesday, January 06, 2010 1:13 PM
To: Discussion of IronPython
Subject: [IronPython] Apparent bug with redirecting output in IronPython 2.6

Hi,

I've been evaluating a suite of python code originally targeting CPython 2.5 to 
see what needs to be fixed/changed to run under IronPython 2.6.  I ran into a 
problem in IronPython 2.6 where I redirect sys.stdout through a class object 
that forwards output to the original sys.stdout.  When control returns to the 
python command prompt, an exception is displayed in an infinite loop.

If I redirect sys.stderr first (to the same object) before redirecting 
sys.stdout, IronPython 2.6 shows two exception errors then abruptly exits.

Since this particular part of my python code runs fine under CPython 2.5, 2.6 
and IronPython 2.0.3, I'm thinking it may be a bug in IronPython 2.6.

What follows is a reproduction case showing IronPython 2.6 exiting after two 
exceptions.  Note that the redirection is actually working and that the 
exception occurs only when the python console prompt is displayed.

1. Create a file called testredirect.py with the following code:

import sys

class _StreamLog(object):
def __init__(self, ostream):
self.ostream = ostream

def write(self, *args):
self.ostream.write("{")
self.ostream.write(*args)
self.ostream.write("}")

def flush(self):
self.ostream.flush()

if not sys.stderr.__class__ == _StreamLog:
sys.stderr = _StreamLog(sys.stderr)
if not sys.stdout.__class__ == _StreamLog:
sys.stdout = _StreamLog(sys.stdout)

print >> sys.stderr, "Redirected stderr\n"
print >> sys.stdout, "Redirected stdout\n"


2. Open an IronPython 2.6 console and import the testredirect module.  This 
produces the following output:

C:\>ipy
IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>> import testredirect
{Redirected stderr
}{
}{Redirected stdout
}{
}{>>> }{Traceback (most recent call last):
SystemError: Object reference not set to an instance of an object.
}Unhandled exception:
Traceback (most recent call last):
SystemError: Object reference not set to an instance of an object.


4. Rerunning the above test with -X:ExceptionDetail enabled, I get the 
following:

C:\ >ipy -X:ExceptionDetail
IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>> import testredirect
{Redirected stderr
}{
}{Redirected stdout
}{
}{>>> }{Object reference not set to an instance of an object.
   at IronPython.Runtime.OutputWriter.Flush()
   at Microsoft.Scripting.Hosting.Shell.BasicConsole.Write(String text, Style 
style)
   at Microsoft.Scripting.Hosting.Shell.CommandLine.ReadStatement(Boolean& 
continueInteraction)
   at IronPython.Hosting.PythonCommandLine.RunOneInteraction()
   at IronPython.Hosting.PythonCommandLine.TryInteractiveActionWorker()
   at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
   at Microsoft.Scripting.Hosting.Shell.CommandLine.RunInteractiveLoop()
SystemError: Object reference not set to an instance of an object.
}Unhandled exception:
Object reference not set to an instance of an object.
   at IronPython.Runtime.OutputWriter.Flush()
   at Microsoft.Scripting.Hosting.Shell.BasicConsole.Write(String text, Style 
style)
   at Microsoft.Scripting.Hosting.Shell.BasicConsole.WriteLine(String text, 
Style style)
   at IronPython.Runtime.Operations.PythonOps.PrintException(CodeContext 
context, Exception exception, IConsole console)
   at IronPython.Hosting.PythonCommandLine.UnhandledException(Exception e)
   at Microsoft.Scripting.Hosting.Shell.CommandLine.RunInteractiveLoop()
   at IronPython.Hosting.PythonCommandLine.RunInteractive()
   at Microsoft.Scripting.Hosting.Shell.CommandLine.Run()
   at IronPython.Hosting.PythonCommandLine.Run()
   at Microsoft.Scripting.Hosting.Shell.CommandLine.Run(ScriptEngine engine, 
IConsole console, ConsoleOptions options)
   at Microsoft.Scripting.Hosting.Shell.ConsoleHost.RunCommandLine()
SystemError: Object reference not set to an instance of an object.


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

Re: [IronPython] Custom module storage.

[Dino Viehland]

Using Python's import hooks is one way to go and is also nice because 
you can do  it all from Python as well - see PEP 302 which is at
http://www.python.org/dev/peps/pep-0302/.  You can also subclass ScriptHost 
and provide a custom PlatformAdaptionLayer which re-maps file I/O to the 
database.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Suhotyuk Pavel
> Sent: Sunday, January 10, 2010 1:08 PM
> To: Discussion of IronPython
> Subject: [IronPython] Custom module storage.
> 
> Hello.
> 
> I have sql database with sources of python packages and modules. How I
> can run IronPython with custom module storage?
> May I build custom module loader with IronPython.Modules.PythonImport
> or
> DLR and IronPython have some ways for this?
> 
> Thanks.
> ___
> 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] Converting C# to Python ... the lock() keyword?

[Dino Viehland]

If you really want to use .NET monitors you can code it up as a try/finally:

Monitor.Enter(m_object)
try:
if ...:
...
finally:
Monitor.Exit(m_object)

If you'd like to do a slightly more Pythonic lock you could do:

import threading

x = threading.Lock()
with x:
pass

Or you could combine the two approaches:

from System.Threading import Monitor
class ObjectLocker(object):
def __init__(self, obj):
self.obj = obj
def __enter__(self):
Monitor.Enter(self.obj)
def __exit__(self, *args):
Monitor.Exit(self.obj)

with ObjectLocker(object()):
pass



> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Sandy Walsh
> Sent: Monday, January 11, 2010 9:43 AM
> To: users@lists.ironpython.com
> Subject: [IronPython] Converting C# to Python ... the lock() keyword?
> 
> Hi,
> 
> I'm converting a C# program to IronPython and running into the C# lock()
> command ... what is the equivalent operation in IronPython?
> 
> The C# is like:
> 
>   lock(m_object)
>  if (...)
>  {
>   ...
>   }
> 
> Thanks!
> -Sandy

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

Re: [IronPython] Converting C# to Python ... the lock() keyword?

[Dino Viehland]

Correct - threading.Lock is a custom lock implementation (it's also 
non-reentrant)
so if you need to interoperate Monitor is the way to go.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Sandy Walsh
> Sent: Monday, January 11, 2010 10:31 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Converting C# to Python ... the lock() keyword?
> 
> Thanks for the prompt answer Dino.
> 
> The lock is defined in a C# library and I have to access it ... I assume
> Monitor and threading.Lock() are different implementations (specifically, you
> can't mix and match)?
> 
> I can live with the Monitor for now I think.
> 
> Thanks again!
> -Sandy
> 
> 
> On 1/11/2010 2:23 PM, Dino Viehland wrote:
> > If you really want to use .NET monitors you can code it up as a try/finally:
> >
> > Monitor.Enter(m_object)
> > try:
> > if ...:
> > ...
> > finally:
> > Monitor.Exit(m_object)
> >
> > If you'd like to do a slightly more Pythonic lock you could do:
> >
> > import threading
> >
> > x = threading.Lock()
> > with x:
> >  pass
> >
> > Or you could combine the two approaches:
> >
> > from System.Threading import Monitor
> > class ObjectLocker(object):
> >  def __init__(self, obj):
> >  self.obj = obj
> >  def __enter__(self):
> >  Monitor.Enter(self.obj)
> >  def __exit__(self, *args):
> >  Monitor.Exit(self.obj)
> >
> > with ObjectLocker(object()):
> >  pass
> >
> >
> >
> >
> >> -Original Message-
> >> From: users-boun...@lists.ironpython.com [mailto:users-
> >> boun...@lists.ironpython.com] On Behalf Of Sandy Walsh
> >> Sent: Monday, January 11, 2010 9:43 AM
> >> To: users@lists.ironpython.com
> >> Subject: [IronPython] Converting C# to Python ... the lock() keyword?
> >>
> >> Hi,
> >>
> >> I'm converting a C# program to IronPython and running into the C#
> >> lock() command ... what is the equivalent operation in IronPython?
> >>
> >> The C# is like:
> >>
> >>lock(m_object)
> >>   if (...)
> >>   {
> >>...
> >>}
> >>
> >> Thanks!
> >> -Sandy
> >>
> > ___
> > 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] IronPython 2.6 final: Debugging not working?

[Dino Viehland]

What does program.py look like?  Is it all top-level code or does it also
contain functions and classes?  And are the break points in the top-level
code or are they in functions/classes?  

I ask because I can't seem to hit breakpoints in top-level code at all but
so far I reliably hit them in functions - but that may just be the way the
races are going on my machine.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Joshua Kramer
> Sent: Sunday, December 13, 2009 8:32 PM
> To: users@lists.ironpython.com
> Subject: Re: [IronPython] IronPython 2.6 final: Debugging not working?
> 
> 
> Dino,
> 
> This actually appears to be a threading issue.  While I was filing a bug
> report for PyDev I did further testing.  In three debugging sessions, two
> sessions worked fine with full debugging and one session skipped the
> breakpoints.  Here's a relevant debug log:
> 
> This is where it DOES work:
> 
> pydev debugger: starting
> ('Executing file ', 'C:\\Documents and
> Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py')
> ('arguments:', "['C:Documents and
> SettingsJoshua.KramerworkspaceDebugTestsrcProgram.py']")
> ('Connecting to ', 'localhost', ':', '3416')
> ('Connected.',)
> ('received command ', '501\t1\t1.1')
> ('received command ', '111\t3\tC:\\Documents and
> Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py\t10\t**FUNC**\t
> None')
> sending cmd: CMD_THREAD_CREATE 1032name="pydevd.reader" id="-1"/>
> 
> sending cmd: CMD_VERSION 501  1   1.1
> 
> sending cmd: CMD_THREAD_CREATE 1034name="pydevd.writer" id="-1"/>
> 
> Added breakpoint:c:\documents and
> settings\joshua.kramer\workspace\debugtest\src\program.py - line:10 -
> func_name:
> ('received command ', '101\t5\t')
> hello
> lightbulb
> ('found a new thread ', 'pid264_seq1')
> sending cmd: CMD_THREAD_CREATE 1036name="MainThread" id="pid264_seq1" />
> 
> sending cmd: CMD_THREAD_SUSPEND 105   8id="pid264_seq1" stop_reason="111"> name="%26lt%3Bmodule%26gt%3B" file="c%253A%255Cdocuments and
> settings%255Cjoshua.kramer%255Cworkspace%255Cdebugtest%255Csrc%255Cprogram.py"
> line="10">"
> 
> ('received command ', '114\t7\tpid264_seq1\t43\tFRAME')
> ('processing internal command ', ' at 0x002C>')
> sending cmd: CMD_GET_FRAME 1147name="%24globalContext"
> type="CodeContext" value="CodeContext%253A
> %253CIronPython.Runtime.CodeContext object at 0x002D
> %255BIronPython.Runtime.CodeContext%255D%26gt%3B" isContainer="True"
> />%0A%0A name="functionCode" type="code" value="code%253A %253Ccode object at
> 0x002E%26gt%3B" isContainer="True" />%0A
> 
> This is where it does NOT work:
> 
> pydev debugger: starting
> ('Executing file ', 'C:\\Documents and
> Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py')
> ('arguments:', "['C:Documents and
> SettingsJoshua.KramerworkspaceDebugTestsrcProgram.py']")
> ('Connecting to ', 'localhost', ':', '3422')
> ('Connected.',)
> ('received command ', '501\t1\t1.1')
> ('received command ', '111\t3\tC:\\Documents and
> Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py\t10\t**FUNC**\t
> None')
> sending cmd: CMD_THREAD_CREATE 1032name="pydevd.reader" id="-1"/>
> 
> sending cmd: CMD_VERSION 501  1   1.1
> 
> sending cmd: CMD_THREAD_CREATE 1034name="pydevd.writer" id="-1"/>
> 
> Added breakpoint:c:\documents and
> settings\joshua.kramer\workspace\debugtest\src\program.py - line:10 -
> func_name:
> ('received command ', '101\t5\t')
> hello
> lightbulb
> goodbye
> gobble
> done testing
> 
> How can I further assist?
> 
> Thanks,
> -Josh
> 
> --
> 
> -
> http://www.globalherald.net/jb01
> GlobalHerald.NET, the Smarter Social Network! (tm)
> ___
> 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] IronPython 2.6 final: Debugging not working?

[Dino Viehland]

Thanks! In that case I think I understand what's going on and it should 
be fairly simple to fix.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Joshua Kramer
> Sent: Monday, January 11, 2010 7:57 PM
> To: users@lists.ironpython.com
> Subject: Re: [IronPython] IronPython 2.6 final: Debugging not working?
> 
> 
> "I ask because I can't seem to hit breakpoints in top-level code at all
> but so far I reliably hit them in functions - but that may just be the
> way
> the races are going on my machine."
> 
> That is interesting, Dino.  At first my debug program was five simple
> print statements.  The debug breakpoint was hit approximately 66% of
> the
> time.  In a function, the debug breakpoint was hit 100% of the time,
> and
> the debug breakpoint on the top-level code still only hit 66% of the
> time.
> 
> --
> 
> -
> http://www.globalherald.net/jb01
> GlobalHerald.NET, the Smarter Social Network! (tm)
> ___
> 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] IronPython.Modules.dll bug when access from Delphi

[Dino Viehland]

The attachment was deleted - can you post it somewhere?  For example you could
open a bug on our CodePlex site and attach it.  

Also do you have VisualStudio installed?  If so you could attach the debugger
to your process and send the stack trace of where it's hanging.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
> Sent: Wednesday, January 13, 2010 10:37 AM
> To: Discussion of IronPython
> Subject: [IronPython] IronPython.Modules.dll bug when access from Delphi
> 
> Hi,
> I have almost succesfully managed to access IronPython from Delphi 7 (Win32).
> But I have also encountered a bug connected with IronPython.Modules.dll.
> 
> Here are steps to recreate it:
> 1. Unzip the attached file somewhere
> 2) Put IronPython IronPython-2.6 with IronPython dlls to the same folder (or
> change the path in Host\build.bat)
> 3) Build the host with Host\build.bat
> 4) Run Host\Host.exe - it runs OK
> 5) Run Delphi\IpyTest.exe - it runs OK
> 6) Put IronPython.Modules.dll to Delphi\ folder
> 7) Run Delphi\IpyTest.exe - it freezes. It freezes during creating IronPython
> engine.
> 8) Host\Host.exe runs fine with IronPython.Modules.dll
> 
> I don't know how to debug this problem - can somebody please look at it?
> Thank you.
> 
> --
> -- Lukáš

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

Re: [IronPython] IronPython.Modules.dll bug when access from Delphi

[Dino Viehland]

Ok, Dave was also somehow able to get the attachment and send it to me...



What is IpyTest.exe?  It's a big unmanaged EXE which I'm not inclined to run.



Is this hosting the CLR somehow?  Could you attach the debugger using windbg

which is a free download and get the stack from there?


From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
Sent: Wednesday, January 13, 2010 11:06 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython.Modules.dll bug when access from Delphi

I have created CodePlex issue:
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25933

Unfortunately, I have only VS Express so I cannot attach debugger to a process.

--
-- Lukáš


Dino Viehland wrote:

The attachment was deleted - can you post it somewhere?  For example you could

open a bug on our CodePlex site and attach it.



Also do you have VisualStudio installed?  If so you could attach the debugger

to your process and send the stack trace of where it's hanging.





-Original Message-

From: 
users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> 
[mailto:users-

boun...@lists.ironpython.com<mailto:boun...@lists.ironpython.com>] On Behalf Of 
Lukas Cenovsky

Sent: Wednesday, January 13, 2010 10:37 AM

To: Discussion of IronPython

Subject: [IronPython] IronPython.Modules.dll bug when access from Delphi



Hi,

I have almost succesfully managed to access IronPython from Delphi 7 (Win32).

But I have also encountered a bug connected with IronPython.Modules.dll.



Here are steps to recreate it:

1. Unzip the attached file somewhere

2) Put IronPython IronPython-2.6 with IronPython dlls to the same folder (or

change the path in Host\build.bat)

3) Build the host with Host\build.bat

4) Run Host\Host.exe - it runs OK

5) Run Delphi\IpyTest.exe - it runs OK

6) Put IronPython.Modules.dll to Delphi\ folder

7) Run Delphi\IpyTest.exe - it freezes. It freezes during creating IronPython

engine.

8) Host\Host.exe runs fine with IronPython.Modules.dll



I don't know how to debug this problem - can somebody please look at it?

Thank you.



--

-- Lukáš





___

Users mailing list

Users@lists.ironpython.com<mailto: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] IronPython.Modules.dll bug when access from Delphi

[Dino Viehland]

It'll be interesting to see what windbg shows - I just tried it and it works 
for me w/ or w/o IronPython.Modules.dll.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
Sent: Wednesday, January 13, 2010 11:21 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython.Modules.dll bug when access from Delphi

IpyTest is compiled IpyTest.dpr by Delphi 7. Yes, it hosts CLR.
I'll try the windbg.

--
-- Lukáš


Dino Viehland wrote:

Ok, Dave was also somehow able to get the attachment and send it to me...



What is IpyTest.exe?  It's a big unmanaged EXE which I'm not inclined to run.



Is this hosting the CLR somehow?  Could you attach the debugger using windbg

which is a free download and get the stack from there?


From: 
users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
Sent: Wednesday, January 13, 2010 11:06 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython.Modules.dll bug when access from Delphi

I have created CodePlex issue:
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25933

Unfortunately, I have only VS Express so I cannot attach debugger to a process.

--
-- Lukáš


Dino Viehland wrote:

The attachment was deleted - can you post it somewhere?  For example you could

open a bug on our CodePlex site and attach it.



Also do you have VisualStudio installed?  If so you could attach the debugger

to your process and send the stack trace of where it's hanging.





-Original Message-

From: 
users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> 
[mailto:users-

boun...@lists.ironpython.com<mailto:boun...@lists.ironpython.com>] On Behalf Of 
Lukas Cenovsky

Sent: Wednesday, January 13, 2010 10:37 AM

To: Discussion of IronPython

Subject: [IronPython] IronPython.Modules.dll bug when access from Delphi



Hi,

I have almost succesfully managed to access IronPython from Delphi 7 (Win32).

But I have also encountered a bug connected with IronPython.Modules.dll.



Here are steps to recreate it:

1. Unzip the attached file somewhere

2) Put IronPython IronPython-2.6 with IronPython dlls to the same folder (or

change the path in Host\build.bat)

3) Build the host with Host\build.bat

4) Run Host\Host.exe - it runs OK

5) Run Delphi\IpyTest.exe - it runs OK

6) Put IronPython.Modules.dll to Delphi\ folder

7) Run Delphi\IpyTest.exe - it freezes. It freezes during creating IronPython

engine.

8) Host\Host.exe runs fine with IronPython.Modules.dll



I don't know how to debug this problem - can somebody please look at it?

Thank you.



--

-- Lukáš





___

Users mailing list

Users@lists.ironpython.com<mailto:Users@lists.ironpython.com>

http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




















___

Users mailing list

Users@lists.ironpython.com<mailto: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] IronPython in Visual Studio 2008

[Dino Viehland]

Does Wing now work w/ IronPython for debugging now that we added sys.settrace 
in 2.6?

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Vernon Cole
Sent: Tuesday, January 19, 2010 1:17 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython in Visual Studio 2008

Vincent:

I will try the first part of an answer to your question.  It is a long 
question, so you will probably get lots of different answers...

There are several different implementations of Python. I will talk about the 
two which are most common on Windows systems. I use both.

CPython is implemented in the C++ language and uses the traditional (or OLD, 
depending on your point of view) method of operating a Windows program.  It is 
much more mature, starts up much faster, and has lots of available modules, 
including numpy, scipy and countless others. You find it at 
http://python.org. To do Windows specific things with it, 
you also need pywin32 .  It can be 
used on a web server, and several web engines such as django, are written using 
it.  It cannot be used as a client script on a web page.

IronPython is new, written by Microsoft in the C# language, and uses the new 
.NET way of hooking things together.  It is a VERY good implementation of 
standard Python, but since many of the add-on libraries were written in C++, 
not C#, you cannot link to them. There is a package called IronClad which seeks 
to make this happen, often successfully. ( 
http://www.resolversystems.com/products/ironclad/ .) IronPython also suffers 
from the frustrating habit of ALL .NET implementations of taking several 
seconds (which at times feels like several minutes) to start a new process 
running. So while it may often be FASTER than CPython after it finally gets 
going, don't even THINK about using it for a quick command-line script.  On the 
other hand, if you are trying to interface with a new .NET project, it is only 
reasonable way to go.  It also runs on the Silverlight platform, so can be used 
as a scripting language for a web client page, not only a server page.

I have heard nothing but BAD reports about using Iron Python Studio. However, 
there are several Integrated Development Environments which work with CPython, 
IronPython, or both.  I, personally, use Wing for debugging, and the IDE which 
is built in to pywin32 for rough work.

Will Python code run as fast as C, or C++, or C# code?  No.  (or almost never.) 
 Will it run fast enough that a human user will never notice the difference?  
Almost always.  So what you do is prototype in Python, where you are most 
productive, then if you find that some part of your system actually needs the 
performance boost, you recode that piece in C++ (or C#).  I find that design 
changes usually do much more to boost perceived speed than compiler changes do. 
 Python excels at that.

So welcome aboard.  You have discovered a great tool.
--
Vernon Cole

On Tue, Jan 19, 2010 at 10:22 AM, Vicent 
mailto:vgi...@gmail.com>> wrote:
Hello to all.

This is my first message to the list. I would like to ask you some basic 
questions about IronPython. First of all, sorry for my English.

I've just discovered IronPython, and I am actually a new-by in Python, not an 
expert programmer. So maybe you'll find my questions quite simple or naive.

I read the first chapter of the classic book for IronPython 
(http://www.manning.com/foord/SampleChapter1.pdf), and in pages 7-8 the author 
says:

"Visual Studio 2008 integration exists in the form of IronPython Studio, which 
is implemented through the Visual Studio Shell extensibility framework. 
IronPython Studio can either be run standalone (without requiring Visual Studio 
to be installed) or integrated into Visual Studio. It includes Windows Forms 
and WPF designers and is capable of producing binary executables from Python 
projects."

I am very interested in fully understanding this sentence above, because I 
currently use C++ in MS Visual Studio 2008, but I like Python more.

So, with IronPython + Visual Studio 2008:

(1) Can I obtain compiled code from Python source, as efficient/fast/etc. as if 
it was made from C++?
(2) Can I obtain executables (programs that people can install and use, in the 
"normal user" language) as good/fast/efficient as I would obtain using Visual 
C++?
(3) Can I easily link my Python code with existing external C/C++ libraries?
(4) (Similar to the previous one) Can I easily link my Python code with some 
C/C++ source code (I mean, mixing up Python and C in the same project, in a 
transparent way)?
(5) Can I use NumPy, SciPy and other key (scientific) Python libraries in a 
transparent way?

(or am I just dreaming??)

Any answer will be appreciated. Thank you in advance.

--
Vicent Giner

___
Users mailing list
Users@lists.ironpython.com
http://li

Re: [IronPython] IronPython in Visual Studio 2008

[Dino Viehland]

There've been a couple of bugs discovered in settrace but they're getting fixed 
for 2.6.1 (the import os issue works on my machine w/o me having to fix 
anything, so I guess it's a duplicate of some other bug).  Bummer, I was hoping 
Wing might have implemented debugging like PyDev (a set of scripts).

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, January 20, 2010 2:28 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython in Visual Studio 2008

On 20/01/2010 02:34, Dino Viehland wrote:
Does Wing now work w/ IronPython for debugging now that we added sys.settrace 
in 2.6?
Does settrace work? I've seen two questions about it in as many days that are 
as yet unanswered.

The short answer is no. The Wing debugger is written in C. The SharpDevelop 
debugger (written in C#) does work with IronPython though.

Michael




From: 
users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Vernon Cole
Sent: Tuesday, January 19, 2010 1:17 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython in Visual Studio 2008

Vincent:

I will try the first part of an answer to your question.  It is a long 
question, so you will probably get lots of different answers...

There are several different implementations of Python. I will talk about the 
two which are most common on Windows systems. I use both.

CPython is implemented in the C++ language and uses the traditional (or OLD, 
depending on your point of view) method of operating a Windows program.  It is 
much more mature, starts up much faster, and has lots of available modules, 
including numpy, scipy and countless others. You find it at 
http://python.org.<http://python.org%20> To do Windows specific things with it, 
you also need pywin32<http://sourceforge.net/projects/pywin32> .  It can be 
used on a web server, and several web engines such as django, are written using 
it.  It cannot be used as a client script on a web page.

IronPython is new, written by Microsoft in the C# language, and uses the new 
.NET way of hooking things together.  It is a VERY good implementation of 
standard Python, but since many of the add-on libraries were written in C++, 
not C#, you cannot link to them. There is a package called IronClad which seeks 
to make this happen, often successfully. ( 
http://www.resolversystems.com/products/ironclad/ .) IronPython also suffers 
from the frustrating habit of ALL .NET implementations of taking several 
seconds (which at times feels like several minutes) to start a new process 
running. So while it may often be FASTER than CPython after it finally gets 
going, don't even THINK about using it for a quick command-line script.  On the 
other hand, if you are trying to interface with a new .NET project, it is only 
reasonable way to go.  It also runs on the Silverlight platform, so can be used 
as a scripting language for a web client page, not only a server page.

I have heard nothing but BAD reports about using Iron Python Studio. However, 
there are several Integrated Development Environments which work with CPython, 
IronPython, or both.  I, personally, use Wing for debugging, and the IDE which 
is built in to pywin32 for rough work.

Will Python code run as fast as C, or C++, or C# code?  No.  (or almost never.) 
 Will it run fast enough that a human user will never notice the difference?  
Almost always.  So what you do is prototype in Python, where you are most 
productive, then if you find that some part of your system actually needs the 
performance boost, you recode that piece in C++ (or C#).  I find that design 
changes usually do much more to boost perceived speed than compiler changes do. 
 Python excels at that.

So welcome aboard.  You have discovered a great tool.
--
Vernon Cole


On Tue, Jan 19, 2010 at 10:22 AM, Vicent 
mailto:vgi...@gmail.com>> wrote:
Hello to all.

This is my first message to the list. I would like to ask you some basic 
questions about IronPython. First of all, sorry for my English.

I've just discovered IronPython, and I am actually a new-by in Python, not an 
expert programmer. So maybe you'll find my questions quite simple or naive.

I read the first chapter of the classic book for IronPython 
(http://www.manning.com/foord/SampleChapter1.pdf), and in pages 7-8 the author 
says:

"Visual Studio 2008 integration exists in the form of IronPython Studio, which 
is implemented through the Visual Studio Shell extensibility framework. 
IronPython Studio can either be run standalone (without requiring Visual Studio 
to be installed) or integrated into Visual Studio. It includes Windows Forms 
and WPF designers and is capable of producing binary executables from Python 
projects."

I am very interested in fully understanding this sentence above, because I 
currentl

Re: [IronPython] to invoke ironpython from runtime in .NET framework 4.0

[Dino Viehland]

You need to download the version of IronPython which is built for .NET 4.0: 
http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28125

That'll just work and it'll support interop w/ C# 4.0.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Neelima Potti
Sent: Monday, January 25, 2010 1:48 PM
To: users@lists.ironpython.com
Subject: [IronPython] to invoke ironpython from runtime in .NET framework 4.0

Hi,
I am new to IronPython..
I have downloaded IronPython from the website
http://www.codeplex.com/IronPython lastweek.
When I open IronPython Console, it shows
IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.3053

I am trying to invoke the Python engine at run time
By calling in c# source(.NET 4.0 framework)

_runtime = ScriptRuntime.CreateFromConfiguration()

When I add Microsoft.Scripting as a Reference to this project, it shows the 
version as 2.6.911.0

And my app.config has



  

  
  

  

  



During runtime, I get the error:
An error occurred creating the configuration section handler for 
microsoft.scripting: Could not load file or assembly 'Microsoft.Scripting, 
Version=2.6.911.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of 
its dependencies. The located assembly's manifest definition does not match the 
assembly reference. (Exception from HRESULT: 0x80131040

What am I missing here? Is my version wrong or publicKeyToken wrong or??

Any help would be greatly appreciated

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

Re: [IronPython] bug with closure in coroutine

[Dino Viehland]

It's so easy to fix it's actually already fixed for 2.6.1 :)  Thanks for 
reporting it though.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Ronnie Maor
Sent: Wednesday, January 27, 2010 8:17 AM
To: Discussion of IronPython
Subject: [IronPython] bug with closure in coroutine

Hi IronPython team,

Seems IronPython 2.6 has some problems with compiling coroutines that contain 
closures:

tmp.py:
def coroutine():
x = yield 3
def inner():
print 'x=',x
inner()

c = coroutine()
c.next()
c.send(10)

with CPython:
C:\Temp>python tmp.py
x= 10
Traceback (most recent call last):
  File "tmp.py", line 9, in 
c.send(10)
StopIteration


with IronPython 2.6:
C:\Temp>ipy tmp.py
Traceback (most recent call last):
  File "tmp.py", line 7, in tmp.py
TypeError: Unable to cast object of type 
'Microsoft.Scripting.Ast.FieldExpression' to type 
'Microsoft.Scripting.Ast.BlockExpression'.


workarounds:
1) re-assign the result returned from yield to another variable
def coroutine():
tmp_x = yield 3
x = tmp_x
def inner():
print 'x=',x
inner()

2) pass the value explicitly instead of using a closure
def coroutine():
x = yield 3
def inner(x):
print 'x=',x
inner(x)

hope it's easy to fix

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

Re: [IronPython] IronPython 2.6 CodePlex Source Update

[Dino Viehland]

My bad, I forgot the magic marker which includes the commit message.

This was just an integration of all the changes from Main that have
Gone in over the past few months (which have for the most part had 
commit messages) to the 2.6 servicing branch.  The only differences 
were to avoid binary breaking changes which might break apps between 
Main and 2.6.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Wednesday, January 27, 2010 1:38 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython 2.6 CodePlex Source Update
> 
> It's commits like this that I wish had an explanation :).
> 
> - Jeff
> 
> On Wed, Jan 27, 2010 at 1:10 PM,   wrote:
> > This is an automated email letting you know that sources
> > have recently been pushed out.  You can download these newer
> > sources directly from
> http://ironpython.codeplex.com/SourceControl/changeset/view/63614.
> >
> > ADDED SOURCES
> >
>  $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/Runtime/ArgumentArr
> ay.cs
> >       ...
> ___
> 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] Django, __unicode__, and #20366

[Dino Viehland]

I'll take a look and see what breaks if we call __unicode__ when it's defined
when the user calls str/unicode.  

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Sunday, January 31, 2010 11:25 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Django, __unicode__, and #20366
> 
> On 31/01/2010 01:21, Jeff Hardy wrote:
> > Hi all,
> > I've got a question regarding __unicode__ and issue #20366[0]. Django
> > explicitly encourages the use of __unicode__ on models[1], which
> would
> > not be available on IronPython. Also, they have some lazy evaluation
> > functions that depend on differences between str and unicode, and
> > default to using __unicode__. Now, these differences could be worked
> > around in Django, but I wonder if that's the right place for them.
> There's *unlikely* to be an easy fix in IronPython any time soon,
> although I would love to be proved wrong. The Django team have
> *explicitly* said that they are open to patches (or even just bug
> reports) to make Django compatible with IronPython.
> 
> > I
> > also have no idea how this will play out under 3.0.
> >
> >
> 
> Django is not expecting to move to Python 3 for quite some time as I
> understand it.
> 
> > I'm working around by checking `str is unicode`; I'm not sure there's
> > really a better option.
> >
> 
> That sounds like a good solution to me.
> 
> > - Jeff
> >
> >
> > [0]
> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=20366
> >
> I still think the partial-fix I suggest in that issue would be much
> better than the current situation...
> 
> All the best,
> 
> Michael
> 
> > [1]
> http://docs.djangoproject.com/en/1.1/ref/models/instances/#django.db.mo
> dels.Model.__unicode__
> > ___
> > Users mailing list
> > Users@lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> 
> 
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
> 
> READ CAREFULLY. By accepting and reading this email you agree, on
> behalf of your employer, to release me from all obligations and waivers
> arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-
> service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-
> disclosure, non-compete and acceptable use policies ("BOGUS
> AGREEMENTS") that I have entered into with your employer, its partners,
> licensors, agents and assigns, in perpetuity, without prejudice to my
> ongoing rights and privileges. You further represent that you have the
> authority to release me from any BOGUS AGREEMENTS on behalf of your
> employer.
> 
> 
> ___
> 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] Django, __unicode__, and #20366

[Dino Viehland]

The following tests break:
test_str.test_conversion
We already disable a single test case (Foo9 called with 
unicode) but now we would disable 3 (Foo6, Foo7, and Foo9 called with str).  
Supporting it on old-style classes also causes us to disable Foo0.
test_unicode.test_conversion:
We currently disable most of the test cases here - all except 
for Foo8 (Unicode)/Foo9 (str).  After the change those two are failing and 
everything else is now passing.
Test_traceback.test_format_exception_only_bad__str__:
BaseException defines __unicode__ and so it gets called instead 
of __str__ - it looks like I can fix this one.
Test_doctest:
There's one failure here, it's the same as the test_traceback 
issue, and again it looks like it's fixable.

So the net result is that tests which specifically check for differences with 
__unicode__ / __str__ when called with Unicode/str change behavior.  Everything 
else works the same.  

My initial test job didn't include support for __unicode__ on old-style classes 
or have the fix for exceptions.  I'm sending it through again to make sure 
those two changes didn't break anything else.  But I'm inclined to say that 
this change is for the better.  Thoughts?


> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Sunday, January 31, 2010 12:23 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Django, __unicode__, and #20366
> 
> On 31/01/2010 20:14, Dino Viehland wrote:
> > I'll take a look and see what breaks if we call __unicode__ when it's
> defined
> > when the user calls str/unicode.
> >
> >
> Great. Given that *currently* IronPython will do the wrong thing I can't
> *imagine* any failures caused by this, but this probably a lack of
> imagination on my part...
> 
> All the best,
> 
> Michael
> 
> >> -Original Message-
> >> From: users-boun...@lists.ironpython.com [mailto:users-
> >> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> >> Sent: Sunday, January 31, 2010 11:25 AM
> >> To: Discussion of IronPython
> >> Subject: Re: [IronPython] Django, __unicode__, and #20366
> >>
> >> On 31/01/2010 01:21, Jeff Hardy wrote:
> >>
> >>> Hi all,
> >>> I've got a question regarding __unicode__ and issue #20366[0]. Django
> >>> explicitly encourages the use of __unicode__ on models[1], which
> >>>
> >> would
> >>
> >>> not be available on IronPython. Also, they have some lazy evaluation
> >>> functions that depend on differences between str and unicode, and
> >>> default to using __unicode__. Now, these differences could be worked
> >>> around in Django, but I wonder if that's the right place for them.
> >>>
> >> There's *unlikely* to be an easy fix in IronPython any time soon,
> >> although I would love to be proved wrong. The Django team have
> >> *explicitly* said that they are open to patches (or even just bug
> >> reports) to make Django compatible with IronPython.
> >>
> >>
> >>> I
> >>> also have no idea how this will play out under 3.0.
> >>>
> >>>
> >>>
> >> Django is not expecting to move to Python 3 for quite some time as I
> >> understand it.
> >>
> >>
> >>> I'm working around by checking `str is unicode`; I'm not sure there's
> >>> really a better option.
> >>>
> >>>
> >> That sounds like a good solution to me.
> >>
> >>
> >>> - Jeff
> >>>
> >>>
> >>> [0]
> >>>
> >> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=20366
> >>
> >>>
> >> I still think the partial-fix I suggest in that issue would be much
> >> better than the current situation...
> >>
> >> All the best,
> >>
> >> Michael
> >>
> >>
> >>> [1]
> >>>
> >> http://docs.djangoproject.com/en/1.1/ref/models/instances/#django.db.mo
> >> dels.Model.__unicode__
> >>
> >>> ___
> >>> Users mailing list
> >>> Users@lists.ironpython.com
> >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>
> >>>
> >>
> >> --
> >> http://www.ironpythoninact

Re: [IronPython] Django, __unicode__, and #20366

[Dino Viehland]

It always prefers __unicode__ over __str__.  We can't really only call 
__unicode__ when __str__ isn't there because __str__ is always there.

We could do a search based upon MRO and call the first one we find but
I don't think that'll change the behavior very much and it'll certainly
be more difficult to understand.

The actual code is added to StringOps.FastNew:

if (x is string) {
// check ascii
return CheckAsciiString(context, (string)x);
}

+object value;
+if (PythonTypeOps.TryInvokeUnaryOperator(context, x, 
"__unicode__", out value)) {
+if (value is string || value is Extensible) {
+return value;
+}
+throw PythonOps.TypeError("coercing to Unicode: exected 
string, got {0}", PythonTypeOps.GetName(value));
+}
+
+OldInstance oi = x as OldInstance;
+
+if (oi != null && oi.TryGetBoundCustomMember(context, 
"__unicode__", out value)) {
+value = context.LanguageContext.Call(context, value);
+if (value is string || value is Extensible) {
+return value;
+}
+throw PythonOps.TypeError("coercing to Unicode: exected 
string, got {0}", PythonTypeOps.GetName(value));
+}

// we don't invoke PythonOps.StringRepr here because we want to 
return the 
// Extensible directly back if that's what we received from 
__str__.
value = PythonContext.InvokeUnaryOperator(context, 
UnaryOperators.String, x);
if (value is string || value is Extensible) {
return value;
}

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Monday, February 01, 2010 1:16 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Django, __unicode__, and #20366
> 
> On Mon, Feb 1, 2010 at 1:19 PM, Dino Viehland  wrote:
> > My initial test job didn't include support for __unicode__ on old-style
> classes or have the fix for exceptions.  I'm sending it through again to make
> sure those two changes didn't break anything else.  But I'm inclined to say
> that this change is for the better.  Thoughts?
> 
> How does the implementation work? Does always it prefer __unicode__ to
> __str__, or does it only call __unicode__ if it is present and __str__
> is missing?
> 
> - Jeff
> ___
> 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] Django, __unicode__, and #20366

[Dino Viehland]

> How about having str and unicode as different objects internally - so
> IronPython can tell the difference - but fake equality and identity
> checks *inside* IronPython. :-)
> 
> Or do something a bit similar to what Python 3 does with super...
> Compile different code for str(...) and unicode(...). I think I prefer
> that to the above. :-)
> 

Messing with identity starts to get really scary and I'd rather not go
there - I'm sure there will be lots of edge cases which will be broken.  

I could see is making unicode(foo) do something different.  If you aliased 
unicode then you'd get str's behavior though but that might be perfectly 
acceptable.  It's definitely a solution I had not considered and it'd 
probably fix multiple issues.




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

Re: [IronPython] Django, __unicode__, and #20366

[Dino Viehland]

Jeff wrote:
> OK - didn't realize that. Not sure it would really improve the
> behaviour all that much anyway.
> 
> Anything that really needs to know the difference and support
> IronPython can just check `str is unicode` anyway.
> 
> Random thought: str(x, yes_really=True) to always call __str__? :)

I'm not sure that'll help with compatibility w/ Django go unless
other implementations were to support it as well.


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

Re: [IronPython] Hosting DLR under ASP.NET

[Dino Viehland]

I would recommend:
Keep 1 ScriptRuntime/ScriptEngine (as Jimmy mentions you can repeatedly 
grab the SE off the SR)
Compile the code to a CompiledCode object and repeatedly execute it 
rather than re-compiling and executing
Create a new ScriptScope for each request

That's basically what the ASP.NET integration for IronPython does.  

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jimmy Schementi
> Sent: Tuesday, February 02, 2010 9:53 AM
> To: Discussion of IronPython; ironruby-c...@rubyforge.org
> Subject: Re: [IronPython] Hosting DLR under ASP.NET
> 
> Recreating them on each call is OK for really simple script usages, since
> multiple requests of an ASP.NET app run in the same CLR instance, and the
> result of ScriptRuntime.GetEngine("langName") is cached, so the app will only
> incur a performance hit (because of the language's assemblies JITing) on the
> first request. However, if you want to keep some state around, let's say by
> defining some functions or importing a library for your script code to use,
> then you'll want to at least keep track of a ScriptScope, and then you might
> as well keep track of a ScriptEngine as well. You can store those anywhere
> you'd normally store things that need to persist between requests.
> 
> ~js
> 
> > -Original Message-
> > From: users-boun...@lists.ironpython.com [mailto:users-
> > boun...@lists.ironpython.com] On Behalf Of Marco Parenzan
> > Sent: Tuesday, February 02, 2010 5:09 AM
> > To: ironruby-c...@rubyforge.org; users@lists.ironpython.com
> > Subject: [IronPython] Hosting DLR under ASP.NET
> >
> > Dear All,
> >
> > are there any advices about hosting DLR under ASP.NET for scripting? (not
> for
> > views!)?
> > Where hosting ScriptingRuntime, ScriptingEngine?
> > As static variables in Global.asax? In Application?
> > Where hosting ScriptingScope? In Session? Destroy and reistantiate at each
> > call?
> >
> > I have to develop an ASP.NET MVC application, with no serious performance
> > issues, but I don't want to abuse...
> >
> > Thanks in advance
> >
> > Marco Parenzan
> >
> > ___
> > 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