[IronPython] Compiling IP2 on mono
Hi folks, I've tried following Seo's steps [1] for compiling IP2 on the current mono trunk but it keeps failing with the next error: sylv...@localhost:~/download/IronPython-2.0/Src$ nant NAnt 0.86 (Build 0.86.2898.0; beta1; 08/12/2007) Copyright (C) 2001-2007 Gerry Shaw http://nant.sourceforge.net Buildfile: file:///home/sylvain/download/IronPython-2.0/Src/IronPython.build Target framework: Mono 2.0 Profile [csc] Compiling 200 files to '/home/sylvain/download/IronPython-2.0/Src/Microsoft.Scripting.Core.dll'. [csc] /home/sylvain/download/IronPython-2.0/Src/Microsoft.Scripting.Core/Actions/MetaObjectExtensions.cs(20,27): error CS0234: The type or namespace name `Generation' does not exist in the namespace `Microsoft.Scripting'. Are you missing an assembly reference? [csc] /home/sylvain/download/IronPython-2.0/Src/Microsoft.Scripting.Core/Actions/MetaObjectExtensions.cs(20,27): error CS0234: The type or namespace name `Generation' does not exist in the namespace `Microsoft.Scripting'. Are you missing an assembly reference? [csc] Compilation failed: 2 error(s), 0 warnings BUILD FAILED - 0 non-fatal error(s), 2 warning(s) /home/sylvain/download/IronPython-2.0/Src/IronPython.build(3,6): External Program Failed: /usr/local/lib/mono/2.0/gmcs.exe (return code was 1) Total time: 1.2 seconds Has anyone got an idea? Cheers, - Sylvain [1] http://www.nabble.com/IronPython-2.0-RC-2-on-Mono-td20889619.html ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.0 Beta 4 MSI setup error.
I'm hijacking this thread as I also have errors with this release. The installation went fine but I get an unhandled exception when starting ipy.exe which terminates the process immediately. Hey for once I've sent a report to Microsoft about it though ;) Does this release require a specific version of .NET BTW? i'll try the zip package just in case. - Sylvain The MSI refuses to install with message: requires .NET framework 2.0 SP1. I am pretty sure that there are SP1 on the two machines I tried. They both have XP SP3. They all have the following .NET framework versions: 1.1 2.0 SP1 3.0 SP1 3.5 Thanks! -J.___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Sylvain Hellegouarch http://www.defuze.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.0 Beta 4 MSI setup error.
I'm hijacking this thread as I also have errors with this release. The installation went fine but I get an unhandled exception when starting ipy.exe which terminates the process immediately. Hey for once I've sent a report to Microsoft about it though ;) Does this release require a specific version of .NET BTW? i'll try the zip package just in case. FYI, the zip package has the same behavior. - Sylvain -- Sylvain Hellegouarch http://www.defuze.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.0 Beta 4 MSI setup error.
I'm hijacking this thread as I also have errors with this release. The installation went fine but I get an unhandled exception when starting ipy.exe which terminates the process immediately. Hey for once I've sent a report to Microsoft about it though ;) Does this release require a specific version of .NET BTW? i'll try the zip package just in case. FYI, the zip package has the same behavior. After upgrading to .NET 3.5, the zip package decided to work fine without crashing. However I can't install the MSI any longer due to the same SP1 requirement others have had which prevents the installation from even starting. - Sylvain -- Sylvain Hellegouarch http://www.defuze.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Roadmap and updates
Hi, Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the community is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. I will not comment on the state of Silverlight or XAML as I don't use them but I've been using the PyQt4+Python2.5 combination for some time and it's been working great. My main concern with IronPython at this stage is its inability to offer a clear view of its capacity to support pure Python libraries. I keep running in shortcomings or bugs [1] that make me nervous about investing time in IP when using existing pure Python libraries. I do understand IP is still in beta and bugs are expected at this stage but not having an up-to-date grid of what is officially implemented, supported, worked on is rather frustrating. In other words, if you start from scratch then IP+.NET is a solid choice but if you already have a large bunch of Python code I would personally be very careful as you might end up having to spend quite a lot of time in debugging the reason why your code isn't working as expected, opening tickets on CodePlex and never hearing about their progress again until they are potentially fixed. I do not want to sound like I downplay the IP team work, not at all, but the lack of visibility is not playing in their favor in my opinion. Writing code is one thing, giving recurrent feedback is sometimes worth more ;) I believe IP is worth the interest but keep in mind the product is still rather a long way. - Sylvain [1] http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17561 It might not sound like it but that bug was quite hard to track down because of the rather poor traceback information provided by IP as well as the fact that the IndexError, though a consequence of the bug, wasn't immediate to correlate back to the bug itself. -- Sylvain Hellegouarch http://www.defuze.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Roadmap and updates
I do not want to sound like I downplay the IP team work, not at all, but the lack of visibility is not playing in their favor in my opinion. Writing code is one thing, giving recurrent feedback is sometimes worth more ;) I wanted to reiterate that I don't downplay the IP team's work. They've been very responsive and friendly to the community. However, visibility is sometimes lacking (mind you like many other large OSS projects ;)). I do realize as well that if I don't ask questions, I won't have answers... - Sylvain -- Sylvain Hellegouarch http://www.defuze.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Python Pages -- web application stack (like django, rails, ...)
Tim Roberts a écrit : On Thu, 12 Jun 2008 02:18:58 +0200, Jonathan Slenders [EMAIL PROTECTED] wrote: 2008/6/12 Tim Roberts [EMAIL PROTECTED]: May I ask what motivated you to create this from scratch? There are a number of excellent Python web application frameworks available today, several of which have syntax and functionality almost exactly like yours If you know that many Python web frameworks, I'd really like to hear about it. (I've seen several, yes, but some were very outdated and and not maintained anymore) Because I don't know much of them it's hard to say what I missed. Several is a very dramatic understatement. * Django * Pylons * TurboGears * Zope * Karrigell * SkunkWeb * Webware * CherryPy * web2py * Albatross * Aquarium * Python Servlet Engine * Quixote * Snakelets * WebStack And that's still not the complete list. That's why I asked the question. I almost didn't ask, because I didn't want to sound like I was suppressing innovation, but I have to believe it would be better for the community as a whole to embrace and enhance one of the existing packages, rather than start over from scratch. I find better for a community to have a few large projects acting like locomotives for the rest. That's exactly what happens with Python and the web. Among the products you've mentioned, today's main actors are probably Django and Zope. They have demonstrated, and still do, that Python is a good environment for long term, powerful and dynamic projects. A platform a company can rely on. The others demonstrate that the community still strives for innovation and can challenge the estblishment. I find that attitude quite sane. Having the whole community focused on one single project doesn't make it better. I wouldn't say Ruby on Rails is that better because there is hardly any competition in the Ruby world for it. - Sylvain ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] NWSGI 0.1 released!
That's great news. Congratulations :) - Sylvain Jeff Hardy a écrit : Hi all, I've finally built a binary version of NWSGI, which is much easier to use than building it from source. It also includes a very simple Hello, World! app to get started. I've tested with some simple Paste applications, and CherryPy *almost* works; if you hack around the bugs that it exposes, you'll get a nice 503 error page. With news that Django works, I'll give that a spin when all of the bits are available. Right now, it works best with IIS7 - deployment is dead simple. Stories about IIS6 would be appreciated, as I don't have access to it. Any and all comments are very much appreciated. - Jeff Hardy ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] How to use Tao.Glfw or Tao.OpenGL Zooming windows
Hi Jane, I'd say that you'll have to go through the Tao documentation [1] and get a good OpenGL tutorial [2]. Note that the Tao distribution contains the NeHe tutorial ported to C#. I don't remember much of my OpenGL years but I think zoom doesn't exist per se, instead you change the view matrix. Have a look at [3]. - Sylvain [1] http://taoframework.com/project [2] http://nehe.gamedev.net/ [3] http://www.opengl.org/resources/faq/technical/viewing.htm jane janet a écrit : Hi all, Me again. I wanna know how to zoom my application windows using Tao framework. I have no experience in this stuff. Please tell me clearly. All the best, Jane *Jane* Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] How to use Tao.Glfw or Tao.OpenGL Zooming windows
Jane, If you're only interested in 2D, you might want to use TaoSDL rather than TaoOpenGL+TaoGLFW. SDL is a pretty cool graphics library that runs on practically anything that exists. It might be easier than OpenGL but will only make sense in 2D context. For instance look at SdlGfx.zoomSurface from [1]. - Sylvain [1] http://docs.taoframework.com/Tao.Sdl/ jane janet a écrit : I forgot to tell you something. My application window is 2 dimension. I wanna zoom 2D windows. Best regards, Jane *Jane* Shed those extra pounds with MSN and The Biggest Loser! Learn more. http://biggestloser.msn.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] How to use Tao.Glfw or Tao.OpenGL Zooming windows
FYI, I took a couple of hours to write an example using TaoSDL on the IronPython cookbook [1]. I wanted to notice that accessing attributes is not very smooth and I assume it's due to the fac that TaoSDL structures are all unmanaged. Not very foxy :) - Sylvain [1] http://www.ironpython.info/index.php/SDL_Zoom Sylvain Hellegouarch a écrit : Jane, If you're only interested in 2D, you might want to use TaoSDL rather than TaoOpenGL+TaoGLFW. SDL is a pretty cool graphics library that runs on practically anything that exists. It might be easier than OpenGL but will only make sense in 2D context. For instance look at SdlGfx.zoomSurface from [1]. - Sylvain [1] http://docs.taoframework.com/Tao.Sdl/ jane janet a écrit : I forgot to tell you something. My application window is 2 dimension. I wanna zoom 2D windows. Best regards, Jane *Jane* Shed those extra pounds with MSN and The Biggest Loser! Learn more. http://biggestloser.msn.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] OpenGL with IronPython
Hi there,
You might want to use Tao [1].
The example below works fine with the latest stable release of Tao
(2.0.0) and Mono 1.2.6
Note that I'm using Glfw [2] here but you could use FreeGlut instead of
course.
That example simply renders a spinning triangle onto a window.
- Sylvain
[1] http://taoframework.com/
[2] http://glfw.sourceforge.net/
import clr
clr.AddReference('Tao.Glfw')
clr.AddReference('Tao.OpenGl')
from Tao.Glfw import Glfw
from Tao.OpenGl import Gl, Glu
def run():
Glfw.glfwInit()
if not Glfw.glfwOpenWindow(640, 480, 0, 0, 0, 0, 0, 0,
Glfw.GLFW_WINDOW):
Glfw.glfwTerminate()
return 2
Glfw.glfwEnable(Glfw.GLFW_STICKY_KEYS)
Glfw.glfwSwapInterval(0)
running = True
frame_count = 0
start_time = Glfw.glfwGetTime()
while running:
current_time = Glfw.glfwGetTime()
coordinates = Glfw.glfwGetMousePos()
#Calculate and display FPS (frames per second)
if (current_time - start_time) 1 or frame_count == 0:
frame_rate = frame_count / (current_time - start_time);
Glfw.glfwSetWindowTitle(Spinning Triangle (%d FPS) %
frame_rate)
start_time = current_time
frame_count = 0
frame_count = frame_count + 1
window_dim = Glfw.glfwGetWindowSize()
if window_dim[1] 0:
height = window_dim[1]
else:
height = 1
# Set viewport
Gl.glViewport(0, 0, window_dim[0], height)
# Clear color buffer
Gl.glClearColor(0, 0, 0, 0)
Gl.glClear(Gl.GL_COLOR_BUFFER_BIT)
# Select and setup the projection matrix
Gl.glMatrixMode(Gl.GL_PROJECTION)
Gl.glLoadIdentity()
Glu.gluPerspective(65, window_dim[0]/height, 1, 100)
# Select and setup the modelview matrix
Gl.glMatrixMode(Gl.GL_MODELVIEW)
Gl.glLoadIdentity()
Glu.gluLookAt(0, 1, 0, 0, 20, 0, 0, 0, 1)
# Draw a rotating colorful triangle
Gl.glTranslatef(0, 14, 0)
Gl.glRotatef(1/3 * float(coordinates[0]) + float(current_time) *
100,
0, 0, 1)
Gl.glBegin(Gl.GL_TRIANGLES)
Gl.glColor3f(1, 0, 0)
Gl.glVertex3f(-5, 0, -4)
Gl.glColor3f(0, 1, 0)
Gl.glVertex3f(5, 0, -4)
Gl.glColor3f(0, 0, 1)
Gl.glVertex3f(0, 0, 6)
Gl.glEnd();
Glfw.glfwSwapBuffers()
running = ((Glfw.glfwGetKey(Glfw.GLFW_KEY_ESC) ==
Glfw.GLFW_RELEASE) and
Glfw.glfwGetWindowParam(Glfw.GLFW_OPENED) == Gl.GL_TRUE)
Glfw.glfwTerminate()
if __name__ == '__main__':
run()
jane janet a écrit :
Hi all,
I need help again.
I don't know how to use OpenGL in IronPython.
I want to draw the line in IronPython application.
Please teach me clearly.
All the best,
Jane
*Jane*
Connect and share in new ways with Windows Live. Get it now!
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
___
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] Mailing list vs. Web discussions on CodePlex
Personally I don't think the IP-list has enough volume to justify a split and that would be detrimental. If people don't want to subscribe to a list for fear of spam it's fair enough but the list has been working just fine until now and I personally would not pay attention to a forum per se myself. Anyway, just my 2 cents. - Sylvain Dino Viehland wrote: Just thought I'd collect some opinions here. Internally we discussed this sometime ago but never made any decisions and haven't done much to push this forward... On CodePlex we have the ability to enable a discussion forum (which would look like http://www.codeplex.com/CodePlex/Thread/List.aspx) where people could post questions, discuss issues, etc... CodePlex is heavily RSS-enabled so you could also get RSS feeds to track the discussions in RSS form. There've been some requests on the main page (http://www.codeplex.com/IronPython) and at least one person who didn't like the mailing list. But obviously we don't want to get rid of the mailing list format - personally it's the format I prefer (and find the least overhead for replying). But I've started to use RSS a lot recently so I can certainly see the appeal there, and maybe others here do as well... Overall my own personal worry is that we'll be fragmenting the two discussions and actually hinder some discussion. So, thoughts? Should we: Very easy: just open the flood gates on the discussions and everyone can go where they want - let the search engines sort it out! vs Requires some work: open up the RSS feed but setup some thread-propagation-bot? open up the RSS feed but send out regular digests? vs the unknown: something completely different? ___ 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] FePy patches
Thanks a lot Seo. I can confirm I managed to compile IP2.0a4 after applying Seo's patchs using the release of mono 1.2.5.1. It even launched and hasn't crashed yet :) Again, thank you Seo. You rock! - Sylvain Sanghyeon Seo wrote: I overhauled FePy patches list. http://fepy.sourceforge.net/patches.html There are now separate pages for IronPython 1.x branch and 2.x branch. I cleaned up all patches I wrote for 2.x branch, added some more, and documented them. The simple result is that Mono 1.2.5 should compile and run all 2.x Alpha releases with these patches. Many of them are workarounds for Mono bugs, which aren't very interesting. I hope equivalent of patch-flags-argcount to be applied in 2.0 Alpha 5 to fix #6805, which is already fixed in 1.1. Is there any chance you can take patch-nant-build, that is, include IronPython.build under Src directory? Since that is in patch form, the copy I am using is here: http://sparcs.kaist.ac.kr/~tinuviel/download/IronPython/IronPython.build ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Any news about the next release?
Hi all, I was wondering if there was any news about the next available release? Will it be a beta or still an alpha? When may we expect it? Just to feed my curiosity :) Thanks, - Sylvain ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Any news about the next release?
Oh sweet news. However, what is the big showstopper to become a beta? A fifth alpha means there must be something quite blocking down the line. /me hopes he'll manage to get it compiled with mono this time. - Sylvain Dave Fugate wrote: Hi, IronPython 2.0 Alpha 5 will be released after we wrap up work on a number of high priority bug fixes. This is scheduled to be completed at the end of this week which means it's likely 2.0A5 will become available sometime next week. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch Sent: Tuesday, October 02, 2007 3:19 PM To: users@lists.ironpython.com Subject: [IronPython] Any news about the next release? Hi all, I was wondering if there was any news about the next available release? Will it be a beta or still an alpha? When may we expect it? Just to feed my curiosity :) Thanks, - Sylvain ___ 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] Any news about the next release?
Thanks Dave for the much appreciate feedback. - Sylvain Dave Fugate wrote: The reason we've been releasing 2.0 as monthly alphas is that the Dynamic Language Runtime is still solidifying with improvements being made for IronRuby among other things. While we could release a single alpha (or two) a month prior to 2.0 beta 1, we like to integrate feedback from the community into IronPython frequently. Also, our team tries to follow the agile software development process (i.e., short release cycles). Last but definitely not least, we're aiming to be Python 2.5 compatible with IronPython 2.0 and we're not quite there yet. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch Sent: Tuesday, October 02, 2007 3:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Any news about the next release? Oh sweet news. However, what is the big showstopper to become a beta? A fifth alpha means there must be something quite blocking down the line. /me hopes he'll manage to get it compiled with mono this time. - Sylvain Dave Fugate wrote: Hi, IronPython 2.0 Alpha 5 will be released after we wrap up work on a number of high priority bug fixes. This is scheduled to be completed at the end of this week which means it's likely 2.0A5 will become available sometime next week. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch Sent: Tuesday, October 02, 2007 3:19 PM To: users@lists.ironpython.com Subject: [IronPython] Any news about the next release? Hi all, I was wondering if there was any news about the next available release? Will it be a beta or still an alpha? When may we expect it? Just to feed my curiosity :) Thanks, - Sylvain ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Please remove me from the mailing list - thanks
Paul Sherr a écrit : ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com Read the instructions: http://lists.ironpython.com/listinfo.cgi/users-ironpython.com - Sylvain ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [Kamaelia-list] Kamaelia and IronPython (was: Hosting IronPython 2.X in .NET app)
M. David Peterson a écrit : On 7/20/07, *Michael Sparks* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, In the interests of you having a quiet life (who wants to be dealing with lawyers when writing code? :-)... Who wants to deal with lawyers *EVER*! ;-) I must admit though, after so many years in OSS, this is the first time I hear this sentence. Mind you this is not as if Microsoft was the only one doing so, I bet all the big companies do so. They have to. From a developer point of view though, it's a big WTF? :D Thanks Dino for the honesty nonetheless. - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] PythonEngine no constructors defined
If you are using IP2 you should go with:
PythonEngine _engine = PythonEngine.CurrentEngine;
- Sylvain
googen a écrit :
Hello, I am trying to run a python script via a VC# project, purely to create
an exe for my application. But I am having a problem
building every example I have found. It does not help that I have no idea
about C#. Any help would be greatly appreciated, as I would love to
have an exe to pass to my friends with my application, and a google on this
shows nothing. The code I tryed last is
using System;
using System.Collections;
using System.Collections.Generic;
using System.IO;
using IronPython.Hosting;
using IronPython.Runtime;
namespace Payper
{
class Class1
{
static IronPython.Hosting.PythonEngine Py;
[STAThread]
static void Main(String[] rawArgs)
{
Py = new PythonEngine();
Py.AddToPath(Environment.CurrentDirectory);
Py.ExecuteFile(Payper.py);
}
}
}
When I try to build this, or any other example I have followed I get the
following error...
The type 'IronPython.Hosting.PythonEngine' has no constructors defined
So what am i missing?, or does anybody know another way of creating an exe
from ironpython?
Thanks in advance
googen.
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [Kamaelia-list] Kamaelia and IronPython (was: Hosting IronPython 2.Xin .NET app)
Now we just need to to encourage the [EMAIL PROTECTED] to build integrated (P)LINQ support into IronPython ;-) :D That would certainly be a greater incentive to attract a bigger community around IP. - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Hosting IronPython 2.X in .NET app
Ken Manheimer a écrit : On 7/10/07, *M. David Peterson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 7/10/07, *Sylvain Hellegouarch* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Not to worry :) However the question stands, will Python support closures (or does it already via lambda expressions?) Depends on your interpretation of what a closure is. One interpretation is that w ith closures you can, for example, have a series of lambda expressions, evaluate up to a certain point, add a marker, store it, and then continue where you left off at a later date. just to clarify, it sounds like you may be mistaking terminology here. the elementary structures by which computations can be stored for later continuation are called just that - continuations. closures, on the other hand, are an organization of program state that can be associated with an object - typically to implement static scoping, as was done for python functions and methods around, someone said, python 2.1. i seem to recall that ruby manifests blocks as first class objects, and associates closures with them, as well. (continuations are interesting, but mostly in the abstract - they're not generally of interest for direct use by programmers. they're the mother of all control flow structures - all the others can be expressed and built using them, but they're very low-level - you would hardly ever want to program with them directly. stackless python uses (used?) them as a key means of building the other flow control structures without using the machine (c, in that case) stack, and they enable economies for massive parallelism that most of us don't need (and couldn't handle without major attention). generators provide the means to express much of what programmers practically want in this vein, and the recent refinements to enable use of generators as coroutines (pep 342 http://www.python.org/dev/peps/pep-0342/) covers most of the rest. how these structures map to parallelism are up to the language implementation. guido has been actively disinterested in incorporating continuations to the python definition, for various reasons, and i don't expect that to change.) i couldn't resist this clarification, and hope i haven't mistaken what you were saying (or, what i'm saying:-). -- Thanks Ken as well for this explanation. This is one of those confusing subject for me and you helped a lot here :) Side note, talking about stackless, Arnar Birgisson just released yesterday a stackless version of the CherryPy HTTP server: http://code.google.com/p/stacklessexamples/wiki/StacklessWSGI Interesting days that is :) - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Hosting IronPython 2.X in .NET app
Curt Hagenlocher a écrit : On 7/10/07, *Curt Hagenlocher* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 7/10/07, *Dino Viehland* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Major things we know we still have to do include yield expressions (sorry, there's probably a technical term for them) Closures :P. Doh! I'm so retarded that I misspelled generators :(. Apparently I've been reading too much about Ruby lately... Not to worry :) However the question stands, will Python support closures (or does it already via lambda expressions?) (/me is lame at language theory) - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Hosting IronPython 2.X in .NET app
Jacob Lee a écrit : -Original Message- From: [EMAIL PROTECTED] [mailto:users- [EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch Sent: Tuesday, July 10, 2007 12:54 PM To: Discussion of IronPython Subject: Re: [IronPython] Hosting IronPython 2.X in .NET app Curt Hagenlocher a écrit : On 7/10/07, *Curt Hagenlocher* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 7/10/07, *Dino Viehland* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Major things we know we still have to do include yield expressions (sorry, there's probably a technical term for them) Closures :P. Doh! I'm so retarded that I misspelled generators :(. Apparently I've been reading too much about Ruby lately... Not to worry :) However the question stands, will Python support closures (or does it already via lambda expressions?) (/me is lame at language theory) - Sylvain Closures have existed in Python since version 2.1 or so: def f(): x = 5 return lambda: x closure = f() print closure() # prints 5 Here, the anonymous inner function returned by f is able to refer to variables defined in outer scopes. As for the Python 3000 question -- The one current limitation is that you cannot rebind names defined in outer scopes. That is, the following code does not work as expected: def f(): x = 5 def g(): x = 7 # x is local to g here You could use the global statement to indicate that x is a global despite it being assigned to inside the function, but there was no equivalent way to indicate that x refers to a variable in an outer, but non-global, scope. Python 3000 will introduce the nonlocal statement that works like the global statement to fill this gap. As usual, the best source is the relevant PEP: http://www.python.org/dev/peps/pep-3104/ Hope this helps. Many thanks Jacob. I will admit that I don't often use lambdas in my own code and therefore when asked a straight question aboud them I dodged :) saving face attempt That's what I thought of course /saving face attempt Thanks again. - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Hosting IronPython 2.X in .NET app
Dino Viehland a écrit : Does Kamaelia use the new syntax as supported via PEP-342 (http://www.python.org/dev/peps/pep-0342/). That’s the particular piece that we don’t support and is new to 2.5 – we do support generators when you use yield as a statement instead of as an expression (in other words, we don’t support the send method on the generator – only next). It’s hard to tell as 1.5.1 was released shortly after Python 2.5 and I don’t see any statements about which version of Python is required. Looking at all the various things it supports I would be shocked if there wasn’t some use of the C-based extension API (which would prevent, at least some portions, from working). I can understand your feeling but the core of the library is actually pure Python and very small. It's only all its extra features that do use C libraries. The core of Kamaelia is Python. I'm trying to use it with IP2A2 but I get a huge mono traceback currently (mono from svn compiled IP2) so well... not getting really far at the moment :) - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] zope, cherrypy
David Jensen a écrit : Will IronPython on the backend support web server software such as Zope and CherryPy, and, therefore, Plone, TurboGears, Django, etc.? I cannot speak for Zope but IP1.1 will not run CherryPy 3 as-is because there are some shotcomings in IP1.1 that prevent it. However it is possible to run part of CP3, notably its HTTP server. Note that I believe those issues will be addressed in IP2 and I do hope we will be able to run CP3 without hack. Nonetheless, Zope, TurboGears and other large frameworks do tend to use Python to its stretch and may rely on some behavior inherent to CPython itself. It might never be possible to run those completely with IP, at least not without some hacking. - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Is IronPython Project on CodePlex Now Accepting Patches?
Nice. Question though: What kind of patch format should be expected by the teams? - Sylvain M. David Peterson a écrit : @ http://www.codeplex.com/IronPython/SourceControl/PatchList.aspx Anyone can upload a patch. Patches are evaluated by project team members and either Applied or Declined. -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 ___ 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] __doc__ on None
Martin Maly a écrit : Thanks for yet another bug report, we now have it on codeplex as: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=10823 As Shri already said earlier, we are focusing most of our energy on the 2.0 development, but will address important blocking issues that are found in IronPython 1.1. We have moved all issues tracked on CodePlex over to target the 2.0 release, however if we did accidentally moved a serious blocking issue, please let us know so that we can track the important bugs that need to be fixed in the 1.1 release. Good to hear. I prefer that you guys focus on 2.0 too and backport to 1.1 once 2.0 is out in the field. It looks like 2.0 will bring some nice modifications that will extend the capacity of IP both with .NET and Python packages so I'm waiting for it :) - Sylvain Thanks! Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, June 04, 2007 8:46 AM To: Discussion of IronPython Subject: [IronPython] __doc__ on None Hello all, More fun with None: CPython 2.4.4: print None.__doc__ None IP 1.1: print None.__doc__ T.__new__(S, ...) - a new object with type S, a subtype of T This is again confusing our auto-documentation tool. :-) By the way - can any of 'the team' answer the question as to whether the 1.1 branch is still being developed? (Bugfixes being backported?) Thanks Michael Foord -- Michael Foord Resolver Systems [EMAIL PROTECTED] 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@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] SyntaxError: yield in more than one try blocks
[EMAIL PROTECTED] mono bin/ipy.exe IronPython 1.1 (1.1) on .NET 2.0.50727.42 def test(): try: yield 1 except: try: yield 2 except: pass if __name__ == '__main__': for _ in test(): print _ Will produce: [EMAIL PROTECTED] mono bin/ipy.exe -X:Python25 testyield.py Traceback (most recent call last): SyntaxError: yield in more than one try blocks (testyield.py, line 6) It does work fine with CPython 2.5 - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] SyntaxError: yield in more than one try blocks
I assume you are looking at a solution in the future :) Martin Maly wrote: Yes, this is currently a an unfortunate limitation of our compiler. Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch Sent: Thursday, May 10, 2007 3:40 AM To: Discussion of IronPython Subject: [IronPython] SyntaxError: yield in more than one try blocks [EMAIL PROTECTED] mono bin/ipy.exe IronPython 1.1 (1.1) on .NET 2.0.50727.42 def test(): try: yield 1 except: try: yield 2 except: pass if __name__ == '__main__': for _ in test(): print _ Will produce: [EMAIL PROTECTED] mono bin/ipy.exe -X:Python25 testyield.py Traceback (most recent call last): SyntaxError: yield in more than one try blocks (testyield.py, line 6) It does work fine with CPython 2.5 - Sylvain ___ 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] Problem importing standard libraries
I was wondering if you were using IPCE or a vanilla IP? http://fepy.sourceforge.net/ Look notably at fepy's options: http://fepy.sourceforge.net/doc/fepy-options.html - Sylvain Joss Burnett wrote: I am very new to Python and IronPython, so my apologies if this is a very dumb question: I have been trying to import the standard Python libraries and having some issues (apparently with module dependancies), for example: If my Site.py file is set up as follows: import sys sys.path.append(rc:\Python24\Lib) and I import the os module, import os It appears to work correctly, but certain functions do not appear to have the correct dependancies loaded (e.g. when using any of the exec routines I receive the following message NameError: name 'execv' not defined ). Also, packages installed in the site-packages directory cannot be directly loaded as they can via normal python. I am pretty sure I have set something up incorrectly and if someone could point me in the right direction I'd really appreciate it. Joss Burnett LiveDrive.Com ___ users mailing list [EMAIL PROTECTED] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list [EMAIL PROTECTED] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem importing standard libraries
Joss Burnett wrote: Hi Sylvain, I am using the version of IronPython from: http://www.codeplex.com/IronPython IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. I have not seen the FePy version before but I will take a look. You should indeed because it contains quite a few improvements to get the stdlib and other third-party Python packages to work with IP. You can grab IPCEr5 which contains IP1a1 IIRC. But you should be able to drop the latest IP binaries in the folder and it would work the same. - Sylvain ___ users mailing list [EMAIL PROTECTED] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython v1.1 RC1 Released
Congrats guys :) Dino Viehland wrote: Now with the link to the release :) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Friday, March 23, 2007 1:09 PM To: users@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 Candidatehttp://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@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] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@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] Metaclass bug?
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 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] End of the World? No just end of the line.
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 CRLF. If I'm not mistaken CPython always ensures the end of line is CRLF 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 CRLF 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 CRLF 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@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] End of the World? No just end of the line.
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 CRLF. If I'm not mistaken CPython always ensures the end of line is CRLF 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 CRLF 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 CRLF 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. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] ANN: bridge 0.2.4
Hi all, I am pleased to announce the release of bridge 0.2.4, a general purpose XML library for Python and IronPython. == Overview == bridge is very simple and light. It basically let you load an XML document via a set of different parsers (xml.dom, expat, Amara, lxml, System.Xml and ElementTree) and creates a tree of Elements and Attributes before releasing the parser resources. This means that once the document is loaded it is independent from the underlying parser. bridge then provides a straightforward interface to navigate through the tree and manipulate it. bridge does not try to replace underlying XML engines but offer a common API so that your applications are less dependent of those engines. bridge offers a couple of other goodies however to play with the tree of elements (see the documentation). == What's new? == This release is an important milestone for bridge: * added expat parser (seems to be the fatest parser bridge has) * many namespace issues fixed with the default parser * added incremental parsing with dispatching based on rules during the parsing of bridge Elements * added path lookup support (not XPath) * slightly increased the API of a few helps functions == TODO == Potentially the IronPython implementation is not as up-to-date as the other parsers. All parsers will generate the same bridge structure. The only minor difference at the present time is coming from the lxml parser which does not preserve processing instructions and comments before the root element. bridge cannot therefore access them. Add more unit tests. == Download == * easy_install -U bridge * Tarballs http://www.defuze.org/oss/bridge/ * svn co https://svn.defuze.org/oss/bridge/ == Documentation == Wiki: http://trac.defuze.org/wiki/bridge Have fun, -- Sylvain Hellegouarch http://www.defuze.org ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython on Ubuntu
Web Mayfield wrote: Are there any instructions anywhere about how to get IronPython 1.0.1 running with Mono 1.1.13.6? Is IP 1.0.1 even compatible with Mono 1.1.13.6 or am I going to have to figure out how to upgrade Mono to a higher version? There probably is and I was just didn't find the right combination of search terms to find it. I'm on Mono 1.1.13.6 because that seems to be the highest version that I can find packaged for Ubuntu 6.06. I'm no Linux guy, so I'd like to stick to what shows up in Ubuntu's package manager if at all possible. I'm just trying to make sure that I don't write anything on Windows that won't also run on Mono. IMO you should upgrade to Mono 1.2.x. Simply download the binary installer and launch it in your home directory somewhere. This won't be disruptive to the rest of your system and you will get all the latest Mono support. I run a Ubuntu-based distrib and that's what I've done. ftp://www.go-mono.com/archive/1.2.2.1/linux-installer/1/mono-1.2.2.1_1-installer.bin - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Potential issue with the 'in' construction?
Hi folks,
Say I have the following class:
class Test(dict):
def __getitem__(self, key):
print __gelitem__ called
return dict.__getitem__(self, key.title())
def __setitem__(self, key, value):
print __selitem__ called
dict.__setitem__(self, key.title(), value)
def __delitem__(self, key):
print __delitem__ called
dict.__delitem__(self, key.title())
def __contains__(self, key):
print __contains__ called
return dict.__contains__(self, key.title())
def has_key(self, key):
print has_key called
return dict.__contains__(self, key.title())
Now say I have this code:
if __name__ == __main__:
u = Test()
u['simple'] = 'text'
print u.keys()
print 'simple' in u
print u.__contains__('simple')
print u.has_key('simple')
print u['simple']
del u['simple']
I will get the following output:
__selitem__ called
['Simple']
False
__contains__ called
True
has_key called
True
__gelitem__ called
text
__delitem__ called
As you can see all the overridden methods were correctly called except
the __contains__ on 'in' construction.
The same test with CPython:
__selitem__ called
['Simple']
__contains__ called
True
__contains__ called
True
has_key called
True
__gelitem__ called
text
__delitem__ called
In that case everything is as I expected.
So could there be a problem on the way IP manages in?
This looks like a minor bug but prevent me from running CherryPy 3 which
uses the same type of Case Insensitive dict to handle easily HTTP headers.
Thoughts on a workaround or fix?
- Sylvain
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Potential issue with the 'in' construction?
Forgot to say that I tested with the latest IPCE svn trunk build against
mono 1.2
- Sylvain
Sylvain Hellegouarch wrote:
Hi folks,
Say I have the following class:
class Test(dict):
def __getitem__(self, key):
print __gelitem__ called
return dict.__getitem__(self, key.title())
def __setitem__(self, key, value):
print __selitem__ called
dict.__setitem__(self, key.title(), value)
def __delitem__(self, key):
print __delitem__ called
dict.__delitem__(self, key.title())
def __contains__(self, key):
print __contains__ called
return dict.__contains__(self, key.title())
def has_key(self, key):
print has_key called
return dict.__contains__(self, key.title())
Now say I have this code:
if __name__ == __main__:
u = Test()
u['simple'] = 'text'
print u.keys()
print 'simple' in u
print u.__contains__('simple')
print u.has_key('simple')
print u['simple']
del u['simple']
I will get the following output:
__selitem__ called
['Simple']
False
__contains__ called
True
has_key called
True
__gelitem__ called
text
__delitem__ called
As you can see all the overridden methods were correctly called except
the __contains__ on 'in' construction.
The same test with CPython:
__selitem__ called
['Simple']
__contains__ called
True
__contains__ called
True
has_key called
True
__gelitem__ called
text
__delitem__ called
In that case everything is as I expected.
So could there be a problem on the way IP manages in?
This looks like a minor bug but prevent me from running CherryPy 3 which
uses the same type of Case Insensitive dict to handle easily HTTP headers.
Thoughts on a workaround or fix?
- Sylvain
___
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] os.popen() + Mono == segfault
Just to confirm I get the same issue with IPCE-r3 and mono 1.2.1
- Sylvain
Anthony Baxter wrote:
On both IronPython 1.0.1 and IPCE release 4, os.popen() segfaults
under Mono 1.17.1 (on Ubuntu edgy).
To reproduce:
ipy.exe -c import os; print os.popen('/bin/ls', 'r').read()
Stacktrace follows, for whatever value it is... I can't tell
immediately whether it's an IronPython or Mono problem, although it
_appears_ to be in Mono. If other people agree, I'll log a Mono bug
tomorrow.
It looks like most of the os module to do with spawning commands is
missing, apart from os.spawnl(), which _appears_ to work. It should be
possible to re implement the stdlib's popen2 module on top of that.
Whether it will work is another matter entirely, of course :-)
=
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=
Stacktrace
at (wrapper managed-to-native)
System.Diagnostics.Process.CreateProcess_internal
(System.Diagnostics.ProcessStartInfo,intptr,intptr,intptr,System.Diagnostics.Process/ProcInfo)
0x4
at (wrapper managed-to-native)
System.Diagnostics.Process.CreateProcess_internal
(System.Diagnostics.ProcessStartInfo,intptr,intptr,intptr,System.Diagnostics.Process/ProcInfo)
0x
at System.Diagnostics.Process.Start_noshell
(System.Diagnostics.ProcessStartInfo,System.Diagnostics.Process)
0x00547
at System.Diagnostics.Process.Start_common
(System.Diagnostics.ProcessStartInfo,System.Diagnostics.Process)
0x0007c
at System.Diagnostics.Process.Start
(System.Diagnostics.ProcessStartInfo) 0x00032
at IronPython.Modules.PythonNT.OpenPipedCommand
(IronPython.Runtime.Calls.ICallerContext,string,string,int) 0x000ae
at IronPython.Modules.PythonNT.OpenPipedCommand
(IronPython.Runtime.Calls.ICallerContext,string,string) 0x00015
at (wrapper dynamic-method) System.Object.OpenPipedCommand##49
(IronPython.Runtime.Calls.ICallerContext,object,object) 0x
at (wrapper delegate-invoke)
System.MulticastDelegate.invoke_object_ICallerContext_object_object
(IronPython.Runtime.Calls.ICallerContext,object,object) 0x
at IronPython.Runtime.Calls.FastCallableWithContextAny.Call
(IronPython.Runtime.Calls.ICallerContext,object,object) 0x00023
at IronPython.Runtime.Calls.BuiltinFunction.Call
(IronPython.Runtime.Calls.ICallerContext,object,object) 0x00023
at IronPython.Runtime.Operations.Ops.CallWithContext
(IronPython.Runtime.Calls.ICallerContext,object,object,object)
0x00042
at (wrapper dynamic-method) System.Object.stdin##47
(IronPython.Runtime.ModuleScope) 0x
at (wrapper delegate-invoke)
System.MulticastDelegate.invoke_object_ModuleScope
(IronPython.Runtime.ModuleScope) 0x
at IronPython.Hosting.CompiledCode.Run
(IronPython.Runtime.ModuleScope) 0x00048
at IronPython.Hosting.PythonEngine.ExecuteToConsole
(string,IronPython.Hosting.EngineModule,System.Collections.Generic.IDictionary`2)
0x00180
at IronPython.Hosting.PythonEngine.ExecuteToConsole (string) 0x00015
at IronPythonConsole.PythonCommandLine.RunString
(IronPython.Hosting.PythonEngine,string) 0x000bc
at IronPythonConsole.PythonCommandLine.Run
(IronPython.Hosting.PythonEngine,string) 0x0002b
at IronPythonConsole.PythonCommandLine.Main (string[]) 0x002bf
at (wrapper runtime-invoke)
System.Object.runtime_invoke_int_string[]
(object,intptr,intptr,intptr) 0x
Native stacktrace:
/usr/bin/mono(mono_handle_native_sigsegv+0xde) [0x815644e]
/usr/bin/mono [0x8122c88]
[0xe440]
/usr/bin/mono(mono_unicode_to_external+0x3f) [0x811309f]
/usr/bin/mono [0x8103947]
/usr/bin/mono [0x80d6b57]
[0xb6e5d3fa]
[0xb6e5c880]
[0xb6e5c275]
[0xb6e5c0cb]
[0xb6e5ba5f]
[0xb6e5b996]
[0xb6e5b90a]
[0xb6e6b45c]
[0xb6e6b3d4]
[0xb6e5acfc]
[0xb6e5ac73]
[0xb6e5b6b3]
[0xb6e5378a]
[0xb6e53711]
[0xb6e5af89]
[0xb6e5adee]
[0xb706d4fd]
[0xb706d34c]
[0xb79725a0]
[0xb7971a84]
/usr/bin/mono(mono_runtime_exec_main+0x9f) [0x80996ef]
/usr/bin/mono(mono_runtime_run_main+0x1b9) [0x809]
/usr/bin/mono(mono_main+0xe47) [0x805d477]
/usr/bin/mono [0x805c122]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc) [0xb7d058cc]
/usr/bin/mono [0x805c071]
___
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] unicode object type
Sylvain Hellegouarch wrote: Fredrik Lundh wrote: Sylvain Hellegouarch wrote: Is this the correct behavior? yes. a Python implementation is not required to have a distinct Unicode string type; see: http://jython.sourceforge.net/docs/differences.html /F OK. Thanks for the heads up. Mind you I find that a bit confusing and I'd rather have the type to display unicode rather than str in that case. But fair enough. Interestingly after reading Peter Bengtsson's last post [1] i tried the following: CPython 't' is u't' False u't' is 't' False IronPython 't' is u't' True u't' is 't' True I can understand why IP or JYthon uses the same type but then the results don't seem to be consistent with CPython. I might misunderstand something here. Alternatively I assume using 'is' implies such issues. - Sylvain [1] http://www.peterbe.com/plog/is-equal-in-python ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] unicode object type
Fredrik Lundh wrote: Sylvain Hellegouarch wrote: I can understand why IP or JYthon uses the same type but then the results don't seem to be consistent with CPython. I might misunderstand something here. Alternatively I assume using 'is' implies such issues. you're confusing CPython implementation details with the language specification. Python makes very few guarantees about object identities; the specification says that there must be exactly one None object, and the type object for two objects of the same type is the same object (obviously), but that's about it. I see. My bad then. I assume then that people like me will have to be careful between those small differences which are not entirely valid cases. Thanks for the heads up. - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] unicode object type
CPython
str(None)
'None'
unicode(None)
u'None'
type(unicode(None))
type 'unicode'
type(unicode('ble'))
type 'unicode'
IronPython
str(None)
'None'
unicode(None)
'None'
type(unicode(None))
type 'str'
type(unicode('ble'))
type 'str'
Is this the correct behavior?
- Sylvain
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] unicode object type
Fredrik Lundh wrote: Sylvain Hellegouarch wrote: Is this the correct behavior? yes. a Python implementation is not required to have a distinct Unicode string type; see: http://jython.sourceforge.net/docs/differences.html /F OK. Thanks for the heads up. Mind you I find that a bit confusing and I'd rather have the type to display unicode rather than str in that case. But fair enough. - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Is any one use IronPython in your project?
Fredrik Lundh wrote: sounds like you're confusing Python with the stuff I get when I download the CPython 2.5 installer from python.org. don't do that; it only muddles the water for people who can distinguish between a language and a given im- plementation of it, and scares away people who haven't used either Python implementation. I don't muddle anything. But you are being harsh. If IP was only meant for .NET developers to move to dynamic languages such as Python then either the project is half useful or you've missed something. you're stuck in the Python is CPython 2.5 as packaged by python.org mode of thinking. snap out of it. It's funny because then you are tsuck in the .NET as framework mode of thinking since the beginning of this thread. Not once have you mentioned C# or Vb#. So one hand you don't want people to mix between Python the language and Python the environment but you quite happily do it with .NET. IP has a platform will only achieve its goal if it allows Python developers to try the .NET environment AND if .NET developers understand that some things are much easier with the Python environment (language+stdlib). it's not obvious to me that Python's standard library is, in any way, better than the DotNet standard library. it's obvious that the Python language is better than other languages for lots of tasks. I did not say the stdlib was better than the .NET framework I said it was also part of Python's (the language) success. Python without its stdlib would not have arrived where it is now without it IMO. So the fact IP does not support it really well in a 1.0 release is annoying *to me*. Funny enough what has made Python a success is also its stdlib. the standard library was a lot more important when Python was competing with languages didn't have extensive standard libraries too. True. And? Given that ElementTree is now part of that same stdlib I assume you know that it will make it an even bigger success. as of 1.2.7, ElementTree also supports IronPython 1.0 natively, right out of the box. thanks to careful design of the XMLReader stuff in the DotNet standard library, and careful modular design on the ET side of things. took me minutes to find the right DotNet API, and figure out how to use it. I'm not sure I can say the same about many Python XML API:s. You are right. It took me no time to incorporate it into bridge either. But so what? I mean what do you proove? In my previous message I said the goal of IP was to allow people to use the best of *both* world. Have you noticed how painful it was to serialize to a string from XmlWriter while it was a one line job in xml.dom. I agree this is thanks to the Python language but Again I agree with you. Not everything in the stdlib is great but neither is the .NET framework (and I have worked on a large project with .NET and C#... not everything is great and I wish I had had IP back then). (and what's the point running your existing Python stuff on IronPython? don't you already have CPython for that purpose? what I love with IronPython is all the *new* things I can do with it, and all the *new* projects I can bring Python into. not that I get yet another platform to run my old crap on.) That's stupid reasoning I'm sorry. The all point is to be able to use the best of both worlds and you only look at one side. I could have sworn that *I* was the one who said that IronPython success- fully fuses Python the language with DotNet the platform, and you were the one who kept repeating that CPython is the one true Python, and Iron- Python is not CPython, so it's broken, but maybe I missed some post in this thread. No you just want to read what you want to read and make me look like the daft Python coder who has just arrived into the game. I will repeat it. IP goal should be to allow developers of both sides to see how to make the best of both environments doesn't matter, really: It does not matter but you like showing it, don't you? among my customers, IronPython has done more for Python's visibility and marketability than *any* other Python project in recent times, and I'm learning a *lot* from integrating IronPython in existing DotNet projects. I could of course ignore that, and sit in a corner by myself muttering that it's not real Python, and they're not using it the right way, so why are they so darn happy with it in a Homer Simpson voice, but that would be more religion than engineering, and it would definitely not be Pythonic. For Christ's sake. Did you even read what I said? I never said IP was a bastard project not worth the penny. I said that in its current state it was limited. Right maybe it could only be for my sole purpose and not the whole Python community. I'll give you that. But when did I say that Python was the one and only? Stop making others look like they are the bad guys please. This is annoying. Where I wholeheartedly
Re: [IronPython] Is any one use IronPython in your project?
Kevien Lee wrote: Hi, Now ,Ironpython had release some time,but i want to konw is any one use IronPython in your project? As a dynamic language ,what it will bring us some advantage for project,which the advantage C#,VB.net couldn't have? From a Python user POV, IP is far from being good enough as it is now. I have actually hard times understanding why it went in version 1.0 so fast. Don't get me wrong IP is stable and is good implementation of Python but it is only a milestone towards a truly useful platform. Basically it seems IP only implements the language itself but as we have seen on this list since it was released only a handful of Python modules can be run as-is within IP. I do hope the next milestone will focus on a much better support of those external packages. To achieve this goal the IP team will have to look at IPCE and understand what needs to be done first (support more of the stdlib and third-party modules). IP as a language is cool but we cannot run most of our common Python packages on it, making it as useful as a cherry on top of a cake. Nice but not essential. Make IP a cake in itself and you'll have a winner. However I have a feeling IP has been more relevant to regular .NET users coming from C# who wanted to keep their platform while making a step towards dynamic languages. That's great and I'm sure once they'll start they won't be able to stop, but for now I have not found IP entirely satisfying coming from Python itself and I hardly do anything productive with it (while I'd really like to). - Sylvain http://www.defuze.org ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] ANN: bridge 0.1.0 a general Python and IronPython XML library
Hi all, I'm happy to introduce the first release of bridge. A general purpose XML library for Python and IronPython (and ultimately Jython). bridge is very simple and light. It basically let you load an XML document via a set of different parsers (xml.dom, Amara, lxml, System.Xml) and creates a tree of Elements and Attributes before releasing the parser resources. This means that once the document is loaded it is independent from the underlying parser. bridge then provides a straightforward interface to navigate through the tree and manipulate it. bridge does not try to replace underlying XML engines but offer a common API so that your applications are less dependent of those engines. bridge offers a couple of other goodies however to play with the tree of elements (see the documentation). == Download == * easy_install -U bridge * Tarballs http://www.defuze.org/oss/bridge/ * svn co https://svn.defuze.org/oss/bridge/ == Documentation == http://trac.defuze.org/wiki/bridge Hope this will help a few people in working with XML without worrying on which engine they choose to use. Have fun, -- Sylvain Hellegouarch http://www.defuze.org ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 1.0.1 Released!
I could not agree more. If people are two write Python packages which
could run in both environment they may need to differentiate both in some
cases (like import statements of assemblies which would fail with
CPython).
This is quite an important piece of information and I was so surprised to
see sys.version returning my CPython major version number (because it does
not set the minor version number either).
Thanks,
- Sylvain
I notice the format of sys.version has changed. Since sys.version_info
lies, and sys.subversion isn't supported, could this please not be
changed so much?
Old:
IronPython 1.0.2453 on .NET 2.0.50727.42
New:
IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
On another related matter, there really is no useful way to ask what
version of IronPython is the user running that I can see. Ideally,
IronPython would also support sys.subversion in some way, at least -
even if it has to synthesise the values. But *please* don't just copy
the sys.subversion values from CPython - actually make it relevant to
the IronPython release!
Python 2.5 (r25:51908, Sep 19 2006, 14:29:31)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type help, copyright, credits or license for more information.
t import sys
sys.subversion
('CPython', 'tags/r25', '51908')
___
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] FePy SourceForge website updates
I am not saying Seo's choice of license was a bad one, but I don't know if it has a value by itself that's all. The question is not to please people but to convey the correct rights as well as the responsability you take as the provide for the piece of software. The MIT license is as easy to understand and does just that IMO ;) Mind you it seems some people believe the public domain license such as the MIT one is actually not a license: http://www.linuxjournal.com/article/6225 via http://programming.reddit.com/info/k9kl/comments - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] FePy SourceForge website updates
Terry L. Triplett wrote: Your comment seems to directly contradict what Larry Rosen said in the article. Yes my mistake :) - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] FePy SourceForge website updates
I faily agree and I'm not sure that license has any realy meaning in fact. If you want you can use a Public Domain license in that case. - Sylvain Terry L. Triplett wrote: Thanks for all your efforts. Not to be picky or anything, but it might be prudent to tweak the name of one of the licenses to be a bit more work friendly. The current name is likely to get the site added to banned sites list of some companies. The license I'm referring to should be obvious. :-) On 9/29/06, Sanghyeon Seo [EMAIL PROTECTED] wrote: * IPCE software licenses: http://fepy.sourceforge.net/license.html ___ 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] [ANN] IronPython Community Edition 1.0r2
Brilliant Seo. Thanks a lot :) BTW, if it can be useful and you're happy with the code, don't hesitate to include my port of the Gzip module. Its a BSD license :) - Sylvain This is the second release of IronPython Community Edition (IPCE), 1.0 revision 2, based on IronPython 1.0. Get it here: http://sparcs.kaist.ac.kr/~tinuviel/download/IPCE-1.0r2.zip Binary is built with Mono 1.1.17.1. BIG WARNING: it won't work with Mono versions below 1.1.17. Please don't mail me or IronPython mailing list before checking your Mono version! IPCE has a new home on SourceForge: http://fepy.sourceforge.net/ And here's the license and the summary of applied patches: http://fepy.sourceforge.net/license.html http://fepy.sourceforge.net/patches.html Changes in this revision: * Includes the Python standard library from CPython 2.4.3. (Not everything is included -- that would be pointless. Those I tested and work reasonably are included.) * Includes following CPython-compatible wrappers for .NET library: md5, pyexpat, select, sha, socket, ssl, unicodedata. * Includes DB-API wrapper for ADO.NET. * Includes BeautifulSoup and ElementTree for you to test. (Both work great with IronPython!) * Does not include Doc, Src, Tutorial from the original IronPython release. You know where to get them... Reduces size by about half. * Extracts to IPCE-1.0r2. (The first revision extracted to IronPython-1.0 and it could overwrite existing installation. Thanks to Anthony Baxter for pointing this out.) -- Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Gzip module
Hi all, Just gave a stab to a gzip module yesterday evening and I thought it might be handy for others. http://www.defuze.org/oss/ipextra/gzip.txt Mind you I haven't tested thoroughly so wouldn't be surprised that it brings the World to an end. It uses the SharZipLib package for .NET. It is bundled by default with Mono but I don't know for MS.NET. I assume implementing other modules such as bzip2, zlib ad tarfile would not be much harder. - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] CherryPy 3 on top of IronPython 1.0... kind of working
2006/9/6, Sylvain Hellegouarch [EMAIL PROTECTED]:
a. First string.encode('hex') is not implemented so:
LookupError: unknown encoding: hex
This is CodePlex 1214.
http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPythonWorkItemId=1214
As I commented, this can be easily fixed by adding this line to site.py:
import encodings
CPython does this import implicitly inside _PyCodecRegistry_Init:
http://pxr.openlook.org/pxr/source/Python/codecs.c?v=2.4.2#828
You are precious Seo!
Thanks,
- Sylvain
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] more pythonic than python (end)
For sure, i don´t want nor like a messy language with thousands of features that would satisfy any randomic newbie wish. I want a compact, clean, robust, simple, coerent and friendly language: everything that Python promissed to be. Of course, such perfect language won´t 100% satisfy everybody, but then it will be a case of Love it or leave it. It is interesting that you claim promises to have all the features you listed and yet you think it should break those features to be nice to newbies. As stated what you suggested is a matter of taste, therefore little long term value for the community. I remember one of my first wish I sent to the Python community (sadly I sent it on the python-dev list and got [rightly] kicked out) was to add a new keyword Empty because I found that None was sometimes semantically unclear in some contexts. In the end a few developers explained what I wanted was syntaxic sugar which added no value to the language itself. They were right. If i understand well, the good developers of the language have too much work to deal with changes that would fit in the fundamental principles over wich the language as prototyped (Zen of Python, for example) but are not indispensable for make a piece of code works. I think that it is a pity that they are too busy. I don't think you understood correctly. They won't do what you suggest because they are too busy but because they don't believe it would add any value, and since the language already allows you to achieve it, why should they spend time on it? - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] IRC channel
Hi folks, I was wondering if you'd be interested in meeting in an IRC channel to know each other a bit more and well alternatively answer IP related questions :) Network: Freenode Server: irc.freenode.net Channel: #ironpython I have registered the channel and my nickname is Lawouach. Hope to see you there soon, - Sylvain http://www.defuze.org ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] IronPython features matrix
Hi folks, I've been trying to fiond a way to make way through IP for a while now (such as working on Seo's work of bringing CherryPy to IP) but I fail to find the right catch the train because it's hard for an occasional user as me to have a clear picture of what IP covers of the Python language as of today. Therefore is there a plan to create some kind of features matrix whic would give a detailed overview of what is completed or not in IP in regards to the Python language? That would be a great help for me to become a more regular user. Thanks, - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Question to IronPython team
Do you plan to include socket module in IronPython before releasing IronPython 1.0? I cannot deny this would be a great decision to be made :D - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] socket for IronPython update
Hi all, I've copied Sylvain Hellegouarch, one of the CP project developers as I know he has had this on his list of things to get working. Indeed. I've tried a few things already but I always ran into issues. There's a lot of folks, including myself, that would LOVE to see CP running via IronPython... Sylvain, it seems that maybe Seo and you could compare notes? I'd love to help where I can just not quite sure where/what work needs to be done. I'd love to check out your progress Seo and help as I can. - Sylvain ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
