Red Flag(?) change in "import"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Red Flag(?) change in "import"

Vernon D. Cole
I can't see an item like this on the bug list. Perhaps the sky is falling, perhaps, not. I am reporting the problem here in case it is. It seems like something the "big guns" should be made aware of right away.  The behavior seems to have changed since IPy 2.6, and if someone has indeed been working on "import" then we have a regression.

First.... here's CPython 2.7 -- I install the package and then import it from another directory...
<console dump>
C:\hg\adodbapi>py27 setup.py install

C:\hg\adodbapi>c:\python27\python.exe setup.py install
adodbapi version="2.4.0.2"
running install
running build
running build_py
copying adodbapi.py -> build\lib\adodbapi
copying ado_consts.py -> build\lib\adodbapi
copying __init__.py -> build\lib\adodbapi
running install_lib
copying build\lib\adodbapi\adodbapi.py -> c:\python27\Lib\site-packages\adodbapi

running install_egg_info
Writing c:\python27\Lib\site-packages\adodbapi-2.4.0.2-py2.7.egg-info

C:\hg\adodbapi>home

C:\hg\adodbapi>C:

C:\hg\adodbapi>cd \Users\vernon
C:\Users\vernon>py27

C:\Users\vernon>c:\python27\python.exe

Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
'adodbapi v2.4.0.2'
</console>
...................  The version attribute works

Now I try the same thing on an administrator console (I think that IronPython is correct in required the higher privilege here)
and a big THANK YOU for having a working distutils!     ........
<console AS ADMINISTRATOR dump>
C:\hg\adodbapi>ipy setup.py install

C:\hg\adodbapi>"c:\program files\IronPython 2.7\ipy.exe" setup.py install

adodbapi version="2.4.0.2"
running install
running build
running build_py
copying adodbapi.py -> build\lib\adodbapi
copying ado_consts.py -> build\lib\adodbapi
copying __init__.py -> build\lib\adodbapi
warning: build_py: byte-compiling is disabled, skipping.

running install_lib
warning: install_lib: byte-compiling is disabled, skipping.

running install_egg_info
Removing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.
7.egg-info
Writing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.7
.egg-info

C:\hg\adodbapi>home

C:\hg\adodbapi>C:

C:\hg\adodbapi>cd \Users\vernon
C:\Users\vernon>ipy

C:\Users\vernon>"c:\program files\IronPython 2.7\ipy.exe"
IronPython 2.7 Beta 2 (2.7.0.20) on .NET 4.0.30319.1
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'version'
</console>
................. Where did the attribute go??????????????

Now I hand copy the adodbapi folder from IronPython 2.7 site-packages into IronPython 2.6 site packages (because 2.6 distutils will not work) and continue with the same admin console...
<console dump continues>
>>> exit()

C:\Users\vernon>ipy26

C:\Users\vernon>"c:\program files\Ironpython 2.6\ipy.exe"
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.4206
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
'adodbapi v2.4.0.2'
</console>
........................ so it seems to me that "import" is badly broken.  I am unable to test adodbapi.

The code I am testing is at:
hg clone http://adodbapi.hg.sourceforge.net:8000/hgroot/adodbapi/adodbapi#main

Is there anything I should do?
--
Vernon


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Red Flag(?) change in "import"

Federico Vaggi
I ran into a relatively similar problem with importing networkx into IronPython, but was able to fix it by editing out a few of the lines.  It seems that the import behaviour in cpython and ironpython is slightly different sometime.

I can post a list of the steps that I took if it is helpful at all.

Federico
On 09/02/2011 23:45, Vernon Cole wrote:
I can't see an item like this on the bug list. Perhaps the sky is falling, perhaps, not. I am reporting the problem here in case it is. It seems like something the "big guns" should be made aware of right away.  The behavior seems to have changed since IPy 2.6, and if someone has indeed been working on "import" then we have a regression.

First.... here's CPython 2.7 -- I install the package and then import it from another directory...
<console dump>
C:\hg\adodbapi>py27 setup.py install

C:\hg\adodbapi>c:\python27\python.exe setup.py install
adodbapi version="2.4.0.2"
running install
running build
running build_py
copying adodbapi.py -> build\lib\adodbapi
copying ado_consts.py -> build\lib\adodbapi
copying __init__.py -> build\lib\adodbapi
running install_lib
copying build\lib\adodbapi\adodbapi.py -> c:\python27\Lib\site-packages\adodbapi

running install_egg_info
Writing c:\python27\Lib\site-packages\adodbapi-2.4.0.2-py2.7.egg-info

C:\hg\adodbapi>home

C:\hg\adodbapi>C:

C:\hg\adodbapi>cd \Users\vernon
C:\Users\vernon>py27

C:\Users\vernon>c:\python27\python.exe

Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
'adodbapi v2.4.0.2'
</console>
...................  The version attribute works

Now I try the same thing on an administrator console (I think that IronPython is correct in required the higher privilege here)
and a big THANK YOU for having a working distutils!     ........
<console AS ADMINISTRATOR dump>
C:\hg\adodbapi>ipy setup.py install

