Re: [Mono-dev] Patch for CookieContainer.SetCookies
Hello Tom, On Mon, 2010-01-18 at 15:31 -0800, Tom Philpot wrote: The current implementation of CookieContainer.SetCookies does not handle the case where a cookie contains an expires=... attribute. As documented on MSDN here: http://msdn.microsoft.com/en-us/library/aa384321%28VS.85%29.aspx the Set-Cookie: header expires attribute uses the following format: DAY, DD-MMM- HH:MM:SS GMT The current version of SetCookies simply does a split on ',' in the header which totally causes the CookieContainer to choke when the expires attribute is set as MS recommends. Also, the Add (Cookie) method of CookieContainer does not clone all the properties of the incoming cookie before adding it to the collection. Using SetCookies(Uri, string) should clone all the properties, so that is fixes as well in the patch and a test is added in the test cases. I believe this makes the behavior of CookieContainer more bug-compatible with .NET. Great, I'll merge it with my local changes today (there are still more issues than that) and try them (on mono and moonlight). Can I assume the diff are against HEAD ? (the code is a bit different on 2-6 and 2-4 due to 1.x support and compiler differences). Please review the patch and the test cases. Please have a look at http://www.mono-project.com/Coding_Guidelines In particular avoid unneeded changes (like space additions/removal), code style changes (even more when they are against conventions) and the place of () [] after method / variables names. Thanks Sebastien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] COM Interop - Support for [in] parameters of type SAFEARRAY[VARIANT]
Sylvain Committed to the trunk. r149817 Thanks -bill On Mon, Nov 9, 2009 at 7:17 AM, Sylvain Dupont dupo...@gmail.com wrote: Hi, The patch attached is a continuation of my previous patch committed in r136836. It adds support for [in] parameters of type SAFEARRAY[VARIANT], and also for other variations of in/out/byval/byref options. In addition to the tests included in the patch, I have also tested this against other COM components, both on Windows and Linux (using Mainwin and with the MONO_COM environment variable set to MS). Contributed under MIT/X11 license. Thanks, Sylvain ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Preliminary ia64-hpux porting committed
Hi all I've committed the first bits of a port to ia64-hpux, in the branch /source/branches/dick/ia64-hpux The approach I took was to let the compiler work in the existing little-endian mode, and byteswap when the instructions are emitted. This kept code changes to a minimum. I'm not sure I completely figured out the patching code, so I'm not 100% certain that the byteswapping is happening in the right place, but a different attempt at byteswapping much later in the compilation process gave precisely the same results. Code generation seems to work: the disassembled code output when run with sufficient verbosity matches the ia64-linux output. However, executing the generated code segfaults straight away. I suspect this is coming from the unwinding code - it took me several goes to get libunwind built for hpux, and I'm still not convinced it's working correctly. Unfortunately we won't be able to spend any more time on this in the near future, so it's being committed into svn in the hope that others can take it up. Thanks are due to Miguel and Thomas for arranging access to an ia64-linux machine while I was working on this, which made the work a lot easier. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
