From sdm900 at gmail.com  Thu Mar  1 06:39:55 2007
From: sdm900 at gmail.com (Stuart Midgley)
Date: Thu, 1 Mar 2007 14:39:55 +0900
Subject: [IronPython] shelve bug?
Message-ID: <E2AB00DD-54ED-4EB4-A664-A322F0AA6435@gmail.com>

Afternoon

I am not sure if this has done the rounds previously, but shelves  
don't appear to be fully supported on IronPython

My code (shelvebug.py) is


import sys

sys.path.append("/opt/local/Library/Frameworks/Python.framework/ 
Libraries/python2.4")

import shelve

d=shelve.open("aaa", writeback=True)
d["a"] = 1
d.close()


and the output is


stu:/IronPython-1.0.1 > mono -O=all ipy.exe shelvebug.py
Traceback (most recent call last):
   File shelvebug, line unknown, in Initialize
   File shelve, line unknown, in __setitem__
   File dumbdbm, line unknown, in __setitem__
   File dumbdbm, line unknown, in _addval
NotImplementedError: bad mode: rb+


This obviously works just fine on my MacOSX system with python2.4.3

Stu.



--
Dr Stuart Midgley
sdm900 at gmail.com




From sdm900 at gmail.com  Thu Mar  1 07:42:28 2007
From: sdm900 at gmail.com (Stuart Midgley)
Date: Thu, 1 Mar 2007 15:42:28 +0900
Subject: [IronPython] bug in commands module
Message-ID: <50B26C47-E2B9-48EB-A5C7-2BCE1DB44460@gmail.com>

Hmmm... I appear to be getting an error inside the commands module

Traceback (most recent call last):
   File main, line unknown, in executestr
   File q, line unknown, in __init__
   File q, line unknown, in cache
   File commands, line unknown, in getstatusoutput
WindowsError: The system can not find command '{'

now, I suspect its got something to do with (from the python docs for  
getstatusoutput )

	cmd is actually run as { cmd ; } 2>&1

any ideas?

Stu.

--
Dr Stuart Midgley
sdm900 at gmail.com




From njriley at uiuc.edu  Thu Mar  1 08:34:20 2007
From: njriley at uiuc.edu (Nicholas Riley)
Date: Thu, 1 Mar 2007 01:34:20 -0600
Subject: [IronPython] bug in commands module
In-Reply-To: <50B26C47-E2B9-48EB-A5C7-2BCE1DB44460@gmail.com>
References: <50B26C47-E2B9-48EB-A5C7-2BCE1DB44460@gmail.com>
Message-ID: <20070301073419.GC80787@uiuc.edu>

On Thu, Mar 01, 2007 at 03:42:28PM +0900, Stuart Midgley wrote:
> Hmmm... I appear to be getting an error inside the commands module
> 
> Traceback (most recent call last):
>    File main, line unknown, in executestr
>    File q, line unknown, in __init__
>    File q, line unknown, in cache
>    File commands, line unknown, in getstatusoutput
> WindowsError: The system can not find command '{'
> 
> now, I suspect its got something to do with (from the python docs for  
> getstatusoutput )
> 
> 	cmd is actually run as { cmd ; } 2>&1

The commands module is Unix-only and more or less deprecated; it
doesn't work on Windows in CPython either, so it's not an
IronPython-specific issue.

<http://mail.python.org/pipermail/python-dev/2004-August/047779.html>

Unfortunately it seems the subprocess module doesn't work on
IronPython either because it wants to use Win32 APIs directly.  You'll
have to use os.popen directly, or a native API.

-- 
Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>


From wd at teleri.net  Thu Mar  1 08:42:23 2007
From: wd at teleri.net (Chip Norkus)
Date: Wed, 28 Feb 2007 23:42:23 -0800
Subject: [IronPython] shelve bug?
In-Reply-To: <E2AB00DD-54ED-4EB4-A664-A322F0AA6435@gmail.com>
References: <E2AB00DD-54ED-4EB4-A664-A322F0AA6435@gmail.com>
Message-ID: <20070301074223.GJ47199@teleri.net>

On Thu Mar 01, 2007; 02:39PM +0900, Stuart Midgley wrote:
> Afternoon
> 
> I am not sure if this has done the rounds previously, but shelves  
> don't appear to be fully supported on IronPython
> 
> My code (shelvebug.py) is

I believe that IP does not support pyd modules (that is DLLs for Python)
which is where the real support for dbm on Windows comes from.  As such
the shelve module can't currently be supported well (dumbdbm is not very
good. :))

Additionaly some mode flags to open() don't work quite right in IP1.0,
but I *think* they are fixed in the latest 1.1 (not sure...)

> 
> 
> import sys
> 
> sys.path.append("/opt/local/Library/Frameworks/Python.framework/ 
> Libraries/python2.4")
> 
> import shelve
> 
> d=shelve.open("aaa", writeback=True)
> d["a"] = 1
> d.close()
> 
> 
> and the output is
> 
> 
> stu:/IronPython-1.0.1 > mono -O=all ipy.exe shelvebug.py
> Traceback (most recent call last):
>    File shelvebug, line unknown, in Initialize
>    File shelve, line unknown, in __setitem__
>    File dumbdbm, line unknown, in __setitem__
>    File dumbdbm, line unknown, in _addval
> NotImplementedError: bad mode: rb+
> 
> 
> This obviously works just fine on my MacOSX system with python2.4.3
> 
> Stu.
> 
> 
> 
> --
> Dr Stuart Midgley
> sdm900 at gmail.com
> 
> 
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-chip
--
personal: chip norkus; irc: wd;                   wd at teleri.net
info:     finger wd at teleri.net for plan or keys;  http://telekinesis.org


From sdm900 at gmail.com  Thu Mar  1 08:48:16 2007
From: sdm900 at gmail.com (Stuart Midgley)
Date: Thu, 1 Mar 2007 16:48:16 +0900
Subject: [IronPython] bug in commands module
In-Reply-To: <20070301073419.GC80787@uiuc.edu>
References: <50B26C47-E2B9-48EB-A5C7-2BCE1DB44460@gmail.com>
	<20070301073419.GC80787@uiuc.edu>
Message-ID: <EF39D955-0572-48D6-B4A4-4FAE429C9C09@gmail.com>

Yes, I realise it is a unix only command, I was just hoping that it  
might work on mono under unix.

Stu.




> The commands module is Unix-only and more or less deprecated; it
> doesn't work on Windows in CPython either, so it's not an
> IronPython-specific issue.
>
> <http://mail.python.org/pipermail/python-dev/2004-August/047779.html>
>
> Unfortunately it seems the subprocess module doesn't work on
> IronPython either because it wants to use Win32 APIs directly.  You'll
> have to use os.popen directly, or a native API.

--
Dr Stuart Midgley
sdm900 at gmail.com




From sdm900 at gmail.com  Thu Mar  1 08:49:10 2007
From: sdm900 at gmail.com (Stuart Midgley)
Date: Thu, 1 Mar 2007 16:49:10 +0900
Subject: [IronPython] shelve bug?
In-Reply-To: <20070301074223.GJ47199@teleri.net>
References: <E2AB00DD-54ED-4EB4-A664-A322F0AA6435@gmail.com>
	<20070301074223.GJ47199@teleri.net>
Message-ID: <BA198F56-B432-4C79-B2F9-449F4909D715@gmail.com>

shelves are working just fine in IP1.1b1 as I discovered after posting.


>
> Additionaly some mode flags to open() don't work quite right in IP1.0,
> but I *think* they are fixed in the latest 1.1 (not sure...)

--
Dr Stuart Midgley
sdm900 at gmail.com




From adam.hill at gmail.com  Thu Mar  1 17:35:04 2007
From: adam.hill at gmail.com (Adam Hill)
Date: Thu, 1 Mar 2007 10:35:04 -0600
Subject: [IronPython] WorldWind and IronPython
Message-ID: <d5ec7b310703010835l53cd64c0pa86b39d333995309@mail.gmail.com>

NASA WorldWind now has a IP console.

http://pneumatictu.be/modelfrompython.png

Announcement here:

http://forum.worldwindcentral.com/showthread.php?t=8882&highlight=ironpython

I would like to thank Jim and crew for a great addition to the .NET
toolbox that is so easy to reuse!

Adam Hill


From joesox at gmail.com  Thu Mar  1 21:41:57 2007
From: joesox at gmail.com (JoeSox)
Date: Thu, 1 Mar 2007 12:41:57 -0800
Subject: [IronPython] WorldWind and IronPython
In-Reply-To: <d5ec7b310703010835l53cd64c0pa86b39d333995309@mail.gmail.com>
References: <d5ec7b310703010835l53cd64c0pa86b39d333995309@mail.gmail.com>
Message-ID: <785694cd0703011241o71c4457eh5734eebd657b85c5@mail.gmail.com>

Cool news.  I'm glad to see some people get use from my IronTextBox control
http://www.codeproject.com/useritems/irontextbox.asp

This will motivate me to start seeing what I can do for tab completion
support. :)

and I also again IronPython is a great addition to .Net.

Thanks, JoeSox


On 3/1/07, Adam Hill <adam.hill at gmail.com> wrote:
> NASA WorldWind now has a IP console.
>
> http://pneumatictu.be/modelfrompython.png
>
> Announcement here:
>
> http://forum.worldwindcentral.com/showthread.php?t=8882&highlight=ironpython
>
> I would like to thank Jim and crew for a great addition to the .NET
> toolbox that is so easy to reuse!
>
> Adam Hill


From sdm900 at gmail.com  Fri Mar  2 05:55:20 2007
From: sdm900 at gmail.com (Stuart Midgley)
Date: Fri, 2 Mar 2007 13:55:20 +0900
Subject: [IronPython] pickle broken?
Message-ID: <B5490A29-E597-4ABE-A30D-D3E8D1D24F8F@gmail.com>

Looks like pickling doesn't work fully in IP1.1b1

Stu.


 >>> import sys
 >>> sys.path.append("/opt/local/Library/Frameworks/Python.framework/ 
Libraries/python2.4")
 >>> import re, pickle
 >>> pickle.dumps(re.compile('.*'))
Traceback (most recent call last):
   File pickle, line unknown, in dumps
   File pickle, line unknown, in dump
   File pickle, line unknown, in save
   File pickle, line unknown, in save_reduce
   File pickle, line unknown, in save_reduce
   File pickle, line unknown, in save
   File pickle, line unknown, in save_tuple
   File pickle, line unknown, in save
   File pickle, line unknown, in save_global
pickle.PicklingError: Can't pickle <type 'RE_Pattern'>: it's not  
found as re.RE_Pattern


--
Dr Stuart Midgley
sdm900 at gmail.com




From dinov at exchange.microsoft.com  Fri Mar  2 06:21:07 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 1 Mar 2007 21:21:07 -0800
Subject: [IronPython] pickle broken?
In-Reply-To: <B5490A29-E597-4ABE-A30D-D3E8D1D24F8F@gmail.com>
References: <B5490A29-E597-4ABE-A30D-D3E8D1D24F8F@gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C22276A61ECC2E2@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for reporting this.  I don't think we currently support Pickling the various re objects.  I've opened CodePlex bug #8592 to track it (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8592).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Stuart Midgley
Sent: Thursday, March 01, 2007 8:55 PM
To: Discussion of IronPython
Subject: [IronPython] pickle broken?

Looks like pickling doesn't work fully in IP1.1b1

Stu.


 >>> import sys
 >>> sys.path.append("/opt/local/Library/Frameworks/Python.framework/
Libraries/python2.4")
 >>> import re, pickle
 >>> pickle.dumps(re.compile('.*'))
Traceback (most recent call last):
   File pickle, line unknown, in dumps
   File pickle, line unknown, in dump
   File pickle, line unknown, in save
   File pickle, line unknown, in save_reduce
   File pickle, line unknown, in save_reduce
   File pickle, line unknown, in save
   File pickle, line unknown, in save_tuple
   File pickle, line unknown, in save
   File pickle, line unknown, in save_global
pickle.PicklingError: Can't pickle <type 'RE_Pattern'>: it's not
found as re.RE_Pattern


--
Dr Stuart Midgley
sdm900 at gmail.com


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


From sh at defuze.org  Sat Mar  3 20:29:19 2007
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Sat, 03 Mar 2007 19:29:19 +0000
Subject: [IronPython] End of the World? No just end of the line.
Message-ID: <45E9CC8F.2000004@defuze.org>

Hi folks,

Working with M. David Peterson trying to run the CherryPy HTTP server on
IP under Windows we ran into a fairly subtle bug that was actually not
so subtle at all.

When the server accepts a connection it maps the socket into a file
object so that it can read and write with a nice API.

When using IPCE socket module this achieves the same by doing this:

def makefile(self, mode='r', bufsize=-1):
    stream = NetworkStream(self.socket)
    return file(stream, mode)

This works great when you don't care about the way the end of the lines
is defined but if you do be ready for some hair-tearing hours.

Indeed with IronPython running on Windows with the .NET framework the
end of the line is defined as <LF> whereas for instance on Linux with
Mono it's <CR><LF>.

If I'm not mistaken CPython always ensures the end of line is <CR><LF>
so that people don't have to worry about the underlying OS behavior.

The problem I faced is that HTTP marks the end of the header lists via a
<CR><LF> but because CherryPy reads the socket as a file it only gets a
<LF> with IP under Windows and therefore fails miserably. I've added a
test for a single <LF> in my copy of CherryPy and it fixed the problem.
But this is a bit of a hassle.

I don't think there is a bug of any of the part here. However I believe
there should be either a very clear warning that this difference will
always exists and Python developer will have to check for that case, or
maybe IP should find a way to ensure that <CR><LF> is always returned
even under Windows (which I doubt is an easy thing to do).

In any case if your code depends on the line ending be aware of that
difference as you could end up swearing too loud for your own good.

- Sylvain


From sh at defuze.org  Sat Mar  3 22:31:49 2007
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Sat, 03 Mar 2007 21:31:49 +0000
Subject: [IronPython] End of the World? No just end of the line.
In-Reply-To: <45E9CC8F.2000004@defuze.org>
References: <45E9CC8F.2000004@defuze.org>
Message-ID: <45E9E945.9000507@defuze.org>

After discussing with Robert Brewer (the main developer of CherryPy) it
appeared that this can be easily avoided if you make sure to use the
"rb" mode when calling socket.makefile() rather than "r".

With CPython it doesn't make a difference in that specific case but IP
it does.

- Sylvain

Sylvain Hellegouarch wrote:
> Hi folks,
> 
> Working with M. David Peterson trying to run the CherryPy HTTP server on
> IP under Windows we ran into a fairly subtle bug that was actually not
> so subtle at all.
> 
> When the server accepts a connection it maps the socket into a file
> object so that it can read and write with a nice API.
> 
> When using IPCE socket module this achieves the same by doing this:
> 
> def makefile(self, mode='r', bufsize=-1):
>     stream = NetworkStream(self.socket)
>     return file(stream, mode)
> 
> This works great when you don't care about the way the end of the lines
> is defined but if you do be ready for some hair-tearing hours.
> 
> Indeed with IronPython running on Windows with the .NET framework the
> end of the line is defined as <LF> whereas for instance on Linux with
> Mono it's <CR><LF>.
> 
> If I'm not mistaken CPython always ensures the end of line is <CR><LF>
> so that people don't have to worry about the underlying OS behavior.
> 
> The problem I faced is that HTTP marks the end of the header lists via a
> <CR><LF> but because CherryPy reads the socket as a file it only gets a
> <LF> with IP under Windows and therefore fails miserably. I've added a
> test for a single <LF> in my copy of CherryPy and it fixed the problem.
> But this is a bit of a hassle.
> 
> I don't think there is a bug of any of the part here. However I believe
> there should be either a very clear warning that this difference will
> always exists and Python developer will have to check for that case, or
> maybe IP should find a way to ensure that <CR><LF> is always returned
> even under Windows (which I doubt is an easy thing to do).
> 
> In any case if your code depends on the line ending be aware of that
> difference as you could end up swearing too loud for your own good.
> 


From karren.sulliver at gmail.com  Sun Mar  4 13:33:47 2007
From: karren.sulliver at gmail.com (Karren Sulliver)
Date: Sun, 4 Mar 2007 07:33:47 -0500
Subject: [IronPython] update
Message-ID: <4b1e4fc0703040433s2c558971s5f75f1c500b4d54f@mail.gmail.com>

Hello,

I would like to include a rule when another is triggered, for example:

If this rule is triggered:
drop tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg: "BLEEDING-EDGE
Malware Gator/Clarian Agent"; flow: to_server,established;
uricontent:"/gbsf/gd/ne/new.net.gtrg2ze"; nocase; classtype:
policy-violation; reference:url,
www3.ca.com/securityadvisor/pest/content.aspx?q=67999; sid: 2001306;
rev:5;)

I would like to also trigger this rule for n minutes/seconds:
drop tcp any any -> any 80 (classtype:attempted-user; msg:"Port 80
connection initiated";)

I've looked at the tagging option for rules but I need to drop them, not
just log them.

Any ideas?



http://www.webservertalk.com/archive251-2005-12-1314914.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-December/004607.html
http://www.webservertalk.com/archive251-2005-12-1309708.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-December/004731.html
http://lists.ibiblio.org/pipermail/cc-licenses/2004-June/000915.html
http://9fans.net/archive/2005/04/4
http://lists.ibiblio.org/pipermail/cc-licenses/2006-October/004203.html
http://lists.ibiblio.org/pipermail/cc-licenses/2005-March/001764.html
http://www.webservertalk.com/archive251-2005-10-1221632.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-October/004360.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-October/004454.html
http://9fans.net/archive/2005/04/251
http://lists.ibiblio.org/pipermail/cc-licenses/2007-January/004931.html
http://lists.ibiblio.org/pipermail/cc-licenses/2005-March/001765.html
http://lists.ibiblio.org/pipermail/cc-licenses/2007-January/004931.html
http://root.cern.ch/root/roottalk/roottalk05/2994.html
http://root.cern.ch/root/roottalk/roottalk05/2578.html
http://root.cern.ch/root/roottalk/roottalk04/2681.html
http://9fans.net/archive/2005/04/366
http://root.cern.ch/root/roottalk/roottalk05/2439.html
http://root.cern.ch/root/roottalk/roottalk05/0505.html
http://sourceforge.net/mailarchive/message.php?msg_id=8539894
http://sourceforge.net/mailarchive/forum.php?thread_id=5617912&forum_id=9566
http://lists.us.dell.com/pipermail/dkms-devel/2005-December/000417.html
http://lists.us.dell.com/pipermail/dkms-devel/2005-March/000309.html
http://www.webservertalk.com/archive251-2005-10-1222482.html

Sguil (pronounced sgweel) is built by network security analysts for
network security analysts. Sguil's main component is an intuitive GUI
that provides realtime events from snort/barnyard. It also includes
other components which facilitate the practice of Network Security
Monitoring and event driven analysis of IDS alerts. The sguil client
is written in tcl/tk and can be run on any operating system that
supports tcl/tk (including Linux, *BSD, Solaris, MacOS, and Win32).

Sguil version 0.6.0 contains two significant differences from previous
versions. The first difference is the use of the mysql MRG_MyISAM
(MERGE) engine for the sancp, event, *hdr, and data tables. With the
MERGE engine, it is possible to keep hundreds of millions of rows of
data active and online and still be functional (queries to the DB are
reasonably responsive). The use of MERGE and the associated schema
makes backing up and restoring data amazingly simple and quick. The
UPGRADE text in the sguil-0.6.0/doc directory of the source contains
more detail as well as upgrade instructions.

The second major change was to the sguil output plugin for barnyard
(op_sguil) and the communications structure between the sensors and
sguild. Op_sguil now uses tcl libraries and sends data via localhost
to the sensor's agent. All communications between the sensor and
sguild now flow thru sensor_agent. This means the mysql libraries are
no longer needed on the sensors. Since barnyard does not need to be
compiled with mysql support, op_sguil (barnyard) and mysql 4+ may be
used together without any license conflicts.


http://lists.us.dell.com/pipermail/dkms-devel/2005-December/000425.html
http://lists.ibiblio.org/pipermail/cc-licenses/2005-December/003059.html
http://comments.gmane.org/gmane.comp.java.junit.announce/110
http://9fans.net/archive/2006/08/6
http://9fans.net/archive/2005/03/82
http://9fans.net/archive/2006/08/146
http://blog.gmane.org/gmane.comp.java.junit.announce
http://9fans.net/archive/2006/05/12
http://9fans.net/archive/2005/03/97
http://9fans.net/archive/2006/05/131
http://segate.sunet.se/cgi-bin/wa?A2=ind0409&L=handikapp&P=23681
http://www.tutorials-blog.com/plan9/plan9-26.html
http://9fans.net/archive/2006/05/255
http://www.arcknowledge.com/gmane.comp.lang.c++.root/2004-09/threads.html
http://www.webservertalk.com/archive251-2005-10-1236635.html
http://news.gmane.org/group/gmane.comp.java.junit.announce/last=/force_load=t
http://9fans.net/archive/2006/05/274
http://marc.10east.com/?l=mysap-linux-general&r=1&b=200503&w=1
http://www.webservertalk.com/archive251-2005-9-1188388.html
http://www.webservertalk.com/archive251-2004-9.html
http://www.webservertalk.com/archive251-2005-9-1217604.html
http://9fans.net/archive/2006/12/141


 have just patched snort 2.3.3 with ClamAV-2.3.3-1.diff and it doesn't
seem to work as advertised. I have the following preprocessor line

preprocessor clamav: ports all !20 !22 !443, toclientonly, dbdir
/var/ftp/pub/tools/clamav-devel/share/clamav/, dbreload-time 43200,
file-descriptor-mode

I strace'd snort while downloading EICAR.COM and the klez virus from a
remote HTTP server - the strace shows the daily.* files being loaded -
which tells me ClamAV is being enabled - but nothing got detected. I
even ran tcpdump on the same interface and can see the HTTP download -
so it's definitely not a wiring issue either.

I can see tonnes of /tmp/snort_inline-clamav-XXXXXX files being created,
opened,closed and unlinked - but no virus was detected. The summary that
is outputted when snort exits shows zero alerts - and nothing shows up
via the syslog or mysql output processors I use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070304/513db932/attachment.html>

From supermeter at 163.com  Sun Mar  4 15:12:48 2007
From: supermeter at 163.com (supermeter)
Date: Sun, 4 Mar 2007 22:12:48 +0800
Subject: [IronPython] serialport
References: <4b1e4fc0703040433s2c558971s5f75f1c500b4d54f@mail.gmail.com>
Message-ID: <200703042212470968160@163.com>

I hope IronPython can support Serialport Class.




supermeter
2007-03-04



???? Karren Sulliver
????? 2007-03-04 20:33:44
???? users at lists.ironpython.com
??? 
??? [IronPython] update


Hello,
I would like to include a rule when another is triggered, for example:
If this rule is triggered:
drop tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg: "BLEEDING-EDGE
Malware Gator/Clarian Agent"; flow: to_server,established;
uricontent:"/gbsf/gd/ne/new.net.gtrg2ze"; nocase; classtype: 
policy-violation; reference:url,
www3.ca.com/securityadvisor/pest/content.aspx?q=67999; sid: 2001306;
rev:5;)
I would like to also trigger this rule for n minutes/seconds:
drop tcp any any -> any 80 (classtype:attempted-user; msg:"Port 80
connection initiated";)
I've looked at the tagging option for rules but I need to drop them, not
just log them.
Any ideas?

http://www.webservertalk.com/archive251-2005-12-1314914.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-December/004607.html
http://www.webservertalk.com/archive251-2005-12-1309708.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-December/004731.html
http://lists.ibiblio.org/pipermail/cc-licenses/2004-June/000915.html 
http://9fans.net/archive/2005/04/4
http://lists.ibiblio.org/pipermail/cc-licenses/2006-October/004203.html 
http://lists.ibiblio.org/pipermail/cc-licenses/2005-March/001764.html
http://www.webservertalk.com/archive251-2005-10-1221632.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-October/004360.html 
http://lists.ibiblio.org/pipermail/cc-licenses/2006-October/004454.html
http://9fans.net/archive/2005/04/251 
http://lists.ibiblio.org/pipermail/cc-licenses/2007-January/004931.html
http://lists.ibiblio.org/pipermail/cc-licenses/2005-March/001765.html
http://lists.ibiblio.org/pipermail/cc-licenses/2007-January/004931.html 
http://root.cern.ch/root/roottalk/roottalk05/2994.html
http://root.cern.ch/root/roottalk/roottalk05/2578.html 
http://root.cern.ch/root/roottalk/roottalk04/2681.html
http://9fans.net/archive/2005/04/366 
http://root.cern.ch/root/roottalk/roottalk05/2439.html
http://root.cern.ch/root/roottalk/roottalk05/0505.html 
http://sourceforge.net/mailarchive/message.php?msg_id=8539894
http://sourceforge.net/mailarchive/forum.php?thread_id=5617912&forum_id=9566
http://lists.us.dell.com/pipermail/dkms-devel/2005-December/000417.html 
http://lists.us.dell.com/pipermail/dkms-devel/2005-March/000309.html
http://www.webservertalk.com/archive251-2005-10-1222482.html
Sguil (pronounced sgweel) is built by network security analysts for
network security analysts. Sguil's main component is an intuitive GUI
that provides realtime events from snort/barnyard. It also includes
other components which facilitate the practice of Network Security
Monitoring and event driven analysis of IDS alerts. The sguil client
is written in tcl/tk and can be run on any operating system that
supports tcl/tk (including Linux, *BSD, Solaris, MacOS, and Win32). 
Sguil version 0.6.0 contains two significant differences from previous
versions. The first difference is the use of the mysql MRG_MyISAM
(MERGE) engine for the sancp, event, *hdr, and data tables. With the
MERGE engine, it is possible to keep hundreds of millions of rows of 
data active and online and still be functional (queries to the DB are
reasonably responsive). The use of MERGE and the associated schema
makes backing up and restoring data amazingly simple and quick. The
UPGRADE text in the sguil-0.6.0/doc directory of the source contains
more detail as well as upgrade instructions.
The second major change was to the sguil output plugin for barnyard
(op_sguil) and the communications structure between the sensors and
sguild. Op_sguil now uses tcl libraries and sends data via localhost
to the sensor's agent. All communications between the sensor and 
sguild now flow thru sensor_agent. This means the mysql libraries are
no longer needed on the sensors. Since barnyard does not need to be
compiled with mysql support, op_sguil (barnyard) and mysql 4+ may be
used together without any license conflicts. 

http://lists.us.dell.com/pipermail/dkms-devel/2005-December/000425.html
http://lists.ibiblio.org/pipermail/cc-licenses/2005-December/003059.html
http://comments.gmane.org/gmane.comp.java.junit.announce/110
http://9fans.net/archive/2006/08/6
http://9fans.net/archive/2005/03/82
http://9fans.net/archive/2006/08/146
http://blog.gmane.org/gmane.comp.java.junit.announce
http://9fans.net/archive/2006/05/12
http://9fans.net/archive/2005/03/97
http://9fans.net/archive/2006/05/131
http://segate.sunet.se/cgi-bin/wa?A2=ind0409&L=handikapp&P=23681 
http://www.tutorials-blog.com/plan9/plan9-26.html
http://9fans.net/archive/2006/05/255
http://www.arcknowledge.com/gmane.comp.lang.c++.root/2004-09/threads.html
http://www.webservertalk.com/archive251-2005-10-1236635.html
http://news.gmane.org/group/gmane.comp.java.junit.announce/last=/force_load=t
http://9fans.net/archive/2006/05/274
http://marc.10east.com/?l=mysap-linux-general&r=1&b=200503&w=1
http://www.webservertalk.com/archive251-2005-9-1188388.html
http://www.webservertalk.com/archive251-2004-9.html
http://www.webservertalk.com/archive251-2005-9-1217604.html
http://9fans.net/archive/2006/12/141

 have just patched snort 2.3.3 with ClamAV-2.3.3-1.diff and it doesn't
seem to work as advertised. I have the following preprocessor line
preprocessor clamav: ports all !20 !22 !443, toclientonly, dbdir
/var/ftp/pub/tools/clamav-devel/share/clamav/, dbreload-time 43200,
file-descriptor-mode
I strace'd snort while downloading EICAR.COM and the klez virus from a
remote HTTP server - the strace shows the daily.* files being loaded -
which tells me ClamAV is being enabled - but nothing got detected. I 
even ran tcpdump on the same interface and can see the HTTP download -
so it's definitely not a wiring issue either.
I can see tonnes of /tmp/snort_inline-clamav-XXXXXX files being created,
opened,closed and unlinked - but no virus was detected. The summary that
is outputted when snort exits shows zero alerts - and nothing shows up 
via the syslog or mysql output processors I use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070304/1394d400/attachment.html>

From dinov at exchange.microsoft.com  Sun Mar  4 21:37:18 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Sun, 4 Mar 2007 12:37:18 -0800
Subject: [IronPython] serialport
In-Reply-To: <200703042212470968160@163.com>
References: <4b1e4fc0703040433s2c558971s5f75f1c500b4d54f@mail.gmail.com>,
	<200703042212470968160@163.com>
Message-ID: <7AD436E4270DD54A94238001769C22276A624808C9@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

You should be able to from System.IO import Ports and then have access to the .NET SerialPort functionality.  Is this not working for you or do you mean something else?

________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of supermeter [supermeter at 163.com]
Sent: Sunday, March 04, 2007 6:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] serialport

I hope IronPython can support Serialport Class.

________________________________
supermeter
2007-03-04
________________________________
???? Karren Sulliver
????? 2007-03-04 20:33:44
???? users at lists.ironpython.com
???
??? [IronPython] update


Hello,

I would like to include a rule when another is triggered, for example:

If this rule is triggered:
drop tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg: "BLEEDING-EDGE
Malware Gator/Clarian Agent"; flow: to_server,established;
uricontent:"/gbsf/gd/ne/new.net.gtrg2ze"; nocase; classtype:
policy-violation; reference:url,
www3.ca.com/securityadvisor/pest/content.aspx?q=67999<http://www3.ca.com/securityadvisor/pest/content.aspx?q=67999>; sid: 2001306;
rev:5;)