C:\hg\adodbapi>"c:\program files\IronPython 2.7\ipy.exe" setup.py install

adodbapi version="2.4.0.2"
running install
running build
running build_py
copying adodbapi.py -> build\lib\adodbapi
copying ado_consts.py -> build\lib\adodbapi
copying __init__.py -> build\lib\adodbapi
warning: build_py: byte-compiling is disabled, skipping.

running install_lib
warning: install_lib: byte-compiling is disabled, skipping.

running install_egg_info
Removing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.
7.egg-info
Writing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.7
.egg-info

C:\hg\adodbapi>home

C:\hg\adodbapi>C:

C:\hg\adodbapi>cd \Users\vernon
C:\Users\vernon>ipy

C:\Users\vernon>"c:\program files\IronPython 2.7\ipy.exe"
IronPython 2.7 Beta 2 (2.7.0.20) on .NET 4.0.30319.1
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'version'
</console>
................. Where did the attribute go??????????????

Now I hand copy the adodbapi folder from IronPython 2.7 site-packages into IronPython 2.6 site packages (because 2.6 distutils will not work) and continue with the same admin console...
<console dump continues>
>>> exit()

C:\Users\vernon>ipy26

C:\Users\vernon>"c:\program files\Ironpython 2.6\ipy.exe"
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.4206
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
'adodbapi v2.4.0.2'
</console>
........................ so it seems to me that "import" is badly broken.  I am unable to test adodbapi.

The code I am testing is at:
hg clone http://adodbapi.hg.sourceforge.net:8000/hgroot/adodbapi/adodbapi#main

Is there anything I should do?
--
Vernon

_______________________________________________ Users mailing list [hidden email] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Red Flag(?) change in "import"

Vernon D. Cole
Okay, I have filed codeplex issue 30143 for this, with a simple test module which demonstrates the problem.
This completely breaks adodbapi, and would probably kill many other imported modules. I think someone should go in an jack up the priority to high.
IMHO it is a release breaker.  Is not adodbapi still part of the test suite? The failure should have shown up there.
--
Vernon Cole

On Thu, Feb 10, 2011 at 3:42 AM, Federico Vaggi <[hidden email]> wrote:
I ran into a relatively similar problem with importing networkx into IronPython, but was able to fix it by editing out a few of the lines.  It seems that the import behaviour in cpython and ironpython is slightly different sometime.

I can post a list of the steps that I took if it is helpful at all.

Federico

On 09/02/2011 23:45, Vernon Cole wrote:
I can't see an item like this on the bug list. Perhaps the sky is falling, perhaps, not. I am reporting the problem here in case it is. It seems like something the "big guns" should be made aware of right away.  The behavior seems to have changed since IPy 2.6, and if someone has indeed been working on "import" then we have a regression.

First.... here's CPython 2.7 -- I install the package and then import it from another directory...
<console dump>
C:\hg\adodbapi>py27 setup.py install

C:\hg\adodbapi>c:\python27\python.exe setup.py install
adodbapi version="2.4.0.2"
running install
running build
running build_py
copying adodbapi.py -> build\lib\adodbapi
copying ado_consts.py -> build\lib\adodbapi
copying __init__.py -> build\lib\adodbapi
running install_lib
copying build\lib\adodbapi\adodbapi.py -> c:\python27\Lib\site-packages\adodbapi

running install_egg_info
Writing c:\python27\Lib\site-packages\adodbapi-2.4.0.2-py2.7.egg-info

C:\hg\adodbapi>home

C:\hg\adodbapi>C:

C:\hg\adodbapi>cd \Users\vernon
C:\Users\vernon>py27

C:\Users\vernon>c:\python27\python.exe

Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
'adodbapi v2.4.0.2'
</console>
...................  The version attribute works

Now I try the same thing on an administrator console (I think that IronPython is correct in required the higher privilege here)
and a big THANK YOU for having a working distutils!     ........
<console AS ADMINISTRATOR dump>
C:\hg\adodbapi>ipy setup.py install

C:\hg\adodbapi>"c:\program files\IronPython 2.7\ipy.exe" setup.py install

adodbapi version="2.4.0.2"
running install
running build
running build_py
copying adodbapi.py -> build\lib\adodbapi
copying ado_consts.py -> build\lib\adodbapi
copying __init__.py -> build\lib\adodbapi
warning: build_py: byte-compiling is disabled, skipping.

running install_lib
warning: install_lib: byte-compiling is disabled, skipping.

running install_egg_info
Removing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.
7.egg-info
Writing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.7
.egg-info

C:\hg\adodbapi>home

C:\hg\adodbapi>C:

C:\hg\adodbapi>cd \Users\vernon
C:\Users\vernon>ipy

C:\Users\vernon>"c:\program files\IronPython 2.7\ipy.exe"
IronPython 2.7 Beta 2 (2.7.0.20) on .NET 4.0.30319.1
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'version'
</console>
................. Where did the attribute go??????????????

