Re: [IronPython] vs integration

[Dino Viehland]

I didn't know it off the top of my head, but it looks like this is devenv.exe 
/rootsuffix Exp (devenv is in (in %ProgramFiles%\Microsoft Visual Studio 
8\Common7\IDE\)).

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill64bits
Sent: Tuesday, November 14, 2006 5:09 PM
To: Discussion of IronPython
Subject: Re: [IronPython] vs integration

That works. Thanks!
Do you remember what "command IronPython.sln runs when you hit F5." ?
- Original Message -
From: Dino Viehland
To: Discussion of IronPython
Sent: Tuesday, November 14, 2006 3:44 PM
Subject: Re: [IronPython] vs integration

How are you starting VS after the installation, are you starting the 
experimental hive?  The way I typically start this is in  %ProgramFiles% 
(%ProgramFiles(x86)% if yo're on 64-bit) there's a Visual Studio 2005 SDK 
folder that has a year.month folder (I don't remember what v3 is off the top of 
my head) that has 
VisualStudioIntegration\Samples\IronPythonIntegration\IronPython.sln below it.  
If you open this solution, hit F5 in VS, then another copy of VS opens.  It's 
this "inner" copy of VS which contains the IronPython integration support.

Once you've done that once you should be able to start the experimental hive of 
VS directly w/ IronPython support by starting the same command IronPython.sln 
runs when you hit F5.



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill64bits
Sent: Tuesday, November 14, 2006 1:36 PM
To: Discussion of IronPython
Subject: Re: [IronPython] vs integration

File->New Web Site was used in an example I looked at.

But I tried it your way, and File->New Project does not show anything about 
IronPython.

- Original Message -
From: Dino Viehland
To: Discussion of IronPython
Sent: Tuesday, November 14, 2006 2:03 PM
Subject: Re: [IronPython] vs integration

Are you doing File->New Web Site?  I think you need to do File->New Project

Then choose IronPython->Web from the tree view and then there are options for 
ASP.NET Web Application.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
Behalf Of Bill64bits
Sent: Tuesday, November 14, 2006 11:47 AM
To: users@lists.ironpython.com
Subject: [IronPython] vs integration

I installed the Visual Studio 2005 SDK "v3" on my box (win2000 server) but when 
I create a new web_site,
IronPython is not given as a choice under "language".
Do I have to do something else to make it work?

(yes, IronPython-1.0.1 is installed)

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

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

Re: [IronPython] Python Cryptographic Toolkit for IronPython

[Jörgen Stenarson]

Hi

I'm happy to announce that my attempt to port pyreadline to ironpython 
finally has reached a state where I think it can be used. A new feature 
of this version of pyreadline is that you can select text using 
shift-Left/Right. Copy is bound to ctrl-shift-x (I might move it to 
ctrl-c but right now ctrl-c generates KeyboardInterupt so that will 
probably take some work)

It has not been too difficult to get it to work. Most work was spent 
trying to understand and work around the differences between plain win32 
console functions and .NET System.Console.

In this post I will describe how you can try it out for your self, in 
another post I will describe the differences I found between how cpython 
and ironpython use readline.


1) You will need to compile your own version of ironpython because there 
is need for a patch to allow pyreadline to insert itself as a new readline.

Download ironpython source and make sure you can compile it.

then in the file PythonCommandLine.cs patch the class definition:

 change:

 class PythonCommandLine

 to:

 public class PythonCommandLine
Now recompile

2) you will also need to patch rlcompleter.py in the cpython lib if you 
want tab completion to work for global variables

line 85:
self.namespace = __main__.__dict__
should read
self.namespace = __main__.__dict__.copy()

3) get pyreadline using svn from:
svn co http://ipython.scipy.org/svn/ipython/pyreadline/branches/refactor 
  localpath/pyreadline_branch



4) copy pyreadlineconfig.ini from 
localpath/pyreadline_branch/pyreadline/configuration/ to your 
c:/documents and settings/USERNAME

   copy startup.py from 
localpath/pyreadline_branch/pyreadline/configuration/ to your pythonpath



5) launch ipy and do import startup. Now you should have pyreadline 
active with tabcompletion


/Jörgen



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

Re: [IronPython] Singles not comparing properly

[Dave Fugate]

Thanks for reporting this!  The bug is that <, <=, >, and >= do not work when 
the left operand
is a System.Single and the right operand is just about any integer type (CLR or 
Python).
The CodePlex Work Item for this is 
http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=5682


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mujtaba Syed
Sent: Friday, November 03, 2006 1:55 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Singles not comparing properly

Also note that:

>>> 5.0 <= s <= 500.0
True
>>> 5.0 <= d <= 500.0
True

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian 
Muirhead
Sent: Friday, November 03, 2006 3:25 AM
To: users@lists.ironpython.com
Subject: [IronPython] Singles not comparing properly

Hi guys -

We encountered a strange bug today, which we eventually worked out was
being caused by the fact that a number we thought was a float (a Double)
was actually a Single. The problem was this:

 >>> from System import Double, Single
 >>> d = Double(8.0)
 >>> d
8.0
 >>> 5 <= d <= 500
True
 >>> s = Single(8.0)
 >>> s
8.0
 >>> 5 <= s <= 500
False

There's no real analogue to this in CPython, but it feels like Single
and Double should behave the same here. Is this a bug?

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

[IronPython] Differences between cpython and ironpython

[Jörgen Stenarson]

Hi,

Sorry my announcement message on the ironpython pyreadline port got the 
wrong subject.

This mail contains the differences I found between cpython and 
ironpython when working on the pyreadline port.

1) import time is much higher in ironpython than cpython

2) Had to patch source to be able to replace readline function:

in PythonCommandLine.cs change class definition:
   class PythonCommandLine
to:
   public class PythonCommandLine

3) Defaultprompt, in cpython the prompt is printed by readline (it is 
passed as a parameter to readline).
In ironpython the interpreter prints it before calling readline.


4) mode string for open: in cpython does not react to unknown characters 
like "rt"=="r"

5) It seems I'm unable to catch KeyboardInterrupts properly. It looks 
like the except logic is executed but the KeyboardInterrupt is reraised 
automatically.

6) rlcompleter had to be patched

line 85:
 self.namespace = __main__.__dict__
should read
 self.namespace = __main__.__dict__.copy()
I think it is related to the following difference in behaviour


C:\IronPython-1.0.1>ipy
IronPython 1.0 (1.0) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> import __main__
 >>> w=10
 >>> for w in __main__.__dict__:
...  print w
...
[__name__, __main__]
Traceback (most recent call last):
   File , line 0, in ##105
   File mscorlib, line unknown, in MoveNext
   File mscorlib, line unknown, in ThrowInvalidOperationException
SystemError: Collection was modified; enumeration operation may not execute.
 >>>

compared to cpython:
C:\IronPython-1.0.1>python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import __main__
 >>> w=10
 >>> for w in __main__.__dict__:
... print w
...
quit
__builtins__
__file__
exit
w
__main__
__name__
__doc__
 >>>



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

Re: [IronPython] fepy socket seek

[Christopher Baus]

> When you write to file,
> 1. writer is checked for null. If it is, stream is not writable. Raise
> exception.
> 2. string is passed to the writer.
> 3. The writer does appropriate newline translation and write it.
> 4. The number of bytes written, after newline translation, is returned.
> 5. reader is checked for null. If it is, some steps are skipped.
> 6. reader's position is read.
> 7. The number of bytes written is added to the current position.
> 8. reader's position is set to the sum in 7 in order to syncrhonise.
>
> 6 will cause seek error if stream is not seekable. This doesn't
> happen, because reader implementations maintain position by themselves
> instead of reading underlying stream's position. It does read
> underlying stream's position in the constructor, but only if it's
> seekable. Bah, except PythonBinaryReader, that is.
>
> So seek error is inevitable, whenever all of following conditions are met:
> 1. write() is called
> 2. underlying stream is writable
> 3. underlying stream is readable
> 4. binary reader is used
> 5. underlying stream is not seekable
>

Great analysis Seo.  What I don't understand is why this happens only in
binary mode, and when the write flag is set.  Why is there a
PythonBinaryReader created at all?

I'm setting up my development environment to trace the IP code.


http://baus.net/

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

Re: [IronPython] fepy socket seek

[Sanghyeon Seo]

2006/11/16, Christopher Baus <[EMAIL PROTECTED]>:
> Good question.  The seek must be in the binary write.  I'm not calling it
> directly.  Again, the error only occurs when the binary flag is set.  Any
> write on a socket file with the binary flag set causes a seek error.

Let's see what's going on here...

There is no socket.makefile in IronPython.

socket.makefile in FePy is implemented by creating NetworkStream from
.NET socket and "open" it using file() built-in. NetworkStream is not
seekable!

Internally, file() built-in is implemented by PythonFile class. It has
two important members, reader of type PythonStreamReader, and writer
of type PythonStreamWriter. If underlying system is not readable,
reader is null, and if it is not writable, writer is null. N.B. file
mode you pass to file() is not used.

As NetworkStream is readable and writable, reader and writer are
instantiated. Exactly which reader or writer is determined by file
mode. There are PythonBinaryReader, PythonText{CRLF,CR,LF}Reader, and
PythonUniversalReader, and they do what you can guess from the name.
There are also corresponding writers.