I would like to also trigger this rule for n minutes/seconds:
drop tcp any any -> any 80 (classtype:attempted-user; msg:"Port 80
connection initiated";)

I've looked at the tagging option for rules but I need to drop them, not
just log them.

Any ideas?



http://www.webservertalk.com/archive251-2005-12-1314914.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-December/004607.html
http://www.webservertalk.com/archive251-2005-12-1309708.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-December/004731.html
http://lists.ibiblio.org/pipermail/cc-licenses/2004-June/000915.html
http://9fans.net/archive/2005/04/4
http://lists.ibiblio.org/pipermail/cc-licenses/2006-October/004203.html
http://lists.ibiblio.org/pipermail/cc-licenses/2005-March/001764.html
http://www.webservertalk.com/archive251-2005-10-1221632.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-October/004360.html
http://lists.ibiblio.org/pipermail/cc-licenses/2006-October/004454.html
http://9fans.net/archive/2005/04/251
http://lists.ibiblio.org/pipermail/cc-licenses/2007-January/004931.html
http://lists.ibiblio.org/pipermail/cc-licenses/2005-March/001765.html
http://lists.ibiblio.org/pipermail/cc-licenses/2007-January/004931.html
http://root.cern.ch/root/roottalk/roottalk05/2994.html
http://root.cern.ch/root/roottalk/roottalk05/2578.html
http://root.cern.ch/root/roottalk/roottalk04/2681.html
http://9fans.net/archive/2005/04/366
http://root.cern.ch/root/roottalk/roottalk05/2439.html
http://root.cern.ch/root/roottalk/roottalk05/0505.html
http://sourceforge.net/mailarchive/message.php?msg_id=8539894
http://sourceforge.net/mailarchive/forum.php?thread_id=5617912&forum_id=9566
http://lists.us.dell.com/pipermail/dkms-devel/2005-December/000417.html
http://lists.us.dell.com/pipermail/dkms-devel/2005-March/000309.html
http://www.webservertalk.com/archive251-2005-10-1222482.html

Sguil (pronounced sgweel) is built by network security analysts for
network security analysts. Sguil's main component is an intuitive GUI
that provides realtime events from snort/barnyard. It also includes
other components which facilitate the practice of Network Security
Monitoring and event driven analysis of IDS alerts. The sguil client
is written in tcl/tk and can be run on any operating system that
supports tcl/tk (including Linux, *BSD, Solaris, MacOS, and Win32).

Sguil version 0.6.0 contains two significant differences from previous
versions. The first difference is the use of the mysql MRG_MyISAM
(MERGE) engine for the sancp, event, *hdr, and data tables. With the
MERGE engine, it is possible to keep hundreds of millions of rows of
data active and online and still be functional (queries to the DB are
reasonably responsive). The use of MERGE and the associated schema
makes backing up and restoring data amazingly simple and quick. The
UPGRADE text in the sguil-0.6.0/doc directory of the source contains
more detail as well as upgrade instructions.

The second major change was to the sguil output plugin for barnyard
(op_sguil) and the communications structure between the sensors and
sguild. Op_sguil now uses tcl libraries and sends data via localhost
to the sensor's agent. All communications between the sensor and
sguild now flow thru sensor_agent. This means the mysql libraries are
no longer needed on the sensors. Since barnyard does not need to be
compiled with mysql support, op_sguil (barnyard) and mysql 4+ may be
used together without any license conflicts.

http://lists.us.dell.com/pipermail/dkms-devel/2005-December/000425.html
http://lists.ibiblio.org/pipermail/cc-licenses/2005-December/003059.html
http://comments.gmane.org/gmane.comp.java.junit.announce/110
http://9fans.net/archive/2006/08/6
http://9fans.net/archive/2005/03/82
http://9fans.net/archive/2006/08/146
http://blog.gmane.org/gmane.comp.java.junit.announce
http://9fans.net/archive/2006/05/12
http://9fans.net/archive/2005/03/97
http://9fans.net/archive/2006/05/131
http://segate.sunet.se/cgi-bin/wa?A2=ind0409&L=handikapp&P=23681
http://www.tutorials-blog.com/plan9/plan9-26.html
http://9fans.net/archive/2006/05/255
http://www.arcknowledge.com/gmane.comp.lang.c++.root/2004-09/threads.html
http://www.webservertalk.com/archive251-2005-10-1236635.html
http://news.gmane.org/group/gmane.comp.java.junit.announce/last=/force_load=t
http://9fans.net/archive/2006/05/274
http://marc.10east.com/?l=mysap-linux-general&r=1&b=200503&w=1
http://www.webservertalk.com/archive251-2005-9-1188388.html
http://www.webservertalk.com/archive251-2004-9.html
http://www.webservertalk.com/archive251-2005-9-1217604.html
http://9fans.net/archive/2006/12/141

 have just patched snort 2.3.3 with ClamAV-2.3.3-1.diff and it doesn't
seem to work as advertised. I have the following preprocessor line

preprocessor clamav: ports all !20 !22 !443, toclientonly, dbdir
/var/ftp/pub/tools/clamav-devel/share/clamav/, dbreload-time 43200,
file-descriptor-mode

I strace'd snort while downloading EICAR.COM<http://EICAR.COM> and the klez virus from a
remote HTTP server - the strace shows the daily.* files being loaded -
which tells me ClamAV is being enabled - but nothing got detected. I
even ran tcpdump on the same interface and can see the HTTP download -
so it's definitely not a wiring issue either.

I can see tonnes of /tmp/snort_inline-clamav-XXXXXX files being created,
opened,closed and unlinked - but no virus was detected. The summary that
is outputted when snort exits shows zero alerts - and nothing shows up
via the syslog or mysql output processors I use.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070304/99676541/attachment.html>

From xmlhacker at gmail.com  Mon Mar  5 20:29:36 2007
From: xmlhacker at gmail.com (M. David Peterson)
Date: Mon, 5 Mar 2007 12:29:36 -0700
Subject: [IronPython] End of the World? No just end of the line.
In-Reply-To: <45E9CC8F.2000004@defuze.org>
References: <45E9CC8F.2000004@defuze.org>
Message-ID: <eab75e160703051129x545a9b40o1a29c17503f8df50@mail.gmail.com>

I would just like to take a time out to congratulate Sylvain on coming up
with a subject line that brings tears of joy to a phreak-geek like me who
takes pride in coming up with cheezy one-liners such as that so eloquently
displayed in the subject of the original post.

Thanks for the laugh/smile, Sylvain! :D

On 3/3/07, Sylvain Hellegouarch <sh at defuze.org> wrote:
>
> Hi folks,
>
> Working with M. David Peterson trying to run the CherryPy HTTP server on
> IP under Windows we ran into a fairly subtle bug that was actually not
> so subtle at all.
>
> When the server accepts a connection it maps the socket into a file
> object so that it can read and write with a nice API.
>
> When using IPCE socket module this achieves the same by doing this:
>
> def makefile(self, mode='r', bufsize=-1):
>     stream = NetworkStream(self.socket)
>     return file(stream, mode)
>
> This works great when you don't care about the way the end of the lines
> is defined but if you do be ready for some hair-tearing hours.
>
> Indeed with IronPython running on Windows with the .NET framework the
> end of the line is defined as <LF> whereas for instance on Linux with
> Mono it's <CR><LF>.
>
> If I'm not mistaken CPython always ensures the end of line is <CR><LF>
> so that people don't have to worry about the underlying OS behavior.
>
> The problem I faced is that HTTP marks the end of the header lists via a
> <CR><LF> but because CherryPy reads the socket as a file it only gets a
> <LF> with IP under Windows and therefore fails miserably. I've added a
> test for a single <LF> in my copy of CherryPy and it fixed the problem.
> But this is a bit of a hassle.
>
> I don't think there is a bug of any of the part here. However I believe
> there should be either a very clear warning that this difference will
> always exists and Python developer will have to check for that case, or
> maybe IP should find a way to ensure that <CR><LF> is always returned
> even under Windows (which I doubt is an easy thing to do).
>
> In any case if your code depends on the line ending be aware of that
> difference as you could end up swearing too loud for your own good.
>
> - Sylvain
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070305/e2098301/attachment.html>

From xmlhacker at gmail.com  Mon Mar  5 20:48:09 2007
From: xmlhacker at gmail.com (M. David Peterson)
Date: Mon, 5 Mar 2007 12:48:09 -0700
Subject: [IronPython] End of the World? No just end of the line.
In-Reply-To: <eab75e160703051129x545a9b40o1a29c17503f8df50@mail.gmail.com>
References: <45E9CC8F.2000004@defuze.org>
	<eab75e160703051129x545a9b40o1a29c17503f8df50@mail.gmail.com>
Message-ID: <eab75e160703051148q7347196doef9e850215f2515@mail.gmail.com>

Oh, and if any of you want to play with the result of Sylvain's sleuth
detective work coupled with our ongoing hybrid efforts to merge Amplee with
AtomicXML, you can access a ClickOnce app** @
http://xameleon.org/webapp/publish.htm

>From the commandline,

>>> from cherrypyserver import server

Which will result in,

Creating APP store
> Creating the service WSGI application
> Creating the collection WSGI application
> All good!
>

>>> server.start()

Will then allow access to http://localhost:9999/ at which point you will
receive,

<?xml version="1.0" encoding="utf-8"?>
<atom:feed xmlns:atom="http://www.w3.org/2005/Atom">
  <atom:id>urn:uuid:7d971f07-acb2-50e2-bec6-33c283572247</atom:id>
  <atom:updated>2007-03-05T19:42:53.125000Z</atom:updated>
  <atom:title type="text">My Music</atom:title>
</atom:feed>

in response.

Please see  http://trac.defuze.org/wiki/amplee for extended detail on where
to go from here.
Please see
http://www.oreillynet.com/xml/blog/2007/02/week_8_open_source_xml_weekly.htmland
http://www.oreillynet.com/xml/blog/2007/02/week_7_open_source_xml_weekly.htmlfor
extended detail as to where we're taking all of this.

Code is @ http://extf.googlecode.com/svn/trunk/WebApp for a standalone
version of the above that works on any .NET-enabled client (MS.NET or Mono:
both work equally as well, and in fact it was the fact that it worked with
Mono and did not with MS.NET that led to Sylvain's discovery and fix
mentioned at the start of this thread.  Mono helping to discover and solve
MS.NET <~> Unix* incompatibility issues > I *LOVE* IT! :D)

ClickOnce app is @ http://extf.googlecode.com/svn/trunk/Xameleon.ClickOnce/

Get all of this integrated into a nice, simple, and clean browser-based UI
is on tap for today.  When in decent demoable shape, one of us will update
this thread.


** From within Internet Explorer > I tried the ClickOnce Fx plugin suggested
on this list a while back, and could never get it to work > Any ideas from
any of you out there?)

On 3/5/07, M. David Peterson <xmlhacker at gmail.com> wrote:
>
> I would just like to take a time out to congratulate Sylvain on coming up
> with a subject line that brings tears of joy to a phreak-geek like me who
> takes pride in coming up with cheezy one-liners such as that so eloquently
> displayed in the subject of the original post.
>
> Thanks for the laugh/smile, Sylvain! :D
>
> On 3/3/07, Sylvain Hellegouarch <sh at defuze.org> wrote:
> >
> > Hi folks,
> >
> > Working with M. David Peterson trying to run the CherryPy HTTP server on
> > IP under Windows we ran into a fairly subtle bug that was actually not
> > so subtle at all.
> >
> > When the server accepts a connection it maps the socket into a file
> > object so that it can read and write with a nice API.
> >
> > When using IPCE socket module this achieves the same by doing this:
> >
> > def makefile(self, mode='r', bufsize=-1):
> >     stream = NetworkStream(self.socket )
> >     return file(stream, mode)
> >
> > This works great when you don't care about the way the end of the lines
> > is defined but if you do be ready for some hair-tearing hours.
> >
> > Indeed with IronPython running on Windows with the .NET framework the
> > end of the line is defined as <LF> whereas for instance on Linux with
> > Mono it's <CR><LF>.
> >
> > If I'm not mistaken CPython always ensures the end of line is <CR><LF>
> > so that people don't have to worry about the underlying OS behavior.
> >
> > The problem I faced is that HTTP marks the end of the header lists via a
> > <CR><LF> but because CherryPy reads the socket as a file it only gets a
> > <LF> with IP under Windows and therefore fails miserably. I've added a
> > test for a single <LF> in my copy of CherryPy and it fixed the problem.
> > But this is a bit of a hassle.
> >
> > I don't think there is a bug of any of the part here. However I believe
> > there should be either a very clear warning that this difference will
> > always exists and Python developer will have to check for that case, or
> > maybe IP should find a way to ensure that <CR><LF> is always returned
> > even under Windows (which I doubt is an easy thing to do).
> >
> > In any case if your code depends on the line ending be aware of that
> > difference as you could end up swearing too loud for your own good.
> >
> > - Sylvain
> > _______________________________________________
> > users mailing list
> > users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
>
>
>
> --
> /M:D
>
> M. David Peterson
> http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
> http://dev.aol.com/blog/3155




-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070305/920f476f/attachment.html>

From oliyu at yahoo.com  Tue Mar  6 01:39:50 2007
From: oliyu at yahoo.com (Oliver Yu)
Date: Mon, 5 Mar 2007 16:39:50 -0800 (PST)
Subject: [IronPython] An implementation bug in itertools?
Message-ID: <120913.61188.qm@web33105.mail.mud.yahoo.com>

Try:

 

from itertools 
import *

l = 
[1,2,3,4,5,6]
i = iter(l)
for x,y in izip(i,i):
    print "%d %d" % 
(x,y)

 

Under CPython you 
get the expected:

1 2
3 4
5 
6

 

Under IronPython I 
got:

2 2
4 4
6 
6

 

This is under: 
IronPython console: IronPython 1.1a1 (1.1) on .NET 
2.0.50727.42

 
Oli





From haiboluo at exchange.microsoft.com  Tue Mar  6 01:59:33 2007
From: haiboluo at exchange.microsoft.com (Haibo Luo)
Date: Mon, 5 Mar 2007 16:59:33 -0800
Subject: [IronPython] An implementation bug in itertools?
In-Reply-To: <120913.61188.qm@web33105.mail.mud.yahoo.com>
References: <120913.61188.qm@web33105.mail.mud.yahoo.com>
Message-ID: <B5F2A8845315C94E838A0901C3A036B9679D15D400@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for the bug report. I filed it as http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8678.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Oliver Yu
Sent: Monday, March 05, 2007 4:40 PM
To: users at lists.ironpython.com
Subject: [IronPython] An implementation bug in itertools?

Try:



from itertools
import *

l =
[1,2,3,4,5,6]
i = iter(l)
for x,y in izip(i,i):
    print "%d %d" %
(x,y)



Under CPython you
get the expected:

1 2
3 4
5
6



Under IronPython I
got:

2 2
4 4
6
6



This is under:
IronPython console: IronPython 1.1a1 (1.1) on .NET
2.0.50727.42


Oli



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


From davidjensen at usa.net  Wed Mar  7 01:21:54 2007
From: davidjensen at usa.net (David Jensen)
Date: Tue, 06 Mar 2007 19:21:54 -0500
Subject: [IronPython] windows mobile 5
Message-ID: <419Lcgau34918S06.1173226914@cmsweb06.cms.usa.net>

Does IronPython work in windows mobile 5. If so, how do I get it over there
with vs 2005 $200 edition (comes with ce emulator)?


David Jensen
Apartment 412
414 West 120th Street
New York, New York 10027
212-866-7094 
646-245-2654 (cell)
206-984-4900 (fax to email)
davidjensen at usa.net
 




From dinov at exchange.microsoft.com  Wed Mar  7 01:53:10 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 6 Mar 2007 16:53:10 -0800
Subject: [IronPython] windows mobile 5
In-Reply-To: <419Lcgau34918S06.1173226914@cmsweb06.cms.usa.net>
References: <419Lcgau34918S06.1173226914@cmsweb06.cms.usa.net>
Message-ID: <7AD436E4270DD54A94238001769C22276A624808D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Unfortunately the answer is no.  We don't work w/ the Compact Framework which is what I believe ships w/ all versions of Windows Mobile.  The problem here is that the Compact Framework is missing the Reflection.Emit APIs that we need for code generation.

________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of David Jensen [davidjensen at usa.net]
Sent: Tuesday, March 06, 2007 4:21 PM
To: users at lists.ironpython.com
Subject: [IronPython] windows mobile 5

Does IronPython work in windows mobile 5. If so, how do I get it over there
with vs 2005 $200 edition (comes with ce emulator)?


David Jensen
Apartment 412
414 West 120th Street
New York, New York 10027
212-866-7094
646-245-2654 (cell)
206-984-4900 (fax to email)
davidjensen at usa.net



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


From redmoon17 at gmail.com  Wed Mar  7 09:15:19 2007
From: redmoon17 at gmail.com (Kevin Chu)
Date: Wed, 7 Mar 2007 16:15:19 +0800
Subject: [IronPython] windows mobile 5
In-Reply-To: <7AD436E4270DD54A94238001769C22276A624808D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <419Lcgau34918S06.1173226914@cmsweb06.cms.usa.net>
	<7AD436E4270DD54A94238001769C22276A624808D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <41d7f4a90703070015m3123b82eob1f6c660c43f51a9@mail.gmail.com>

Can we use Mono Cecil to help IronPython generate code?

On 3/7/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
>
> Unfortunately the answer is no.  We don't work w/ the Compact Framework
> which is what I believe ships w/ all versions of Windows Mobile.  The
> problem here is that the Compact Framework is missing the Reflection.EmitAPIs that we need for code generation.
>
> ________________________________________
> From: users-bounces at lists.ironpython.com [
> users-bounces at lists.ironpython.com] On Behalf Of David Jensen [
> davidjensen at usa.net]
> Sent: Tuesday, March 06, 2007 4:21 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] windows mobile 5
>
> Does IronPython work in windows mobile 5. If so, how do I get it over
> there
> with vs 2005 $200 edition (comes with ce emulator)?
>
>
> David Jensen
> Apartment 412
> 414 West 120th Street
> New York, New York 10027
> 212-866-7094
> 646-245-2654 (cell)
> 206-984-4900 (fax to email)
> davidjensen at usa.net
>
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
Once in a Redmoon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070307/d6dd49fa/attachment.html>

From sh at defuze.org  Wed Mar  7 15:14:39 2007
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 07 Mar 2007 14:14:39 +0000
Subject: [IronPython] Metaclass bug?
Message-ID: <45EEC8CF.8050800@defuze.org>

The following code:

class C(object):
    pass

class Meta(type):
    pass

class A(object):
    __metaclass__ = Meta

    def __init__(self, e, s):
        print "__init__ A"

    def __call__(self, e, s):
        print "__call__ A"

class B(object):
    def mount(self, c):
        a = A(c, "")

if __name__ == '__main__':
    b = B()
    b.mount(C())


=============================================
Python 2.5
$ python test.py
__init__ A

=============================================
IronPython 1.1b1 (1.1) on .NET 2.0.50727.42
$ mono bin/ipy.exe test.py
Traceback (most recent call last):
  File test, line unknown, in Initialize
  File test, line unknown, in mount
TypeError: unbound method __call__() must be called with A instance as
first argument (got C instance instead)


It appears that because of the meta-class IP gets confused as to what to
call since the __init__ and __call__ gave the same signature.

- Sylvain



From dans at houmus.org  Wed Mar  7 15:27:09 2007
From: dans at houmus.org (Dan Shechter)
Date: Wed, 7 Mar 2007 16:27:09 +0200
Subject: [IronPython] IronPython / Unicode / os.walk
Message-ID: <001001c760c4$b2cca100$1865e300$@org>

Hi everyone,
I'm using IP 1.0 trying to make some CPython code work as expected.
I'm trying to write a Unicode string using the following piece of code:

 (UTF8_encode, UTF8_decode, UTF8_streamreader, UTF8_streamwriter) =
codecs.lookup('UTF-8')
cache_file_obj = UTF8_streamwriter(open(cache_file , 'wb'))
cache_file_obj.writelines(cache_data)

where CPython is capable of executing codecs.lookup() successfully and IP
returns:
>>> codecs.lookup("UTF-8")
Traceback (most recent call last):
  File , line 0, in <stdin>##89
  File , line 0, in Lookup##78
LookupError: unknown encoding: UTF-8

Suggestions, alternatives?