Now I hand copy the adodbapi folder from IronPython 2.7 site-packages into IronPython 2.6 site packages (because 2.6 distutils will not work) and continue with the same admin console...
<console dump continues>
>>> exit()

C:\Users\vernon>ipy26

C:\Users\vernon>"c:\program files\Ironpython 2.6\ipy.exe"
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.4206
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
'adodbapi v2.4.0.2'
</console>
........................ so it seems to me that "import" is badly broken.  I am unable to test adodbapi.

The code I am testing is at:
hg clone http://adodbapi.hg.sourceforge.net:8000/hgroot/adodbapi/adodbapi#main

Is there anything I should do?
--
Vernon

_______________________________________________ Users mailing list [hidden email] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Red Flag(?) change in "import"

Dino Viehland

If no one else steps up to look at it I can take a look this weekend.  But let me tell everyone fixing import bugs is awesome fun!

 

I thought adodbapi was still part of the test suite but I don’t know how it transitioned when MS gave the project to the community.  It may have not been pushed out and may need to be re-added.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Vernon Cole
Sent: Thursday, February 10, 2011 3:50 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Red Flag(?) change in "import"

 

Okay, I have filed codeplex issue 30143 for this, with a simple test module which demonstrates the problem.
This completely breaks adodbapi, and would probably kill many other imported modules. I think someone should go in an jack up the priority to high.
IMHO it is a release breaker.  Is not adodbapi still part of the test suite? The failure should have shown up there.
--
Vernon Cole

On Thu, Feb 10, 2011 at 3:42 AM, Federico Vaggi <[hidden email]> wrote:

I ran into a relatively similar problem with importing networkx into IronPython, but was able to fix it by editing out a few of the lines.  It seems that the import behaviour in cpython and ironpython is slightly different sometime.

I can post a list of the steps that I took if it is helpful at all.

Federico


On 09/02/2011 23:45, Vernon Cole wrote:

I can't see an item like this on the bug list. Perhaps the sky is falling, perhaps, not. I am reporting the problem here in case it is. It seems like something the "big guns" should be made aware of right away.  The behavior seems to have changed since IPy 2.6, and if someone has indeed been working on "import" then we have a regression.

First.... here's CPython 2.7 -- I install the package and then import it from another directory...
<console dump>
C:\hg\adodbapi>py27 setup.py install

C:\hg\adodbapi>c:\python27\python.exe setup.py install
adodbapi version="2.4.0.2"
running install
running build
running build_py
copying adodbapi.py -> build\lib\adodbapi
copying ado_consts.py -> build\lib\adodbapi
copying __init__.py -> build\lib\adodbapi
running install_lib
copying build\lib\adodbapi\adodbapi.py -> c:\python27\Lib\site-packages\adodbapi

running install_egg_info
Writing c:\python27\Lib\site-packages\adodbapi-2.4.0.2-py2.7.egg-info

C:\hg\adodbapi>home

C:\hg\adodbapi>C:

C:\hg\adodbapi>cd \Users\vernon
C:\Users\vernon>py27

C:\Users\vernon>c:\python27\python.exe

Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
'adodbapi v2.4.0.2'
</console>

...................  The version attribute works

Now I try the same thing on an administrator console (I think that IronPython is correct in required the higher privilege here)
and a big THANK YOU for having a working distutils!     ........
<console AS ADMINISTRATOR dump>
C:\hg\adodbapi>ipy setup.py install

C:\hg\adodbapi>"c:\program files\IronPython 2.7\ipy.exe" setup.py install

adodbapi version="2.4.0.2"
running install
running build
running build_py
copying adodbapi.py -> build\lib\adodbapi
copying ado_consts.py -> build\lib\adodbapi
copying __init__.py -> build\lib\adodbapi
warning: build_py: byte-compiling is disabled, skipping.

running install_lib
warning: install_lib: byte-compiling is disabled, skipping.

running install_egg_info
Removing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.
7.egg-info
Writing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.7
.egg-info

C:\hg\adodbapi>home

C:\hg\adodbapi>C:

C:\hg\adodbapi>cd \Users\vernon
C:\Users\vernon>ipy

C:\Users\vernon>"c:\program files\IronPython 2.7\ipy.exe"
IronPython 2.7 Beta 2 (2.7.0.20) on .NET 4.0.30319.1
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'version'

</console>
................. Where did the attribute go??????????????

Now I hand copy the adodbapi folder from IronPython 2.7 site-packages into IronPython 2.6 site packages (because 2.6 distutils will not work) and continue with the same admin console...
<console dump continues>
>>> exit()

C:\Users\vernon>ipy26

C:\Users\vernon>"c:\program files\Ironpython 2.6\ipy.exe"
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.4206
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
'adodbapi v2.4.0.2'

</console>
........................ so it seems to me that "import" is badly broken.  I am unable to test adodbapi.

The code I am testing is at:
hg clone http://adodbapi.hg.sourceforge.net:8000/hgroot/adodbapi/adodbapi#main

Is there anything I should do?
--
Vernon

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Embedding IPython Shell into IronPython