When you write to file,
1. writer is checked for null. If it is, stream is not writable. Raise
exception.
2. string is passed to the writer.
3. The writer does appropriate newline translation and write it.
4. The number of bytes written, after newline translation, is returned.
5. reader is checked for null. If it is, some steps are skipped.
6. reader's position is read.
7. The number of bytes written is added to the current position.
8. reader's position is set to the sum in 7 in order to syncrhonise.

6 will cause seek error if stream is not seekable. This doesn't
happen, because reader implementations maintain position by themselves
instead of reading underlying stream's position. It does read
underlying stream's position in the constructor, but only if it's
seekable. Bah, except PythonBinaryReader, that is.

So seek error is inevitable, whenever all of following conditions are met:
1. write() is called
2. underlying stream is writable
3. underlying stream is readable
4. binary reader is used
5. underlying stream is not seekable

Solution: Check if stream is seekable in PythonBinaryReader too. If
it's not seekable, it doesn't make much sense to set Position "to
synchronise" anyway.

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

Re: [IronPython] fepy socket seek

[Christopher Baus]

> where's the seek ?
>
> the second argument to makefile is the requested buffer size.
>

Good question.  The seek must be in the binary write.  I'm not calling it
directly.  Again, the error only occurs when the binary flag is set.  Any
write on a socket file with the binary flag set causes a seek error.


http://baus.net/

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

Re: [IronPython] Mono, ironPython and WinForms

[Giles Thomas]

Thanks, Seo - I'll give it another go and will report any results to the 
list.


Cheers,

Giles
>
> 2006/11/13, Giles Thomas <[EMAIL PROTECTED]>:
>>
>>  Seo,
>>
>> Does that extend to support for WinForms 2.0? Last time I tried 
>> running one
>> of my .NET apps under Mono, it could not find the System.Windows.Forms
>> 2.0.0.0 DLL. I may well have been missing something obvious, however.
>
> Mono includes System.Windows.Forms 2.0.0.0 DLL too. I am not sure why
> you had problems.
>

-- 
Giles Thomas
Resolver Systems
[EMAIL PROTECTED]

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

Re: [IronPython] Need authors for IronPython books

[Michael Foord]

Sanghyeon Seo wrote:
> 2006/11/15, Mahesh Prakriya <[EMAIL PROTECTED]>:
>   
>> Couples of publishers have ping'ed me about whether anyone is interested in
>> writing a book on IronPython and they're currently bottlenecked on finding
>> qualified authors.
>> 
>
> I know that Michael Foord is already writing a book on IronPython.
>
>   
I guess my cover is blown now... ;-)

Michael
http://www.voidspace.org.uk/index2.shtml


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

[IronPython] Python Cryptographic Toolkit for IronPython

[Sanghyeon Seo]

Python Cryptographic Toolkit is what you expect it to be.
http://www.amk.ca/python/code/crypto

One part of it is block encryption algorithms, like AES and DES. It
follows PEP 272, API for Block Encryption Algorithms.
http://www.python.org/dev/peps/pep-0272/

I wrote a simple wrapper transforming any .NET classes subclassing
SymmetricAlgorithm in System.Security.Cryptography to PEP
272-compliant block encryption module. Here it is:
https://svn.sourceforge.net/svnroot/fepy/trunk/cli/cipher.py

And here is a test script I used to test it:
https://svn.sourceforge.net/svnroot/fepy/trunk/example/cipher_test.py

To use it,

import cli
cli.install('cipher')

That's all! This performs some magic to insert modules created from
Rijndael, DES, TripleDES classes to Crypto.Cipher package namespace as
AES, DES, DES3, as you would expect from pycrypto. So you don't need
to modify your existing Python sources!

This will be included in the next IPCE release.

Thanks!

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

Re: [IronPython] Need authors for IronPython books

[Sanghyeon Seo]

2006/11/15, Mahesh Prakriya <[EMAIL PROTECTED]>:
> Couples of publishers have ping'ed me about whether anyone is interested in
> writing a book on IronPython and they're currently bottlenecked on finding
> qualified authors.

I know that Michael Foord is already writing a book on IronPython.

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

Re: [IronPython] Mono, ironPython and WinForms

[Sanghyeon Seo]

2006/11/13, Giles Thomas <[EMAIL PROTECTED]>:
>
>  Seo,
>
> Does that extend to support for WinForms 2.0? Last time I tried running one
> of my .NET apps under Mono, it could not find the System.Windows.Forms
> 2.0.0.0 DLL. I may well have been missing something obvious, however.

Mono includes System.Windows.Forms 2.0.0.0 DLL too. I am not sure why
you had problems.

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