From jjl at pobox.com  Wed Mar  7 16:31:13 2007
From: jjl at pobox.com (John J Lee)
Date: Wed, 7 Mar 2007 15:31:13 +0000 (GMT Standard Time)
Subject: [IronPython] IronPython / Unicode / os.walk
In-Reply-To: <001001c760c4$b2cca100$1865e300$@org>
References: <001001c760c4$b2cca100$1865e300$@org>
Message-ID: <Pine.WNT.4.64.0703071530380.4452@shaolin>

On Wed, 7 Mar 2007, Dan Shechter wrote:
[...]
>>>> codecs.lookup("UTF-8")
> Traceback (most recent call last):
>  File , line 0, in <stdin>##89
>  File , line 0, in Lookup##78
> LookupError: unknown encoding: UTF-8
>
> Suggestions, alternatives?

Did you try 'utf-8' (i.e. lowercase)?


John


From luismgz at gmail.com  Wed Mar  7 16:28:21 2007
From: luismgz at gmail.com (luismg)
Date: Wed, 07 Mar 2007 15:28:21 -0000
Subject: [IronPython] DataGridView and Ironpython
Message-ID: <1173281301.329826.253260@8g2000cwh.googlegroups.com>

I'm having problems with this control.
I tried to replicate many examples of datagridview usage from C# to
Ironpython, but so far I failed misserably...
I wonder if it's currently possible to use this control from
ironpython.
I tried displaying simple collections (python's, arraylists,
generics...) but none of them seem to work.

I'm not talking about object instances, which I know they cannot be
displayed due to some properties problem, but simple records from
collections.

I tried setting different collections as datasources or adding arrays
as rows, but nothing seemed to work.
I don't know much about informs or databinding, so I'm probably
missing something...

If possible, I would highly appreciate if someone shows me a simple
example.
Also, I'd like to know if someone succeded displaying data on a
datagridview while using the dbapi wrapper instead of plain ADO.NET.

Thanks in advance!
Luis



From dinov at exchange.microsoft.com  Wed Mar  7 17:51:04 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 7 Mar 2007 08:51:04 -0800
Subject: [IronPython] IronPython / Unicode / os.walk
In-Reply-To: <Pine.WNT.4.64.0703071530380.4452@shaolin>
References: <001001c760c4$b2cca100$1865e300$@org>
	<Pine.WNT.4.64.0703071530380.4452@shaolin>
Message-ID: <7AD436E4270DD54A94238001769C22276A624C7CDD@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

I think we'll also accept utf_8 or utf8.  This is basically covered under this bug http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3094  (although the description doesn't make it entirely obvious).

If you could vote on the bug it'd help raise the visibility of the issue and we'll get to it sooner.

Thanks for reporting this!

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of John J Lee
Sent: Wednesday, March 07, 2007 7:31 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython / Unicode / os.walk

On Wed, 7 Mar 2007, Dan Shechter wrote:
[...]
>>>> codecs.lookup("UTF-8")
> Traceback (most recent call last):
>  File , line 0, in <stdin>##89
>  File , line 0, in Lookup##78
> LookupError: unknown encoding: UTF-8
>
> Suggestions, alternatives?

Did you try 'utf-8' (i.e. lowercase)?


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


From dinov at exchange.microsoft.com  Wed Mar  7 17:58:42 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 7 Mar 2007 08:58:42 -0800
Subject: [IronPython] Metaclass bug?
In-Reply-To: <45EEC8CF.8050800@defuze.org>
References: <45EEC8CF.8050800@defuze.org>
Message-ID: <7AD436E4270DD54A94238001769C22276A624C7CE6@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for reporting this Sylvain.  I believe this is the same or very similar to bug #7594 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7594).

The good news is that this is fixed in our internal v2.0 branch.  The bad news is the fix was close to re-writing the type system (also fixing type(type) is type).  That makes it fairly unlikely that we'll be able to back port this to v1.x without seriously destabilizing it.  But it will be fixed in the future.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch
Sent: Wednesday, March 07, 2007 6:15 AM
To: Discussion of IronPython
Subject: [IronPython] Metaclass bug?

The following code:

class C(object):
    pass

class Meta(type):
    pass

class A(object):
    __metaclass__ = Meta

    def __init__(self, e, s):
        print "__init__ A"

    def __call__(self, e, s):
        print "__call__ A"

class B(object):
    def mount(self, c):
        a = A(c, "")

if __name__ == '__main__':
    b = B()
    b.mount(C())


=============================================
Python 2.5
$ python test.py
__init__ A

=============================================
IronPython 1.1b1 (1.1) on .NET 2.0.50727.42
$ mono bin/ipy.exe test.py
Traceback (most recent call last):
  File test, line unknown, in Initialize
  File test, line unknown, in mount
TypeError: unbound method __call__() must be called with A instance as
first argument (got C instance instead)


It appears that because of the meta-class IP gets confused as to what to
call since the __init__ and __call__ gave the same signature.

- Sylvain

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


From sh at defuze.org  Wed Mar  7 18:13:27 2007
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 07 Mar 2007 17:13:27 +0000
Subject: [IronPython] Metaclass bug?
In-Reply-To: <7AD436E4270DD54A94238001769C22276A624C7CE6@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <45EEC8CF.8050800@defuze.org>
	<7AD436E4270DD54A94238001769C22276A624C7CE6@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <45EEF2B7.5030600@defuze.org>

Dino Viehland wrote:
> Thanks for reporting this Sylvain.  I believe this is the same or very similar to bug #7594 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7594).
> 
> The good news is that this is fixed in our internal v2.0 branch.  The bad news is the fix was close to re-writing the type system (also fixing type(type) is type).  That makes it fairly unlikely that we'll be able to back port this to v1.x without seriously destabilizing it.  But it will be fixed in the future.
> 

I like that good news but less the bad one :p
I can live with it for now. You would not have a rough idea as to when
you plan v2.0 for roughly?

- Sylvain

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch
> Sent: Wednesday, March 07, 2007 6:15 AM
> To: Discussion of IronPython
> Subject: [IronPython] Metaclass bug?
> 
> The following code:
> 
> class C(object):
>     pass
> 
> class Meta(type):
>     pass
> 
> class A(object):
>     __metaclass__ = Meta
> 
>     def __init__(self, e, s):
>         print "__init__ A"
> 
>     def __call__(self, e, s):
>         print "__call__ A"
> 
> class B(object):
>     def mount(self, c):
>         a = A(c, "")
> 
> if __name__ == '__main__':
>     b = B()
>     b.mount(C())
> 
> 
> =============================================
> Python 2.5
> $ python test.py
> __init__ A
> 
> =============================================
> IronPython 1.1b1 (1.1) on .NET 2.0.50727.42
> $ mono bin/ipy.exe test.py
> Traceback (most recent call last):
>   File test, line unknown, in Initialize
>   File test, line unknown, in mount
> TypeError: unbound method __call__() must be called with A instance as
> first argument (got C instance instead)
> 
> 
> It appears that because of the meta-class IP gets confused as to what to
> call since the __init__ and __call__ gave the same signature.
> 
> - Sylvain
> 
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From dinov at exchange.microsoft.com  Wed Mar  7 19:46:44 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 7 Mar 2007 10:46:44 -0800
Subject: [IronPython] Metaclass bug?
In-Reply-To: <45EEF2B7.5030600@defuze.org>
References: <45EEC8CF.8050800@defuze.org>
	<7AD436E4270DD54A94238001769C22276A624C7CE6@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<45EEF2B7.5030600@defuze.org>
Message-ID: <7AD436E4270DD54A94238001769C22276A624C7DC4@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

We're actively working on it now and you should see something in Alpha form by the summer at the very latest.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch
Sent: Wednesday, March 07, 2007 9:13 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Metaclass bug?

Dino Viehland wrote:
> Thanks for reporting this Sylvain.  I believe this is the same or very similar to bug #7594 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7594).
>
> The good news is that this is fixed in our internal v2.0 branch.  The bad news is the fix was close to re-writing the type system (also fixing type(type) is type).  That makes it fairly unlikely that we'll be able to back port this to v1.x without seriously destabilizing it.  But it will be fixed in the future.
>

I like that good news but less the bad one :p
I can live with it for now. You would not have a rough idea as to when
you plan v2.0 for roughly?

- Sylvain

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch
> Sent: Wednesday, March 07, 2007 6:15 AM
> To: Discussion of IronPython
> Subject: [IronPython] Metaclass bug?
>
> The following code:
>
> class C(object):
>     pass
>
> class Meta(type):
>     pass
>
> class A(object):
>     __metaclass__ = Meta
>
>     def __init__(self, e, s):
>         print "__init__ A"
>
>     def __call__(self, e, s):
>         print "__call__ A"
>
> class B(object):
>     def mount(self, c):
>         a = A(c, "")
>
> if __name__ == '__main__':
>     b = B()
>     b.mount(C())
>
>
> =============================================
> Python 2.5
> $ python test.py
> __init__ A
>
> =============================================
> IronPython 1.1b1 (1.1) on .NET 2.0.50727.42
> $ mono bin/ipy.exe test.py
> Traceback (most recent call last):
>   File test, line unknown, in Initialize
>   File test, line unknown, in mount
> TypeError: unbound method __call__() must be called with A instance as
> first argument (got C instance instead)
>
>
> It appears that because of the meta-class IP gets confused as to what to
> call since the __init__ and __call__ gave the same signature.
>
> - Sylvain
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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


From sh at defuze.org  Wed Mar  7 19:50:20 2007
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 07 Mar 2007 18:50:20 +0000
Subject: [IronPython] Metaclass bug?
In-Reply-To: <7AD436E4270DD54A94238001769C22276A624C7DC4@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <45EEC8CF.8050800@defuze.org>	<7AD436E4270DD54A94238001769C22276A624C7CE6@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<45EEF2B7.5030600@defuze.org>
	<7AD436E4270DD54A94238001769C22276A624C7DC4@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <45EF096C.9050005@defuze.org>

Dino Viehland wrote:
> We're actively working on it now and you should see something in Alpha form by the summer at the very latest.
> 

Thanks :)
That does sound promising.

- Sylvain


From fireonyoursleeve at hotmail.com  Wed Mar  7 20:27:31 2007
From: fireonyoursleeve at hotmail.com (Aaron Leiby)
Date: Wed, 7 Mar 2007 11:27:31 -0800
Subject: [IronPython] ValueTypes
References: <45EEC8CF.8050800@defuze.org>	<7AD436E4270DD54A94238001769C22276A624C7CE6@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<45EEF2B7.5030600@defuze.org><7AD436E4270DD54A94238001769C22276A624C7DC4@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<45EF096C.9050005@defuze.org>
Message-ID: <BAY106-DAV19E22010DBFCD577E40C76CB7A0@phx.gbl>

Just started using IronPython - playing with XNA.

Digging up a couple old threads:
http://lists.ironpython.com/htdig.cgi/users-ironpython.com/2006-May/002265.html
http://lists.ironpython.com/htdig.cgi/users-ironpython.com/2005-May/000651.html
etc. and
http://channel9.msdn.com/wiki/default.aspx/IronPython.ValueTypes

Can new value types (i.e. structs) be declared in IronPython?  If so, what 
defines the data layout.  Like for instance if I want to create a new 
VertextDeclaration.

What's the current status of a[i].x = n?  Well, the current status is it 
throws an exception warning you that it cannot be modified.  What's the 
proper way to update elements in an array?  Is it possible to do without 
replacing the entire element?  I'm currently using a.SetItem(i, 
Element(a[i].UnchangedValues, n)).

For now, I've moved my vertex declarations back into C#, and since I care 
about performance in the update loop, I should probably push that back into 
C# as well, avoiding these issues entirely.

There's no way to partially implement a class across the language 
boundaries, is there?  (Since they would need to span assemblies?)  Anything 
that needs to get pushed back to C# for performance reasons will need to 
have any required member data pass along, correct?

Thanks for bearing with these newb questions. 



From Martin.Maly at microsoft.com  Wed Mar  7 21:55:19 2007
From: Martin.Maly at microsoft.com (Martin Maly)
Date: Wed, 7 Mar 2007 12:55:19 -0800
Subject: [IronPython] ValueTypes
In-Reply-To: <BAY106-DAV19E22010DBFCD577E40C76CB7A0@phx.gbl>
References: <45EEC8CF.8050800@defuze.org>
	<7AD436E4270DD54A94238001769C22276A624C7CE6@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<45EEF2B7.5030600@defuze.org><7AD436E4270DD54A94238001769C22276A624C7DC4@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<45EF096C.9050005@defuze.org>
	<BAY106-DAV19E22010DBFCD577E40C76CB7A0@phx.gbl>
Message-ID: <C80B82844D92F64FA5D3B4790737D18D799AD7FDC5@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

New value types cannot be defined in IronPython, you can only instantiate and use existing ones.

The a[i].x = n does throw and it is not possible to achieve this without replacing the whole array element. Essentially, for IronPython, value types are immutable and they can only be copied as a whole.

Alternative to what you are doing with a.SetItem, could be (but it ultimately ends up doing pretty much the same operation):

a[i] = new MyValueType(a[i].UnchangedValues, n)

Partial class implementation cross language is not possible in the "partial class" C# sense. However since you can inherit from .NET class in IronPython, you could perhaps achieve what you need through inheritance.

Martin


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Aaron Leiby
Sent: Wednesday, March 07, 2007 11:28 AM
To: Discussion of IronPython
Subject: [IronPython] ValueTypes

Just started using IronPython - playing with XNA.

Digging up a couple old threads:
http://lists.ironpython.com/htdig.cgi/users-ironpython.com/2006-May/002265.html
http://lists.ironpython.com/htdig.cgi/users-ironpython.com/2005-May/000651.html
etc. and
http://channel9.msdn.com/wiki/default.aspx/IronPython.ValueTypes

Can new value types (i.e. structs) be declared in IronPython?  If so, what
defines the data layout.  Like for instance if I want to create a new
VertextDeclaration.

What's the current status of a[i].x = n?  Well, the current status is it
throws an exception warning you that it cannot be modified.  What's the
proper way to update elements in an array?  Is it possible to do without
replacing the entire element?  I'm currently using a.SetItem(i,
Element(a[i].UnchangedValues, n)).

For now, I've moved my vertex declarations back into C#, and since I care
about performance in the update loop, I should probably push that back into
C# as well, avoiding these issues entirely.

There's no way to partially implement a class across the language
boundaries, is there?  (Since they would need to span assemblies?)  Anything
that needs to get pushed back to C# for performance reasons will need to
have any required member data pass along, correct?

Thanks for bearing with these newb questions.

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


From fuzzyman at voidspace.org.uk  Wed Mar  7 22:46:27 2007
From: fuzzyman at voidspace.org.uk (fuzzyman at voidspace.org.uk)
Date: Wed, 7 Mar 2007 21:46:27 +0000
Subject: [IronPython] Embedding IronPython
Message-ID: <20070307214627.XAJR29112.aamtaout04-winn.ispmail.ntl.com@[192.168.1.100]>

{ran_emo} I've put another IronPython article up. It is a simple example of embedding the IronPython engine into a dotnet application. 

* `Embedding IronPython <embedding.shtml>`_

     In this example (taken from the `Tabbed Image Viewer <http://code.google.com/p/tabbedimages/>`_) IronPython is embedded in C# to create a custom executable.

Tonight I'm leaving to attend a `Polish Academic Student Conference <http://www.sfi.org.pl/agenda>`_ [#]_, to talk about IronPython. Hopefully see you there. {sm;:wink:}

Oh - and if you're interested in the possibility of being an intern at Resolver this summer, stay tuned for an announcement about how to apply *soon*.

.. [#] Organised by Jan, one of our interns from last summer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070307/cf85fac6/attachment.html>

From scarabx at gmail.com  Wed Mar  7 22:54:30 2007
From: scarabx at gmail.com (=?WINDOWS-1252?Q?StRyder=99?=)
Date: Wed, 7 Mar 2007 16:54:30 -0500
Subject: [IronPython] Embedding IronPython
In-Reply-To: <20070307214627.XAJR29112.aamtaout04-winn.ispmail.ntl.com@192.168.1.100>
References: <20070307214627.XAJR29112.aamtaout04-winn.ispmail.ntl.com@192.168.1.100>
Message-ID: <eeafd0c70703071354vbac4b94n8e3dae99dfcbcf17@mail.gmail.com>

I'm getting a 404 Not Found on the article link.

On 3/7/07, fuzzyman at voidspace.org.uk <fuzzyman at voidspace.org.uk> wrote:
>
>  Embedding IronPython
>
> [image: emoticon:black_hat] I've put another IronPython article up. It is
> a simple example of embedding the IronPython engine into a dotnet
> application.
>
>    -
>
>    Embedding IronPython<http://www.voidspace.org.uk/python/weblog/embedding.shtml>
>
>    In this example (taken from the Tabbed Image Viewer<http://code.google.com/p/tabbedimages/>)
>    IronPython is embedded in C# to create a custom executable.
>
>
> Tonight I'm leaving to attend a Polish Academic Student Conference<http://www.sfi.org.pl/agenda>
> [1] <http://www.voidspace.org.uk/python/weblog/index.shtml#e655id2>, to
> talk about IronPython. Hopefully see you there. [image: Wink]
>
> Oh - and if you're interested in the possibility of being an intern at
> Resolver this summer, stay tuned for an announcement about how to apply *
> soon*.
>   [1] <http://www.voidspace.org.uk/python/weblog/index.shtml#e655id1>Organised
> by Jan, one of our interns from last summer.
>
> Posted by *Fuzzyman* on 2007-03-07 21:21:43.
> Categories: IronPython<http://www.voidspace.org.uk/python/weblog/arch_IronPython.shtml>,
> General Programming<http://www.voidspace.org.uk/python/weblog/arch_General%20Programming.shtml>,
> Python <http://www.voidspace.org.uk/python/weblog/arch_Python.shtml>,
> Writing <http://www.voidspace.org.uk/python/weblog/arch_Writing.shtml>
> Visit the Voidspace Techie Blog<http://www.voidspace.org.uk/python/weblog/index.shtml>to read this entry and more.
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


-- 
"I can calculate the movement of the stars, but not the madness of men."
- Sir Isaac Newton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070307/53583312/attachment.html>

From fuzzyman at voidspace.org.uk  Wed Mar  7 22:56:52 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 07 Mar 2007 21:56:52 +0000
Subject: [IronPython] Embedding IronPython
In-Reply-To: <eeafd0c70703071354vbac4b94n8e3dae99dfcbcf17@mail.gmail.com>
References: <20070307214627.XAJR29112.aamtaout04-winn.ispmail.ntl.com@192.168.1.100>
	<eeafd0c70703071354vbac4b94n8e3dae99dfcbcf17@mail.gmail.com>
Message-ID: <45EF3524.7030309@voidspace.org.uk>

StRyder? wrote:
> I'm getting a 404 Not Found on the article link.
*damn* - copy and paste error.

http://www.voidspace.org.uk/ironpython/embedding.shtml

Sorry.

Fuzzyman


>
>
> On 3/7/07, *fuzzyman at voidspace.org.uk 
> <mailto:fuzzyman at voidspace.org.uk>* < fuzzyman at voidspace.org.uk 
> <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>
>         Embedding IronPython
>
>     emoticon:black_hat I've put another IronPython article up. It is a
>     simple example of embedding the IronPython engine into a dotnet
>     application.
>
>        *
>
>           Embedding IronPython
>           <http://www.voidspace.org.uk/python/weblog/embedding.shtml>
>
>               In this example (taken from the Tabbed Image Viewer
>               <http://code.google.com/p/tabbedimages/>) IronPython is
>               embedded in C# to create a custom executable.
>
>     Tonight I'm leaving to attend a Polish Academic Student Conference
>     <http://www.sfi.org.pl/agenda> [1]
>     <http://www.voidspace.org.uk/python/weblog/index.shtml#e655id2>,
>     to talk about IronPython. Hopefully see you there. Wink
>
>     Oh - and if you're interested in the possibility of being an
>     intern at Resolver this summer, stay tuned for an announcement
>     about how to apply /soon/.
>
>     [1]
>     <http://www.voidspace.org.uk/python/weblog/index.shtml#e655id1>
>     Organised by Jan, one of our interns from last summer.
>
>     Posted by *Fuzzyman* on 2007-03-07 21:21:43.
>     Categories: IronPython
>     <http://www.voidspace.org.uk/python/weblog/arch_IronPython.shtml>,
>     General Programming
>     <http://www.voidspace.org.uk/python/weblog/arch_General%20Programming.shtml>,
>     Python
>     <http://www.voidspace.org.uk/python/weblog/arch_Python.shtml>,
>     Writing
>     <http://www.voidspace.org.uk/python/weblog/arch_Writing.shtml>
>     Visit the Voidspace Techie Blog
>     <http://www.voidspace.org.uk/python/weblog/index.shtml> to read
>     this entry and more.
>
>
>     _______________________________________________
>     users mailing list
>     users at lists.ironpython.com <mailto:users at lists.ironpython.com>
>     http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>
> -- 
> "I can calculate the movement of the stars, but not the madness of men."
> - Sir Isaac Newton
> ------------------------------------------------------------------------
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   



From scarabx at gmail.com  Thu Mar  8 00:15:43 2007
From: scarabx at gmail.com (=?WINDOWS-1252?Q?StRyder=99?=)
Date: Wed, 7 Mar 2007 18:15:43 -0500
Subject: [IronPython] Embedding IronPython
In-Reply-To: <45EF3524.7030309@voidspace.org.uk>
References: <20070307214627.XAJR29112.aamtaout04-winn.ispmail.ntl.com@192.168.1.100>
	<eeafd0c70703071354vbac4b94n8e3dae99dfcbcf17@mail.gmail.com>
	<45EF3524.7030309@voidspace.org.uk>
Message-ID: <eeafd0c70703071515y7c200d49pff51be082f48700c@mail.gmail.com>

Awesome! Thanks man

On 3/7/07, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>
> StRyder? wrote:
> > I'm getting a 404 Not Found on the article link.
> *damn* - copy and paste error.
>
> http://www.voidspace.org.uk/ironpython/embedding.shtml
>
> Sorry.
>
> Fuzzyman
>
>
>
-- 
"I can calculate the movement of the stars, but not the madness of men."
- Sir Isaac Newton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070307/a61f8cbe/attachment.html>

From dans at houmus.org  Thu Mar  8 00:29:17 2007
From: dans at houmus.org (Dan Shechter)
Date: Thu, 8 Mar 2007 01:29:17 +0200
Subject: [IronPython] IronPython / Unicode / os.walk
In-Reply-To: <7AD436E4270DD54A94238001769C22276A624C7CDD@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <001001c760c4$b2cca100$1865e300$@org>	<Pine.WNT.4.64.0703071530380.4452@shaolin>
	<7AD436E4270DD54A94238001769C22276A624C7CDD@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <002901c76110$6e4a69d0$4adf3d70$@org>

Well, right now (1.0) neither UTF-8, utf-8, utf8 nor utf_8 seem to be
working...

So I take it there's not much than to sit and wait right now?
Does 1.1B1 help me?

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Wednesday, March 07, 2007 18:51
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython / Unicode / os.walk

I think we'll also accept utf_8 or utf8.  This is basically covered under
this bug
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3094
(although the description doesn't make it entirely obvious).

If you could vote on the bug it'd help raise the visibility of the issue and
we'll get to it sooner.

Thanks for reporting this!

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of John J Lee
Sent: Wednesday, March 07, 2007 7:31 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython / Unicode / os.walk

On Wed, 7 Mar 2007, Dan Shechter wrote:
[...]
>>>> codecs.lookup("UTF-8")
> Traceback (most recent call last):
>  File , line 0, in <stdin>##89
>  File , line 0, in Lookup##78
> LookupError: unknown encoding: UTF-8
>
> Suggestions, alternatives?

Did you try 'utf-8' (i.e. lowercase)?


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



From szport at gmail.com  Thu Mar  8 07:43:59 2007
From: szport at gmail.com (Andrew)
Date: Thu, 8 Mar 2007 09:43:59 +0300
Subject: [IronPython] IronPython / Unicode / os.walk
In-Reply-To: <002901c76110$6e4a69d0$4adf3d70$@org>
References: <001001c760c4$b2cca100$1865e300$@org>
	<Pine.WNT.4.64.0703071530380.4452@shaolin>
	<7AD436E4270DD54A94238001769C22276A624C7CDD@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<002901c76110$6e4a69d0$4adf3d70$@org>
Message-ID: <e2a7590703072243k69caae75xcc56459926610cca@mail.gmail.com>

This is working in IP 1.1b1:

C:\IronPython>ipy.exe
IronPython 1.1b1 (1.1) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import sys
>>> sys.path.append(r'c:\Python24\Lib')
>>> from encodings import codecs
>>> codecs
<module 'codecs' from 'c:\Python24\Lib\codecs.py'>
>>> codecs.lookup('utf-8')
(<built-in function utf_8_encode>, <function decode at 0x000000000000002B>,
<class encodings.utf_8.StreamReader at 0x000000000000002C>, <class
encodings.utf_8.StreamWriter at 0x000000000000002D>)
>>>

Andrew

2007/3/8, Dan Shechter <dans at houmus.org>:
>
> Well, right now (1.0) neither UTF-8, utf-8, utf8 nor utf_8 seem to be
> working...
>
> So I take it there's not much than to sit and wait right now?
> Does 1.1B1 help me?
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Wednesday, March 07, 2007 18:51
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython / Unicode / os.walk
>
> I think we'll also accept utf_8 or utf8.  This is basically covered under
> this bug
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3094
> (although the description doesn't make it entirely obvious).
>
> If you could vote on the bug it'd help raise the visibility of the issue
> and
> we'll get to it sooner.
>
> Thanks for reporting this!
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of John J Lee
> Sent: Wednesday, March 07, 2007 7:31 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython / Unicode / os.walk
>
> On Wed, 7 Mar 2007, Dan Shechter wrote:
> [...]
> >>>> codecs.lookup("UTF-8")
> > Traceback (most recent call last):
> >  File , line 0, in <stdin>##89
> >  File , line 0, in Lookup##78
> > LookupError: unknown encoding: UTF-8
> >
> > Suggestions, alternatives?
>
> Did you try 'utf-8' (i.e. lowercase)?
>
>
> John
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070308/cebfe86e/attachment.html>

From rachest at microsoft.com  Fri Mar  9 01:27:05 2007
From: rachest at microsoft.com (Rachel Hestilow)
Date: Thu, 8 Mar 2007 16:27:05 -0800
Subject: [IronPython] Fix for bug #8073: Implement os.access
Message-ID: <8CEEE36B62BC0F4FAFDAA26BDA6603F20A23FB558C@NA-EXMSG-C107.redmond.corp.microsoft.com>

Attached is a patch which implements nt.access. This should allow os.access to work when using the Python 2.4 os module.

Notes:
* The fix only takes the file's ReadOnly status into account, in order to be compatible with CPython's behavior on Windows. I also have a different version of this patch which also consults the ACL, but seeing as how neither CPython's os.access nor the CRT's _access honors ACL rules, I decided compatibility was more important.
* The patch was generated against a recent source snapshot of the 1.1 tree.
* The original bug for this is at http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8073

Cheers,
Rachel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: access.diff
Type: application/octet-stream
Size: 1503 bytes
Desc: access.diff
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070308/bc5f036c/attachment.obj>

From fuzzyman at voidspace.org.uk  Fri Mar  9 13:30:33 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 09 Mar 2007 12:30:33 +0000
Subject: [IronPython] IronPython and Big Numbers
Message-ID: <45F15369.8090409@voidspace.org.uk>

IronPython doesn't seem to like *very* big integers :

IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> 10 ** 10 ** 10
Traceback (most recent call last):
  File , line 0, in <stdin>##78
ValueError: number too big

This may be fixed in 1.1, or it may not be important. :-)

Michael Foord
http://www.voidspace.org.uk/ironpython/index.shtml



From fireonyoursleeve at hotmail.com  Fri Mar  9 18:34:05 2007
From: fireonyoursleeve at hotmail.com (Aaron Leiby)
Date: Fri, 9 Mar 2007 09:34:05 -0800
Subject: [IronPython] IronPython and Big Numbers
References: <45F15369.8090409@voidspace.org.uk>
Message-ID: <BAY106-DAV2B57E11CE0652C3B1E940CB780@phx.gbl>

http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=Differences

"IronPython raises a ValueError for very large exponents (for example, 10 ** 
735293857239475) while CPython hangs trying to compute the number.  We 
probably won't fix this one."

----- Original Message -----
From: "Michael Foord" <fuzzyman at voidspace.org.uk>
To: "Discussion of IronPython" <users at lists.ironpython.com>
Sent: Friday, March 09, 2007 4:30 AM
Subject: [IronPython] IronPython and Big Numbers

> IronPython doesn't seem to like *very* big integers :
>
> IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> 10 ** 10 ** 10
> Traceback (most recent call last):
>  File , line 0, in <stdin>##78
> ValueError: number too big
>
> This may be fixed in 1.1, or it may not be important. :-)
>
> Michael Foord
> http://www.voidspace.org.uk/ironpython/index.shtml
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 


From fuzzyman at voidspace.org.uk  Fri Mar  9 18:40:53 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 09 Mar 2007 17:40:53 +0000
Subject: [IronPython] IronPython and Big Numbers
In-Reply-To: <BAY106-DAV2B57E11CE0652C3B1E940CB780@phx.gbl>
References: <45F15369.8090409@voidspace.org.uk>
	<BAY106-DAV2B57E11CE0652C3B1E940CB780@phx.gbl>
Message-ID: <45F19C25.2050300@voidspace.org.uk>

Aaron Leiby wrote:
> http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=Differences
>
> "IronPython raises a ValueError for very large exponents (for example, 10 ** 
> 735293857239475) while CPython hangs trying to compute the number.  We 
> probably won't fix this one."
>   

:-)
> ----- Original Message -----
> From: "Michael Foord" <fuzzyman at voidspace.org.uk>
> To: "Discussion of IronPython" <users at lists.ironpython.com>
> Sent: Friday, March 09, 2007 4:30 AM
> Subject: [IronPython] IronPython and Big Numbers
>
>   
>> IronPython doesn't seem to like *very* big integers :
>>
>> IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>     
>>>>> 10 ** 10 ** 10
>>>>>           
>> Traceback (most recent call last):
>>  File , line 0, in <stdin>##78
>> ValueError: number too big
>>
>> This may be fixed in 1.1, or it may not be important. :-)
>>
>> Michael Foord
>> http://www.voidspace.org.uk/ironpython/index.shtml
>>
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>     
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From dinov at exchange.microsoft.com  Fri Mar  9 20:21:46 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 9 Mar 2007 11:21:46 -0800
Subject: [IronPython] IronPython and Big Numbers
In-Reply-To: <45F19C25.2050300@voidspace.org.uk>
References: <45F15369.8090409@voidspace.org.uk>
	<BAY106-DAV2B57E11CE0652C3B1E940CB780@phx.gbl>
	<45F19C25.2050300@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C22276A6453E053@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for reporting this.  This is actually slightly different than the bug described in the differences doc.  There we're actually just preventing you from an inevitable OOM and here we're failing to do the power which should succeed.