Dave Wald
In reply to this post by Federico Vaggi

First off, Thanks to all the developers! 2.7b1 and b2 have been excellent so far, at least as far as my current needs go. The new subprocess module is great. Came just in time. Great work!

Federico,

Your post caught my eye, as I also like good embeddable console apps. Hadn't used IPython before so I downloaded it and played with it. Installed the PyReadline library as recommended to get all the command line goodies. Nice.

OK, so then, of course, I had to try it in IronPython, and immediately hit the same issues you did, with almost the exact same traceback info, etc.

So, I fired up the excellent Tools for Visual Studio 2010 and created a little project to embed the shell and call it from my running IPyScratchPad app (with a WinForms dll to house the form) and traced thru it in the Debugger.

Long story short, I found the major issue (and a couple of minor ones) and got it to run.

Now, I'm pretty sure Readline has not been ported to IronPython yet, and you know it requires pywin32. So that is not going to run under IronPython.

But the rest of it seems to be working ok. No tab completion or colorization but...

Here's what I did (ultimately) to get it to run:

First of all, copied the whole IPython folder structure over under "C:\Program Files (x86)\IronPython 2.7\Lib\site-packages".

I created a new Scripts folder under "C:\Program Files (x86)\IronPython 2.7", as IPython creates under Python 2.6.

Copied the following two files into it:

                "C:\Python26\Scripts\ipython.py"

                "C:\Python26\Scripts\ipython.bat"

Modified ipython.bat file to read:

                cd "C:\Program Files (x86)\IronPython 2.7"

                ipy.exe -X:Frames .\Scripts\ipython.py %*

 Double-clicking the bat file will now start up the IPython console running in IPy.exe.

 Notice the " -X:Frames " option specified. That is the major key to this.

Turns out, IronPython does not enable sys._getframe by default, which is required by IPython.

Note (from the Python doc):

sys._getframe([depth])

Return a frame object from the call stack. If optional integer depth is given, return the frame object that many calls below the top of the stack. If that is deeper than the call stack, ValueError is raised. The default for depth is zero, returning the frame at the top of the call stack.

CPython implementation detail: This function should be used for internal and specialized purposes only. It is not guaranteed to exist in all implementations of Python.

 
Found a post on StackOverflow, with a reply by Jeff Hardy about this, which is what tipped me off. Thanks Jeff!

http://stackoverflow.com/questions/3780379/how-can-i-enable-sys-getframe-in-ironpython-2-6-1

 OK, so far so good.

Now. Embedding...

 I used the simplest example in the IPython manual pdf, in section "3.2.4 Embedding IPython" on page 32-33.

I placed the following code into my app, in a button-click event handler.

     def testIPyShell(self, sender, event):

        from IPython.Shell import IPShellEmbed

        args = ['-colors','NoColor','-noreadline','-classic','-x','Verbose']

        ipshell = IPShellEmbed(args)

        ipshell()

In the Project Properties page, I set "Command Line Arguments" to   -X:Frames    and Interpreter Path to    C:\Program Files (x86)\IronPython 2.7\ipy.exe
(which is now 2.7b2) and check the "Debug Standard Library" box.

Hit F5, click the button and it works. The shell starts up. Main app blocks on it, tho. Hmmm. Well, may be a way around that too.

But it starts up and runs. Type "%magic" or "?" and it prints out all the doc, etc. Shell commands seem to work ok.

