Re: [IronPython] End of the World? No just end of the line.
Oh, and if any of you want to play with the result of Sylvain's sleuth detective work coupled with our ongoing hybrid efforts to merge Amplee with AtomicXML, you can access a ClickOnce app** @ http://xameleon.org/webapp/publish.htm From the commandline, from cherrypyserver import server Which will result in, Creating APP store Creating the service WSGI application Creating the collection WSGI application All good! server.start() Will then allow access to http://localhost:/ at which point you will receive, http://www.w3.org/2005/Atom";> urn:uuid:7d971f07-acb2-50e2-bec6-33c283572247 2007-03-05T19:42:53.125000Z My Music in response. Please see http://trac.defuze.org/wiki/amplee for extended detail on where to go from here. Please see http://www.oreillynet.com/xml/blog/2007/02/week_8_open_source_xml_weekly.htmland http://www.oreillynet.com/xml/blog/2007/02/week_7_open_source_xml_weekly.htmlfor extended detail as to where we're taking all of this. Code is @ http://extf.googlecode.com/svn/trunk/WebApp for a standalone version of the above that works on any .NET-enabled client (MS.NET or Mono: both work equally as well, and in fact it was the fact that it worked with Mono and did not with MS.NET that led to Sylvain's discovery and fix mentioned at the start of this thread. Mono helping to discover and solve MS.NET <~> Unix* incompatibility issues > I *LOVE* IT! :D) ClickOnce app is @ http://extf.googlecode.com/svn/trunk/Xameleon.ClickOnce/ Get all of this integrated into a nice, simple, and clean browser-based UI is on tap for today. When in decent demoable shape, one of us will update this thread. ** From within Internet Explorer > I tried the ClickOnce Fx plugin suggested on this list a while back, and could never get it to work > Any ideas from any of you out there?) On 3/5/07, M. David Peterson <[EMAIL PROTECTED]> wrote: I would just like to take a time out to congratulate Sylvain on coming up with a subject line that brings tears of joy to a phreak-geek like me who takes pride in coming up with cheezy one-liners such as that so eloquently displayed in the subject of the original post. Thanks for the laugh/smile, Sylvain! :D On 3/3/07, Sylvain Hellegouarch <[EMAIL PROTECTED]> 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 whereas for instance on Linux with > Mono it's . > > If I'm not mistaken CPython always ensures the end of line is > 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 > but because CherryPy reads the socket as a file it only gets a > with IP under Windows and therefore fails miserably. I've added a > test for a single 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 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 > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 ___ 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.
I would just like to take a time out to congratulate Sylvain on coming up with a subject line that brings tears of joy to a phreak-geek like me who takes pride in coming up with cheezy one-liners such as that so eloquently displayed in the subject of the original post. Thanks for the laugh/smile, Sylvain! :D On 3/3/07, Sylvain Hellegouarch <[EMAIL PROTECTED]> 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 whereas for instance on Linux with Mono it's . If I'm not mistaken CPython always ensures the end of line is 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 but because CherryPy reads the socket as a file it only gets a with IP under Windows and therefore fails miserably. I've added a test for a single 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 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 -- /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
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 whereas for instance on Linux with > Mono it's . > > If I'm not mistaken CPython always ensures the end of line is > 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 > but because CherryPy reads the socket as a file it only gets a > with IP under Windows and therefore fails miserably. I've added a > test for a single 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 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] 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 whereas for instance on Linux with Mono it's . If I'm not mistaken CPython always ensures the end of line is 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 but because CherryPy reads the socket as a file it only gets a with IP under Windows and therefore fails miserably. I've added a test for a single 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 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