This seems to work as long as the left hand side of the power operation is a BigInt:

>>> x = 10 ** 10
>>> x ** 10
10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L
>>> 10 ** x
Number too big


We probably need to support reverse-power on IntOps.  I've opened a work item for this (#8795, http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8795).  Please feel free to vote on it to help us prioritize the bugs.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, March 09, 2007 9:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython and Big Numbers

Aaron Leiby wrote:
> http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=Differences
>
> "IronPython raises a ValueError for very large exponents (for example, 10 **
> 735293857239475) while CPython hangs trying to compute the number.  We
> probably won't fix this one."
>

:-)
> ----- Original Message -----
> From: "Michael Foord" <fuzzyman at voidspace.org.uk>
> To: "Discussion of IronPython" <users at lists.ironpython.com>
> Sent: Friday, March 09, 2007 4:30 AM
> Subject: [IronPython] IronPython and Big Numbers
>
>
>> IronPython doesn't seem to like *very* big integers :
>>
>> IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>
>>>>> 10 ** 10 ** 10
>>>>>
>> Traceback (most recent call last):
>>  File , line 0, in <stdin>##78
>> ValueError: number too big
>>
>> This may be fixed in 1.1, or it may not be important. :-)
>>
>> Michael Foord
>> http://www.voidspace.org.uk/ironpython/index.shtml
>>
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>

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


From billk at sunflower.com  Fri Mar  9 22:44:16 2007
From: billk at sunflower.com (Bill Kinnersley)
Date: Fri, 9 Mar 2007 15:44:16 -0600
Subject: [IronPython] IronPython and Big Numbers
References: <45F15369.8090409@voidspace.org.uk><BAY106-DAV2B57E11CE0652C3B1E940CB780@phx.gbl><45F19C25.2050300@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C22276A6453E053@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <001b01c76294$1637b560$6401a8c0@BILLK>


----- Original Message ----- 
From: "Dino Viehland" <dinov at exchange.microsoft.com>
To: "Discussion of IronPython" <users at lists.ironpython.com>
Sent: Friday, March 09, 2007 1:21 PM
Subject: Re: [IronPython] IronPython and Big Numbers


> Thanks for reporting this.  This is actually slightly different than the 
> bug described in the differences doc.  There we're actually just 
> preventing you from an inevitable OOM and here we're failing to do the 
> power which should succeed.
>
> This seems to work as long as the left hand side of the power operation is 
> a BigInt:
>
>>>> x = 10 ** 10
>>>> x ** 10
> 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L
>>>> 10 ** x
> Number too big
>
This is not surprising, Dino.  The two results are not supposed to be the 
same. 10 ** x will be one followed by ten billion zeroes.  So I think 
"Number too big" is the right answer in the second case!




From dinov at exchange.microsoft.com  Fri Mar  9 23:00:24 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 9 Mar 2007 14:00:24 -0800
Subject: [IronPython] IronPython and Big Numbers
In-Reply-To: <001b01c76294$1637b560$6401a8c0@BILLK>
References: <45F15369.8090409@voidspace.org.uk><BAY106-DAV2B57E11CE0652C3B1E940CB780@phx.gbl><45F19C25.2050300@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C22276A6453E053@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<001b01c76294$1637b560$6401a8c0@BILLK>
Message-ID: <7AD436E4270DD54A94238001769C22276CEAC0CA88@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Oh, you're right, apparently I've forgotten what powers do :).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Bill Kinnersley
Sent: Friday, March 09, 2007 1:44 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython and Big Numbers


----- Original Message -----
From: "Dino Viehland" <dinov at exchange.microsoft.com>
To: "Discussion of IronPython" <users at lists.ironpython.com>
Sent: Friday, March 09, 2007 1:21 PM
Subject: Re: [IronPython] IronPython and Big Numbers


> Thanks for reporting this.  This is actually slightly different than the
> bug described in the differences doc.  There we're actually just
> preventing you from an inevitable OOM and here we're failing to do the
> power which should succeed.
>
> This seems to work as long as the left hand side of the power operation is
> a BigInt:
>
>>>> x = 10 ** 10
>>>> x ** 10
> 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L
>>>> 10 ** x
> Number too big
>
This is not surprising, Dino.  The two results are not supposed to be the
same. 10 ** x will be one followed by ten billion zeroes.  So I think
"Number too big" is the right answer in the second case!


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


From fuzzyman at voidspace.org.uk  Sat Mar 10 14:24:40 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 10 Mar 2007 13:24:40 +0000
Subject: [IronPython] Translating C# into IronPython
Message-ID: <45F2B198.7020804@voidspace.org.uk>

Hello all,

I was about to email this list with a question about translating a 
particular piece of C# into IronPython, when I remembered a commercial 
product called 'Instant Python'.

http://www.tangiblesoftwaresolutions.com/

I have just tried the demo version, which will convert snippets of up to 
100 lines, and I'm finding it very useful.

All the best,

Michael Foord
http://www.voidspace.org.uk/ironpython/


From fuzzyman at voidspace.org.uk  Sat Mar 10 14:27:03 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 10 Mar 2007 13:27:03 +0000
Subject: [IronPython] Calling Scope Globals
Message-ID: <45F2B227.7030102@voidspace.org.uk>

Hello all,

Occasionally I have code that would like to know what module (scope) 
some code is being called from. In CPython I would do :

calling_scope = sys._getframe(1).f_globals['__name__']

How can I do this in IronPython ? (Ugly hacks accepted.)

Thanks

Michael
http://www.voidspace.org.uk/ironpython/


From fuzzyman at voidspace.org.uk  Sat Mar 10 14:34:32 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 10 Mar 2007 13:34:32 +0000
Subject: [IronPython] C#, Types and IronPython
Message-ID: <45F2B3E8.8070605@voidspace.org.uk>

Hello all,

Despite my previous email, I still need some help. :-)

I have some C# that is getting at type objects in several different 
ways, and I would like to know the difference.

Type.GetType("int")
typeof(int)

and I think :

int.GetType()

What are the differences in semantics between 'typeof(...)' and 
'Type.GetType(...)' ?

All the best,

Michael
http://www.voidspace.org.uk/ironpython/


From fuzzyman at voidspace.org.uk  Sat Mar 10 15:20:43 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 10 Mar 2007 14:20:43 +0000
Subject: [IronPython] Type.GetType returns None
Message-ID: <45F2BEBB.10605@voidspace.org.uk>

Hello all,

Why does "Type.GetType(string)" return None from IronPython ?