There is a minor issue in file iplib.py, line 646:

                self.usage_min =  """\

where it continues a multi-line string. The trailing back irritates the VS2010 Debugger to where it gets out of sync with the code.

I just took it out. If you're not running the debugger, you probably won't ever notice it.

If you ARE running the VS2010 debugger, you will get all kinds of stoppages, anywhere anything is raised. And it does that a lot.

Just ignore them. Hit the continue button.

 

And that's about it. Pretty cool little console.

All that having been said, of course, I think there may be an even better option. Possibly.

 

Check this out: http://lists.ironpython.com/pipermail/users-ironpython.com/2011-January/014218.html

Curt Hagenlocher posted this a couple of weeks ago. "Sho" is an IronPython shell from MS Research Labs. Played with it some. It's pretty cool. Very geared towards math/science/engineering apps.

The doc says it can be "embedded", but from what I have read (haven't tried it yet), it looks like you can call into it and use it's code and libraries of course, but I don't think the console will pop up. Don't know for sure. Need to play with it and see. That's next.

(Also, downloaded SilverShell http://code.google.com/p/silvershell/ (written in IronPython and WPF) coupla weeks ago and got it running under 2.7 - it's nice, but... seems to have some issues. I think I like Sho better for simplicity and raw power. You might give 'em a try and see which works better for you.)

 
That's all for now. Have fun with IPython. Holler if you have any questions.

 Dave

 

 

 

 

 

 

 

 

 

 

 

 

 

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Red Flag(?) change in "import"

Jeff Hardy-4
In reply to this post by Dino Viehland
On Thu, Feb 10, 2011 at 6:11 PM, Dino Viehland <[hidden email]> wrote:
> If no one else steps up to look at it I can take a look this weekend.  But
> let me tell everyone fixing import bugs is awesome fun!

That sounds like sarcasm to me...

> I thought adodbapi was still part of the test suite but I don’t know how it
> transitioned when MS gave the project to the community.  It may have not
> been pushed out and may need to be re-added.

I'm pretty sure it wasn't removed, so it might just have never been there.

- Jeff
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Embedding IPython Shell into IronPython

Federico Vaggi
In reply to this post by Federico Vaggi
Hey Dave,

thanks a lot for all the help.  Without the tab completion/colour it seems like this is a lot of work for a very plain shell, and Sho looks like a much better option - I played around with it a fair bit (it seems better than the plain IronPython console) but I haven't found much on how to embed it yet.  I'll head over to their forums and see if there is something I am missing.

Federico

On 11/02/2011 05:09, Dave Wald wrote:

First off, Thanks to all the developers! 2.7b1 and b2 have been excellent so far, at least as far as my current needs go. The new subprocess module is great. Came just in time. Great work!

Federico,

Your post caught my eye, as I also like good embeddable console apps. Hadn't used IPython before so I downloaded it and played with it. Installed the PyReadline library as recommended to get all the command line goodies. Nice.

OK, so then, of course, I had to try it in IronPython, and immediately hit the same issues you did, with almost the exact same traceback info, etc.

So, I fired up the excellent Tools for Visual Studio 2010 and created a little project to embed the shell and call it from my running IPyScratchPad app (with a WinForms dll to house the form) and traced thru it in the Debugger.

Long story short, I found the major issue (and a couple of minor ones) and got it to run.

Now, I'm pretty sure Readline has not been ported to IronPython yet, and you know it requires pywin32. So that is not going to run under IronPython.

But the rest of it seems to be working ok. No tab completion or colorization but...

Here's what I did (ultimately) to get it to run:

First of all, copied the whole IPython folder structure over under "C:\Program Files (x86)\IronPython 2.7\Lib\site-packages".

I created a new Scripts folder under "C:\Program Files (x86)\IronPython 2.7", as IPython creates under Python 2.6.

Copied the following two files into it:

                "C:\Python26\Scripts\ipython.py"

                "C:\Python26\Scripts\ipython.bat"

Modified ipython.bat file to read:

                cd "C:\Program Files (x86)\IronPython 2.7"

                ipy.exe -X:Frames .\Scripts\ipython.py %*

 Double-clicking the bat file will now start up the IPython console running in IPy.exe.

 Notice the " -X:Frames " option specified. That is the major key to this.

Turns out, IronPython does not enable sys._getframe by default, which is required by IPython.

Note (from the Python doc):

sys._getframe([depth])

Return a frame object from the call stack. If optional integer depth is given, return the frame object that many calls below the top of the stack. If that is deeper than the call stack, ValueError is raised. The default for depth is zero, returning the frame at the top of the call stack.

CPython implementation detail: This function should be used for internal and specialized purposes only. It is not guaranteed to exist in all implementations of Python.

 
Found a post on StackOverflow, with a reply by Jeff Hardy about this, which is what tipped me off. Thanks Jeff!

http://stackoverflow.com/questions/3780379/how-can-i-enable-sys-getframe-in-ironpython-2-6-1

 OK, so far so good.

Now. Embedding...

 I used the simplest example in the IPython manual pdf, in section "3.2.4 Embedding IPython" on page 32-33.

I placed the following code into my app, in a button-click event handler.

     def testIPyShell(self, sender, event):

        from IPython.Shell import IPShellEmbed

        args = ['-colors','NoColor','-noreadline','-classic','-x','Verbose']

        ipshell = IPShellEmbed(args)

        ipshell()

In the Project Properties page, I set "Command Line Arguments" to   -X:Frames    and Interpreter Path to    C:\Program Files (x86)\IronPython 2.7\ipy.exe
(which is now 2.7b2) and check the "Debug Standard Library" box.

Hit F5, click the button and it works. The shell starts up. Main app blocks on it, tho. Hmmm. Well, may be a way around that too.

But it starts up and runs. Type "%magic" or "?" and it prints out all the doc, etc. Shell commands seem to work ok.

There is a minor issue in file iplib.py, line 646:

                self.usage_min =  """\

where it continues a multi-line string. The trailing back irritates the VS2010 Debugger to where it gets out of sync with the code.

I just took it out. If you're not running the debugger, you probably won't ever notice it.

If you ARE running the VS2010 debugger, you will get all kinds of stoppages, anywhere anything is raised. And it does that a lot.

Just ignore them. Hit the continue button.

 

And that's about it. Pretty cool little console.

All that having been said, of course, I think there may be an even better option. Possibly.

 

Check this out: http://lists.ironpython.com/pipermail/users-ironpython.com/2011-January/014218.html

Curt Hagenlocher posted this a couple of weeks ago. "Sho" is an IronPython shell from MS Research Labs. Played with it some. It's pretty cool. Very geared towards math/science/engineering apps.