I need to use it with names like "Console", "int" and "string" - 
fetching the .NET type objects. I guess this is because of the reflected 
types ? Do I have an alternative that will work ? (other than stub C#).

All the best,

Michael Foord

http://www.voidspace.org.uk/ironpython/


From fuzzyman at voidspace.org.uk  Sat Mar 10 15:48:37 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 10 Mar 2007 14:48:37 +0000
Subject: [IronPython] Type.GetType returns None
In-Reply-To: <45F2BEBB.10605@voidspace.org.uk>
References: <45F2BEBB.10605@voidspace.org.uk>
Message-ID: <45F2C545.80308@voidspace.org.uk>

Michael Foord wrote:
> Hello all,
>
> Why does "Type.GetType(string)" return None from IronPython ?
>
> I need to use it with names like "Console", "int" and "string" - 
> fetching the .NET type objects. I guess this is because of the reflected 
> types ? Do I have an alternative that will work ? (other than stub C#).
>   
Interesting - even with the following C# called from IronPython it 
returns None. The code I am translating is from the MSDN docs. Any clues ?

namespace SimpleTest
{
    public class SimpleTest
    {
        public static Type getType(string typename){
            return Type.GetType(typename);
        }
}

Michael Foord
http://www.voidspace.org.uk/ironpython/

> All the best,
>
> Michael Foord
>
> http://www.voidspace.org.uk/ironpython/
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From jvm_cop at spamcop.net  Sat Mar 10 17:13:25 2007
From: jvm_cop at spamcop.net (J. Merrill)
Date: Sat, 10 Mar 2007 11:13:25 -0500
Subject: [IronPython] Type.GetType returns None
In-Reply-To: <45F2C545.80308@voidspace.org.uk>
References: <45F2BEBB.10605@voidspace.org.uk> <45F2C545.80308@voidspace.org.uk>
Message-ID: <7.0.1.0.2.20070310105328.07329270@wheresmymailserver.com>

Those aren't comparable statements.  If you had passed "String" (in quotes) in your C# I think that would have worked, but "string" should not -- the Type.GetType(string) overload is defined as a case-sensitive search, and in general wants an "assembly qualified name".

http://msdn2.microsoft.com/en-us/library/system.type.assemblyqualifiedname.aspx

Perhaps all would be fine in pure IP if you had just used Type.GetType(String) or String.GetType(); I'm away and not easily able to try it myself.

I would guess that the cause is that Python's "string" type (lowercase without the quotes) is not the same as .Net's "String" type (mixed case without quotes).

At 09:48 AM 3/10/2007, Michael Foord wrote
>Michael Foord wrote:
>> Hello all,
>>
>> Why does "Type.GetType(string)" return None from IronPython ?
>>
>> I need to use it with names like "Console", "int" and "string" - 
>> fetching the .NET type objects. I guess this is because of the reflected 
>> types ? Do I have an alternative that will work ? (other than stub C#).
>>   
>Interesting - even with the following C# called from IronPython it 
>returns None. The code I am translating is from the MSDN docs. Any clues ?
>
>namespace SimpleTest
>{
>    public class SimpleTest
>    {
>        public static Type getType(string typename){
>            return Type.GetType(typename);
>        }
>}
>
>Michael Foord
>http://www.voidspace.org.uk/ironpython/


J. Merrill / Analytical Software Corp




From jjl at pobox.com  Sat Mar 10 20:33:54 2007
From: jjl at pobox.com (John J Lee)
Date: Sat, 10 Mar 2007 19:33:54 +0000 (GMT)
Subject: [IronPython] IronPython and Big Numbers
In-Reply-To: <001b01c76294$1637b560$6401a8c0@BILLK>
References: <45F15369.8090409@voidspace.org.uk><BAY106-DAV2B57E11CE0652C3B1E940CB780@phx.gbl><45F19C25.2050300@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C22276A6453E053@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<001b01c76294$1637b560$6401a8c0@BILLK>
Message-ID: <Pine.LNX.4.64.0703101926430.5773@alice>

On Fri, 9 Mar 2007, Bill Kinnersley wrote:
[...]
>>>>> x = 10 ** 10
>>>>> x ** 10
>> 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L
>>>>> 10 ** x
>> Number too big
>>
> This is not surprising, Dino.  The two results are not supposed to be the
> same. 10 ** x will be one followed by ten billion zeroes.  So I think
> "Number too big" is the right answer in the second case!

...and ** is right-associative, so 10**10**10 is indeed 10**(10**10).

(I had to look that up :-)


John



From kfarmer at thuban.org  Sat Mar 10 22:23:27 2007
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Sat, 10 Mar 2007 13:23:27 -0800
Subject: [IronPython] C#, Types and IronPython
Message-ID: <EEDCD954DD4A0D488BBDBDDCC26075441E0955@meta-exchange.circle-cross.home>

http://msdn2.microsoft.com/en-us/library/system.type.gettype.aspx

The C# typeof(typeid) operator doesn't take a string.  Instead, it takes the type identifier and returns an object representing that type.  It's basically a compile-time operation.

The framework's Type.GetType methods are runtime operations that take some input (eg, a string containing the name of a type, or a variable whose type you want to know) and return the appropriate Type object.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Saturday, March 10, 2007 5:35 AM
To: Discussion of IronPython
Subject: [IronPython] C#, Types and IronPython

Hello all,

Despite my previous email, I still need some help. :-)

I have some C# that is getting at type objects in several different 
ways, and I would like to know the difference.

Type.GetType("int")
typeof(int)

and I think :

int.GetType()

What are the differences in semantics between 'typeof(...)' and 
'Type.GetType(...)' ?

All the best,

Michael
http://www.voidspace.org.uk/ironpython/
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From njriley at uiuc.edu  Sun Mar 11 06:49:50 2007
From: njriley at uiuc.edu (Nicholas Riley)
Date: Sat, 10 Mar 2007 23:49:50 -0600
Subject: [IronPython] C#, Types and IronPython
In-Reply-To: <45F2B3E8.8070605@voidspace.org.uk>
References: <45F2B3E8.8070605@voidspace.org.uk>
Message-ID: <20070311054950.GB1477@uiuc.edu>

On Sat, Mar 10, 2007 at 01:34:32PM +0000, Michael Foord wrote:
> I have some C# that is getting at type objects in several different 
> ways, and I would like to know the difference.
> 
> Type.GetType("int")
> typeof(int)
> 
> and I think :
> 
> int.GetType()

In IronPython this is asking for the type of 'int' here, not the type
of _an_ int.  In C# it does both.

> What are the differences in semantics between 'typeof(...)' and 
> 'Type.GetType(...)' ?

There should be none; however, as you saw in another post, you have to
provide qualified type names to Type.GetType.  For example, this works
fine:

>>> import clr; from System import *
>>> Type.GetType('System.String')
<System.RuntimeType object at 0x000000000000002C [System.String]>
>>> 'foo'.GetType()
<System.RuntimeType object at 0x000000000000002C [System.String]>

as does this:

>>> (5).GetType()
<System.RuntimeType object at 0x000000000000002D [System.Int32]>

IronPython has its own definition of types, which isn't the same as
the CLR types.  The IronPython runtime creates objects which conform
to an "IPythonType" interface to represent its own type system.

If you need to get a Pythonic view of type objects you'll have to
mirror the logic you find in IronPython.Runtime.Operations.Ops.GetAttr
(in C#), or the weird way the single-parameter 'type' constructor
works as if it's a function.

You can see the mapping as follows:

>>> from IronPython.Runtime.Operations.Ops import *
>>> GetDynamicType(5)
<type 'int'>
>>> GetDynamicType('foo')
<type 'str'>
>>> GetDynamicType(Type)
<type 'type'>

-- 
Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>


From fuzzyman at voidspace.org.uk  Sun Mar 11 15:27:11 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 11 Mar 2007 14:27:11 +0000
Subject: [IronPython] C#, Types and IronPython
In-Reply-To: <EEDCD954DD4A0D488BBDBDDCC26075441E0955@meta-exchange.circle-cross.home>
References: <EEDCD954DD4A0D488BBDBDDCC26075441E0955@meta-exchange.circle-cross.home>
Message-ID: <45F411BF.7040907@voidspace.org.uk>

Keith J. Farmer wrote:
> http://msdn2.microsoft.com/en-us/library/system.type.gettype.aspx
>
> The C# typeof(typeid) operator doesn't take a string.  Instead, it takes the type identifier and returns an object representing that type.  It's basically a compile-time operation.
>
> The framework's Type.GetType methods are runtime operations that take some input (eg, a string containing the name of a type, or a variable whose type you want to know) and return the appropriate Type object.
>   
Right - so they both just return a type object. The distinction is that 
one is dynamic (runtime) and the other compile time. That much is fine.

It still doesn't explain to me why they are both used in the MSDN 
example, and more to the point why the example doesn't just use the type 
objects in the first place ! (I don't expect you to answer this. :-)

What object does 'typeof(int)' (in C# *not* IronPython) return. I guess 
it is not System.Int32 ! Is there a common base class for the C# number 
types ?

Thanks

Fuzzyman
http://www.voidspace.org.uk/ironpython/


> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Saturday, March 10, 2007 5:35 AM
> To: Discussion of IronPython
> Subject: [IronPython] C#, Types and IronPython
>
> Hello all,
>
> Despite my previous email, I still need some help. :-)
>
> I have some C# that is getting at type objects in several different 
> ways, and I would like to know the difference.
>
> Type.GetType("int")
> typeof(int)
>
> and I think :
>
> int.GetType()
>
> What are the differences in semantics between 'typeof(...)' and 
> 'Type.GetType(...)' ?
>
> All the best,
>
> Michael
> http://www.voidspace.org.uk/ironpython/
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From fuzzyman at voidspace.org.uk  Sun Mar 11 15:35:09 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 11 Mar 2007 14:35:09 +0000
Subject: [IronPython] Type.GetType returns None
In-Reply-To: <7.0.1.0.2.20070310105328.07329270@wheresmymailserver.com>
References: <45F2BEBB.10605@voidspace.org.uk> <45F2C545.80308@voidspace.org.uk>
	<7.0.1.0.2.20070310105328.07329270@wheresmymailserver.com>
Message-ID: <45F4139D.1060109@voidspace.org.uk>

J. Merrill wrote:
> Those aren't comparable statements.  If you had passed "String" (in quotes) in your C# I think that would have worked, but "string" should not -- 
In the example I gave, 'string' was a variable name, not a literal. :-)

There are overloads that allow you to specify a case-insensitive search 
as well by the way.

The trouble I have is that in IronPython 'Type.GetType("String")' 
returns None. In fact all the following return None :

 >>> Type.GetType("String")
 >>> Type.GetType("int")
 >>> Type.GetType("Int32")

Even when I move the 'Type.GetType' call into C# and then call it from 
IronPython it still returns None - meaning it couldn't find the type I 
was asking for. I don't understand why...

Adding the assembly qualifier (System.String) works - but they are used 
without the qualifier in an MSDN example, which works when compiled as C#...

Using "some string".GetType() (with a string literal) works - but is a 
little inconvenient.

Also - the C# examples use 'typeof(int)' and 'Type.GetType("int")'. To 
make it work I've replaced these with 'Int32', which works but is 
obviously not exactly the same...

Thanks

Fuzzyman
http://www.voidspace.org.uk/ironpython/

> the Type.GetType(string) overload is defined as a case-sensitive search, and in general wants an "assembly qualified name".
>
> http://msdn2.microsoft.com/en-us/library/system.type.assemblyqualifiedname.aspx
>
> Perhaps all would be fine in pure IP if you had just used Type.GetType(String) or String.GetType(); I'm away and not easily able to try it myself.
>
> I would guess that the cause is that Python's "string" type (lowercase without the quotes) is not the same as .Net's "String" type (mixed case without quotes).
>
> At 09:48 AM 3/10/2007, Michael Foord wrote
>   
>> Michael Foord wrote:
>>     
>>> Hello all,
>>>
>>> Why does "Type.GetType(string)" return None from IronPython ?
>>>
>>> I need to use it with names like "Console", "int" and "string" - 
>>> fetching the .NET type objects. I guess this is because of the reflected 
>>> types ? Do I have an alternative that will work ? (other than stub C#).
>>>   
>>>       
>> Interesting - even with the following C# called from IronPython it 
>> returns None. The code I am translating is from the MSDN docs. Any clues ?
>>
>> namespace SimpleTest
>> {
>>    public class SimpleTest
>>    {
>>        public static Type getType(string typename){
>>            return Type.GetType(typename);
>>        }
>> }
>>
>> Michael Foord
>> http://www.voidspace.org.uk/ironpython/
>>     
>
>
> J. Merrill / Analytical Software Corp
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From fuzzyman at voidspace.org.uk  Sun Mar 11 15:45:55 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 11 Mar 2007 14:45:55 +0000
Subject: [IronPython] C#, Types and IronPython
In-Reply-To: <20070311054950.GB1477@uiuc.edu>
References: <45F2B3E8.8070605@voidspace.org.uk>
	<20070311054950.GB1477@uiuc.edu>
Message-ID: <45F41623.7090400@voidspace.org.uk>

Nicholas Riley wrote:
> On Sat, Mar 10, 2007 at 01:34:32PM +0000, Michael Foord wrote:
>   
>> I have some C# that is getting at type objects in several different 
>> ways, and I would like to know the difference.
>>
>> Type.GetType("int")
>> typeof(int)
>>
>> and I think :
>>
>> int.GetType()
>>     
>
> In IronPython this is asking for the type of 'int' here, not the type
> of _an_ int.  In C# it does both.
>
>   

Right - but what I want to do is get the type object for 'int' that 
would be returned by that call in C#.

I realise that what Python understands as 'int' is a different thing to 
what C# understands as int.

Thanks for the other info. I see that 'Type.GetType' works when you pass 
in a fully qualified type name - but I swear I saw an example in C# that 
didn't. I'm trying to find it now and failing ! I give up. Perhaps I 
hallucinated it.

All the best,

Fuzzyman
http://www.voidspace.org.uk/ironpython/


From njriley at uiuc.edu  Sun Mar 11 15:56:32 2007
From: njriley at uiuc.edu (Nicholas Riley)
Date: Sun, 11 Mar 2007 09:56:32 -0500
Subject: [IronPython] C#, Types and IronPython
In-Reply-To: <45F411BF.7040907@voidspace.org.uk>
References: <EEDCD954DD4A0D488BBDBDDCC26075441E0955@meta-exchange.circle-cross.home>
	<45F411BF.7040907@voidspace.org.uk>
Message-ID: <20070311145632.GA9074@uiuc.edu>

On Sun, Mar 11, 2007 at 02:27:11PM +0000, Michael Foord wrote:
> What object does 'typeof(int)' (in C# *not* IronPython) return. I guess 
> it is not System.Int32 !

Indeed it is; I'm not sure why you're confused about this when a
one-line C# program will give you the answer :-)  typeof(int) is
converted by the C# compiler into the following IL:

ldtoken    [mscorlib]System.Int32
call       class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)

which makes it pretty clear that System.Int32 is specified at compile
time.

> Is there a common base class for the C# number types ?

No; however there are several common interfaces these types implement,
such as IConvertible.

-- 
Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>


From fuzzyman at voidspace.org.uk  Sun Mar 11 16:08:21 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 11 Mar 2007 15:08:21 +0000
Subject: [IronPython] C#, Types and IronPython
In-Reply-To: <20070311145632.GA9074@uiuc.edu>
References: <EEDCD954DD4A0D488BBDBDDCC26075441E0955@meta-exchange.circle-cross.home>	<45F411BF.7040907@voidspace.org.uk>
	<20070311145632.GA9074@uiuc.edu>
Message-ID: <45F41B65.3090907@voidspace.org.uk>

Nicholas Riley wrote:
> On Sun, Mar 11, 2007 at 02:27:11PM +0000, Michael Foord wrote:
>   
>> What object does 'typeof(int)' (in C# *not* IronPython) return. I guess 
>> it is not System.Int32 !
>>     
>
> Indeed it is; I'm not sure why you're confused about this when a
> one-line C# program will give you the answer :-)  typeof(int) is
> converted by the C# compiler into the following IL:
>
> ldtoken    [mscorlib]System.Int32
> call       class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)
>
> which makes it pretty clear that System.Int32 is specified at compile
> time.
>
>   
>> Is there a common base class for the C# number types ?
>>     
>
> No; however there are several common interfaces these types implement,
> such as IConvertible.
>
>   
Ok - cool. That's very helpful. I'm still not really used to the idea of 
decompiling assemblies to get this sort of information.

Several of the MSDN examples use 'typeof(int)', why not just specify 
'Int32' ? I guess it makes the code less platform dependent ?? Oh well.

Thanks

Michael



From simon.dahlbacka at gmail.com  Sun Mar 11 19:34:25 2007
From: simon.dahlbacka at gmail.com (Simon Dahlbacka)
Date: Sun, 11 Mar 2007 20:34:25 +0200
Subject: [IronPython] C#, Types and IronPython
In-Reply-To: <45F41B65.3090907@voidspace.org.uk>
References: <EEDCD954DD4A0D488BBDBDDCC26075441E0955@meta-exchange.circle-cross.home>
	<45F411BF.7040907@voidspace.org.uk> <20070311145632.GA9074@uiuc.edu>
	<45F41B65.3090907@voidspace.org.uk>
Message-ID: <57124720703111134i2bdcfc7bofb136290901e3d20@mail.gmail.com>

>
>
> Several of the MSDN examples use 'typeof(int)', why not just specify
> 'Int32' ? I guess it makes the code less platform dependent ?? Oh well.
>

they are not the same thing

In CLS (or whatever the .net type system is called), System.Int32 is the
"normal" integer type, that you can type just int in C# is just syntactic
sugar.

In normal cases you work with variables, but in some cases you want to work
with the types (just as you can use e.g. type(42) in python), in that case
you can use either typeof(int) or int foo=42;foo.GetType() (or Type.GetType
("System.Int32") ) and of these the former is more efficient if the type you
want is known at compile time..

hope this helps,

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070311/a337a3f7/attachment.html>

From fuzzyman at voidspace.org.uk  Sun Mar 11 22:05:23 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 11 Mar 2007 21:05:23 +0000
Subject: [IronPython] Missing __long__ method on int
Message-ID: <45F46F13.9060209@voidspace.org.uk>

Hello all,

It looks like integer objects in IronPython are missing the '__long__' 
method. My apologies if this is a duplicate.

All the best,

Michael
http://www.voidspace.org.uk/ironpython/


From kfarmer at thuban.org  Mon Mar 12 09:26:07 2007
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Mon, 12 Mar 2007 01:26:07 -0700
Subject: [IronPython] C#, Types and IronPython
Message-ID: <EEDCD954DD4A0D488BBDBDDCC26075441E0956@meta-exchange.circle-cross.home>

Reflector is your friend:

	http://www.aisto.com/roeder/dotnet/

Whether you see int or System.Int32 in C# code is a matter of aesthetics on the part of the person who wrote the code.  As mentioned elsewhere, int is defined in C# as an alias for the type identifier System.Int32 (see below).  The predefined types are listed in 8.2.1 of the C# spec: 

	http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf

The predefined Simple types are in 11.1.4:

	Reserved word	Aliased type

	sbyte 		System.SByte
	byte			System.Byte
	short			System.Int16
	ushort		System.UInt16
	int			System.Int32
	uint			System.UInt32
	long			System.Int64
	ulong			System.UInt64
	char			System.Char
	float			System.Single
	double		System.Double
	bool			System.Boolean
	decimal		System.Decimal

typeof is defined in 14.5.11.



-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Sunday, March 11, 2007 8:08 AM

Ok - cool. That's very helpful. I'm still not really used to the idea of 
decompiling assemblies to get this sort of information.

Several of the MSDN examples use 'typeof(int)', why not just specify 
'Int32' ? I guess it makes the code less platform dependent ?? Oh well.


From fuzzyman at voidspace.org.uk  Mon Mar 12 15:16:30 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 12 Mar 2007 14:16:30 +0000
Subject: [IronPython] C#, Types and IronPython
In-Reply-To: <EEDCD954DD4A0D488BBDBDDCC26075441E0956@meta-exchange.circle-cross.home>
References: <EEDCD954DD4A0D488BBDBDDCC26075441E0956@meta-exchange.circle-cross.home>
Message-ID: <45F560BE.8000200@voidspace.org.uk>

Keith J. Farmer wrote:
> Reflector is your friend:
>
> 	http://www.aisto.com/roeder/dotnet/
>
>   
Cool - many thanks Keith.

Michael

> Whether you see int or System.Int32 in C# code is a matter of aesthetics on the part of the person who wrote the code.  As mentioned elsewhere, int is defined in C# as an alias for the type identifier System.Int32 (see below).  The predefined types are listed in 8.2.1 of the C# spec: 
>
> 	http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf
>
> The predefined Simple types are in 11.1.4:
>
> 	Reserved word	Aliased type
>
> 	sbyte 		System.SByte
> 	byte			System.Byte
> 	short			System.Int16
> 	ushort		System.UInt16
> 	int			System.Int32
> 	uint			System.UInt32
> 	long			System.Int64
> 	ulong			System.UInt64
> 	char			System.Char
> 	float			System.Single
> 	double		System.Double
> 	bool			System.Boolean
> 	decimal		System.Decimal
>
> typeof is defined in 14.5.11.
>
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Sunday, March 11, 2007 8:08 AM
>
> Ok - cool. That's very helpful. I'm still not really used to the idea of 
> decompiling assemblies to get this sort of information.
>
> Several of the MSDN examples use 'typeof(int)', why not just specify 
> 'Int32' ? I guess it makes the code less platform dependent ?? Oh well.
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From dinov at exchange.microsoft.com  Mon Mar 12 17:21:23 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 12 Mar 2007 09:21:23 -0700
Subject: [IronPython] Calling Scope Globals
In-Reply-To: <45F2B227.7030102@voidspace.org.uk>
References: <45F2B227.7030102@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C22276CEAC0CD59@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Unfortunately I can't think of a clever way to do this other than flowing in the calling scope explicitly somehow (e.g. passing in __name__) which I assume is not a good enough ugly hack :).


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Saturday, March 10, 2007 5:27 AM
To: Discussion of IronPython
Subject: [IronPython] Calling Scope Globals

Hello all,

Occasionally I have code that would like to know what module (scope)
some code is being called from. In CPython I would do :

calling_scope = sys._getframe(1).f_globals['__name__']

How can I do this in IronPython ? (Ugly hacks accepted.)

Thanks

Michael
http://www.voidspace.org.uk/ironpython/
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Mon Mar 12 17:28:18 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 12 Mar 2007 09:28:18 -0700
Subject: [IronPython] Missing __long__ method on int
In-Reply-To: <45F46F13.9060209@voidspace.org.uk>
References: <45F46F13.9060209@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C22276CEAC0CD64@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks Michael!  I've opened bug #8853 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8853).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Sunday, March 11, 2007 2:05 PM
To: Discussion of IronPython
Subject: [IronPython] Missing __long__ method on int

Hello all,

It looks like integer objects in IronPython are missing the '__long__'
method. My apologies if this is a duplicate.

All the best,

Michael
http://www.voidspace.org.uk/ironpython/
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From edfialk at gmail.com  Mon Mar 12 23:12:45 2007
From: edfialk at gmail.com (Ed Fialkowski)
Date: Mon, 12 Mar 2007 17:12:45 -0500
Subject: [IronPython] Interface in IronPython
Message-ID: <f4c7e92f0703121512l116c69acv37f513244f59e473@mail.gmail.com>

Hi all, I'm pretty much totally new to IronPython and have come to the
point that I need an interface to interact with a co-worker's code,
but I can't seem to find any documents or discussion on syntax for
writing an interface.

Does anyone know of a link that talks about interfaces in IronPython
or feel like explaining one too me? :)
Any advice would be greatly appreciated.
Thanks.
-Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070312/0ae9c400/attachment.html>

From curt at hagenlocher.org  Mon Mar 12 23:26:08 2007
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Mon, 12 Mar 2007 15:26:08 -0700
Subject: [IronPython] Interface in IronPython
In-Reply-To: <f4c7e92f0703121512l116c69acv37f513244f59e473@mail.gmail.com>
References: <f4c7e92f0703121512l116c69acv37f513244f59e473@mail.gmail.com>
Message-ID: <d2155e360703121526h37349d4bya4314d2a00fcd8e@mail.gmail.com>

If you mean a CLR interface, you will have to define it in a C# or
VB.NETassembly and then derive from that interface in IronPython.
There's not
currently any way to define a CLR interface from IronPython.

On 3/12/07, Ed Fialkowski <edfialk at gmail.com> wrote:
>
> Hi all, I'm pretty much totally new to IronPython and have come to the
> point that I need an interface to interact with a co-worker's code,
> but I can't seem to find any documents or discussion on syntax for
> writing an interface.
>
> Does anyone know of a link that talks about interfaces in IronPython
> or feel like explaining one too me? :)
> Any advice would be greatly appreciated.
> Thanks.
> -Ed
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070312/748c60c3/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Mar 13 00:14:32 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 12 Mar 2007 23:14:32 +0000
Subject: [IronPython] Interface in IronPython
In-Reply-To: <f4c7e92f0703121512l116c69acv37f513244f59e473@mail.gmail.com>
References: <f4c7e92f0703121512l116c69acv37f513244f59e473@mail.gmail.com>
Message-ID: <45F5DED8.8090406@voidspace.org.uk>

Ed Fialkowski wrote:
> Hi all, I'm pretty much totally new to IronPython and have come to the
> point that I need an interface to interact with a co-worker's code,
> but I can't seem to find any documents or discussion on syntax for
> writing an interface.
>
> Does anyone know of a link that talks about interfaces in IronPython
> or feel like explaining one too me? :)
>
Hello Ed,

Do you already have an interface defined elsewhere (in C# perhaps) that 
you need to support from an IronPython class ?

Or do you want to create an interface in IronPython ?

The first will work (just subclassing the interface has worked for us). 
The second won't work. :-)

If you don't mean either of these things, can you try and explain what 
you do mean.

Thanks

Fuzzyman
http://www.voidspace.org.uk/ironpython/


> Any advice would be greatly appreciated.
> Thanks.
> -Ed
> ------------------------------------------------------------------------
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   



From alex at moreati.org.uk  Tue Mar 13 00:37:21 2007
From: alex at moreati.org.uk (Alex Willmer)
Date: Mon, 12 Mar 2007 23:37:21 +0000
Subject: [IronPython] Interface in IronPython
In-Reply-To: <f4c7e92f0703121512l116c69acv37f513244f59e473@mail.gmail.com>
References: <f4c7e92f0703121512l116c69acv37f513244f59e473@mail.gmail.com>
Message-ID: <1173742641.12588.48.camel@martha>

On Mon, 2007-03-12 at 17:12 -0500, Ed Fialkowski wrote:
> Hi all, I'm pretty much totally new to IronPython and have come to
> the 
> point that I need an interface to interact with a co-worker's code, 
> but I can't seem to find any documents or discussion on syntax for 
> writing an interface. 

Do you mean calling an interface defined by your co-worker, or
implementing an interface in IronPython for you co-worker to call?

> Does anyone know of a link that talks about interfaces in IronPython 
> or feel like explaining one too me? :) 

To my knowledge you cannot create a class in IronPython to be consumed
by C# or VB. I don't know if an IronPython class can implement an
interface.

To call an explicitly implemented interface, or access the properties of
an explicit interface use the following:

ISomeInterface.MethodName(instance, args)
ISomeInterface.PropertyName.GetValue(instance)
ISomeInterface.PropertyName.SetValue(instance, value)

As you've probably found attempting to cast, fails.

If you need to perform the equivalent of the C# expression 'instance is
ISomeInterface' (a QueryInterface?), then you'll find isinstance()
fails. Instead, for now use:

clr.GetClrType(ISomeInterface).IsAssignableFrom(clr.GetClrType(type(instance)))

Here are a couple of relevant bug reports:

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=4538
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=1506

My thanks to Shri Borde for helping me understand this.

Regards, Alex



From edfialk at gmail.com  Tue Mar 13 02:24:57 2007
From: edfialk at gmail.com (Ed Fialkowski)
Date: Mon, 12 Mar 2007 19:24:57 -0600
Subject: [IronPython] Interface in IronPython
In-Reply-To: <1173742641.12588.48.camel@martha>
References: <f4c7e92f0703121512l116c69acv37f513244f59e473@mail.gmail.com>
	<1173742641.12588.48.camel@martha>
Message-ID: <f4c7e92f0703121824j3ce75364x862af7d831f55ae6@mail.gmail.com>

I did mean create an interface in IronPython for my co-worker to call, but
we've since come to the conclusion it doesn't seem possible.

Thanks very much for confirming.

-Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070312/fc58a7c6/attachment.html>

From ckoers at fulladsl.be  Tue Mar 13 11:13:07 2007
From: ckoers at fulladsl.be (Cesar Koers)
Date: Tue, 13 Mar 2007 11:13:07 +0100
Subject: [IronPython] Using python docutils from C# - difference between
 shell and embedded engine?
Message-ID: <45F67933.8090307@fulladsl.be>

Hi all,

I could use some help with embedding Python docutils 
(http://docutils.sourceforge.net/) with C#. At this point, I'm able to 
use the 'docutils.core.publish_string' function from the ipy.exe shell 
with decent output.

However, when embedding the PythonEngine in my C# app, and executing 
'docutils.core.publish_string' with the exact same arguments (*), 
execution stops at a "raise TypeError" in Python code (in Debug mode, in 
Release mode I believe it doesn't return from the Python code at all). 
Repeatedly stepping out of the Python code (10-15 times) with the 
debugger finishes the program.

VS shows that the TypeError is caused by indexing a null array (named 
'children'). When examining the call stack though, I understood that the 
program shouldn't even reach this code because it first checks the value 
of 'len(children)' before accessing 'children'.


Could there be a problem with environment settings or something? I 
compared path and loaded modules between ipy.exe session and embedded 
engine; there are some differences which i can't explain.


Best regards,

C

(*) note that importing docutils.core requires executing 
PythonEngine.InitializeModules first and 
PythonEngine.Import("docutils.core") is not a substitute for 
PythonEngine.Execute("import docutils.core")



PS: using "IronPython Community Edition r5" and VS Express 2005


From christian.muirhead at resolversystems.com  Tue Mar 13 16:18:03 2007
From: christian.muirhead at resolversystems.com (Christian Muirhead)
Date: Tue, 13 Mar 2007 15:18:03 +0000
Subject: [IronPython] float.__long__?
Message-ID: <45F6C0AB.9070006@resolversystems.com>

Hi -

We've noticed that floats are also missing __long__ (very much like this 
bug: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8853):

IP:
 >>> long(1.0)
1L
 >>> 1.0.__long__
Traceback (most recent call last):
   File , line 0, in <stdin>##17
AttributeError: 'float' object has no attribute '__long__'

CPython:
 >>> 1.0.__long__
<method-wrapper '__long__' of float object at 0x00C5DED0>


Having this would mean that we won't need to special-case __long__ when 
auto-delegating to floats.

Thanks,
Christian

-- 
Christian Muirhead
Resolver Systems
christian.muirhead at resolversystems.com

Office address:     17a Clerkenwell Road, London EC1M 5RD, UK
Registered address: 843 Finchley Road, London NW11 8NA, UK

Resolver Systems Limited is registered in England and Wales as company 
number 5467329.
VAT No. GB 893 5643 79


From christian.muirhead at resolversystems.com  Tue Mar 13 16:24:19 2007
From: christian.muirhead at resolversystems.com (Christian Muirhead)
Date: Tue, 13 Mar 2007 15:24:19 +0000
Subject: [IronPython] float.__long__?
In-Reply-To: <45F6C0AB.9070006@resolversystems.com>
References: <45F6C0AB.9070006@resolversystems.com>
Message-ID: <45F6C223.8030300@resolversystems.com>

Christian Muirhead wrote:
> We've noticed that floats are also missing __long__

Oops - they're also missing __float__.

Cheers,
Christian

-- 
Christian Muirhead
Resolver Systems
christian.muirhead at resolversystems.com

Office address:     17a Clerkenwell Road, London EC1M 5RD, UK
Registered address: 843 Finchley Road, London NW11 8NA, UK

Resolver Systems Limited is registered in England and Wales as company 
number 5467329.
VAT No. GB 893 5643 79


From dinov at exchange.microsoft.com  Tue Mar 13 17:17:49 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 13 Mar 2007 09:17:49 -0700
Subject: [IronPython] Using python docutils from C# - difference between
 shell and embedded engine?
In-Reply-To: <45F67933.8090307@fulladsl.be>
References: <45F67933.8090307@fulladsl.be>
Message-ID: <7AD436E4270DD54A94238001769C22276CEAC0D18B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Could it be that you have 1st chance exceptions enabled and this exception is actually handled and recovered from?  Python programs tend to throw exceptions more than your typical C# app.  Given that stepping out seems to allow the program to complete this sounds like what's happening.

You can disable 1st chance exceptions w/ Debug->Exceptions and then uncheck anything checked in the "Thrown" column.  Leave "User Unhandled" checked.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
Sent: Tuesday, March 13, 2007 3:13 AM
To: users at lists.ironpython.com
Subject: [IronPython] Using python docutils from C# - difference between shell and embedded engine?

Hi all,

I could use some help with embedding Python docutils
(http://docutils.sourceforge.net/) with C#. At this point, I'm able to
use the 'docutils.core.publish_string' function from the ipy.exe shell
with decent output.

However, when embedding the PythonEngine in my C# app, and executing
'docutils.core.publish_string' with the exact same arguments (*),
execution stops at a "raise TypeError" in Python code (in Debug mode, in
Release mode I believe it doesn't return from the Python code at all).
Repeatedly stepping out of the Python code (10-15 times) with the
debugger finishes the program.

VS shows that the TypeError is caused by indexing a null array (named
'children'). When examining the call stack though, I understood that the
program shouldn't even reach this code because it first checks the value
of 'len(children)' before accessing 'children'.


Could there be a problem with environment settings or something? I
compared path and loaded modules between ipy.exe session and embedded
engine; there are some differences which i can't explain.


Best regards,

C

(*) note that importing docutils.core requires executing
PythonEngine.InitializeModules first and
PythonEngine.Import("docutils.core") is not a substitute for
PythonEngine.Execute("import docutils.core")



PS: using "IronPython Community Edition r5" and VS Express 2005
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From ckoers at fulladsl.be  Tue Mar 13 21:06:43 2007
From: ckoers at fulladsl.be (Cesar Koers)
Date: Tue, 13 Mar 2007 21:06:43 +0100
Subject: [IronPython] Using python docutils from C# - difference between
 shell and embedded engine?
In-Reply-To: <7AD436E4270DD54A94238001769C22276CEAC0D18B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <45F67933.8090307@fulladsl.be>
	<7AD436E4270DD54A94238001769C22276CEAC0D18B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <45F70453.3090701@fulladsl.be>

Thanks for pointing me in the right direction. Although unchecking 
everything in the Debug->Exceptions "thrown" column does not change the 
described behaviour.

The stacktrace showed that the particular python exception thrown 
inherited from System.IndexOutOfRangeException. Unchecking 
"User-unhandled" for that exception does the trick.

I am not sure if this is desired behaviour, as I believe that the same 
exception could easily be raised in C# code - not causing the debugger 
to break with these settings.

Running in Release mode goes fine (the fact that it hung before was 
probably due to interference with NUnit).



Dino Viehland wrote:
> Could it be that you have 1st chance exceptions enabled and this exception is actually handled and recovered from?  Python programs tend to throw exceptions more than your typical C# app.  Given that stepping out seems to allow the program to complete this sounds like what's happening.
> 
> You can disable 1st chance exceptions w/ Debug->Exceptions and then uncheck anything checked in the "Thrown" column.  Leave "User Unhandled" checked.
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
> Sent: Tuesday, March 13, 2007 3:13 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
> 
> Hi all,
> 
> I could use some help with embedding Python docutils
> (http://docutils.sourceforge.net/) with C#. At this point, I'm able to
> use the 'docutils.core.publish_string' function from the ipy.exe shell
> with decent output.
> 
> However, when embedding the PythonEngine in my C# app, and executing
> 'docutils.core.publish_string' with the exact same arguments (*),
> execution stops at a "raise TypeError" in Python code (in Debug mode, in
> Release mode I believe it doesn't return from the Python code at all).
> Repeatedly stepping out of the Python code (10-15 times) with the
> debugger finishes the program.
> 
> VS shows that the TypeError is caused by indexing a null array (named
> 'children'). When examining the call stack though, I understood that the
> program shouldn't even reach this code because it first checks the value
> of 'len(children)' before accessing 'children'.
> 
> 
> Could there be a problem with environment settings or something? I
> compared path and loaded modules between ipy.exe session and embedded
> engine; there are some differences which i can't explain.
> 
> 
> Best regards,
> 
> C
> 
> (*) note that importing docutils.core requires executing
> PythonEngine.InitializeModules first and
> PythonEngine.Import("docutils.core") is not a substitute for
> PythonEngine.Execute("import docutils.core")
> 
> 
> 
> PS: using "IronPython Community Edition r5" and VS Express 2005
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 


From dinov at exchange.microsoft.com  Tue Mar 13 21:20:44 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 13 Mar 2007 13:20:44 -0700
Subject: [IronPython] Using python docutils from C# - difference between
 shell and embedded engine?
In-Reply-To: <45F70453.3090701@fulladsl.be>
References: <45F67933.8090307@fulladsl.be>
	<7AD436E4270DD54A94238001769C22276CEAC0D18B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<45F70453.3090701@fulladsl.be>
Message-ID: <7AD436E4270DD54A94238001769C22276CEAC0D31A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

What is the type of children and how does it check the len?  Maybe there's something wrong or broken on our side which is leading us down to this code path.  It could also be that the exception shouldn't occur but there's something wrong in the Python code that causes us to get to the exception (and would presumably do the same on CPython).

Otherwise if the exception occurs on both CPython and IP then I think the IndexOutOfRangeException is correct.  VS does have a "Just My Code" feature so depending on if you're trying to debug IP or a mix of Python code and your own C# code you might find your experience to be better if you don't build IP.  Instead just debug your Python code & C# code against the released binaries (or your own build w/o PDBs).  Without the PDBs for the IP code VS should then only recognize the Python code and your C# and only show you the exceptions coming from your code.  Obviously if you're hacking on the IP runtime this doesn't help you :).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
Sent: Tuesday, March 13, 2007 1:07 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?

Thanks for pointing me in the right direction. Although unchecking
everything in the Debug->Exceptions "thrown" column does not change the
described behaviour.

The stacktrace showed that the particular python exception thrown
inherited from System.IndexOutOfRangeException. Unchecking
"User-unhandled" for that exception does the trick.

I am not sure if this is desired behaviour, as I believe that the same
exception could easily be raised in C# code - not causing the debugger
to break with these settings.

Running in Release mode goes fine (the fact that it hung before was
probably due to interference with NUnit).



Dino Viehland wrote:
> Could it be that you have 1st chance exceptions enabled and this exception is actually handled and recovered from?  Python programs tend to throw exceptions more than your typical C# app.  Given that stepping out seems to allow the program to complete this sounds like what's happening.
>
> You can disable 1st chance exceptions w/ Debug->Exceptions and then uncheck anything checked in the "Thrown" column.  Leave "User Unhandled" checked.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
> Sent: Tuesday, March 13, 2007 3:13 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
>
> Hi all,
>
> I could use some help with embedding Python docutils
> (http://docutils.sourceforge.net/) with C#. At this point, I'm able to
> use the 'docutils.core.publish_string' function from the ipy.exe shell
> with decent output.
>
> However, when embedding the PythonEngine in my C# app, and executing
> 'docutils.core.publish_string' with the exact same arguments (*),
> execution stops at a "raise TypeError" in Python code (in Debug mode, in
> Release mode I believe it doesn't return from the Python code at all).
> Repeatedly stepping out of the Python code (10-15 times) with the
> debugger finishes the program.
>
> VS shows that the TypeError is caused by indexing a null array (named
> 'children'). When examining the call stack though, I understood that the
> program shouldn't even reach this code because it first checks the value
> of 'len(children)' before accessing 'children'.
>
>
> Could there be a problem with environment settings or something? I
> compared path and loaded modules between ipy.exe session and embedded
> engine; there are some differences which i can't explain.
>
>
> Best regards,
>
> C
>
> (*) note that importing docutils.core requires executing
> PythonEngine.InitializeModules first and
> PythonEngine.Import("docutils.core") is not a substitute for
> PythonEngine.Execute("import docutils.core")
>
>
>
> PS: using "IronPython Community Edition r5" and VS Express 2005
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From ckoers at fulladsl.be  Tue Mar 13 21:53:05 2007
From: ckoers at fulladsl.be (Cesar Koers)
Date: Tue, 13 Mar 2007 21:53:05 +0100
Subject: [IronPython] Using python docutils from C# - difference between
 shell and embedded engine?
In-Reply-To: <7AD436E4270DD54A94238001769C22276CEAC0D31A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <45F67933.8090307@fulladsl.be>	<7AD436E4270DD54A94238001769C22276CEAC0D18B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<45F70453.3090701@fulladsl.be>
	<7AD436E4270DD54A94238001769C22276CEAC0D31A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <45F70F31.1000000@fulladsl.be>

In module nodes.py (see http://svn.berlios.de/viewcvs/docutils/trunk/docutils/docutils/nodes.py?rev=4649&view=markup)

The 'len' check is in class 'Node', method 'traverse', starting on line 233:

if descend and len(self.children):
     for child in self:
         r.extend(child.traverse(include_self=1, descend=1, siblings=0, ascend=0, condition=condition))

'children' should be of type 'Element' or 'Text' (see class 'Element' line 375)

The iteration results in a call to Element.__getitem__, which raises the TypeError exception when the code starting on line 465 is executed:

elif isinstance(key, IntType):
     return self.children[key]


There is no indication in ipy that this code behaves unexpectedly. It seems hard to believe that the same code would not work in CPython (didn't check that though).


Please mind that I have no ambition to hack on IronPython, just getting docutils to work will be just fine. For that matter, I'm not even a Python programmer, so hacking on docutils seems unreasonable 
too. Nevertheless, if this can help improve IronPython great!



Dino Viehland wrote:
> What is the type of children and how does it check the len?  Maybe there's something wrong or broken on our side which is leading us down to this code path.  It could also be that the exception shouldn't occur but there's something wrong in the Python code that causes us to get to the exception (and would presumably do the same on CPython).
> 
> Otherwise if the exception occurs on both CPython and IP then I think the IndexOutOfRangeException is correct.  VS does have a "Just My Code" feature so depending on if you're trying to debug IP or a mix of Python code and your own C# code you might find your experience to be better if you don't build IP.  Instead just debug your Python code & C# code against the released binaries (or your own build w/o PDBs).  Without the PDBs for the IP code VS should then only recognize the Python code and your C# and only show you the exceptions coming from your code.  Obviously if you're hacking on the IP runtime this doesn't help you :).
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
> Sent: Tuesday, March 13, 2007 1:07 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
> 
> Thanks for pointing me in the right direction. Although unchecking
> everything in the Debug->Exceptions "thrown" column does not change the
> described behaviour.
> 
> The stacktrace showed that the particular python exception thrown
> inherited from System.IndexOutOfRangeException. Unchecking
> "User-unhandled" for that exception does the trick.
> 
> I am not sure if this is desired behaviour, as I believe that the same
> exception could easily be raised in C# code - not causing the debugger
> to break with these settings.
> 
> Running in Release mode goes fine (the fact that it hung before was
> probably due to interference with NUnit).
> 
> 
> 
> Dino Viehland wrote:
>> Could it be that you have 1st chance exceptions enabled and this exception is actually handled and recovered from?  Python programs tend to throw exceptions more than your typical C# app.  Given that stepping out seems to allow the program to complete this sounds like what's happening.
>>
>> You can disable 1st chance exceptions w/ Debug->Exceptions and then uncheck anything checked in the "Thrown" column.  Leave "User Unhandled" checked.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
>> Sent: Tuesday, March 13, 2007 3:13 AM
>> To: users at lists.ironpython.com
>> Subject: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
>>
>> Hi all,
>>
>> I could use some help with embedding Python docutils
>> (http://docutils.sourceforge.net/) with C#. At this point, I'm able to
>> use the 'docutils.core.publish_string' function from the ipy.exe shell
>> with decent output.
>>
>> However, when embedding the PythonEngine in my C# app, and executing
>> 'docutils.core.publish_string' with the exact same arguments (*),
>> execution stops at a "raise TypeError" in Python code (in Debug mode, in
>> Release mode I believe it doesn't return from the Python code at all).
>> Repeatedly stepping out of the Python code (10-15 times) with the
>> debugger finishes the program.
>>
>> VS shows that the TypeError is caused by indexing a null array (named
>> 'children'). When examining the call stack though, I understood that the
>> program shouldn't even reach this code because it first checks the value
>> of 'len(children)' before accessing 'children'.
>>
>>
>> Could there be a problem with environment settings or something? I
>> compared path and loaded modules between ipy.exe session and embedded
>> engine; there are some differences which i can't explain.
>>
>>
>> Best regards,
>>
>> C
>>
>> (*) note that importing docutils.core requires executing
>> PythonEngine.InitializeModules first and
>> PythonEngine.Import("docutils.core") is not a substitute for
>> PythonEngine.Execute("import docutils.core")
>>
>>
>>
>> PS: using "IronPython Community Edition r5" and VS Express 2005
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 


From dinov at exchange.microsoft.com  Tue Mar 13 22:08:45 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 13 Mar 2007 14:08:45 -0700
Subject: [IronPython] Using python docutils from C# - difference between
 shell and embedded engine?
In-Reply-To: <45F70F31.1000000@fulladsl.be>
References: <45F67933.8090307@fulladsl.be>
	<7AD436E4270DD54A94238001769C22276CEAC0D18B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<45F70453.3090701@fulladsl.be>
	<7AD436E4270DD54A94238001769C22276CEAC0D31A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<45F70F31.1000000@fulladsl.be>
Message-ID: <7AD436E4270DD54A94238001769C22276CEAC0D36C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Unfortunately I don't know if I can actually look at the docutils code :(.  I'll have to ping some people if this doesn't get us to the bottom of it (the license isn't entirely clear to me from http://docutils.sourceforge.net/ either).  The good news is I think I know the problem now so hopefully one more question will confirm this.

I suspect the problem here is that we're not properly supporting overriding __len__ (similar to the bug we have against overriding __contains__).

I think this is the bug:

for x in (tuple, list, dict):
    class subtype(x):
            def __len__(self): return 42
    print len(subtype())

In CPython this prints 42 3 times and in IP it prints 0 3 times.  Can you just confirm that Element and Text derive from some other type like tuple, list, or dict or if not one of those can you let us know what they derive from?

If this is the same bug as __contains__ I think I'm going to try and fix it for v1.1 final.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
Sent: Tuesday, March 13, 2007 1:53 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?

In module nodes.py (see http://svn.berlios.de/viewcvs/docutils/trunk/docutils/docutils/nodes.py?rev=4649&view=markup)

The 'len' check is in class 'Node', method 'traverse', starting on line 233:

if descend and len(self.children):
     for child in self:
         r.extend(child.traverse(include_self=1, descend=1, siblings=0, ascend=0, condition=condition))

'children' should be of type 'Element' or 'Text' (see class 'Element' line 375)

The iteration results in a call to Element.__getitem__, which raises the TypeError exception when the code starting on line 465 is executed:

elif isinstance(key, IntType):
     return self.children[key]


There is no indication in ipy that this code behaves unexpectedly. It seems hard to believe that the same code would not work in CPython (didn't check that though).


Please mind that I have no ambition to hack on IronPython, just getting docutils to work will be just fine. For that matter, I'm not even a Python programmer, so hacking on docutils seems unreasonable
too. Nevertheless, if this can help improve IronPython great!



Dino Viehland wrote:
> What is the type of children and how does it check the len?  Maybe there's something wrong or broken on our side which is leading us down to this code path.  It could also be that the exception shouldn't occur but there's something wrong in the Python code that causes us to get to the exception (and would presumably do the same on CPython).
>
> Otherwise if the exception occurs on both CPython and IP then I think the IndexOutOfRangeException is correct.  VS does have a "Just My Code" feature so depending on if you're trying to debug IP or a mix of Python code and your own C# code you might find your experience to be better if you don't build IP.  Instead just debug your Python code & C# code against the released binaries (or your own build w/o PDBs).  Without the PDBs for the IP code VS should then only recognize the Python code and your C# and only show you the exceptions coming from your code.  Obviously if you're hacking on the IP runtime this doesn't help you :).
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
> Sent: Tuesday, March 13, 2007 1:07 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
>
> Thanks for pointing me in the right direction. Although unchecking
> everything in the Debug->Exceptions "thrown" column does not change the
> described behaviour.
>
> The stacktrace showed that the particular python exception thrown
> inherited from System.IndexOutOfRangeException. Unchecking
> "User-unhandled" for that exception does the trick.
>
> I am not sure if this is desired behaviour, as I believe that the same
> exception could easily be raised in C# code - not causing the debugger
> to break with these settings.
>
> Running in Release mode goes fine (the fact that it hung before was
> probably due to interference with NUnit).
>
>
>
> Dino Viehland wrote:
>> Could it be that you have 1st chance exceptions enabled and this exception is actually handled and recovered from?  Python programs tend to throw exceptions more than your typical C# app.  Given that stepping out seems to allow the program to complete this sounds like what's happening.
>>
>> You can disable 1st chance exceptions w/ Debug->Exceptions and then uncheck anything checked in the "Thrown" column.  Leave "User Unhandled" checked.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
>> Sent: Tuesday, March 13, 2007 3:13 AM
>> To: users at lists.ironpython.com
>> Subject: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
>>
>> Hi all,
>>
>> I could use some help with embedding Python docutils
>> (http://docutils.sourceforge.net/) with C#. At this point, I'm able to
>> use the 'docutils.core.publish_string' function from the ipy.exe shell
>> with decent output.
>>
>> However, when embedding the PythonEngine in my C# app, and executing
>> 'docutils.core.publish_string' with the exact same arguments (*),
>> execution stops at a "raise TypeError" in Python code (in Debug mode, in
>> Release mode I believe it doesn't return from the Python code at all).
>> Repeatedly stepping out of the Python code (10-15 times) with the
>> debugger finishes the program.
>>
>> VS shows that the TypeError is caused by indexing a null array (named
>> 'children'). When examining the call stack though, I understood that the
>> program shouldn't even reach this code because it first checks the value
>> of 'len(children)' before accessing 'children'.
>>
>>
>> Could there be a problem with environment settings or something? I
>> compared path and loaded modules between ipy.exe session and embedded
>> engine; there are some differences which i can't explain.
>>
>>
>> Best regards,
>>
>> C
>>
>> (*) note that importing docutils.core requires executing
>> PythonEngine.InitializeModules first and
>> PythonEngine.Import("docutils.core") is not a substitute for
>> PythonEngine.Execute("import docutils.core")
>>
>>
>>
>> PS: using "IronPython Community Edition r5" and VS Express 2005
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From daftspaniel at gmail.com  Tue Mar 13 22:32:26 2007
From: daftspaniel at gmail.com (Davy Mitchell)
Date: Tue, 13 Mar 2007 21:32:26 +0000
Subject: [IronPython] Bug?
In-Reply-To: <20253b0c0701070521l7a8c2e9buc9734e425d12584e@mail.gmail.com>
References: <20253b0c0701050538y4dc0e512ubba3be54419f3606@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227561A3E5600@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<20253b0c0701070521l7a8c2e9buc9734e425d12584e@mail.gmail.com>
Message-ID: <20253b0c0703131432k7340ce72sf45eb38af744cd0d@mail.gmail.com>

> On 1/5/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> > The System.Timers.Timer class will swallow all exceptions from the timer
> >causing this to happen (and apparently has no way to report those to the user).

In case this helps other people with events in WinForms apps....

I hit a similar situation to this when handling events from the web
browser control. To get the exceptions reported I simply put the
entire handler in a try/catch block and printed it/them out.

Cheers,
Davy

-- 
Davy Mitchell
Blog - http://www.latedecember.co.uk/sites/personal/davy/
Twitter - http://twitter.com/daftspaniel
Skype - daftspaniel


From ckoers at fulladsl.be  Wed Mar 14 08:08:29 2007
From: ckoers at fulladsl.be (Cesar Koers)
Date: Wed, 14 Mar 2007 08:08:29 +0100
Subject: [IronPython] Using python docutils from C# - difference between
 shell and embedded engine?
In-Reply-To: <7AD436E4270DD54A94238001769C22276CEAC0D36C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <45F67933.8090307@fulladsl.be>	<7AD436E4270DD54A94238001769C22276CEAC0D18B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<45F70453.3090701@fulladsl.be>	<7AD436E4270DD54A94238001769C22276CEAC0D31A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<45F70F31.1000000@fulladsl.be>
	<7AD436E4270DD54A94238001769C22276CEAC0D36C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <45F79F6D.2050200@fulladsl.be>

'Element' and 'Text' both derive from 'Node', which does not derive from anything and is described as "Abstract base class of nodes in a document tree."

I don't know if the immediate window should normally be able to interpret 'len', so I don't know if this is a sign of something wrong: I tried to evaluate the value of 'len(self.children)' on line 233 
with the VS debugger. When it breaks at line 466 (where the exception is raised) and I go back one step in the call stack to line 234 (just after the 'len' check), I get in the immediate window:

 >> len(self)
'docutils.nodes.len' is a 'field' but is used like a 'method'
 >> len(self.children)
'docutils.nodes.len' is a 'field' but is used like a 'method'
 >> self
{<paragraph>Something to publish</paragraph>}
 >> self.parent
'object' does not contain a definition for 'parent'
 >> self.children
'object' does not contain a definition for 'children'



Dino Viehland wrote:
> Unfortunately I don't know if I can actually look at the docutils code :(.  I'll have to ping some people if this doesn't get us to the bottom of it (the license isn't entirely clear to me from http://docutils.sourceforge.net/ either).  The good news is I think I know the problem now so hopefully one more question will confirm this.
> 
> I suspect the problem here is that we're not properly supporting overriding __len__ (similar to the bug we have against overriding __contains__).
> 
> I think this is the bug:
> 
> for x in (tuple, list, dict):
>     class subtype(x):
>             def __len__(self): return 42
>     print len(subtype())
> 
> In CPython this prints 42 3 times and in IP it prints 0 3 times.  Can you just confirm that Element and Text derive from some other type like tuple, list, or dict or if not one of those can you let us know what they derive from?
> 
> If this is the same bug as __contains__ I think I'm going to try and fix it for v1.1 final.
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
> Sent: Tuesday, March 13, 2007 1:53 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
> 
> In module nodes.py (see http://svn.berlios.de/viewcvs/docutils/trunk/docutils/docutils/nodes.py?rev=4649&view=markup)
> 
> The 'len' check is in class 'Node', method 'traverse', starting on line 233:
> 
> if descend and len(self.children):
>      for child in self:
>          r.extend(child.traverse(include_self=1, descend=1, siblings=0, ascend=0, condition=condition))
> 
> 'children' should be of type 'Element' or 'Text' (see class 'Element' line 375)
> 
> The iteration results in a call to Element.__getitem__, which raises the TypeError exception when the code starting on line 465 is executed:
> 
> elif isinstance(key, IntType):
>      return self.children[key]
> 
> 
> There is no indication in ipy that this code behaves unexpectedly. It seems hard to believe that the same code would not work in CPython (didn't check that though).
> 
> 
> Please mind that I have no ambition to hack on IronPython, just getting docutils to work will be just fine. For that matter, I'm not even a Python programmer, so hacking on docutils seems unreasonable
> too. Nevertheless, if this can help improve IronPython great!
> 
> 
> 
> Dino Viehland wrote:
>> What is the type of children and how does it check the len?  Maybe there's something wrong or broken on our side which is leading us down to this code path.  It could also be that the exception shouldn't occur but there's something wrong in the Python code that causes us to get to the exception (and would presumably do the same on CPython).
>>
>> Otherwise if the exception occurs on both CPython and IP then I think the IndexOutOfRangeException is correct.  VS does have a "Just My Code" feature so depending on if you're trying to debug IP or a mix of Python code and your own C# code you might find your experience to be better if you don't build IP.  Instead just debug your Python code & C# code against the released binaries (or your own build w/o PDBs).  Without the PDBs for the IP code VS should then only recognize the Python code and your C# and only show you the exceptions coming from your code.  Obviously if you're hacking on the IP runtime this doesn't help you :).
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
>> Sent: Tuesday, March 13, 2007 1:07 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
>>
>> Thanks for pointing me in the right direction. Although unchecking
>> everything in the Debug->Exceptions "thrown" column does not change the
>> described behaviour.
>>
>> The stacktrace showed that the particular python exception thrown
>> inherited from System.IndexOutOfRangeException. Unchecking
>> "User-unhandled" for that exception does the trick.
>>
>> I am not sure if this is desired behaviour, as I believe that the same
>> exception could easily be raised in C# code - not causing the debugger
>> to break with these settings.
>>
>> Running in Release mode goes fine (the fact that it hung before was
>> probably due to interference with NUnit).
>>
>>
>>
>> Dino Viehland wrote:
>>> Could it be that you have 1st chance exceptions enabled and this exception is actually handled and recovered from?  Python programs tend to throw exceptions more than your typical C# app.  Given that stepping out seems to allow the program to complete this sounds like what's happening.
>>>
>>> You can disable 1st chance exceptions w/ Debug->Exceptions and then uncheck anything checked in the "Thrown" column.  Leave "User Unhandled" checked.
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
>>> Sent: Tuesday, March 13, 2007 3:13 AM
>>> To: users at lists.ironpython.com
>>> Subject: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
>>>
>>> Hi all,
>>>
>>> I could use some help with embedding Python docutils
>>> (http://docutils.sourceforge.net/) with C#. At this point, I'm able to
>>> use the 'docutils.core.publish_string' function from the ipy.exe shell
>>> with decent output.
>>>
>>> However, when embedding the PythonEngine in my C# app, and executing
>>> 'docutils.core.publish_string' with the exact same arguments (*),
>>> execution stops at a "raise TypeError" in Python code (in Debug mode, in
>>> Release mode I believe it doesn't return from the Python code at all).
>>> Repeatedly stepping out of the Python code (10-15 times) with the
>>> debugger finishes the program.
>>>
>>> VS shows that the TypeError is caused by indexing a null array (named
>>> 'children'). When examining the call stack though, I understood that the
>>> program shouldn't even reach this code because it first checks the value
>>> of 'len(children)' before accessing 'children'.
>>>
>>>
>>> Could there be a problem with environment settings or something? I
>>> compared path and loaded modules between ipy.exe session and embedded
>>> engine; there are some differences which i can't explain.
>>>
>>>
>>> Best regards,
>>>
>>> C
>>>
>>> (*) note that importing docutils.core requires executing
>>> PythonEngine.InitializeModules first and
>>> PythonEngine.Import("docutils.core") is not a substitute for
>>> PythonEngine.Execute("import docutils.core")
>>>
>>>
>>>
>>> PS: using "IronPython Community Edition r5" and VS Express 2005
>>> _______________________________________________
>>> users mailing list
>>> users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>> _______________________________________________
>>> users mailing list
>>> users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 


From fuzzyman at voidspace.org.uk  Thu Mar 15 00:25:47 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 14 Mar 2007 23:25:47 +0000
Subject: [IronPython] Initialisation of .NET Subclasses
Message-ID: <45F8847B.7070507@voidspace.org.uk>

Hello all,

I'm wondering about best practise when subclassing Windows Forms 
controls. I have a vague memory of hearing that initialisation is done 
in the '__new__' methods of .NET controls, so that '__init__' overrides 
*need not* call up to their base class. Is this correct, or was I 
hallucinating ?

In other words, is the following ok :

class MainForm(Form):
    def __init__(self):
        pass

Or should I be doing :

class MainForm(Form):
    def __init__(self):
        Form.__init__(self)

?

All the best,

Michael Foord
http://www.voidspace.org.uk/ironpython/


From dinov at exchange.microsoft.com  Thu Mar 15 01:11:32 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 14 Mar 2007 17:11:32 -0700
Subject: [IronPython] Initialisation of .NET Subclasses
In-Reply-To: <45F8847B.7070507@voidspace.org.uk>
References: <45F8847B.7070507@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C22276CEB060BF9@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

You are correct in that __new__ methods map to the .NET ctor (both __new__ and the ctor can only be run once, while __init__ can be called an arbitrary number of times).  Of course someone can construct a type from C# which has particular __init__ or __new__ semantics but you won't run into that in Winforms.

The only interesting thing about not calling __init__ is if multiple inheritance starts coming into the picture.  Then you might want to call your super's __init__ to ensure everyone gets __init__ run.  Unfortunately doing super(...).__init__ to make this work seems to be questionable as it may open up its own set of issues.

But there's certainly no need to Form.__init__.
________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Michael Foord [fuzzyman at voidspace.org.uk]
Sent: Wednesday, March 14, 2007 4:25 PM
To: Discussion of IronPython
Subject: [IronPython] Initialisation of .NET Subclasses

Hello all,

I'm wondering about best practise when subclassing Windows Forms
controls. I have a vague memory of hearing that initialisation is done
in the '__new__' methods of .NET controls, so that '__init__' overrides
*need not* call up to their base class. Is this correct, or was I
hallucinating ?

In other words, is the following ok :

class MainForm(Form):
    def __init__(self):
        pass

Or should I be doing :

class MainForm(Form):
    def __init__(self):
        Form.__init__(self)

?

All the best,

Michael Foord
http://www.voidspace.org.uk/ironpython/
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From fuzzyman at voidspace.org.uk  Thu Mar 15 01:14:06 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 15 Mar 2007 00:14:06 +0000
Subject: [IronPython] Initialisation of .NET Subclasses
In-Reply-To: <7AD436E4270DD54A94238001769C22276CEB060BF9@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <45F8847B.7070507@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C22276CEB060BF9@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <45F88FCE.3090001@voidspace.org.uk>

Dino Viehland wrote:
> You are correct in that __new__ methods map to the .NET ctor (both __new__ and the ctor can only be run once, while __init__ can be called an arbitrary number of times).  Of course someone can construct a type from C# which has particular __init__ or __new__ semantics but you won't run into that in Winforms.
>
> The only interesting thing about not calling __init__ is if multiple inheritance starts coming into the picture.  Then you might want to call your super's __init__ to ensure everyone gets __init__ run.  Unfortunately doing super(...).__init__ to make this work seems to be questionable as it may open up its own set of issues.
>
> But there's certainly no need to Form.__init__.
>   
Thanks Dino.

I think I'll leave it in my examples as it is generally good practise - 
except in cases of multiple inheritance which is rarely good practise 
anyway. :-)

Michael

> ________________________________________
> From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Michael Foord [fuzzyman at voidspace.org.uk]
> Sent: Wednesday, March 14, 2007 4:25 PM
> To: Discussion of IronPython
> Subject: [IronPython] Initialisation of .NET Subclasses
>
> Hello all,
>
> I'm wondering about best practise when subclassing Windows Forms
> controls. I have a vague memory of hearing that initialisation is done
> in the '__new__' methods of .NET controls, so that '__init__' overrides
> *need not* call up to their base class. Is this correct, or was I
> hallucinating ?
>
> In other words, is the following ok :
>
> class MainForm(Form):
>     def __init__(self):
>         pass
>
> Or should I be doing :
>
> class MainForm(Form):
>     def __init__(self):
>         Form.__init__(self)
>
> ?
>
> All the best,
>
> Michael Foord
> http://www.voidspace.org.uk/ironpython/
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From dinov at exchange.microsoft.com  Thu Mar 15 01:44:17 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 14 Mar 2007 17:44:17 -0700
Subject: [IronPython] Using python docutils from C# - difference between
 shell and embedded engine?
In-Reply-To: <45F79F6D.2050200@fulladsl.be>
References: <45F67933.8090307@fulladsl.be>
	<7AD436E4270DD54A94238001769C22276CEAC0D18B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<45F70453.3090701@fulladsl.be>
	<7AD436E4270DD54A94238001769C22276CEAC0D31A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<45F70F31.1000000@fulladsl.be>
	<7AD436E4270DD54A94238001769C22276CEAC0D36C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>,
	<45F79F6D.2050200@fulladsl.be>
Message-ID: <7AD436E4270DD54A94238001769C22276CEB060BFE@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

I don't think evaluate will necessarily work with arbitrary Python statements (at least not w/ a normal version of VS - maybe with the VS SDK but I'm not sure).

It sounds as if everything might be working correctly if the type's ultimately aren't deriving from anything and the exception is being handled properly.  We may have discovered a new bug along the way which is always nice :) - so thanks for the report and putting up w/ the back and forth.  I'll open a new bug if this turns out to be different from our existing __contains__ bug.
________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers [ckoers at fulladsl.be]
Sent: Wednesday, March 14, 2007 12:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?

'Element' and 'Text' both derive from 'Node', which does not derive from anything and is described as "Abstract base class of nodes in a document tree."

I don't know if the immediate window should normally be able to interpret 'len', so I don't know if this is a sign of something wrong: I tried to evaluate the value of 'len(self.children)' on line 233
with the VS debugger. When it breaks at line 466 (where the exception is raised) and I go back one step in the call stack to line 234 (just after the 'len' check), I get in the immediate window:

 >> len(self)
'docutils.nodes.len' is a 'field' but is used like a 'method'
 >> len(self.children)
'docutils.nodes.len' is a 'field' but is used like a 'method'
 >> self
{<paragraph>Something to publish</paragraph>}
 >> self.parent
'object' does not contain a definition for 'parent'
 >> self.children
'object' does not contain a definition for 'children'



Dino Viehland wrote:
> Unfortunately I don't know if I can actually look at the docutils code :(.  I'll have to ping some people if this doesn't get us to the bottom of it (the license isn't entirely clear to me from http://docutils.sourceforge.net/ either).  The good news is I think I know the problem now so hopefully one more question will confirm this.
>
> I suspect the problem here is that we're not properly supporting overriding __len__ (similar to the bug we have against overriding __contains__).
>
> I think this is the bug:
>
> for x in (tuple, list, dict):
>     class subtype(x):
>             def __len__(self): return 42
>     print len(subtype())
>
> In CPython this prints 42 3 times and in IP it prints 0 3 times.  Can you just confirm that Element and Text derive from some other type like tuple, list, or dict or if not one of those can you let us know what they derive from?
>
> If this is the same bug as __contains__ I think I'm going to try and fix it for v1.1 final.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
> Sent: Tuesday, March 13, 2007 1:53 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
>
> In module nodes.py (see http://svn.berlios.de/viewcvs/docutils/trunk/docutils/docutils/nodes.py?rev=4649&view=markup)
>
> The 'len' check is in class 'Node', method 'traverse', starting on line 233:
>
> if descend and len(self.children):
>      for child in self:
>          r.extend(child.traverse(include_self=1, descend=1, siblings=0, ascend=0, condition=condition))
>
> 'children' should be of type 'Element' or 'Text' (see class 'Element' line 375)
>
> The iteration results in a call to Element.__getitem__, which raises the TypeError exception when the code starting on line 465 is executed:
>
> elif isinstance(key, IntType):
>      return self.children[key]
>
>
> There is no indication in ipy that this code behaves unexpectedly. It seems hard to believe that the same code would not work in CPython (didn't check that though).
>
>
> Please mind that I have no ambition to hack on IronPython, just getting docutils to work will be just fine. For that matter, I'm not even a Python programmer, so hacking on docutils seems unreasonable
> too. Nevertheless, if this can help improve IronPython great!
>
>
>
> Dino Viehland wrote:
>> What is the type of children and how does it check the len?  Maybe there's something wrong or broken on our side which is leading us down to this code path.  It could also be that the exception shouldn't occur but there's something wrong in the Python code that causes us to get to the exception (and would presumably do the same on CPython).
>>
>> Otherwise if the exception occurs on both CPython and IP then I think the IndexOutOfRangeException is correct.  VS does have a "Just My Code" feature so depending on if you're trying to debug IP or a mix of Python code and your own C# code you might find your experience to be better if you don't build IP.  Instead just debug your Python code & C# code against the released binaries (or your own build w/o PDBs).  Without the PDBs for the IP code VS should then only recognize the Python code and your C# and only show you the exceptions coming from your code.  Obviously if you're hacking on the IP runtime this doesn't help you :).
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
>> Sent: Tuesday, March 13, 2007 1:07 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
>>
>> Thanks for pointing me in the right direction. Although unchecking
>> everything in the Debug->Exceptions "thrown" column does not change the
>> described behaviour.
>>
>> The stacktrace showed that the particular python exception thrown
>> inherited from System.IndexOutOfRangeException. Unchecking
>> "User-unhandled" for that exception does the trick.
>>
>> I am not sure if this is desired behaviour, as I believe that the same
>> exception could easily be raised in C# code - not causing the debugger
>> to break with these settings.
>>
>> Running in Release mode goes fine (the fact that it hung before was
>> probably due to interference with NUnit).
>>
>>
>>
>> Dino Viehland wrote:
>>> Could it be that you have 1st chance exceptions enabled and this exception is actually handled and recovered from?  Python programs tend to throw exceptions more than your typical C# app.  Given that stepping out seems to allow the program to complete this sounds like what's happening.
>>>
>>> You can disable 1st chance exceptions w/ Debug->Exceptions and then uncheck anything checked in the "Thrown" column.  Leave "User Unhandled" checked.
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
>>> Sent: Tuesday, March 13, 2007 3:13 AM
>>> To: users at lists.ironpython.com
>>> Subject: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
>>>
>>> Hi all,
>>>
>>> I could use some help with embedding Python docutils
>>> (http://docutils.sourceforge.net/) with C#. At this point, I'm able to
>>> use the 'docutils.core.publish_string' function from the ipy.exe shell
>>> with decent output.
>>>
>>> However, when embedding the PythonEngine in my C# app, and executing
>>> 'docutils.core.publish_string' with the exact same arguments (*),
>>> execution stops at a "raise TypeError" in Python code (in Debug mode, in
>>> Release mode I believe it doesn't return from the Python code at all).
>>> Repeatedly stepping out of the Python code (10-15 times) with the
>>> debugger finishes the program.
>>>
>>> VS shows that the TypeError is caused by indexing a null array (named
>>> 'children'). When examining the call stack though, I understood that the
>>> program shouldn't even reach this code because it first checks the value
>>> of 'len(children)' before accessing 'children'.
>>>
>>>
>>> Could there be a problem with environment settings or something? I
>>> compared path and loaded modules between ipy.exe session and embedded
>>> engine; there are some differences which i can't explain.
>>>
>>>
>>> Best regards,
>>>
>>> C
>>>
>>> (*) note that importing docutils.core requires executing
>>> PythonEngine.InitializeModules first and
>>> PythonEngine.Import("docutils.core") is not a substitute for
>>> PythonEngine.Execute("import docutils.core")
>>>
>>>
>>>
>>> PS: using "IronPython Community Edition r5" and VS Express 2005
>>> _______________________________________________
>>> users mailing list
>>> users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>> _______________________________________________
>>> users mailing list
>>> users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From manatlan at gmail.com  Thu Mar 15 10:19:49 2007
From: manatlan at gmail.com (manatlan)
Date: Thu, 15 Mar 2007 10:19:49 +0100
Subject: [IronPython] Possible Bug ? in collections/appsettings
Message-ID: <d0dc3e5d0703150219n250ece2by1e1df1d2e2764c64@mail.gmail.com>

With ipy 1.0, 1.0.1 and 1.1B1 ..


Here is a simple ipy example :
-----------------------------------------------------------------
import clr
clr.AddReference("System.Configuration")
from System.Configuration import ConfigurationManager

ConfigurationManager.AppSettings.BaseClear()
ConfigurationManager.AppSettings.BaseAdd("key1","value1")

print ConfigurationManager.AppSettings["key1"]
-----------------------------------------------------------------



it produces (french version ;-):
-----------------------------------------------------------------
Traceback (most recent call last):
  File D:\bug.py, line 10, in Initialize
  File , line 0, in get_Item##14
  File System, line unknown, in get_Item
  File System, line unknown, in Get
TypeError: Impossible d'effectuer un cast d'un objet de type
'System.String' en type 'System.Collections.ArrayList'.
-----------------------------------------------------------------

it seems that the appsettings indexer is waiting for an arraylist
instead of a string ?!


From dinov at exchange.microsoft.com  Thu Mar 15 17:00:32 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 15 Mar 2007 09:00:32 -0700
Subject: [IronPython] Possible Bug ? in collections/appsettings
In-Reply-To: <d0dc3e5d0703150219n250ece2by1e1df1d2e2764c64@mail.gmail.com>
References: <d0dc3e5d0703150219n250ece2by1e1df1d2e2764c64@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C22276CEB1784CA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

You're getting back a subclass of NameValueCollection from Configuration.Appsettings.  The NameValueCollection class uses ArrayList's to associate a key to multiple values.  If you change the code to set an array list it will work:

import clr
clr.AddReference("System.Configuration")
from System.Configuration import ConfigurationManager
from System.Collections import ArrayList

ConfigurationManager.AppSettings.BaseClear()
ConfigurationManager.AppSettings.BaseAdd("key1",ArrayList(['value1', 'value2']))

print ConfigurationManager.AppSettings["key1"]

which then prints:

value1,value2


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of manatlan
Sent: Thursday, March 15, 2007 2:20 AM
To: Discussion of IronPython
Subject: [IronPython] Possible Bug ? in collections/appsettings

With ipy 1.0, 1.0.1 and 1.1B1 ..


Here is a simple ipy example :
-----------------------------------------------------------------
import clr
clr.AddReference("System.Configuration")
from System.Configuration import ConfigurationManager

ConfigurationManager.AppSettings.BaseClear()
ConfigurationManager.AppSettings.BaseAdd("key1","value1")

print ConfigurationManager.AppSettings["key1"]
-----------------------------------------------------------------



it produces (french version ;-):
-----------------------------------------------------------------
Traceback (most recent call last):
  File D:\bug.py, line 10, in Initialize
  File , line 0, in get_Item##14
  File System, line unknown, in get_Item
  File System, line unknown, in Get
TypeError: Impossible d'effectuer un cast d'un objet de type
'System.String' en type 'System.Collections.ArrayList'.
-----------------------------------------------------------------

it seems that the appsettings indexer is waiting for an arraylist
instead of a string ?!
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From xmlhacker at gmail.com  Fri Mar 16 00:49:40 2007
From: xmlhacker at gmail.com (M. David Peterson)
Date: Thu, 15 Mar 2007 17:49:40 -0600
Subject: [IronPython] Differences in resource usage between stand alone and
	ClickOnce > Same code base
Message-ID: <eab75e160703151649l2b75e697rbc0a2cf3991f7184@mail.gmail.com>

In the ongoing development of the Xameleon (merge between Amplee/AtomicXML)
application Sylvain and I have been running into various hurdles, none of
which have been insurmountable, but the most recent of which I am having
trouble attempting to understand the problem.

Background: A few days back we discovered that attempting to startup and run
Amplee via CherryPy we were reaching upwards of 150megs just to start up the
server.  After a bit of digging we discovered that saving the assemblies
(-X:SaveAssemblies) during the first run, and then restarting the app
dropped the resource usage meter from 150 to below 50 megs, something that
was definitely within reason.

That said, assuming that the same resources would be consumed for both a
stand alone implementation, as well as a ClickOnce implementation (both
ClickOnce and standalone were both consuming ~150megs before saving the
assemblies), I was surprised to discover recently that there is ~45meg
increase in the ClickOnce implementation over the standalone.

You can access the standalone files @
http://extf.googlecode.com/files/Xameleon.WebApp.0.1.15.zip and the
ClickOnce app @ http://xameleon.org/Personal.Web.Platform/ClickOnce/

These both come from the exact same code base/project @
http://extf.googlecode.com/svn/trunk/Xameleon.WebApp/ and I've verified that
the same compiled .exe modules exist in both implementations, so as far as I
can tell, this isn't a situation where I simply forgot to include some of
the compiled Python modules in the ClickOnce implementation, accounting for
the difference in resource usage as a result.

Any ideas as to what might be the issue, and how to solve it?

Thanks in advance!

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070315/7aac10a0/attachment.html>

From xmlhacker at gmail.com  Fri Mar 16 01:00:17 2007
From: xmlhacker at gmail.com (M. David Peterson)
Date: Thu, 15 Mar 2007 18:00:17 -0600
Subject: [IronPython] Differences in resource usage between stand alone
	and ClickOnce > Same code base
In-Reply-To: <eab75e160703151649l2b75e697rbc0a2cf3991f7184@mail.gmail.com>
References: <eab75e160703151649l2b75e697rbc0a2cf3991f7184@mail.gmail.com>
Message-ID: <eab75e160703151700y41457af3y33a29e61f6bf9925@mail.gmail.com>

Forgot to mention,

>From the commandline,

>>> from cherrypyserver import run,shutdown
>>> run()

to start the server which is then accessible @ http://localhost:9999/

On 3/15/07, M. David Peterson <xmlhacker at gmail.com> wrote:
>
> In the ongoing development of the Xameleon (merge between
> Amplee/AtomicXML) application Sylvain and I have been running into various
> hurdles, none of which have been insurmountable, but the most recent of
> which I am having trouble attempting to understand the problem.
>
> Background: A few days back we discovered that attempting to startup and
> run Amplee via CherryPy we were reaching upwards of 150megs just to start up
> the server.  After a bit of digging we discovered that saving the assemblies
> (-X:SaveAssemblies) during the first run, and then restarting the app
> dropped the resource usage meter from 150 to below 50 megs, something that
> was definitely within reason.
>
> That said, assuming that the same resources would be consumed for both a
> stand alone implementation, as well as a ClickOnce implementation (both
> ClickOnce and standalone were both consuming ~150megs before saving the
> assemblies), I was surprised to discover recently that there is ~45meg
> increase in the ClickOnce implementation over the standalone.
>
> You can access the standalone files @
> http://extf.googlecode.com/files/Xameleon.WebApp.0.1.15.zip and the
> ClickOnce app @ http://xameleon.org/Personal.Web.Platform/ClickOnce/
>
> These both come from the exact same code base/project @ http://extf.googlecode.com/svn/trunk/Xameleon.WebApp/
> and I've verified that the same compiled .exe modules exist in both
> implementations, so as far as I can tell, this isn't a situation where I
> simply forgot to include some of the compiled Python modules in the
> ClickOnce implementation, accounting for the difference in resource usage as
> a result.
>
> Any ideas as to what might be the issue, and how to solve it?
>
> Thanks in advance!
>
> --
> /M:D
>
> M. David Peterson
> http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
> http://dev.aol.com/blog/3155




-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070315/95cd86be/attachment.html>

From dans at houmus.org  Fri Mar 16 05:14:07 2007
From: dans at houmus.org (Dan Shechter)
Date: Fri, 16 Mar 2007 06:14:07 +0200
Subject: [IronPython] SUGGESTION: "Platformized" builds of IP
Message-ID: <002601c76781$8bbcb230$a3361690$@org>

Hi all,
I think there is a need, at least for users of x64  IP, to include an
additional
x86 build for the purposed of COM interop and such.

This can be achieved very easily with the VS .csproj files, but I think
people
Should first come to agree:
a. that it's needed (which should be very obvious for anyone whose
   spent a few hours through the night wondering why he's not able to load 
   his favorite COM object $@#$@#$)
b. On the naming scheme:
   - I *think* that the "default" *.{exe,dll} should remain platform
agnostic
   - And that a separate "ipy-x86.exe" etc. should be added into a different
directory
c. If possible, I would like future releases to follow this naming scheme...

I know that at a first glance this appears to be very Windows oriented, but
this is actually
Also relevant to Mono when dealing with Platform invocation...

	Regards,
	Shechter.



From manatlan at gmail.com  Fri Mar 16 16:00:56 2007
From: manatlan at gmail.com (manatlan)
Date: Fri, 16 Mar 2007 16:00:56 +0100
Subject: [IronPython] Possible Bug ? in collections/appsettings
In-Reply-To: <7AD436E4270DD54A94238001769C22276CEB1784CA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <d0dc3e5d0703150219n250ece2by1e1df1d2e2764c64@mail.gmail.com>
	<7AD436E4270DD54A94238001769C22276CEB1784CA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <d0dc3e5d0703160800u65f8b65ch123967928a5b5703@mail.gmail.com>

thanks really, it works better !

sorry for the disturbance

On 3/15/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> You're getting back a subclass of NameValueCollection from Configuration.Appsettings.  The NameValueCollection class uses ArrayList's to associate a key to multiple values.  If you change the code to set an array list it will work:
>
> import clr
> clr.AddReference("System.Configuration")
> from System.Configuration import ConfigurationManager
> from System.Collections import ArrayList
>
> ConfigurationManager.AppSettings.BaseClear()
> ConfigurationManager.AppSettings.BaseAdd("key1",ArrayList(['value1', 'value2']))
>
> print ConfigurationManager.AppSettings["key1"]
>
> which then prints:
>
> value1,value2
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of manatlan
> Sent: Thursday, March 15, 2007 2:20 AM
> To: Discussion of IronPython
> Subject: [IronPython] Possible Bug ? in collections/appsettings
>
> With ipy 1.0, 1.0.1 and 1.1B1 ..
>
>
> Here is a simple ipy example :
> -----------------------------------------------------------------
> import clr
> clr.AddReference("System.Configuration")
> from System.Configuration import ConfigurationManager
>
> ConfigurationManager.AppSettings.BaseClear()
> ConfigurationManager.AppSettings.BaseAdd("key1","value1")
>
> print ConfigurationManager.AppSettings["key1"]
> -----------------------------------------------------------------
>
>
>
> it produces (french version ;-):
> -----------------------------------------------------------------
> Traceback (most recent call last):
>   File D:\bug.py, line 10, in Initialize
>   File , line 0, in get_Item##14
>   File System, line unknown, in get_Item
>   File System, line unknown, in Get
> TypeError: Impossible d'effectuer un cast d'un objet de type
> 'System.String' en type 'System.Collections.ArrayList'.
> -----------------------------------------------------------------
>
> it seems that the appsettings indexer is waiting for an arraylist
> instead of a string ?!
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


-- 
"Oui, oui."
                -- Shakespeare (Richard III, Acte I, Sc?ne IV)


From fuzzyman at voidspace.org.uk  Sun Mar 18 23:55:07 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 18 Mar 2007 22:55:07 +0000
Subject: [IronPython] PyPy and GenCLI
Message-ID: <45FDC34B.9040609@voidspace.org.uk>

Hello all,

I've read the PyPy EU report on the CLI backend. Most of it is 
experimental and interesting, but hard to see how it is directly 
immediately useful.

If I understand the GenCLI backend correctly though, it may be of 
interest to this list.

IIUC, GenCLI takes RPython code and compiles to IL - with native .NET 
classes for classes defined in RPython.

In PyPy, this is used to translate PyPy itself to provide a Python 
interpreter on top of .NET (unlike IronPython which is a compiler).

(RPython is a static subset of Python - all RPython code is valid Python 
code, but not vice-versa.)

If I'm right, then RPython could be used to compile native .NET 
assemblies, which of course could be used from IronPython. This may be a 
preferable optimisation route than dropping down into C# where extra 
speed is needed.

When benchmarking performance of GenCLI (and PyPy), this is the figures 
they came up with for an implementation of the classical Martin 
Richards?s benchmark :

Implementation Result
richards-c# 7.093
richards-gencli 13.312
CPython richards.py 1139.632
IronPython richards.py 1751.246
pypy-cli richards.py (built-in) 5952.501
pypy-cli richards.py 12010.541

As you can see, gen-cli code is not much slower than C#.

All the best,

Michael Foord
http://www.voidspace.org.uk/ironpython/


From william at resolversystems.com  Tue Mar 20 20:10:05 2007
From: william at resolversystems.com (William Reade)
Date: Tue, 20 Mar 2007 19:10:05 +0000
Subject: [IronPython] Patching sys.modules to hide CLR 'modules'
Message-ID: <4600318D.2000308@resolversystems.com>

Hi all

I recently wanted to do as described in the subject line. However, it 
seems that when I import (say) System.Drawing, there is no detectable 
change to sys.modules, and so I cannot temporarily replace it with my 
own module in order to substitute simpler functionality for testing 
purposes*. Is this correct? If so, can I work around it, and what 
exciting pitfalls will I walk into if I try?

William

* That is to say, I cannot monkey-patch anything in sys.modules that 
didn't come from IronPython.

-- 
William Reade
Resolver Systems
william at resolversystems.com

Office address:     17a Clerkenwell Road, London EC1M 5RD, UK
Registered address: 843 Finchley Road, London NW11 8NA, UK

Resolver Systems Limited is registered in England and Wales as company number 5467329. 



From dinov at exchange.microsoft.com  Tue Mar 20 20:44:08 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 20 Mar 2007 12:44:08 -0700
Subject: [IronPython] Patching sys.modules to hide CLR 'modules'
In-Reply-To: <4600318D.2000308@resolversystems.com>
References: <4600318D.2000308@resolversystems.com>
Message-ID: <7AD436E4270DD54A94238001769C22276D330D2046@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

The .NET namespaces don't live in sys.modules instead they live in their own hierarchy which is implemented as a "ReflectedPackage" class.  The ReflectedPackage is checked after we fail to find the module in sys.modules so if you to stick something into sys.modules you'll take precedence over the namespaces.

If you want to delegate back to the normal .NET namespaces you'll want to import the namespace first, then patch sys.modules, and have your module delegate back.

Something like:

import System as S
class myclass(object):
    def __init__(self, backing):
            self.backing = backing
    def __getattr__(self, name):
                # your interception here
            return getattr(self.backing, name)
import sys
sys.modules['System'] = myclass(S)
import System.Drawing  # myclass.__getattr__ is called for Drawing


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
Sent: Tuesday, March 20, 2007 12:10 PM
To: Discussion of IronPython
Subject: [IronPython] Patching sys.modules to hide CLR 'modules'

Hi all

I recently wanted to do as described in the subject line. However, it
seems that when I import (say) System.Drawing, there is no detectable
change to sys.modules, and so I cannot temporarily replace it with my
own module in order to substitute simpler functionality for testing
purposes*. Is this correct? If so, can I work around it, and what
exciting pitfalls will I walk into if I try?

William

* That is to say, I cannot monkey-patch anything in sys.modules that
didn't come from IronPython.

--
William Reade
Resolver Systems
william at resolversystems.com

Office address:     17a Clerkenwell Road, London EC1M 5RD, UK
Registered address: 843 Finchley Road, London NW11 8NA, UK

Resolver Systems Limited is registered in England and Wales as company number 5467329.

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


From michael.foord at resolversystems.com  Wed Mar 21 15:01:41 2007
From: michael.foord at resolversystems.com (Michael Foord)
Date: Wed, 21 Mar 2007 14:01:41 +0000
Subject: [IronPython] Problems with Imports
Message-ID: <46013AC5.5030908@resolversystems.com>

Hello all,

We do see some differences between the way IronPython and CPython 
resolve imports. (Tested with IP 1.0.1 I'm afraid.) We encountered these 
when patching sys.modules for the purposes of testing, but they could 
affect any code that does magic with sys.modules.

It looks like you can't put arbitrary objects into sys.modules in 
IronPython, but you can with CPython. The following code works fine on 
CPython, but fails on IP :

import sys
class MockModule(object):
   def __init__(self, name):
   self.__name__ = name


TopModule = MockModule("TopModule")
sys.modules["TopModule"] = TopModule

SubModule = MockModule("SubModule")
SubModule.Object = object()
TopModule.SubModule = SubModule
sys.modules["TopModule.SubModule"] = SubModule

import TopModule.SubModule
from TopModule.SubModule import Object


There is also another difference. The following code works fine on 
IronPython, but *not* on CPython


import sys
ModuleType = type(sys)

TopModule = ModuleType("TopModule")
sys.modules["TopModule"] = TopModule

SubModule = ModuleType("SubModule")
SubModule.Object = object()
TopModule.SubModule = SubModule
# Required for CPython, not IronPython
# sys.modules["TopModule.SubModule"] = SubModule

import TopModule.SubModule
from TopModule.SubModule import Object


You have to uncomment out 'the line' to get it to work in CPython. (Not 
worth fixing by the way - unless it means that something else is broken 
as a result - just a 'difference'.)

Michael Foord
http://www.resolversystems.com

-- 
Michael Foord
Resolver Systems
michael.foord at resolversystems.com

Office address:     17a Clerkenwell Road, London EC1M 5RD, UK
Registered address: 843 Finchley Road, London NW11 8NA, UK

Resolver Systems Limited is registered in England and Wales as company number 5467329.
VAT No. GB 893 5643 79 



From dinov at exchange.microsoft.com  Wed Mar 21 19:56:21 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 21 Mar 2007 11:56:21 -0700
Subject: [IronPython] Problems with Imports
In-Reply-To: <46013AC5.5030908@resolversystems.com>
References: <46013AC5.5030908@resolversystems.com>
Message-ID: <7AD436E4270DD54A94238001769C22276D3374F1FB@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for reporting this.  I've opened bug #9066 to track this.  If you don't need to add custom runtime behavior to the objects as a work around you could create a new module using imp.new_module and push the values into there.  I'm marking this as a v2.0 bug but if it's blocking you let me know.

On the 2nd example you might want to try using a type other than sys as the module type.  Sys is a little special in IronPython.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, March 21, 2007 7:02 AM
To: Discussion of IronPython
Subject: [IronPython] Problems with Imports

Hello all,

We do see some differences between the way IronPython and CPython
resolve imports. (Tested with IP 1.0.1 I'm afraid.) We encountered these
when patching sys.modules for the purposes of testing, but they could
affect any code that does magic with sys.modules.

It looks like you can't put arbitrary objects into sys.modules in
IronPython, but you can with CPython. The following code works fine on
CPython, but fails on IP :

import sys
class MockModule(object):
   def __init__(self, name):
   self.__name__ = name


TopModule = MockModule("TopModule")
sys.modules["TopModule"] = TopModule

SubModule = MockModule("SubModule")
SubModule.Object = object()
TopModule.SubModule = SubModule
sys.modules["TopModule.SubModule"] = SubModule

import TopModule.SubModule
from TopModule.SubModule import Object


There is also another difference. The following code works fine on
IronPython, but *not* on CPython


import sys
ModuleType = type(sys)

TopModule = ModuleType("TopModule")
sys.modules["TopModule"] = TopModule

SubModule = ModuleType("SubModule")
SubModule.Object = object()
TopModule.SubModule = SubModule
# Required for CPython, not IronPython
# sys.modules["TopModule.SubModule"] = SubModule

import TopModule.SubModule
from TopModule.SubModule import Object


You have to uncomment out 'the line' to get it to work in CPython. (Not
worth fixing by the way - unless it means that something else is broken
as a result - just a 'difference'.)

Michael Foord
http://www.resolversystems.com

--
Michael Foord
Resolver Systems
michael.foord at resolversystems.com

Office address:     17a Clerkenwell Road, London EC1M 5RD, UK
Registered address: 843 Finchley Road, London NW11 8NA, UK

Resolver Systems Limited is registered in England and Wales as company number 5467329.
VAT No. GB 893 5643 79

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


From giles.thomas at resolversystems.com  Wed Mar 21 20:13:52 2007
From: giles.thomas at resolversystems.com (Giles Thomas)
Date: Wed, 21 Mar 2007 19:13:52 +0000
Subject: [IronPython] IronPython internships!
Message-ID: <460183F0.2010209@resolversystems.com>

Resolver Systems are offering two internships in software development, 
based in London, for the Summer of 2007.  These are designed for 
students looking for work over their Summer vacations.

We are a software company, building a new kind of numerical analysis 
system, using IronPython and the .NET framework in an Agile development 
environment.  Interns will be fully-fledged members of the development 
team for the duration of their stay - we follow the XP practice of pair 
programming, so mentoring will be continuous and intense, giving an 
excellent start in professional software engineering for those who want 
to make it their career.  We're interested in hearing from anyone 
studying for a degree in numerate subject.

Salary is ?1,333 per calendar month; you should be able to work for at 
least 10 weeks over the course of the summer.  Precise dates are negotiable.

Please apply by email, including a CV, to jobs at resolversystems.com.


Regards,

Giles

-- 
Giles Thomas
giles.thomas at resolversystems.com
+44 (0) 20 7253 6372

Resolver Systems Ltd
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



From fuzzyman at voidspace.org.uk  Wed Mar 21 21:43:28 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 21 Mar 2007 20:43:28 +0000
Subject: [IronPython] Problems with Imports
In-Reply-To: <7AD436E4270DD54A94238001769C22276D3374F1FB@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <46013AC5.5030908@resolversystems.com>
	<7AD436E4270DD54A94238001769C22276D3374F1FB@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <460198F0.3020103@voidspace.org.uk>

Dino Viehland wrote:
> Thanks for reporting this.  I've opened bug #9066 to track this.  If you don't need to add custom runtime behavior to the objects as a work around you could create a new module using imp.new_module and push the values into there.  I'm marking this as a v2.0 bug but if it's blocking you let me know.
>   
The second example is our workaround. :-)

Thanks

Michael
http://www.voidspace.org.uk/ironpython/


> On the 2nd example you might want to try using a type other than sys as the module type.  Sys is a little special in IronPython.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Wednesday, March 21, 2007 7:02 AM
> To: Discussion of IronPython
> Subject: [IronPython] Problems with Imports
>
> Hello all,
>
> We do see some differences between the way IronPython and CPython
> resolve imports. (Tested with IP 1.0.1 I'm afraid.) We encountered these
> when patching sys.modules for the purposes of testing, but they could
> affect any code that does magic with sys.modules.
>
> It looks like you can't put arbitrary objects into sys.modules in
> IronPython, but you can with CPython. The following code works fine on
> CPython, but fails on IP :
>
> import sys
> class MockModule(object):
>    def __init__(self, name):
>    self.__name__ = name
>
>
> TopModule = MockModule("TopModule")
> sys.modules["TopModule"] = TopModule
>
> SubModule = MockModule("SubModule")
> SubModule.Object = object()
> TopModule.SubModule = SubModule
> sys.modules["TopModule.SubModule"] = SubModule
>
> import TopModule.SubModule
> from TopModule.SubModule import Object
>
>
> There is also another difference. The following code works fine on
> IronPython, but *not* on CPython
>
>
> import sys
> ModuleType = type(sys)
>
> TopModule = ModuleType("TopModule")
> sys.modules["TopModule"] = TopModule
>
> SubModule = ModuleType("SubModule")
> SubModule.Object = object()
> TopModule.SubModule = SubModule
> # Required for CPython, not IronPython
> # sys.modules["TopModule.SubModule"] = SubModule
>
> import TopModule.SubModule
> from TopModule.SubModule import Object
>
>
> You have to uncomment out 'the line' to get it to work in CPython. (Not
> worth fixing by the way - unless it means that something else is broken
> as a result - just a 'difference'.)
>
> Michael Foord
> http://www.resolversystems.com
>
> --
> Michael Foord
> Resolver Systems
> michael.foord at resolversystems.com
>
> Office address:     17a Clerkenwell Road, London EC1M 5RD, UK
> Registered address: 843 Finchley Road, London NW11 8NA, UK
>
> Resolver Systems Limited is registered in England and Wales as company number 5467329.
> VAT No. GB 893 5643 79
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From belred at gmail.com  Fri Mar 23 19:48:00 2007
From: belred at gmail.com (Bryan)
Date: Fri, 23 Mar 2007 11:48:00 -0700
Subject: [IronPython] compiling
Message-ID: <200703231148.01202.belred@gmail.com>

hi,

i just wrote my first ipy script and i have some questions.  

# hello.py

import clr
clr.AddReference('System.Windows.Forms')
import System.Windows.Forms as WinForms

def show():
    WinForms.MessageBox.Show('Hello', 'Hello World')
    
if __name__ == '__main__':
    show()


when i execute the following

c:\> ipy -X:SaveAssemblies hello.py

a hello.exe file is generated and i can successfully execute it.

but when i compile with pyc as follows:

c:\> ipy pyc /main:hello.py 
Input Files:
    hello.py
Resource Files:
Output:
    hello.exe
Target:
    ConsoleApplication

-or-

c:\> ipy pyc /main:hello.py /target:winexe
Input Files:
    hello.py
Resource Files:
Output:
    hello.exe
Target:
    WindowApplication

it generates hello.exe, but the program doesn't run (the MessageBox doesn't 
display).  i even tried explicitly adding /r:System.Windows.Forms without 
luck.  what am i doing wrong?


thanks,


bryan







From dinov at exchange.microsoft.com  Fri Mar 23 21:09:07 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 23 Mar 2007 13:09:07 -0700
Subject: [IronPython] IronPython v1.1 RC1 Released
Message-ID: <7AD436E4270DD54A94238001769C22276D6CCC08FA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Hello IronPython Community,

We have just released IronPython 1.1 Release Candidate 1. IronPython v1.1 is a minor update to IronPython including both new functionality as well as a number of targeted bug fixes.  The new functionality in v1.1 includes several new modules (array, SHA, MD5, and select), support for XML Doc comments within the help system and __doc__ tags, as well as support for loading cached pre-compiled modules.  If no regressions are discovered with this release then we will re-release the same binary as v1.1 final.
 You can download the release from: 1.1 Release Candidate

We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: Anthony Baxter, Arman0, Christian Muirhead, Doubleyewdee, Eloff, J?rgen Stenarson, Py_Sunil, Seo Sanghyeon, Tarlano, and Whit537.

More complete list of changes and bug fixes:
============================================
CodePlex bug # 1216: ironpython shows different error msgs when we use cpython's os module
CodePlex bug #1403 int.__dict__[0]=0
CodePlex bug #2704 __import__ and packages aren't mixing well
CodePlex bug #5083 operator.__contains__ is broken
CodePlex bug #5445 socket.getaddrinfo(...) does not throw on nonsense parameters
CodePlex bug #5446 socket.getaddrinfo(...) proto parameter CodePlex bug #5566 base64 slash bug
CodePlex bug #5609 (Py2.5) File lacks __enter__ and __exit__
CodePlex bug #5641 co_name in code objects is None
CodePlex bug #5712 iterating over __main__.__dict__ throws
CodePlex bug #5904 Multi-line dictionary expressions in IP interpreter console not compatible w/ CPython Interpreter console
CodePlex bug #6010 UnicodeErrorInit sets @object instead of object
CodePlex bug #6142 Setting func_name on function doesn't show up in __name__
CodePlex bug #6265 maxsplit keyword arg of re.split not accepted
CodePlex bug #6704 globals().fromkeys(...) broken
CodePlex bug #6706 globals().Values enumerator broken
CodePlex bug #6735 help incorrectly displays arguments for params functions
CodePlex bug #6805 func_code.co_argcount and func_code.co_flags are wrong
CodePlex bug #7532 func_defaults is empty tuple when there are no defaults
CodePlex bug #7982 ^L yields SyntaxError CodePlex bug #7827 IronPython thread module does not implement stack_size
CodePlex bug #7828 IronPython lock type does not support context manager methods

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070323/c3ae85d6/attachment.html>

From dinov at exchange.microsoft.com  Fri Mar 23 21:11:28 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 23 Mar 2007 13:11:28 -0700
Subject: [IronPython] IronPython v1.1 RC1 Released
In-Reply-To: <7AD436E4270DD54A94238001769C22276D6CCC08FA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C22276D6CCC08FA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <7AD436E4270DD54A94238001769C22276D6CCC08FC@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Now with the link to the release :)

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, March 23, 2007 1:09 PM
To: users at lists.ironpython.com
Subject: [IronPython] IronPython v1.1 RC1 Released

Hello IronPython Community,

We have just released IronPython 1.1 Release Candidate 1. IronPython v1.1 is a minor update to IronPython including both new functionality as well as a number of targeted bug fixes.  The new functionality in v1.1 includes several new modules (array, SHA, MD5, and select), support for XML Doc comments within the help system and __doc__ tags, as well as support for loading cached pre-compiled modules.  If no regressions are discovered with this release then we will re-release the same binary as v1.1 final.

You can download the release from: 1.1 Release Candidate<http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=1975>

We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: Anthony Baxter, Arman0, Christian Muirhead, Doubleyewdee, Eloff, J?rgen Stenarson, Py_Sunil, Seo Sanghyeon, Tarlano, and Whit537.

More complete list of changes and bug fixes:
============================================
CodePlex bug # 1216: ironpython shows different error msgs when we use cpython's os module
CodePlex bug #1403 int.__dict__[0]=0
CodePlex bug #2704 __import__ and packages aren't mixing well
CodePlex bug #5083 operator.__contains__ is broken
CodePlex bug #5445 socket.getaddrinfo(...) does not throw on nonsense parameters
CodePlex bug #5446 socket.getaddrinfo(...) proto parameter CodePlex bug #5566 base64 slash bug
CodePlex bug #5609 (Py2.5) File lacks __enter__ and __exit__
CodePlex bug #5641 co_name in code objects is None
CodePlex bug #5712 iterating over __main__.__dict__ throws
CodePlex bug #5904 Multi-line dictionary expressions in IP interpreter console not compatible w/ CPython Interpreter console
CodePlex bug #6010 UnicodeErrorInit sets @object instead of object
CodePlex bug #6142 Setting func_name on function doesn't show up in __name__
CodePlex bug #6265 maxsplit keyword arg of re.split not accepted
CodePlex bug #6704 globals().fromkeys(...) broken
CodePlex bug #6706 globals().Values enumerator broken
CodePlex bug #6735 help incorrectly displays arguments for params functions
CodePlex bug #6805 func_code.co_argcount and func_code.co_flags are wrong
CodePlex bug #7532 func_defaults is empty tuple when there are no defaults
CodePlex bug #7982 ^L yields SyntaxError CodePlex bug #7827 IronPython thread module does not implement stack_size
CodePlex bug #7828 IronPython lock type does not support context manager methods

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070323/9a3c2cb0/attachment.html>

From sh at defuze.org  Fri Mar 23 21:13:54 2007
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Fri, 23 Mar 2007 20:13:54 +0000
Subject: [IronPython] IronPython v1.1 RC1 Released
In-Reply-To: <7AD436E4270DD54A94238001769C22276D6CCC08FC@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C22276D6CCC08FA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<7AD436E4270DD54A94238001769C22276D6CCC08FC@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <46043502.3010203@defuze.org>

Congrats guys :)

Dino Viehland wrote:
> Now with the link to the release :)
> 
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Friday, March 23, 2007 1:09 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] IronPython v1.1 RC1 Released
> 
> Hello IronPython Community,
> 
> We have just released IronPython 1.1 Release Candidate 1. IronPython v1.1 is a minor update to IronPython including both new functionality as well as a number of targeted bug fixes.  The new functionality in v1.1 includes several new modules (array, SHA, MD5, and select), support for XML Doc comments within the help system and __doc__ tags, as well as support for loading cached pre-compiled modules.  If no regressions are discovered with this release then we will re-release the same binary as v1.1 final.
> 
> You can download the release from: 1.1 Release Candidate<http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=1975>
> 
> We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: Anthony Baxter, Arman0, Christian Muirhead, Doubleyewdee, Eloff, J?rgen Stenarson, Py_Sunil, Seo Sanghyeon, Tarlano, and Whit537.
> 
> More complete list of changes and bug fixes:
> ============================================
> CodePlex bug # 1216: ironpython shows different error msgs when we use cpython's os module
> CodePlex bug #1403 int.__dict__[0]=0
> CodePlex bug #2704 __import__ and packages aren't mixing well
> CodePlex bug #5083 operator.__contains__ is broken
> CodePlex bug #5445 socket.getaddrinfo(...) does not throw on nonsense parameters
> CodePlex bug #5446 socket.getaddrinfo(...) proto parameter CodePlex bug #5566 base64 slash bug
> CodePlex bug #5609 (Py2.5) File lacks __enter__ and __exit__
> CodePlex bug #5641 co_name in code objects is None
> CodePlex bug #5712 iterating over __main__.__dict__ throws
> CodePlex bug #5904 Multi-line dictionary expressions in IP interpreter console not compatible w/ CPython Interpreter console
> CodePlex bug #6010 UnicodeErrorInit sets @object instead of object
> CodePlex bug #6142 Setting func_name on function doesn't show up in __name__
> CodePlex bug #6265 maxsplit keyword arg of re.split not accepted
> CodePlex bug #6704 globals().fromkeys(...) broken
> CodePlex bug #6706 globals().Values enumerator broken
> CodePlex bug #6735 help incorrectly displays arguments for params functions
> CodePlex bug #6805 func_code.co_argcount and func_code.co_flags are wrong
> CodePlex bug #7532 func_defaults is empty tuple when there are no defaults
> CodePlex bug #7982 ^L yields SyntaxError CodePlex bug #7827 IronPython thread module does not implement stack_size
> CodePlex bug #7828 IronPython lock type does not support context manager methods
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From dinov at exchange.microsoft.com  Fri Mar 23 23:35:43 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 23 Mar 2007 15:35:43 -0700
Subject: [IronPython] compiling
In-Reply-To: <200703231148.01202.belred@gmail.com>
References: <200703231148.01202.belred@gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C22276D6CCC09DF@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

I think the problem is we're not setting the module name to __main__. If I do this with:

import clr

clr.AddReference('System.Windows.Forms')

from System.Windows.Forms import MessageBox

MessageBox.Show(__name__)

>From 'hello.py' the message box shows 'hello'.

I believe this is the same as bug #2537 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=2537).  Currently the bug has 0 votes so we haven't been paying too much attention to it to date.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Bryan
Sent: Friday, March 23, 2007 11:48 AM
To: users at lists.ironpython.com
Subject: [IronPython] compiling

hi,

i just wrote my first ipy script and i have some questions.

# hello.py

import clr
clr.AddReference('System.Windows.Forms')
import System.Windows.Forms as WinForms

def show():
    WinForms.MessageBox.Show('Hello', 'Hello World')

if __name__ == '__main__':
    show()


when i execute the following

c:\> ipy -X:SaveAssemblies hello.py

a hello.exe file is generated and i can successfully execute it.

but when i compile with pyc as follows:

c:\> ipy pyc /main:hello.py
Input Files:
    hello.py
Resource Files:
Output:
    hello.exe
Target:
    ConsoleApplication

-or-

c:\> ipy pyc /main:hello.py /target:winexe
Input Files:
    hello.py
Resource Files:
Output:
    hello.exe
Target:
    WindowApplication

it generates hello.exe, but the program doesn't run (the MessageBox doesn't
display).  i even tried explicitly adding /r:System.Windows.Forms without
luck.  what am i doing wrong?


thanks,


bryan





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


From ward at usq.edu.au  Mon Mar 26 02:36:45 2007
From: ward at usq.edu.au (Ron Ward)
Date: Mon, 26 Mar 2007 10:36:45 +1000
Subject: [IronPython] Renaming bug under mono on Linux - IronPython v1.1 RC1
	Released
References: <7AD436E4270DD54A94238001769C22276D6CCC08FA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <841452F66E1F99488A3BAF44E51CB89520FC46@babbage.usq.edu.au>


os.rename() and posix.rename() does not work under mono on Linux (works OK under windows).

Receive an error message stating that the file you are trying to rename does not exist.

Ron Ward

-----Original Message-----
From: users-bounces at lists.ironpython.com on behalf of Dino Viehland
Sent: Sat 3/24/2007 6:09 AM
To: users at lists.ironpython.com
Subject: [IronPython] IronPython v1.1 RC1 Released
 
Hello IronPython Community,

We have just released IronPython 1.1 Release Candidate 1. IronPython v1.1 is a minor update to IronPython including both new functionality as well as a number of targeted bug fixes.  The new functionality in v1.1 includes several new modules (array, SHA, MD5, and select), support for XML Doc comments within the help system and __doc__ tags, as well as support for loading cached pre-compiled modules.  If no regressions are discovered with this release then we will re-release the same binary as v1.1 final.
 You can download the release from: 1.1 Release Candidate

We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: Anthony Baxter, Arman0, Christian Muirhead, Doubleyewdee, Eloff, J?rgen Stenarson, Py_Sunil, Seo Sanghyeon, Tarlano, and Whit537.

More complete list of changes and bug fixes:
============================================
CodePlex bug # 1216: ironpython shows different error msgs when we use cpython's os module
CodePlex bug #1403 int.__dict__[0]=0
CodePlex bug #2704 __import__ and packages aren't mixing well
CodePlex bug #5083 operator.__contains__ is broken
CodePlex bug #5445 socket.getaddrinfo(...) does not throw on nonsense parameters
CodePlex bug #5446 socket.getaddrinfo(...) proto parameter CodePlex bug #5566 base64 slash bug
CodePlex bug #5609 (Py2.5) File lacks __enter__ and __exit__
CodePlex bug #5641 co_name in code objects is None
CodePlex bug #5712 iterating over __main__.__dict__ throws
CodePlex bug #5904 Multi-line dictionary expressions in IP interpreter console not compatible w/ CPython Interpreter console
CodePlex bug #6010 UnicodeErrorInit sets @object instead of object
CodePlex bug #6142 Setting func_name on function doesn't show up in __name__
CodePlex bug #6265 maxsplit keyword arg of re.split not accepted
CodePlex bug #6704 globals().fromkeys(...) broken
CodePlex bug #6706 globals().Values enumerator broken
CodePlex bug #6735 help incorrectly displays arguments for params functions
CodePlex bug #6805 func_code.co_argcount and func_code.co_flags are wrong
CodePlex bug #7532 func_defaults is empty tuple when there are no defaults
CodePlex bug #7982 ^L yields SyntaxError CodePlex bug #7827 IronPython thread module does not implement stack_size
CodePlex bug #7828 IronPython lock type does not support context manager methods



This email (including any attached files) is confidential and is for the
intended recipient(s) only.  If you received this email by mistake,
please, as a courtesy, tell the sender, then delete this email.

The views and opinions are the originator's and do not necessarily
reflect those of the University of Southern Queensland.  Although all
reasonable precautions were taken to ensure that this email contained no
viruses at the time it was sent we accept no liability for any losses
arising from its receipt.

The University of Southern Queensland is a registered provider of
education with the Australian Government (CRICOS Institution Code No's.
QLD 00244B / NSW 02225M)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4228 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070326/c5521bf7/attachment.bin>

From dans at houmus.org  Mon Mar 26 17:13:50 2007
From: dans at houmus.org (Dan Shechter)
Date: Mon, 26 Mar 2007 17:13:50 +0200
Subject: [IronPython] IronPython x86/x64
Message-ID: <002601c76fb9$5e0be820$1a23b860$@org>

Hi,
Since I didn't receive any comments regarding my proposal last time I will
try to re-iterate it once again.

I think it would be very helpful for IP official builds/project files to
contain two versions of the ipy.exe and ipw.exe
ipy.exe / ipyw.exe - Targeted for all architectures
ipy-x86.exe / ipyw-x86.exe - Targeted for x86 processors specifically.

Having the additional *-x86.exe versions will allow developers needing to
interface with 32-bit DLLs / COM objects on a x64 bit system
do so without having to recompile and tinker with IP project files.

Any official comment / discussion would be greatly appreciated.





From dinov at exchange.microsoft.com  Mon Mar 26 20:36:26 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 26 Mar 2007 11:36:26 -0700
Subject: [IronPython] IronPython x86/x64
In-Reply-To: <002601c76fb9$5e0be820$1a23b860$@org>
References: <002601c76fb9$5e0be820$1a23b860$@org>
Message-ID: <7AD436E4270DD54A94238001769C22276D6CCC0CE8@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

In general I think this is a good idea.  Not only will it improve support in interop scenarios but it also helps with thinks like debugging, profiling, etc...  for those of us doing lots of that w/ VS and IronPython.  Personally I always use an x86 IronPython on my 64-bit machines simply because the tools tend to work much better with it.

I've opened a CodePlex issue to track it (9158 - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9158) but I don't think we'll do this until v2.0.  Thanks for the suggestion and sorry we didn't get back to you the 1st time.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Shechter
Sent: Monday, March 26, 2007 8:14 AM
To: 'Discussion of IronPython'
Subject: [IronPython] IronPython x86/x64

Hi,
Since I didn't receive any comments regarding my proposal last time I will
try to re-iterate it once again.

I think it would be very helpful for IP official builds/project files to
contain two versions of the ipy.exe and ipw.exe
ipy.exe / ipyw.exe - Targeted for all architectures
ipy-x86.exe / ipyw-x86.exe - Targeted for x86 processors specifically.

Having the additional *-x86.exe versions will allow developers needing to
interface with 32-bit DLLs / COM objects on a x64 bit system
do so without having to recompile and tinker with IP project files.

Any official comment / discussion would be greatly appreciated.



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


From kfarmer at thuban.org  Mon Mar 26 23:37:28 2007
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Mon, 26 Mar 2007 14:37:28 -0700
Subject: [IronPython] CodePlex SCC Client
Message-ID: <EEDCD954DD4A0D488BBDBDDCC2607544021524@meta-exchange.circle-cross.home>

Just saw this posting on msdn blogs: http://blogs.msdn.com/codeplex/archive/2007/03/26/announcing-the-codeplex-source-control-client.aspx
 
Note the anonymous access item in the todo list, as well as patch support.  Looks like it'll be easier to subscribe to projects with this tool.