The doc says it can be "embedded", but from what I have read (haven't tried it yet), it looks like you can call into it and use it's code and libraries of course, but I don't think the console will pop up. Don't know for sure. Need to play with it and see. That's next.

(Also, downloaded SilverShell http://code.google.com/p/silvershell/ (written in IronPython and WPF) coupla weeks ago and got it running under 2.7 - it's nice, but... seems to have some issues. I think I like Sho better for simplicity and raw power. You might give 'em a try and see which works better for you.)

 
That's all for now. Have fun with IPython. Holler if you have any questions.

 Dave

 

 

 

 

 

 

 

 

 

 

 

 

 

 

_______________________________________________ Users mailing list [hidden email] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Embedding IPython Shell into IronPython

Dave Wald
Federico,
No problem. Enjoyed working on it. Now, the even better news.
PyReadline HAS BEEN ported to IronPython!  ;-)
http://ironpython-urls.blogspot.com/2006/11/pyreadline-for-ironpython.html
So IPython could very likely be made fully functional... with a bit of work.
From what I gather so far, you may still have to compile your own version of IronPython as per the discussion therein, but, I just need to get some more time to play with this.
I got side-tracked over the weekend um, 'reflecting' on what the internals of Sho might look like, if you could see them, if you get my drift... since the engine source code is not available... It seems the EmbeddedSho class always starts up a new PythoneEngine regardless, and they hardcode the references to version 2.6.2, I believe...
So, that'll take a bit of fiddling to embed it. Hope to get back on that this weekend.
Also, spent a lot of time re-learning Ruby and messing with Cucumber - need to try and get some kind of BDD acceptance-criteria testing automation thing going as simply as possible, but looks like Cucumber only works (best) with Rails. Again - so much to learn, so little time...
BTW, it looks to me like IronRuby has made GREAT strides in the last couple years. Excellent work guys!!! Thanks!
That's about it for now. I really do like IPython. I want to get that going, with the PyReadline support. Soon... very soon...  ;-)
Dave

On 2/15/2011 3:43 AM, Federico Vaggi wrote:
Hey Dave,

thanks a lot for all the help.  Without the tab completion/colour it seems like this is a lot of work for a very plain shell, and Sho looks like a much better option - I played around with it a fair bit (it seems better than the plain IronPython console) but I haven't found much on how to embed it yet.  I'll head over to their forums and see if there is something I am missing.

Federico

On 11/02/2011 05:09, Dave Wald wrote:

First off, Thanks to all the developers! 2.7b1 and b2 have been excellent so far, at least as far as my current needs go. The new subprocess module is great. Came just in time. Great work!

Federico,

Your post caught my eye, as I also like good embeddable console apps. Hadn't used IPython before so I downloaded it and played with it. Installed the PyReadline library as recommended to get all the command line goodies. Nice.

OK, so then, of course, I had to try it in IronPython, and immediately hit the same issues you did, with almost the exact same traceback info, etc.

So, I fired up the excellent Tools for Visual Studio 2010 and created a little project to embed the shell and call it from my running IPyScratchPad app (with a WinForms dll to house the form) and traced thru it in the Debugger.

Long story short, I found the major issue (and a couple of minor ones) and got it to run.

Now, I'm pretty sure Readline has not been ported to IronPython yet, and you know it requires pywin32. So that is not going to run under IronPython.

But the rest of it seems to be working ok. No tab completion or colorization but...

Here's what I did (ultimately) to get it to run:

First of all, copied the whole IPython folder structure over under "C:\Program Files (x86)\IronPython 2.7\Lib\site-packages".

I created a new Scripts folder under "C:\Program Files (x86)\IronPython 2.7", as IPython creates under Python 2.6.

Copied the following two files into it:

                "C:\Python26\Scripts\ipython.py"

                "C:\Python26\Scripts\ipython.bat"

Modified ipython.bat file to read:

                cd "C:\Program Files (x86)\IronPython 2.7"

                ipy.exe -X:Frames .\Scripts\ipython.py %*

 Double-clicking the bat file will now start up the IPython console running in IPy.exe.

 Notice the " -X:Frames " option specified. That is the major key to this.

Turns out, IronPython does not enable sys._getframe by default, which is required by IPython.

Note (from the Python doc):

sys._getframe([depth])

Return a frame object from the call stack. If optional integer depth is given, return the frame object that many calls below the top of the stack. If that is deeper than the call stack, ValueError is raised. The default for depth is zero, returning the frame at the top of the call stack.

CPython implementation detail: This function should be used for internal and specialized purposes only. It is not guaranteed to exist in all implementations of Python.

 
Found a post on StackOverflow, with a reply by Jeff Hardy about this, which is what tipped me off. Thanks Jeff!

http://stackoverflow.com/questions/3780379/how-can-i-enable-sys-getframe-in-ironpython-2-6-1

 OK, so far so good.

Now. Embedding...

 I used the simplest example in the IPython manual pdf, in section "3.2.4 Embedding IPython" on page 32-33.

I placed the following code into my app, in a button-click event handler.

     def testIPyShell(self, sender, event):

        from IPython.Shell import IPShellEmbed

        args = ['-colors','NoColor','-noreadline','-classic','-x','Verbose']

        ipshell = IPShellEmbed(args)

        ipshell()

In the Project Properties page, I set "Command Line Arguments" to   -X:Frames    and Interpreter Path to    C:\Program Files (x86)\IronPython 2.7\ipy.exe
(which is now 2.7b2) and check the "Debug Standard Library" box.

Hit F5, click the button and it works. The shell starts up. Main app blocks on it, tho. Hmmm. Well, may be a way around that too.

But it starts up and runs. Type "%magic" or "?" and it prints out all the doc, etc. Shell commands seem to work ok.

There is a minor issue in file iplib.py, line 646:

                self.usage_min =  """\

where it continues a multi-line string. The trailing back irritates the VS2010 Debugger to where it gets out of sync with the code.

I just took it out. If you're not running the debugger, you probably won't ever notice it.

If you ARE running the VS2010 debugger, you will get all kinds of stoppages, anywhere anything is raised. And it does that a lot.

Just ignore them. Hit the continue button.

 

And that's about it. Pretty cool little console.

All that having been said, of course, I think there may be an even better option. Possibly.

 

Check this out: http://lists.ironpython.com/pipermail/users-ironpython.com/2011-January/014218.html

Curt Hagenlocher posted this a couple of weeks ago. "Sho" is an IronPython shell from MS Research Labs. Played with it some. It's pretty cool. Very geared towards math/science/engineering apps.

The doc says it can be "embedded", but from what I have read (haven't tried it yet), it looks like you can call into it and use it's code and libraries of course, but I don't think the console will pop up. Don't know for sure. Need to play with it and see. That's next.

(Also, downloaded SilverShell http://code.google.com/p/silvershell/ (written in IronPython and WPF) coupla weeks ago and got it running under 2.7 - it's nice, but... seems to have some issues. I think I like Sho better for simplicity and raw power. You might give 'em a try and see which works better for you.)

 
That's all for now. Have fun with IPython. Holler if you have any questions.

 Dave

 

 

 

 

 

 

 

 

 

 

 

 

 

 

_______________________________________________ Users mailing list [hidden email] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________ Users mailing list [hidden email] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Embedding IPython Shell into IronPython

Jörgen Stenarson-2
Dave Wald skrev 2011-02-15 15:31:
> Federico,
> No problem. Enjoyed working on it. Now, the even better news.
> PyReadline HAS BEEN ported to IronPython! ;-)
> http://ironpython-urls.blogspot.com/2006/11/pyreadline-for-ironpython.html
> So IPython could very likely be made fully functional... with a bit of work.
>  From what I gather so far, you may still have to compile your own
> version of IronPython as per the discussion therein, but, I just need to
> get some more time to play with this.
hi,

unfortunately the pyreadline support for ironpython has not been tested
for quite a while so I do not know if it works as is or if some changes
are needed.

I have not seen any bugreports for what is there either but I guess that
may well just be because it is not used. If you find any problems please
report them on the launchpad tracker https://bugs.launchpad.net/pyreadline

/Jörgen
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Embedding IPython Shell into IronPython

Dave Wald
Jörgen,

Thanks for the heads up. I'll take a run at it and see what kind of
shape it's in.

Dave

On 2/15/2011 11:35 AM, Jörgen Stenarson wrote:

> Dave Wald skrev 2011-02-15 15:31:
>> Federico,
>> No problem. Enjoyed working on it. Now, the even better news.
>> PyReadline HAS BEEN ported to IronPython! ;-)
>> http://ironpython-urls.blogspot.com/2006/11/pyreadline-for-ironpython.html 
>>
>> So IPython could very likely be made fully functional... with a bit
>> of work.
>>  From what I gather so far, you may still have to compile your own
>> version of IronPython as per the discussion therein, but, I just need to
>> get some more time to play with this.
> hi,
>
> unfortunately the pyreadline support for ironpython has not been
> tested for quite a while so I do not know if it works as is or if some
> changes are needed.
>
> I have not seen any bugreports for what is there either but I guess
> that may well just be because it is not used. If you find any problems
> please report them on the launchpad tracker
> https://bugs.launchpad.net/pyreadline
>
> /Jörgen
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Red Flag(?) change in "import"

Dino Viehland
In reply to this post by Vernon D. Cole

This is fixed now.  Apparently there was an invalid optimization that I added – so I removed it. 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Vernon Cole
Sent: Thursday, February 10, 2011 3:50 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Red Flag(?) change in "import"

 

Okay, I have filed codeplex issue 30143 for this, with a simple test module which demonstrates the problem.
This completely breaks adodbapi, and would probably kill many other imported modules. I think someone should go in an jack up the priority to high.
IMHO it is a release breaker.  Is not adodbapi still part of the test suite? The failure should have shown up there.
--
Vernon Cole

On Thu, Feb 10, 2011 at 3:42 AM, Federico Vaggi <[hidden email]> wrote:

I ran into a relatively similar problem with importing networkx into IronPython, but was able to fix it by editing out a few of the lines.  It seems that the import behaviour in cpython and ironpython is slightly different sometime.

I can post a list of the steps that I took if it is helpful at all.

Federico


On 09/02/2011 23:45, Vernon Cole wrote:

I can't see an item like this on the bug list. Perhaps the sky is falling, perhaps, not. I am reporting the problem here in case it is. It seems like something the "big guns" should be made aware of right away.  The behavior seems to have changed since IPy 2.6, and if someone has indeed been working on "import" then we have a regression.

First.... here's CPython 2.7 -- I install the package and then import it from another directory...
<console dump>
C:\hg\adodbapi>py27 setup.py install

C:\hg\adodbapi>c:\python27\python.exe setup.py install
adodbapi version="2.4.0.2"
running install
running build
running build_py
copying adodbapi.py -> build\lib\adodbapi
copying ado_consts.py -> build\lib\adodbapi
copying __init__.py -> build\lib\adodbapi
running install_lib
copying build\lib\adodbapi\adodbapi.py -> c:\python27\Lib\site-packages\adodbapi

running install_egg_info
Writing c:\python27\Lib\site-packages\adodbapi-2.4.0.2-py2.7.egg-info

C:\hg\adodbapi>home

C:\hg\adodbapi>C:

C:\hg\adodbapi>cd \Users\vernon
C:\Users\vernon>py27

C:\Users\vernon>c:\python27\python.exe

Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
'adodbapi v2.4.0.2'
</console>

...................  The version attribute works

Now I try the same thing on an administrator console (I think that IronPython is correct in required the higher privilege here)
and a big THANK YOU for having a working distutils!     ........
<console AS ADMINISTRATOR dump>
C:\hg\adodbapi>ipy setup.py install

C:\hg\adodbapi>"c:\program files\IronPython 2.7\ipy.exe" setup.py install

adodbapi version="2.4.0.2"
running install
running build
running build_py
copying adodbapi.py -> build\lib\adodbapi
copying ado_consts.py -> build\lib\adodbapi
copying __init__.py -> build\lib\adodbapi
warning: build_py: byte-compiling is disabled, skipping.

running install_lib
warning: install_lib: byte-compiling is disabled, skipping.

running install_egg_info
Removing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.
7.egg-info
Writing c:\program files\IronPython 2.7\Lib\site-packages\adodbapi-2.4.0.2-py2.7
.egg-info

C:\hg\adodbapi>home

C:\hg\adodbapi>C:

C:\hg\adodbapi>cd \Users\vernon
C:\Users\vernon>ipy

C:\Users\vernon>"c:\program files\IronPython 2.7\ipy.exe"
IronPython 2.7 Beta 2 (2.7.0.20) on .NET 4.0.30319.1
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'version'

</console>
................. Where did the attribute go??????????????

Now I hand copy the adodbapi folder from IronPython 2.7 site-packages into IronPython 2.6 site packages (because 2.6 distutils will not work) and continue with the same admin console...
<console dump continues>
>>> exit()

C:\Users\vernon>ipy26

C:\Users\vernon>"c:\program files\Ironpython 2.6\ipy.exe"
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.4206
Type "help", "copyright", "credits" or "license" for more information.
>>> import adodbapi
>>> adodbapi.version
'adodbapi v2.4.0.2'

</console>
........................ so it seems to me that "import" is badly broken.  I am unable to test adodbapi.

The code I am testing is at:
hg clone http://adodbapi.hg.sourceforge.net:8000/hgroot/adodbapi/adodbapi#main

Is there anything I should do?
--
Vernon

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Embedding IPython Shell into IronPython

Dave Wald
In reply to this post by Jörgen Stenarson-2
Jörgen,
I spent a good bit of time with pyreadline over the weekend but was not
able to get it to work.
It appears that the IronPython-related code is not DLR-aware.
I went ahead and entered a bug report with my findings:
https://bugs.launchpad.net/pyreadline/+bug/722440

Best regards,
Dave

On 2/15/2011 11:35 AM, Jörgen Stenarson wrote:Dave Wald skrev 2011-02-15
15:31:

>> Federico,
>> No problem. Enjoyed working on it. Now, the even better news.
>> PyReadline HAS BEEN ported to IronPython! ;-)
>> http://ironpython-urls.blogspot.com/2006/11/pyreadline-for-ironpython.html 
>>
>> So IPython could very likely be made fully functional... with a bit
>> of work.
>>  From what I gather so far, you may still have to compile your own
>> version of IronPython as per the discussion therein, but, I just need to
>> get some more time to play with this.
> hi,
>
> unfortunately the pyreadline support for ironpython has not been
> tested for quite a while so I do not know if it works as is or if some
> changes are needed.
>
> I have not seen any bugreports for what is there either but I guess
> that may well just be because it is not used. If you find any problems
> please report them on the launchpad tracker
> https://bugs.launchpad.net/pyreadline
>
> /Jörgen
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com