From sanxiyn at gmail.com Mon Oct 1 00:52:13 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 1 Oct 2007 13:52:13 +0900 Subject: [Mono-dev] Mono.Cecil.MethodDefinition.Is* properties Message-ID: <5b0248170709302152p56559f86n7cb98471a6ee4499@mail.gmail.com> Hi, Mono.Cecil.MethodDefinition.Is* properties are settable, and are implemented as: public bool IsPublic { get { return (m_attributes & MethodAttributes.MemberAccessMask) == MethodAttributes.Public; } set { MethodAttributes masked = (MethodAttributes.MemberAccessMask & MethodAttributes.Public); if (value) m_attributes |= masked; else m_attributes &= masked; } } Shouldn't &= be ^= instead? The current implementation doesn't return True for m.IsPublic even after m.IsPublic = true is executed. -- Seo Sanghyeon From atsushi at ximian.com Mon Oct 1 04:00:29 2007 From: atsushi at ximian.com (AtsushiEno) Date: Mon, 01 Oct 2007 17:00:29 +0900 Subject: [Mono-dev] RFC on remoting security stuff Message-ID: <4700A91D.2090307@ximian.com> Hi, As part of filling .NET 2.0 API, I am wondering how and what we need to do secure remoting support (introduced in 2.0), namely HttpChannel, TcpChannel and IpcChannel. (I'd like to put my disclaimer - am far from familiar with those remoting stuff, so don't hit me if I am misunderstanding the entire bits ;-) It seems that secure remoting stuff sorta involves WindowsImpersonationContext which is based on authentication information which will be likely from System.Net.CredentialCache.DefaultCredentials (if written in managed land). DefaultCredentials seems to require CAS (and some work, as it is commented as "Need EnvironmentPermission implementation first"). So I guess it is not likely possible to implement security support in the same manner as .NET does. So I'd like to hear you guys' ideas. Would we just leave them unimplemented, or find some alternative security support, like using TLS to at least enable encryption (and optionally integrity by some certificate configuration) ? (While we could implement NegotiateStream and hence secure connection itself would not be an issue, am having problems to solve NTLM issue on my machine and cannot implement it so far.) Atsushi Eno From sanxiyn at gmail.com Mon Oct 1 04:19:23 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 1 Oct 2007 17:19:23 +0900 Subject: [Mono-dev] Mono.Cecil.MethodDefinition.Is* properties In-Reply-To: <5b0248170709302152p56559f86n7cb98471a6ee4499@mail.gmail.com> References: <5b0248170709302152p56559f86n7cb98471a6ee4499@mail.gmail.com> Message-ID: <5b0248170710010119m1404492ek25ce3e836f2b236@mail.gmail.com> 2007/10/1, Sanghyeon Seo : > Shouldn't &= be ^= instead? The current implementation doesn't return > True for m.IsPublic even after m.IsPublic = true is executed. Should be &= ~masked, instead of &= masked, like other properties? -- Seo Sanghyeon From kostat at mainsoft.com Mon Oct 1 04:42:16 2007 From: kostat at mainsoft.com (Konstantin Triger) Date: Mon, 1 Oct 2007 01:42:16 -0700 Subject: [Mono-dev] Replicating System.Web.Script.Serialization bugs In-Reply-To: <6FA9886A-26CD-4FF9-84F4-8F6A17E37086@monkeypox.org> References: <68CC0483-21EF-4D9B-A52F-9FDB3D317A72@monkeypox.org> <3ec1038d0709250323t3886c646ldb8584f3872c947e@mail.gmail.com> <46FA0CC0.6030909@gmail.com> <6FA9886A-26CD-4FF9-84F4-8F6A17E37086@monkeypox.org> Message-ID: Hey Tyler, If you need this urgently, please provide a fix. If not - it will be somewhere in my todo list and will be fixed in a couple of weeks. Regards, Konstantin Triger > -----Original Message----- > From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list- > bounces at lists.ximian.com] On Behalf Of R. Tyler Ballance > Sent: Thursday, September 27, 2007 11:26 AM > To: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] Replicating System.Web.Script.Serialization bugs > > > On Sep 26, 2007, at 12:39 AM, Andr?s G. Aragoneses [ knocte ] wrote: > > > R. Tyler Ballance escribi?: > >> [...] > >> Without providing compatibility for MS.NET, the only alternatives > >> seem to be some application specific hacks, either with crazy > >> properties as mentioned above, or using Nullable types (which we > >> don't yet support in Mono right?) > > > > Hey, I think Mono has support for Nullables since much time ago. > > Unfortunately, I tried this in Mono, and our > System.Web.Script.Serialization barfs on Nullable types :( > > Fortunately, .NET doesn't! Alas there is hope :) > > I've attached my modified JsonTest class (attached), and here's the > output: > > Microsoft .NET 2.0.5: > -------------------------------------- > Testing for empty values in JSON with this string: > {"int_key" : ""} > int_key = > > -------------------------------------- > > Mono version 1.2.5 (/trunk/ r86375) > -------------------------------------- > [mono] \w @ mono JsonTest.exe > Testing for empty values in JSON with this string: > {"int_key" : ""} > > Unhandled Exception: System.InvalidCastException: Unknown target > conversion type > at System.Convert.ToType (System.Object value, System.Type > conversionType, IFormatProvider provider) [0x00000] > at System.Convert.ChangeType (System.Object value, System.Type > conversionType) [0x00000] > at > System.Web.Script.Serialization.JavaScriptSerializer.ConvertToType > (System.Type type, System.Object obj) [0x00000] > at > System.Web.Script.Serialization.JavaScriptSerializer.ConvertToObject > (IDictionary`2 dict, System.Type type) [0x00000] > at > System.Web.Script.Serialization.JavaScriptSerializer.ConvertToType > (System.Type type, System.Object obj) [0x00000] > at > System.Web.Script.Serialization.JavaScriptSerializer.ConvertToType > [JsonObject] (System.Object obj) [0x00000] > at System.Web.Script.Serialization.JavaScriptSerializer.Deserialize > [JsonObject] (System.String input) [0x00000] > at JsonTests.JsonTest.Main (System.String[] args) [0x00000] > [mono] \w @ > -------------------------------------- > > I've also reported the bug here: https://bugzilla.novell.com/ > show_bug.cgi?id=328836 > > > Cheers > From tyler at monkeypox.org Mon Oct 1 06:06:24 2007 From: tyler at monkeypox.org (R. Tyler Ballance) Date: Mon, 1 Oct 2007 03:06:24 -0700 Subject: [Mono-dev] Replicating System.Web.Script.Serialization bugs In-Reply-To: References: <68CC0483-21EF-4D9B-A52F-9FDB3D317A72@monkeypox.org> <3ec1038d0709250323t3886c646ldb8584f3872c947e@mail.gmail.com> <46FA0CC0.6030909@gmail.com> <6FA9886A-26CD-4FF9-84F4-8F6A17E37086@monkeypox.org> Message-ID: <5713635E-2036-4219-A5B6-49650CEC66C5@monkeypox.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 1, 2007, at 1:42 AM, Konstantin Triger wrote: > Hey Tyler, > > If you need this urgently, please provide a fix. > If not - it will be somewhere in my todo list and will be fixed in > a couple of weeks. Would you recommend just adding another if statement in: > internal object ConvertToType (Type type, object obj) Or is the bug elsewhere? The best I could tell as far as a fix would be would be to check if it's a Nullable type, and then try/catch a convert recursing into ConvertToType and in the catch setting hasValue = false, etc. If you can take the time to suggest a plan of action, I'd be more than happy to fix, test and commit a patch for this, since it's somewhat blocking me right now :) Cheers -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHAMahA2GmJ0VpG78RAj6DAJwNBqkPL85OBjufkZafa4v6/lW60wCgoiJT DUyhiLCjc+xXrwQ6i8ouMcY= =rs5n -----END PGP SIGNATURE----- From jb at nurv.fr Mon Oct 1 07:43:59 2007 From: jb at nurv.fr (Jb Evain) Date: Mon, 1 Oct 2007 13:43:59 +0200 Subject: [Mono-dev] Mono.Cecil.MethodDefinition.Is* properties In-Reply-To: <5b0248170710010119m1404492ek25ce3e836f2b236@mail.gmail.com> References: <5b0248170709302152p56559f86n7cb98471a6ee4499@mail.gmail.com> <5b0248170710010119m1404492ek25ce3e836f2b236@mail.gmail.com> Message-ID: <69f7d8470710010443l2bacacddhe8ad163c0781fedc@mail.gmail.com> Hey, On 10/1/07, Sanghyeon Seo wrote: > Should be &= ~masked, instead of &= masked, like other properties? Yeah, good catch. This is a regression I introduced when I wrote the Is* property generator. The good news is that now, I only have to change the code generator to change all properties :) Thanks, -- Jb Evain From sebastien.pouliot at gmail.com Mon Oct 1 08:28:49 2007 From: sebastien.pouliot at gmail.com (Sebastien Pouliot) Date: Mon, 01 Oct 2007 08:28:49 -0400 Subject: [Mono-dev] RFC on remoting security stuff In-Reply-To: <4700A91D.2090307@ximian.com> References: <4700A91D.2090307@ximian.com> Message-ID: <1191241730.24578.187.camel@poupou.home> On Mon, 2007-10-01 at 17:00 +0900, AtsushiEno wrote: > Hi, > > As part of filling .NET 2.0 API, I am wondering how and what we need to do > secure remoting support (introduced in 2.0), namely HttpChannel, TcpChannel > and IpcChannel. (I'd like to put my disclaimer - am far from familiar > with those > remoting stuff, so don't hit me if I am misunderstanding the entire bits ;-) > > It seems that secure remoting stuff sorta involves > WindowsImpersonationContext > which is based on authentication information which will be likely from > System.Net.CredentialCache.DefaultCredentials (if written in managed land). > DefaultCredentials seems to require CAS (and some work, as it is > commented as "Need EnvironmentPermission implementation first"). I don't see why - as this exists in Windows without .NET. It's probably a local comment (for the next few lines) and not a global one. > So I guess > it is not likely possible to implement security support in the same > manner as > .NET does. The real problem is interoperability. Right now the 1.x profile implements some WindowsIdentity stuff so we use (a) Windows API stuff under Windows and (b) POSIX API elsewhere. This enabled us to provide similar features using the same managed API. However in 2.x the API is much larger. Part of it goes deeply into Win32 structures and design (which doesn't map so well with POSIX) while other parts offers network support. So for network interop purpose our 1.x stuff isn't correct. We need a Windows-client, either managed (one can dream ;-) or by integrating with unmanaged libraries (samba, kerberos...). > So I'd like to hear you guys' ideas. I don't know enough about all channels but it's possible that some, like HTTP, can be implemented without a Windows-client (e.g. using mostly HTTP+SSL support). For such "open" channels I think it would be worth the time to implement them. > Would we just leave them unimplemented, IMHO advanced Win32-specific features that does not benefit Mono (elsewhere) should be considered "out-of-scope" with a big "contributions welcome" sign over them. > or find some alternative security support, Probably out-of-scope for Mono but someone(s) could build, on open standard and FOSS, something very similar to the WindowsIdentity and impersonification features. That would be useful, both to Mono and to Windows developers that don't like being tied to Windows anymore that they can avoid. > like using TLS to at least enable > encryption (and optionally integrity by some certificate configuration) ? SSL/TLS offers integrity. Client authentication requires (from a protocol perspective) x.509 certificates. > (While we could implement NegotiateStream and hence secure connection itself > would not be an issue, am having problems to solve NTLM issue on my machine > and cannot implement it so far.) Even Negotiate has it's own problem. The identity cannot be created like it is on Windows (we would need the password). Also this protocol is a simple "switcher" on the older NTLM and newer PK-enabled Kerberos available in different versions of Windows (so we need both for interoperability). > Atsushi Eno > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From csaba.balazs at researchstudio.at Mon Oct 1 08:37:32 2007 From: csaba.balazs at researchstudio.at (Csaba Balazs) Date: Mon, 01 Oct 2007 14:37:32 +0200 Subject: [Mono-dev] Sockets on mipsel Message-ID: <20071001143732.gccg0k4kgcswg0o0@webmail.researchstudio.at> Hello, I would like to use sockets with mono on mipsel. This is a sample code which works well on PC: using System; using System.IO; using System.Net.Sockets; class ClientDemo { public static void Main(string[] args) { string serverIp = "x.x.x.x"; TcpClient client = new TcpClient(serverIp, 8001); NetworkStream strm = client.GetStream(); // reading / writing via network stream strm.Close(); client.Close(); } } On Mipsel: export MONO_PATH="/usr/lib/mono/1.0/" Stacktrace: at System.Net.Sockets.TcpClient.Connect (string,int) <0xffffffff> at System.Net.Sockets.TcpClient.Connect (string,int) <0x00040> at System.Net.Sockets.TcpClient..ctor (string,int) <0x0003c> at ClientDemo.Main (string[]) <0x00054> at (wrapper runtime-invoke) ClientDemo.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0xffffffff> Aborted export MONO_PATH="/usr/lib/mono/2.0/" Stacktrace: at System.DateTime.ToLocalTime () <0xffffffff> at System.DateTime.ToLocalTime () <0x00028> at System.IO.File..cctor () <0x00050> at (wrapper runtime-invoke) System.Type.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> at System.Configuration.ConfigurationManager.OpenExeConfigurationInternal (System.Configuration.ConfigurationUserLevel,System.Reflection.Assembly,string) <0xffffffff> at System.Configuration.ConfigurationManager.OpenExeConfigurationInternal (System.Configuration.ConfigurationUserLevel,System.Reflection.Assembly,string) <0x00188> at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection (string) <0x000f0> at System.Configuration.ConfigurationManager.GetSection (string) <0x00050> at System.Net.Sockets.Socket.CheckProtocolSupport () <0x0019c> at System.Net.Dns..cctor () <0x00018> at (wrapper runtime-invoke) System.Net.Dns.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> at System.Net.Sockets.TcpClient.Connect (string,int) <0xffffffff> at System.Net.Sockets.TcpClient.Connect (string,int) <0x00040> at System.Net.Sockets.TcpClient..ctor (string,int) <0x0003c> at ClientDemo.Main (string[]) <0x00054> at (wrapper runtime-invoke) ClientDemo.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0xffffffff> Aborted What is the problem? I would like to use mono 2.0 dlls. I can use sockets in C correctly on mipsel. Thank you for your help, Csaba From kumpera at gmail.com Mon Oct 1 11:29:40 2007 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Mon, 1 Oct 2007 12:29:40 -0300 Subject: [Mono-dev] [PATCH] Encoding of the generic type definition. Message-ID: <8cca42d80710010829r61e3cf88g97661d29c35b86b8@mail.gmail.com> Hi, The patch that changed the generic type definition to be the same instance of the fully open instantiation introduced a small issue in the encoding of types. This issue is quite subtle and gmcs produces it only on rare situations. If you use, for example: ILGenerator::Emit (OpCodes.Callvirt, MethodInfo), where the method belongs directly to the TypeBuilder, it will generate the wrong code. This was demonstrated by gtest-203, it generates "callvirt instance void class C`2::bar()" instead of "callvirt instance void class C`2::bar()" (notice that C`2 is instantiated here). The major issue fixing this is regarding how the generic type definition should be encoded in metadata tables. First, all uses should be replaced by an explicit instantiation, a typespec token, and the type itself must be encoded using a typedef or typeref. To archive that I had to do some big changes in reflection.c, shifting the typespec tokens from assembly->typedef cache to assembly->typespec. Cheers, Rodrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071001/319acbaa/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: generics_encode.diff Type: text/x-patch Size: 6001 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071001/319acbaa/attachment.bin From kostat at mainsoft.com Mon Oct 1 12:51:25 2007 From: kostat at mainsoft.com (Konstantin Triger) Date: Mon, 1 Oct 2007 09:51:25 -0700 Subject: [Mono-dev] Replicating System.Web.Script.Serialization bugs In-Reply-To: <5713635E-2036-4219-A5B6-49650CEC66C5@monkeypox.org> References: <68CC0483-21EF-4D9B-A52F-9FDB3D317A72@monkeypox.org> <3ec1038d0709250323t3886c646ldb8584f3872c947e@mail.gmail.com> <46FA0CC0.6030909@gmail.com> <6FA9886A-26CD-4FF9-84F4-8F6A17E37086@monkeypox.org> <5713635E-2036-4219-A5B6-49650CEC66C5@monkeypox.org> Message-ID: Try/catch does not seem the best way to do it, and unfortunately I don't have time now to look into the code. Temporary you may yet do this workaround and compile your own version, so unblock yourself until the fix is available. Regards, Konstantin Triger > -----Original Message----- > From: R. Tyler Ballance [mailto:tyler at monkeypox.org] > Sent: Monday, October 01, 2007 12:06 PM > To: Konstantin Triger > Cc: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] Replicating System.Web.Script.Serialization bugs > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Oct 1, 2007, at 1:42 AM, Konstantin Triger wrote: > > > Hey Tyler, > > > > If you need this urgently, please provide a fix. > > If not - it will be somewhere in my todo list and will be fixed in > > a couple of weeks. > > > Would you recommend just adding another if statement in: > > internal object ConvertToType (Type type, object obj) > > Or is the bug elsewhere? The best I could tell as far as a fix would > be would be to check if it's a Nullable type, and then try/catch a > convert recursing into ConvertToType and in the catch setting > hasValue = false, etc. > > If you can take the time to suggest a plan of action, I'd be more > than happy to fix, test and commit a patch for this, since it's > somewhat blocking me right now :) > > > Cheers > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > > iD8DBQFHAMahA2GmJ0VpG78RAj6DAJwNBqkPL85OBjufkZafa4v6/lW60wCgoiJT > DUyhiLCjc+xXrwQ6i8ouMcY= > =rs5n > -----END PGP SIGNATURE----- From adar.wesley at gmail.com Mon Oct 1 13:17:43 2007 From: adar.wesley at gmail.com (Adar Wesley) Date: Mon, 1 Oct 2007 19:17:43 +0200 Subject: [Mono-dev] Replicating System.Web.Script.Serialization bugs In-Reply-To: References: <68CC0483-21EF-4D9B-A52F-9FDB3D317A72@monkeypox.org> <3ec1038d0709250323t3886c646ldb8584f3872c947e@mail.gmail.com> <46FA0CC0.6030909@gmail.com> <6FA9886A-26CD-4FF9-84F4-8F6A17E37086@monkeypox.org> <5713635E-2036-4219-A5B6-49650CEC66C5@monkeypox.org> Message-ID: Hi Kosta and Tyler, Having worked on this code with Kosta and following this thread a couple of questions come to my mind. 1. Are there any other types that need special care, besides Nullable? How about generic types? As far as I remember, we don't have any tests with generics. Are we missing anything else? 2. I was trying to think of a good strategy for implementing this, and havn't made up my mind yet. I agree with Kosta that the try, catch approach is not the best way. I think something a bit more fine grained should be used. What would happen if the value is "xxx" and the type is "int?"? This should probably throw the error and not silently assign the null value. (Requires a test with MS code...) Just my two cents. --- Adar Wesley On 10/1/07, Konstantin Triger wrote: > > Try/catch does not seem the best way to do it, and unfortunately I don't > have time now to look into the code. > > Temporary you may yet do this workaround and compile your own version, so > unblock yourself until the fix is available. > > Regards, > Konstantin Triger > > > -----Original Message----- > > From: R. Tyler Ballance [mailto:tyler at monkeypox.org] > > Sent: Monday, October 01, 2007 12:06 PM > > To: Konstantin Triger > > Cc: mono-devel-list at lists.ximian.com > > Subject: Re: [Mono-dev] Replicating System.Web.Script.Serialization bugs > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > On Oct 1, 2007, at 1:42 AM, Konstantin Triger wrote: > > > > > Hey Tyler, > > > > > > If you need this urgently, please provide a fix. > > > If not - it will be somewhere in my todo list and will be fixed in > > > a couple of weeks. > > > > > > Would you recommend just adding another if statement in: > > > internal object ConvertToType (Type type, object obj) > > > > Or is the bug elsewhere? The best I could tell as far as a fix would > > be would be to check if it's a Nullable type, and then try/catch a > > convert recursing into ConvertToType and in the catch setting > > hasValue = false, etc. > > > > If you can take the time to suggest a plan of action, I'd be more > > than happy to fix, test and commit a patch for this, since it's > > somewhat blocking me right now :) > > > > > > Cheers > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.7 (Darwin) > > > > iD8DBQFHAMahA2GmJ0VpG78RAj6DAJwNBqkPL85OBjufkZafa4v6/lW60wCgoiJT > > DUyhiLCjc+xXrwQ6i8ouMcY= > > =rs5n > > -----END PGP SIGNATURE----- > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- --- Adar Wesley -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071001/ad739ca1/attachment.html From robertj at gmx.net Mon Oct 1 13:12:00 2007 From: robertj at gmx.net (Robert Jordan) Date: Mon, 01 Oct 2007 19:12:00 +0200 Subject: [Mono-dev] RFC on remoting security stuff In-Reply-To: <4700A91D.2090307@ximian.com> References: <4700A91D.2090307@ximian.com> Message-ID: Hi Atsushi, AtsushiEno wrote: > Hi, > > As part of filling .NET 2.0 API, I am wondering how and what we need to do > secure remoting support (introduced in 2.0), namely HttpChannel, TcpChannel > and IpcChannel. (I'd like to put my disclaimer - am far from familiar > with those > remoting stuff, so don't hit me if I am misunderstanding the entire bits ;-) > > It seems that secure remoting stuff sorta involves > WindowsImpersonationContext > which is based on authentication information which will be likely from > System.Net.CredentialCache.DefaultCredentials (if written in managed land). > > DefaultCredentials seems to require CAS (and some work, as it is > commented as "Need EnvironmentPermission implementation first"). So I guess > it is not likely possible to implement security support in the same > manner as > .NET does. > > So I'd like to hear you guys' ideas. Would we just leave them unimplemented, > or find some alternative security support, like using TLS to at least enable > encryption (and optionally integrity by some certificate configuration) ? > > (While we could implement NegotiateStream and hence secure connection itself > would not be an issue, am having problems to solve NTLM issue on my machine > and cannot implement it so far.) It is possible to implement Mono's secure remoting based on NegotiateStream, but we'd need something like SAMBA to handle the mutual authentication. For impersonation support, we'd need to "suid root" the application, which is a no-no at present. IMO, this would require a complete audit of all participating managed and unmanaged libs. That said, I think we should implement secure remoting on top of AuthenticatedStream (SslStream). This is the only way to make secure remoting really useful on Mono's main platform Unix. For MS.NET interoperability we could provide custom channels for MS.NET based on our channels. Robert From kostat at mainsoft.com Mon Oct 1 13:47:52 2007 From: kostat at mainsoft.com (Konstantin Triger) Date: Mon, 1 Oct 2007 10:47:52 -0700 Subject: [Mono-dev] Replicating System.Web.Script.Serialization bugs In-Reply-To: References: <68CC0483-21EF-4D9B-A52F-9FDB3D317A72@monkeypox.org> <3ec1038d0709250323t3886c646ldb8584f3872c947e@mail.gmail.com> <46FA0CC0.6030909@gmail.com> <6FA9886A-26CD-4FF9-84F4-8F6A17E37086@monkeypox.org> <5713635E-2036-4219-A5B6-49650CEC66C5@monkeypox.org> Message-ID: Hey Adar, It's nice to get your 2 cents :-) >1. Are there any other types that need special care, besides Nullable? How about generic types? > As far as I remember, we don't have any tests with generics. Are we missing anything else? Don't think, since this is a binary serialization. >2. I was trying to think of a good strategy for implementing this, and havn't made up my mind yet. > I agree with Kosta that the try, catch approach is not the best way. I think something a bit more fine grained > should be used. What would happen if the value is "xxx" and the type is "int?"? This should probably > throw the error and not silently assign the null value. (Requires a test with MS code...) That's what I understood Tyler did and got null... Do I understand correctly? Regards, Konstantin Triger ________________________________ From: Adar Wesley [mailto:adar.wesley at gmail.com] Sent: Monday, October 01, 2007 7:18 PM To: Konstantin Triger Cc: R. Tyler Ballance; mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] Replicating System.Web.Script.Serialization bugs Hi Kosta and Tyler, Having worked on this code with Kosta and following this thread a couple of questions come to my mind. Just my two cents. --- Adar Wesley On 10/1/07, Konstantin Triger wrote: Try/catch does not seem the best way to do it, and unfortunately I don't have time now to look into the code. Temporary you may yet do this workaround and compile your own version, so unblock yourself until the fix is available. Regards, Konstantin Triger > -----Original Message----- > From: R. Tyler Ballance [mailto: tyler at monkeypox.org] > Sent: Monday, October 01, 2007 12:06 PM > To: Konstantin Triger > Cc: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] Replicating System.Web.Script.Serialization bugs > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Oct 1, 2007, at 1:42 AM, Konstantin Triger wrote: > > > Hey Tyler, > > > > If you need this urgently, please provide a fix. > > If not - it will be somewhere in my todo list and will be fixed in > > a couple of weeks. > > > Would you recommend just adding another if statement in: > > internal object ConvertToType (Type type, object obj) > > Or is the bug elsewhere? The best I could tell as far as a fix would > be would be to check if it's a Nullable type, and then try/catch a > convert recursing into ConvertToType and in the catch setting > hasValue = false, etc. > > If you can take the time to suggest a plan of action, I'd be more > than happy to fix, test and commit a patch for this, since it's > somewhat blocking me right now :) > > > Cheers > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > > iD8DBQFHAMahA2GmJ0VpG78RAj6DAJwNBqkPL85OBjufkZafa4v6/lW60wCgoiJT > DUyhiLCjc+xXrwQ6i8ouMcY= > =rs5n > -----END PGP SIGNATURE----- _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- --- Adar Wesley -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071001/b3b492bc/attachment.html From tyler at monkeypox.org Mon Oct 1 14:20:40 2007 From: tyler at monkeypox.org (R. Tyler Ballance) Date: Mon, 1 Oct 2007 11:20:40 -0700 Subject: [Mono-dev] Replicating System.Web.Script.Serialization bugs In-Reply-To: References: <68CC0483-21EF-4D9B-A52F-9FDB3D317A72@monkeypox.org> <3ec1038d0709250323t3886c646ldb8584f3872c947e@mail.gmail.com> <46FA0CC0.6030909@gmail.com> <6FA9886A-26CD-4FF9-84F4-8F6A17E37086@monkeypox.org> <5713635E-2036-4219-A5B6-49650CEC66C5@monkeypox.org> Message-ID: <3F6109BC-86CC-4F18-A053-EC77EE83C9D7@monkeypox.org> On Oct 1, 2007, at 10:47 AM, Konstantin Triger wrote: > >2. I was trying to think of a good strategy for implementing this, > and havn't made up my mind yet. > > > I agree with Kosta that the try, catch approach is not the > best way. I think something a bit more fine grained > > > should be used. What would happen if the value is "xxx" and > the type is "int?"? This should probably > > > throw the error and not silently assign the null value. > (Requires a test with MS code...) > > > > That's what I understood Tyler did and got null? Do I understand > correctly? My experiments weren't with JSON that actually was a string (i.e. "xxx") being Convert.ToInt32()'d, it was the fact that most JSON API providers denote any empty value with an empty string (i.e. "") Which in our current serializer, does a check in Convert.ToInt32/Int64 such that str.Length > 0, and throws an exception, instead of handling the nullable type that I was passing it.. I'm not sure if the fix is in Convert.ChangeType to handle Nullable types properly, or if it's specific to System.Web.Script.Serialization. I didn't have the time to test this further. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071001/ba351256/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071001/ba351256/attachment.bin From bratsche at gnome.org Tue Oct 2 00:06:01 2007 From: bratsche at gnome.org (Cody Russell) Date: Mon, 1 Oct 2007 23:06:01 -0500 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1190385617.5494.4.camel@w00den-lappy> References: <46F3D4D8.2070904@gmail.com> Message-ID: <1191297961.6069.16.camel@scherzo> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071001/db29fdfd/attachment.pl From mbd at dbc.dk Tue Oct 2 03:26:22 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Tue, 2 Oct 2007 09:26:22 +0200 Subject: [Mono-dev] SVN does not compile Message-ID: <200710020926.22377.mbd@dbc.dk> Hi there Just a short message to let those responsible know, that svn has not compiled for about three days now. make[8]: Entering directory `/home/compile/Compile/Mono/mcs/class/System.Data' ../../jay/jay -ct < ../../jay/skeleton.cs Mono.Data.SqlExpressions/Parser.jay >Mono.Data.SqlExpressions/Parser.cs ../../jay/jay: 1 shift/reduce conflict. MONO_PATH="../../class/lib/default: $MONO_PATH" /home/compile/Compile/Mono/mono/runtime/mono-wrapper ../../class/lib/default/mcs.exe /codepage:65001 -d:NET_1_1 -d:ONLY_1_1 -debug /noconfig -nowarn:649 -nowarn:169 -nowarn:219 -nowarn:168 -nowarn:1595 -unsafe -r:mscorlib.dll -r:../../class/lib/default/System.dll -r:System.Xml.dll -r:System.EnterpriseServices.dll -r:Mono.Data.Tds.dll -target:library -out:../../class/lib/default/System.Data.dll Mono.Data.SqlExpressions/Parser.cs @System.Data.dll.sources System.Data.Odbc/OdbcTransaction.cs(54,1): error CS1002: Expecting `;' System.Data.Odbc/OdbcTransaction.cs(56,1): error CS1002: Expecting `;' System.Data.Odbc/OdbcTransaction.cs(58,1): error CS1002: Expecting `;' System.Data.Odbc/OdbcTransaction.cs(88,1): error CS1518: Expected `class', `delegate', `enum', `interface', or `struct' Compilation failed: 4 error(s), 0 warnings Regards, Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 From stapostol at gmail.com Tue Oct 2 06:28:33 2007 From: stapostol at gmail.com (StApostol) Date: Tue, 2 Oct 2007 13:28:33 +0300 Subject: [Mono-dev] C# pointer dereference NRE bug Message-ID: <15aef24e0710020328h394f1602x53de0d6d53ab6702@mail.gmail.com> The following code runs correctly under .Net but produces an NRE under Mono 1.2.5 (both mcs and gmcs): using System; namespace Bug { unsafe class Demo { static void Foo(int[] data) { fixed (int* data_ptr = data) { /* Do something */ } } public static void Main() { Foo(null); // Passing null causes the NRE } } } Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object at Bug.Demo.Main () [0x00000] in /home/vm/Desktop/mono_bugs/unsafe.cs:9 Can anyone confirm? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071002/1e850b98/attachment.html From jb at nurv.fr Tue Oct 2 06:39:23 2007 From: jb at nurv.fr (Jb Evain) Date: Tue, 2 Oct 2007 12:39:23 +0200 Subject: [Mono-dev] C# pointer dereference NRE bug In-Reply-To: <15aef24e0710020328h394f1602x53de0d6d53ab6702@mail.gmail.com> References: <15aef24e0710020328h394f1602x53de0d6d53ab6702@mail.gmail.com> Message-ID: <69f7d8470710020339r1e6e7bf0p164e17228e0f0e7f@mail.gmail.com> On 10/2/07, StApostol wrote: > The following code runs correctly under .Net but produces an NRE under Mono > 1.2.5 (both mcs and gmcs): It's a mcs/gmcs bug. The csc compiled version executes fine on Mono 1.2.5, while the mcs compiled version fails with the same exception on .net. Could you please file a bug in bugzilla? Thanks, > using System; > > namespace Bug { > unsafe class Demo { > static void Foo(int[] data) { > fixed (int* data_ptr = data) { /* Do something */ } > } > public static void Main() { > Foo(null); // Passing null causes the NRE > } > } > } > > > > > Unhandled Exception: System.NullReferenceException: Object reference not set > to an instance of an object > at Bug.Demo.Main () [0x00000] in > /home/vm/Desktop/mono_bugs/unsafe.cs:9 > > > > Can anyone confirm? > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Jb Evain From stapostol at gmail.com Tue Oct 2 07:12:39 2007 From: stapostol at gmail.com (StApostol) Date: Tue, 2 Oct 2007 14:12:39 +0300 Subject: [Mono-dev] C# pointer dereference NRE bug In-Reply-To: <15aef24e0710020411uec19426qca1123cfcb59a855@mail.gmail.com> References: <15aef24e0710020328h394f1602x53de0d6d53ab6702@mail.gmail.com> <69f7d8470710020339r1e6e7bf0p164e17228e0f0e7f@mail.gmail.com> <15aef24e0710020348h53a53949q66baa42d14a4977e@mail.gmail.com> <15aef24e0710020411uec19426qca1123cfcb59a855@mail.gmail.com> Message-ID: <15aef24e0710020412j7c21558j8890bd9606a21bca@mail.gmail.com> Filed as bug #330069 (https://bugzilla.novell.com/show_bug.cgi?id=330069) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071002/d32272bc/attachment.html From miguel at novell.com Tue Oct 2 13:30:52 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 02 Oct 2007 13:30:52 -0400 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191297961.6069.16.camel@scherzo> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> Message-ID: <1191346252.4085.71.camel@erandi.dom> Hey Cody, > I just want to quickly point out that we have made numerous improvements > to the look and functionality of gtk+ on Win32 during the 2.10-2.12 > cycle, and we are still working to further improve it. If there are any > particular issues that are blockers for you in gtk+, please file bugs on > bugzilla.gnome.org and CC me, I would really appreciate it and hopefully > we can get it fixed. You guys are maintaining the Gtk# installer for Windows, right? I wonder if we could merge the efforts? From brad at getcoded.net Tue Oct 2 14:42:12 2007 From: brad at getcoded.net (Brad Taylor) Date: Tue, 02 Oct 2007 11:42:12 -0700 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191346252.4085.71.camel@erandi.dom> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> <1191346252.4085.71.camel@erandi.dom> Message-ID: <1191350532.8413.15.camel@nightcrawler> Miguel, > You guys are maintaining the Gtk# installer for Windows, right? Yes -- I maintain the installer, and Cody does all the bug squashing with gtk+ and win32. (Full Disclosure: We're both employed by Medsphere) > I wonder if we could merge the efforts? Are you talking about merging efforts with Wade's Gtk# + Mono Combined installer? We had discussed this about a year ago and decided that we had different interests, since we were focused on using MS .NET on Windows, and the Mono team wanted to (rightfully so) focus on Mono on Windows. That being said, I'd love to see our efforts combined into one Gtk# installer to rule them all. Maybe it would be appropriate to take this offline and discuss it when Cody and I are in Cambridge this Friday? Cheers, -Brad From miguel at novell.com Tue Oct 2 16:56:20 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 02 Oct 2007 16:56:20 -0400 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191350532.8413.15.camel@nightcrawler> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> <1191346252.4085.71.camel@erandi.dom> <1191350532.8413.15.camel@nightcrawler> Message-ID: <1191358580.11169.21.camel@erandi.dom> Hello, > We had discussed this about a year ago and decided that we had different > interests, since we were focused on using MS .NET on Windows, and the > Mono team wanted to (rightfully so) focus on Mono on Windows. Are the binaries for .NET and Mono any different, other than the GAC install directory? Do you think it would be possible to have a single installer that could install the same assemblies into both GACs? > That being said, I'd love to see our efforts combined into one Gtk# > installer to rule them all. Maybe it would be appropriate to take this > offline and discuss it when Cody and I are in Cambridge this Friday? > > Cheers, > > -Brad > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From wberrier at novell.com Tue Oct 2 16:58:33 2007 From: wberrier at novell.com (Wade Berrier) Date: Tue, 02 Oct 2007 14:58:33 -0600 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191358580.11169.21.camel@erandi.dom> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> <1191346252.4085.71.camel@erandi.dom> <1191350532.8413.15.camel@nightcrawler> <1191358580.11169.21.camel@erandi.dom> Message-ID: <1191358713.4626.7.camel@wberrier> On Tue, 2007-10-02 at 16:56 -0400, Miguel de Icaza wrote: > Hello, > > > We had discussed this about a year ago and decided that we had different > > interests, since we were focused on using MS .NET on Windows, and the > > Mono team wanted to (rightfully so) focus on Mono on Windows. > > Are the binaries for .NET and Mono any different, other than the GAC > install directory? I build gtk# on windows with vs .net for the sole purpose of eventually shipping gtk# for ms .net. I think it's ok to have separate installers, but we may want to reconsider the overall picture if we move everything to .msi. (Ie: maybe have an .msi installer for gtk+, or use someone elses, one for core mono, another for gtk#, etc...) Wade > > Do you think it would be possible to have a single installer that could > install the same assemblies into both GACs? > > > > That being said, I'd love to see our efforts combined into one Gtk# > > installer to rule them all. Maybe it would be appropriate to take this > > offline and discuss it when Cody and I are in Cambridge this Friday? > > > > Cheers, > > > > -Brad > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071002/02ea7e50/attachment.bin From brad at getcoded.net Tue Oct 2 17:15:45 2007 From: brad at getcoded.net (Brad Taylor) Date: Tue, 02 Oct 2007 14:15:45 -0700 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191358713.4626.7.camel@wberrier> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> <1191346252.4085.71.camel@erandi.dom> <1191350532.8413.15.camel@nightcrawler> <1191358580.11169.21.camel@erandi.dom> <1191358713.4626.7.camel@wberrier> Message-ID: <1191359745.8413.25.camel@nightcrawler> Hey, > > > We had discussed this about a year ago and decided that we had different > > > interests, since we were focused on using MS .NET on Windows, and the > > > Mono team wanted to (rightfully so) focus on Mono on Windows. > > > > Are the binaries for .NET and Mono any different, other than the GAC > > install directory? No, they're identical. > I build gtk# on windows with vs .net for the sole purpose of eventually > shipping gtk# for ms .net. Ah, we're building gtk# under cygwin (but with MS .NET). > I think it's ok to have separate installers, but we may want to > reconsider the overall picture if we move everything to .msi. > (Ie: maybe have an .msi installer for gtk+, or use someone elses, one > for core mono, another for gtk#, etc...) Yeah, I am intrigued at the possibility of using MSI merge modules so that we could have a Gtk+ MSI merge module, a Gtk# merge module, and one for Mono, and those could be removed/included at will, but I remember hearing (I think from Paco) that it wasn't possible because of issues with GACing. It's definitely something we can (and probably should) look into. > > Do you think it would be possible to have a single installer that > could > > install the same assemblies into both GACs? Yes, I think this is possible, however it would force you guys to ship Mono in a separate installer. While we're chatting, if anyone is interested in getting their hands on the source for our installers, they're available on our SourceForge.net page[1]. Cheers, -Brad -- [1] http://openvista.svn.sourceforge.net/viewvc/openvista/gtksharp-win32-installer/ From meebey at meebey.net Tue Oct 2 17:42:31 2007 From: meebey at meebey.net (Mirco Bauer) Date: Tue, 02 Oct 2007 23:42:31 +0200 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191350532.8413.15.camel@nightcrawler> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> <1191346252.4085.71.camel@erandi.dom> <1191350532.8413.15.camel@nightcrawler> Message-ID: <1191361351.7193.6.camel@redbull.qnetp.net> On Tue, 2007-10-02 at 11:42 -0700, Brad Taylor wrote: > Miguel, > > > You guys are maintaining the Gtk# installer for Windows, right? > > Yes -- I maintain the installer, and Cody does all the bug squashing > with gtk+ and win32. (Full Disclosure: We're both employed by > Medsphere) Ah, this is good to know who maintains that installer. I tried the 2.10 installer once and ran into real problems and could not find the correct contact for it. So here the problem I encountered (I have no idea if that applies to the current installer): The 2.10 installer seems to miss policy files for 2.4, IIRC only 2.6 and 2.8 where present. This made it a no go for us, as all applications where referenced with 2.4 at that time. So then we uninstalled gtk# 2.10 which didn't remove all installed policy files. That made it impossible to get paco's gtk# 2.4 or gtk# 2.8 working again with those stalled policy files. I could not find a way to remove the policy files by hand from the GAC, so we used windows recovery to let the gtk# 2.10 install "unhappen". But now I would reconsider testing the gtk# 2.10 installer :) -- Regards, Mirco 'meebey' Bauer PGP-Key ID: 0xEEF946C8 FOSS Developer meebey at meebey.net http://www.meebey.net/ PEAR Developer meebey at php.net http://pear.php.net/ Debian Developer meebey at debian.org http://www.debian.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071002/e1e2a1b5/attachment.bin From meebey at meebey.net Tue Oct 2 17:50:38 2007 From: meebey at meebey.net (Mirco Bauer) Date: Tue, 02 Oct 2007 23:50:38 +0200 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <46F78002.50906@gmail.com> References: <46F3D4D8.2070904@gmail.com> <1190385617.5494.4.camel@w00den-lappy> <46F3DA0C.10609@gmail.com> <1190457625.6041.11.camel@redbull.qnetp.net> <46F78002.50906@gmail.com> Message-ID: <1191361838.7193.15.camel@redbull.qnetp.net> [please CC me, I am subcribe to the list but I miss replies very fast] On Mon, 2007-09-24 at 11:14 +0200, "Andr?s G. Aragoneses [ knocte ]" wrote: > We've also researched about the best portable I18N method, and we have > discarded Mono.Posix until bug > https://bugzilla.novell.com/show_bug.cgi?id=MONO82850 is closed > (actually not a bug, but a RFE). For deploying applications that use GTK# + gettext this is not a problem. You only need to ship Mono.Posix.dll + libMonoPosixHelper.dll with your application (like inside you application directory). But for development, yes gettext is not the simplest way as you need to generate and update the pot files which AFAIK needs the gettext/intl tools from cygwin. Our company develops under Linux so I have no experience on developing gettext enabled applications on windows. There are for sure PO editors available for windows, but thats only one part of the needed tools. Regarding your feature request, of a fully managed gettext implementation for Mono, that would only work partly if you use glade, as glade will always use the unmanaged version. -- Regards, Mirco 'meebey' Bauer PGP-Key ID: 0xEEF946C8 FOSS Developer meebey at meebey.net http://www.meebey.net/ PEAR Developer meebey at php.net http://pear.php.net/ Debian Developer meebey at debian.org http://www.debian.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071002/0821f117/attachment.bin From miguel at novell.com Tue Oct 2 18:26:34 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 02 Oct 2007 18:26:34 -0400 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191359745.8413.25.camel@nightcrawler> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> <1191346252.4085.71.camel@erandi.dom> <1191350532.8413.15.camel@nightcrawler> <1191358580.11169.21.camel@erandi.dom> <1191358713.4626.7.camel@wberrier> <1191359745.8413.25.camel@nightcrawler> Message-ID: <1191363994.11169.41.camel@erandi.dom> > Yes, I think this is possible, however it would force you guys to ship > Mono in a separate installer. I think we can do that; If we can do installers with dependencies (if we move to MSI) then we can just have one that has everything, right? > While we're chatting, if anyone is interested in getting their hands on > the source for our installers, they're available on our SourceForge.net > page[1]. > > Cheers, > > -Brad > > -- > [1] > http://openvista.svn.sourceforge.net/viewvc/openvista/gtksharp-win32-installer/ > > > From brad at getcoded.net Tue Oct 2 18:25:10 2007 From: brad at getcoded.net (Brad Taylor) Date: Tue, 02 Oct 2007 15:25:10 -0700 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191361351.7193.6.camel@redbull.qnetp.net> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> <1191346252.4085.71.camel@erandi.dom> <1191350532.8413.15.camel@nightcrawler> <1191361351.7193.6.camel@redbull.qnetp.net> Message-ID: <1191363910.8413.34.camel@nightcrawler> Hey Mirco, > Ah, this is good to know who maintains that installer. I tried the 2.10 > installer once and ran into real problems and could not find the correct > contact for it. We're currently trying to track down some crashers we're seeing with PerformQueuedUnrefs () in Gtk# 2.10.2 with TreeModelSort, so I wouldn't recommend using the 2.10 series on Windows at this point. Our application is running fine with our 2.8 series of installers though. > So here the problem I encountered (I have no idea if that applies to the > current installer): > The 2.10 installer seems to miss policy files for 2.4, IIRC only 2.6 and > 2.8 where present. This made it a no go for us, as all applications > where referenced with 2.4 at that time. We've never provided policy files for 2.4 since it seemed old enough to not be necessary, but if you'd like, I'd be happy to add those in the next version we release. > So then we uninstalled gtk# 2.10 which didn't remove all installed > policy files. That made it impossible to get paco's gtk# 2.4 or gtk# 2.8 > working again with those stalled policy files. I could not find a way to > remove the policy files by hand from the GAC, so we used windows > recovery to let the gtk# 2.10 install "unhappen". In the early Gtk# 2.10 transition, I accidentally forgot to ungac policy dlls, but as of 2.10.1-1, you shouldn't be seeing any problems. As usual, if you have any specific issues with installers, please direct them to me, and I'll help you out. > But now I would reconsider testing the gtk# 2.10 installer :) I really wouldn't recommend it at this point due to the bug that we're seeing. However, it may just be our application doing something naughty. Cheers, -Brad From miguel at novell.com Tue Oct 2 18:42:03 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 02 Oct 2007 18:42:03 -0400 Subject: [Mono-dev] gettext and Gtk# In-Reply-To: <1191361838.7193.15.camel@redbull.qnetp.net> References: <46F3D4D8.2070904@gmail.com> <1190385617.5494.4.camel@w00den-lappy> <46F3DA0C.10609@gmail.com> <1190457625.6041.11.camel@redbull.qnetp.net> <46F78002.50906@gmail.com> <1191361838.7193.15.camel@redbull.qnetp.net> Message-ID: <1191364923.11169.50.camel@erandi.dom> > Regarding your feature request, of a fully managed gettext > implementation for Mono, that would only work partly if you use glade, > as glade will always use the unmanaged version. We could always change that. From dkosawa at gmail.com Tue Oct 2 20:50:42 2007 From: dkosawa at gmail.com (Dan Osawa) Date: Tue, 2 Oct 2007 17:50:42 -0700 Subject: [Mono-dev] Cross Compile for Embedded Linux PPC Message-ID: <4e2ed8510710021750p43bdc422qb568cdb4f0694a8e@mail.gmail.com> Hello, I'm trying to build a very minimal Mono (non-gui apps) for an embedded PPC Linux system. I would like to cross compile it on my IA32 Fedora Core system, which has the cross compiler tools located under /opt/Arabella. Are there ./configure paramters that I can use to achieve this? Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071002/67cf7399/attachment.html From alp at atoker.com Tue Oct 2 21:16:11 2007 From: alp at atoker.com (Alp Toker) Date: Wed, 03 Oct 2007 02:16:11 +0100 Subject: [Mono-dev] gnome-keyring-sharp due for the GAC Message-ID: <4702ED5B.9070705@atoker.com> This evening I committed a patch to make Gnome.Keyring, the managed Gnome keyring client implementation written by Gonzalo, installable to the GAC. The patch is based on what's already packaged by OpenSUSE, who have been pushing the envelope to make this library fully installable. The Debian guys were not comfortable applying such a patch, so they've waited patiently for us to provide an official installable release. This is the last chance to make API-breaking changes or even obsoletions before we stabilize and make the release, so application authors and packagers should speak up as soon as possible if they are uncomfortable with any aspect of the library. At this stage, only critical changes will realistically be accepted. We have been cautious with Gnome.Keyring because it contains security-related code, and I would have been happier if we could have done a full audit and feature comparison with the unmanaged Gnome keyring client library, but at this point it works, is tried and tested so we might as well go ahead and make the release. From miguel at novell.com Tue Oct 2 23:50:55 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 02 Oct 2007 23:50:55 -0400 Subject: [Mono-dev] gnome-keyring-sharp due for the GAC In-Reply-To: <4702ED5B.9070705@atoker.com> References: <4702ED5B.9070705@atoker.com> Message-ID: <1191383455.4160.8.camel@erandi.dom> > This is the last chance to make API-breaking changes or even obsoletions > before we stabilize and make the release, so application authors and > packagers should speak up as soon as possible if they are uncomfortable > with any aspect of the library. At this stage, only critical changes > will realistically be accepted. Do we know which users are using gnome-keyring-sharp these days? It might be worth contacting them. From anagappan at novell.com Wed Oct 3 02:57:24 2007 From: anagappan at novell.com (Nagappan) Date: Wed, 03 Oct 2007 12:27:24 +0530 Subject: [Mono-dev] SVN does not compile In-Reply-To: <200710020926.22377.mbd@dbc.dk> References: <200710020926.22377.mbd@dbc.dk> Message-ID: <47033D54.1000509@novell.com> Hi, Not sure about yesterday's update, but today I tried and it worked fine for me, after SVN update. My previous check out was on Friday morning IST and just sometime back I updated once again. No issue on my box at-least. Thanks Nagappan Mads Bondo Dydensborg wrote: > Hi there > > Just a short message to let those responsible know, that svn has not compiled > for about three days now. > > make[8]: Entering directory `/home/compile/Compile/Mono/mcs/class/System.Data' > ../../jay/jay -ct < ../../jay/skeleton.cs Mono.Data.SqlExpressions/Parser.jay > >> Mono.Data.SqlExpressions/Parser.cs >> > ../../jay/jay: 1 shift/reduce conflict. > MONO_PATH="../../class/lib/default: > $MONO_PATH" /home/compile/Compile/Mono/mono/runtime/mono-wrapper ../../class/lib/default/mcs.exe /codepage:65001 -d:NET_1_1 -d:ONLY_1_1 -debug /noconfig -nowarn:649 -nowarn:169 -nowarn:219 -nowarn:168 -nowarn:1595 -unsafe -r:mscorlib.dll -r:../../class/lib/default/System.dll -r:System.Xml.dll -r:System.EnterpriseServices.dll -r:Mono.Data.Tds.dll -target:library -out:../../class/lib/default/System.Data.dll > Mono.Data.SqlExpressions/Parser.cs @System.Data.dll.sources > System.Data.Odbc/OdbcTransaction.cs(54,1): error CS1002: Expecting `;' > System.Data.Odbc/OdbcTransaction.cs(56,1): error CS1002: Expecting `;' > System.Data.Odbc/OdbcTransaction.cs(58,1): error CS1002: Expecting `;' > System.Data.Odbc/OdbcTransaction.cs(88,1): error CS1518: Expected `class', > `delegate', `enum', `interface', or `struct' > Compilation failed: 4 error(s), 0 warnings > > Regards, > > Mads > > -- Nagappan A Novell Software Development (I) Pvt. Ltd. Linux Desktop Testing Project - http://ldtp.freedesktop.org http://nagappanal.blogspot.com/ Novell, Inc. SUSE? Linux Enterprise 10 Your Linux is ready? http://www.novell.com/linux From aras at unity3d.com Wed Oct 3 05:02:06 2007 From: aras at unity3d.com (Aras Pranckevicius) Date: Wed, 3 Oct 2007 11:02:06 +0200 Subject: [Mono-dev] Incorrect trunc() definition for MSVC in mono-compiler.h Message-ID: Hi, mono/utils/mono-compiler.h has incorrect trunc() definition for Visual Studio, causing overflow exceptions to be thrown from int->float conversions with negative inputs. Line 88 is: #define trunc(x) floor((x)) when it should be something like: #define trunc(x) (((x) < 0) ? ceil((x)) : floor((x))) -- Aras Pranckevicius work: http://unity3d.com home: http://aras-p.info From andreas.faerber at web.de Wed Oct 3 05:03:31 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Wed, 3 Oct 2007 11:03:31 +0200 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191363910.8413.34.camel@nightcrawler> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> <1191346252.4085.71.camel@erandi.dom> <1191350532.8413.15.camel@nightcrawler> <1191361351.7193.6.camel@redbull.qnetp.net> <1191363910.8413.34.camel@nightcrawler> Message-ID: <758D3C51-92E5-404C-AD61-F4D8F8AEA9FE@web.de> Am 03.10.2007 um 00:25 schrieb Brad Taylor: >> The 2.10 installer seems to miss policy files for 2.4, IIRC only >> 2.6 and >> 2.8 where present. This made it a no go for us, as all applications >> where referenced with 2.4 at that time. > > We've never provided policy files for 2.4 since it seemed old > enough to > not be necessary, but if you'd like, I'd be happy to add those in the > next version we release. Solaris 10 uses GNOME 2.6, requiring the use of Gtk# 2.4. Andreas From meebey at meebey.net Wed Oct 3 05:44:12 2007 From: meebey at meebey.net (Mirco Bauer) Date: Wed, 03 Oct 2007 11:44:12 +0200 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191363910.8413.34.camel@nightcrawler> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> <1191346252.4085.71.camel@erandi.dom> <1191350532.8413.15.camel@nightcrawler> <1191361351.7193.6.camel@redbull.qnetp.net> <1191363910.8413.34.camel@nightcrawler> Message-ID: <1191404652.7206.5.camel@redbull.qnetp.net> Hi Brad, On Tue, 2007-10-02 at 15:25 -0700, Brad Taylor wrote: > We're currently trying to track down some crashers we're seeing with > PerformQueuedUnrefs () in Gtk# 2.10.2 with TreeModelSort, so I wouldn't > recommend using the 2.10 series on Windows at this point. Our > application is running fine with our 2.8 series of installers though. Ok, I will keep that in mind when testing the gtk# 2.10 installers again. > We've never provided policy files for 2.4 since it seemed old enough to > not be necessary, but if you'd like, I'd be happy to add those in the > next version we release. So that was intended... I agree that 2.4 is old but there are at least 2 reasons still to ship it: a) official gtk# does, why break compatibility with it? b) the gtk# installer from Paco was long time gtk# 2.4 only, so anyone who wanted to transition to gtk# 2.8 could not just replace the installer but also needs to rebuild all assemblies. > In the early Gtk# 2.10 transition, I accidentally forgot to ungac policy > dlls, but as of 2.10.1-1, you shouldn't be seeing any problems. As > usual, if you have any specific issues with installers, please direct > them to me, and I'll help you out. Ok, thanks :) > > > But now I would reconsider testing the gtk# 2.10 installer :) > > I really wouldn't recommend it at this point due to the bug that we're > seeing. However, it may just be our application doing something > naughty. Will see how our applications work. I will give feedback when I tested it. -- Regards, Mirco 'meebey' Bauer PGP-Key ID: 0xEEF946C8 FOSS Developer meebey at meebey.net http://www.meebey.net/ PEAR Developer meebey at php.net http://pear.php.net/ Debian Developer meebey at debian.org http://www.debian.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071003/863a45b1/attachment.bin From meebey at meebey.net Wed Oct 3 05:50:45 2007 From: meebey at meebey.net (Mirco Bauer) Date: Wed, 03 Oct 2007 11:50:45 +0200 Subject: [Mono-dev] gettext and Gtk# In-Reply-To: <1191364923.11169.50.camel@erandi.dom> References: <46F3D4D8.2070904@gmail.com> <1190385617.5494.4.camel@w00den-lappy> <46F3DA0C.10609@gmail.com> <1190457625.6041.11.camel@redbull.qnetp.net> <46F78002.50906@gmail.com> <1191361838.7193.15.camel@redbull.qnetp.net> <1191364923.11169.50.camel@erandi.dom> Message-ID: <1191405045.7206.13.camel@redbull.qnetp.net> On Tue, 2007-10-02 at 18:42 -0400, Miguel de Icaza wrote: > > Regarding your feature request, of a fully managed gettext > > implementation for Mono, that would only work partly if you use glade, > > as glade will always use the unmanaged version. > > We could always change that. You can? glade# calls libglade.so to construct/build/instance the widgets, and a textdomain is passed with that. So libglade.so does the translation calls (to libc6 on *nix and libintl on win32 AFAIK). Btw, there is an fully managed I18N implementation available from the GNU gettext project, but it's not supporting the traditional .mo files but using resource assemblies instead, and that doesn't work with glade's builtin gettext support as that only understands .mo files. IMHO a bit ironic that Mono(.Posix.dll) supports the real gettext (.mo) while GNU gettext itself doesn't but uses the .NET approach instead :-P -- Regards, Mirco 'meebey' Bauer PGP-Key ID: 0xEEF946C8 FOSS Developer meebey at meebey.net http://www.meebey.net/ PEAR Developer meebey at php.net http://pear.php.net/ Debian Developer meebey at debian.org http://www.debian.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071003/fe795793/attachment.bin From m.j.hutchinson at gmail.com Wed Oct 3 06:02:42 2007 From: m.j.hutchinson at gmail.com (Michael Hutchinson) Date: Wed, 3 Oct 2007 11:02:42 +0100 Subject: [Mono-dev] gnome-keyring-sharp due for the GAC In-Reply-To: <1191383455.4160.8.camel@erandi.dom> References: <4702ED5B.9070705@atoker.com> <1191383455.4160.8.camel@erandi.dom> Message-ID: On 10/3/07, Miguel de Icaza wrote: > > > This is the last chance to make API-breaking changes or even obsoletions > > before we stabilize and make the release, so application authors and > > packagers should speak up as soon as possible if they are uncomfortable > > with any aspect of the library. At this stage, only critical changes > > will realistically be accepted. > > Do we know which users are using gnome-keyring-sharp these days? > > It might be worth contacting them. F-spot does. Also, I know someone is working on a patch to use it in MD for SVN passwords, and has expressed satisfaction with the ease-of-use of the API :) -- Michael Hutchinson http://mjhutchinson.com From atsushi at ximian.com Wed Oct 3 06:24:08 2007 From: atsushi at ximian.com (Atsushi Eno) Date: Wed, 03 Oct 2007 19:24:08 +0900 Subject: [Mono-dev] System.Messaging: Anyone currently working on this? In-Reply-To: References: <67c29c7c0709290524s7cdc637cqd33a391fdd21901f@mail.gmail.com> Message-ID: <47036DC8.50503@ximian.com> Hi, It is great that you are interested in hacking this area :-) You can start either based on unfinished SoC effort or from scratch (as you wrote, the existing code is not advanced much). Also, since System.Messaging.dll is not part of our supported component, you can directly work with mono svn. IMO even trunk is still fine (I'll take care of the dll's metadata-wise mismatch) but you might also want to create your own branch. (I noticed that the latest data loss disaster at the hosting service I used also hit my code. So the links at the wiki page results in 404, but I could restore only the patch from archive.org and it actually lacked OpenWireBridge.cs, though it should not be hard to rewrite from scratch.) Thanks! Atsushi Eno M. David Peterson wrote: > On 9/29/07, *M. David Peterson* > wrote: > > I'll run a diff against the two of them and see what I come up with. > > > Doesn't look like much more than the import of the necessary > ActiveMQ/OpenWire.NET projects specified in Eno's write up. > > http://monoport.com/4842 > > If nothing else the GSOC repository seems like a decent place to start > compiling and running some tests, so I guess I'll start there. > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 > | http://dev.aol.com/blog/3155 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From js at hotfeet.ch Wed Oct 3 09:16:10 2007 From: js at hotfeet.ch (Juraj Skripsky) Date: Wed, 03 Oct 2007 15:16:10 +0200 Subject: [Mono-dev] Cosmetic patch to your latest change Message-ID: <1191417370.3304.12.camel@leonardo.hotfeet.ch> Hi Marek, I've just seen your latest commit and would like to propose a cosmetic little change. The patch puts the struct ModMonoConfig in charge to tracking "Changed". May I commit? - Juraj -------------- next part -------------- A non-text attachment was scrubbed... Name: ModMonoRequest.patch Type: text/x-patch Size: 952 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071003/680d0c8a/attachment.bin From grendello at gmail.com Wed Oct 3 09:44:28 2007 From: grendello at gmail.com (Marek Habersack) Date: Wed, 3 Oct 2007 15:44:28 +0200 Subject: [Mono-dev] Cosmetic patch to your latest change In-Reply-To: <1191417370.3304.12.camel@leonardo.hotfeet.ch> References: <1191417370.3304.12.camel@leonardo.hotfeet.ch> Message-ID: <20071003154428.721f7e7d@gmail.com> On Wed, 03 Oct 2007 15:16:10 +0200, Juraj Skripsky scribbled: > Hi Marek, Hey Juraj, > > I've just seen your latest commit and would like to propose a cosmetic > little change. > > The patch puts the struct ModMonoConfig in charge to tracking "Changed". > May I commit? Yep, please do :) marek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071003/791aacc6/attachment.bin From anagappan at novell.com Wed Oct 3 11:29:48 2007 From: anagappan at novell.com (A Nagappan) Date: Wed, 03 Oct 2007 09:29:48 -0600 Subject: [Mono-dev] [PATCH] Mono.Data.SqlExpressions improvements Message-ID: <470402C4020000440000D0C1@lucius.provo.novell.com> Hi, Guess this patch is already checked in ? Thanks Nagappan -- Nagappan A Linux Desktop Testing Project - http://ldtp.freedesktop.org http://nagappanal.blogspot.com Novell, Inc. SUSE? Linux Enterprise 10 Your Linux is ready? http://www.novell.com/linux >>> Joel Reed 10/01/07 8:11 AM >>> I've done a bit more hacking on System.Data - Mono.Data.SqlExpressions in order to fix a previously reported issue with IIF: http://www.nabble.com/IIF-Bug-in-Mono.Data.SqlExpressions-Parser.jay-t4513001.html The attached patch adds 3 new testcases and fixes the following bugs: # IIF: Accept SingleColumnValues and Literals for condition # SUBSTRING: Accept arithmetic expressions for start, and length parameters # Removed last shift/reduce conflict # Fix obvious bug in "ArithExpr NOT LIKE StringLiteral" rule I'd like to apply this patch. Please let me know if you see any issues with it. jr From joelwreed at gmail.com Wed Oct 3 13:04:15 2007 From: joelwreed at gmail.com (Joel Reed) Date: Wed, 3 Oct 2007 13:04:15 -0400 Subject: [Mono-dev] [PATCH] Mono.Data.SqlExpressions improvements In-Reply-To: <470402C4020000440000D0C1@lucius.provo.novell.com> References: <470402C4020000440000D0C1@lucius.provo.novell.com> Message-ID: <20071003170414.GA3732@localdomain> On Wed, Oct 03, 2007 at 09:29:48AM -0600, A Nagappan wrote: > Hi, > > Guess this patch is already checked in ? Yes. Any concerns? Btw, if there are any guidelines like: "wait X number of days" before committing a posted patch I'll happily follow them. Thanks, jr > > Thanks > Nagappan > > -- > Nagappan A > Linux Desktop Testing Project - http://ldtp.freedesktop.org > http://nagappanal.blogspot.com > > Novell, Inc. > SUSE? Linux Enterprise 10 > Your Linux is ready? > http://www.novell.com/linux > > > > >>> Joel Reed 10/01/07 8:11 AM >>> > I've done a bit more hacking on System.Data - Mono.Data.SqlExpressions > in order to fix a previously reported issue with IIF: > > http://www.nabble.com/IIF-Bug-in-Mono.Data.SqlExpressions-Parser.jay-t4513001.html > > The attached patch adds 3 new testcases and fixes the following bugs: > > # IIF: Accept SingleColumnValues and Literals for condition > # SUBSTRING: Accept arithmetic expressions for start, and length > parameters > # Removed last shift/reduce conflict > # Fix obvious bug in "ArithExpr NOT LIKE StringLiteral" rule > > I'd like to apply this patch. Please let me know if you see any > issues with it. > > jr From miguel at novell.com Wed Oct 3 13:46:11 2007 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 03 Oct 2007 13:46:11 -0400 Subject: [Mono-dev] Incorrect trunc() definition for MSVC in mono-compiler.h In-Reply-To: References: Message-ID: <1191433571.4160.106.camel@erandi.dom> Hello, Thanks, I have commited a patch. > Hi, > > mono/utils/mono-compiler.h has incorrect trunc() definition for Visual > Studio, causing overflow exceptions to be thrown from int->float > conversions with negative inputs. > > Line 88 is: > #define trunc(x) floor((x)) > when it should be something like: > #define trunc(x) (((x) < 0) ? ceil((x)) : floor((x))) > From mail at tinco.nl Wed Oct 3 18:53:31 2007 From: mail at tinco.nl (Tinco Andringa) Date: Thu, 4 Oct 2007 00:53:31 +0200 Subject: [Mono-dev] .net library shared source In-Reply-To: <1191433571.4160.106.camel@erandi.dom> References: <1191433571.4160.106.camel@erandi.dom> Message-ID: Hey guys, Have you read this? http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx How will this affect the mono project? Will we able to use it to make the framework match more to microsoft's or is it information we already have (from the spec)? > From: miguel at novell.com> To: aras at unity3d.com> Date: Wed, 3 Oct 2007 13:46:11 -0400> CC: mono-devel-list at lists.ximian.com> Subject: Re: [Mono-dev] Incorrect trunc() definition for MSVC in mono-compiler.h> > Hello,> > Thanks, I have commited a patch.> > > Hi,> > > > mono/utils/mono-compiler.h has incorrect trunc() definition for Visual> > Studio, causing overflow exceptions to be thrown from int->float> > conversions with negative inputs.> > > > Line 88 is:> > #define trunc(x) floor((x))> > when it should be something like:> > #define trunc(x) (((x) < 0) ? ceil((x)) : floor((x)))> > > _______________________________________________> Mono-devel-list mailing list> Mono-devel-list at lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-devel-list _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071004/ae21f551/attachment.html From joncham at gmail.com Wed Oct 3 19:17:05 2007 From: joncham at gmail.com (Jonathan Chambers) Date: Wed, 3 Oct 2007 19:17:05 -0400 Subject: [Mono-dev] .net library shared source In-Reply-To: References: <1191433571.4160.106.camel@erandi.dom> Message-ID: <17c2d80b0710031617n542605a1r3278975e3359eed8@mail.gmail.com> See Miguel's blog post: http://tirania.org/blog/archive/2007/Oct-03.html Also, the rules for contributing are still in effect: http://www.mono-project.com/Contributing "If you have looked at Microsoft's implementation of .NET or their shared source code, you will not be able to contribute to Mono." - Jonathan On 10/3/07, Tinco Andringa wrote: > > Hey guys, > > Have you read this? > > > http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx > > How will this affect the mono project? Will we able to use it to make the > framework match more to microsoft's or is it information we already have > (from the spec)? > > ------------------------------ > > > From: miguel at novell.com > > To: aras at unity3d.com > > Date: Wed, 3 Oct 2007 13:46:11 -0400 > > CC: mono-devel-list at lists.ximian.com > > Subject: Re: [Mono-dev] Incorrect trunc() definition for MSVC in > mono-compiler.h > > > > Hello, > > > > Thanks, I have commited a patch. > > > > > Hi, > > > > > > mono/utils/mono-compiler.h has incorrect trunc() definition for Visual > > > Studio, causing overflow exceptions to be thrown from int->float > > > conversions with negative inputs. > > > > > > Line 88 is: > > > #define trunc(x) floor((x)) > > > when it should be something like: > > > #define trunc(x) (((x) < 0) ? ceil((x)) : floor((x))) > > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > ------------------------------ > Express yourself instantly with MSN Messenger! MSN Messenger > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071003/3b7f20e1/attachment.html From jaebird at gmail.com Wed Oct 3 19:46:10 2007 From: jaebird at gmail.com (Jae Stutzman) Date: Wed, 3 Oct 2007 18:46:10 -0500 Subject: [Mono-dev] .net library shared source In-Reply-To: <17c2d80b0710031617n542605a1r3278975e3359eed8@mail.gmail.com> References: <1191433571.4160.106.camel@erandi.dom> <17c2d80b0710031617n542605a1r3278975e3359eed8@mail.gmail.com> Message-ID: On 10/3/07, Jonathan Chambers wrote: > > See Miguel's blog post: http://tirania.org/blog/archive/2007/Oct-03.html > > Also, the rules for contributing are still in effect: > http://www.mono-project.com/Contributing > > "If you have looked at Microsoft's implementation of .NET or their shared > source code, you will not be able to contribute to Mono." > > - Jonathan Regardless of the "personal" friendly contacts within MS, the lawyers are never friendly! We need to be more diligent now than ever that we do NOT look at the code EVER. It may be good to have an independent 3rd party org that does not contribute to mono to run code analysis between mono's impl and the .net src on regular basis to make sure that the mono implementation remains clean. MS releasing this just gives more ammo to the naysayers. There is enough bad press from the folks that think mono is MS pandering. This kinda thing is starting to make me annoyed! Sometimes I wish that the relationship between Mono and MS was NOT so friendly :) Maybe we should start name calling...heheh Cheers, Jae -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071003/38f314cd/attachment.html From mail at tinco.nl Wed Oct 3 20:46:07 2007 From: mail at tinco.nl (Tinco Andringa) Date: Thu, 4 Oct 2007 02:46:07 +0200 Subject: [Mono-dev] .net library shared source In-Reply-To: <17c2d80b0710031617n542605a1r3278975e3359eed8@mail.gmail.com> References: <1191433571.4160.106.camel@erandi.dom> <17c2d80b0710031617n542605a1r3278975e3359eed8@mail.gmail.com> Message-ID: If we can't even look at the source, it will make it virtually impossible for .net developers to contribute to mono, since the source viewing will be integrated with visual studio and will greatly enhance debugging, it would be stupid not to use it for regular developing. Soon everyone will have seen at least some part of the code. Date: Wed, 3 Oct 2007 19:17:05 -0400From: joncham at gmail.comTo: mail at tinco.nlSubject: Re: [Mono-dev] .net library shared sourceCC: mono-devel-list at lists.ximian.comSee Miguel's blog post: http://tirania.org/blog/archive/2007/Oct-03.htmlAlso, the rules for contributing are still in effect: http://www.mono-project.com/Contributing"If you have looked at Microsoft's implementation of .NET or their shared source code, you will not be able to contribute to Mono."- Jonathan On 10/3/07, Tinco Andringa < mail at tinco.nl> wrote: Hey guys, Have you read this? http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx How will this affect the mono project? Will we able to use it to make the framework match more to microsoft's or is it information we already have (from the spec)? > From: miguel at novell.com> To: aras at unity3d.com> Date: Wed, 3 Oct 2007 13:46:11 -0400> CC: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] Incorrect trunc() definition for MSVC in mono-compiler.h> > Hello,> > Thanks, I have commited a patch.> > > Hi,> > > > mono/utils/mono- compiler.h has incorrect trunc() definition for Visual> > Studio, causing overflow exceptions to be thrown from int->float> > conversions with negative inputs.> > > > Line 88 is: > > #define trunc(x) floor((x))> > when it should be something like:> > #define trunc(x) (((x) < 0) ? ceil((x)) : floor((x)))> > > _______________________________________________ > Mono-devel-list mailing list> Mono-devel-list at lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-devel-list Express yourself instantly with MSN Messenger! MSN Messenger_______________________________________________Mono-devel-list mailing listMono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071004/583394e4/attachment.html From denisraytek at yahoo.com Wed Oct 3 21:26:55 2007 From: denisraytek at yahoo.com (Dennis Hayes) Date: Wed, 3 Oct 2007 18:26:55 -0700 (PDT) Subject: [Mono-dev] .net library shared source In-Reply-To: Message-ID: <990282.83649.qm@web39613.mail.mud.yahoo.com> This source is released under the "reference" licesen. You can look at it, but not modify it or use it in anyother way. They have relesed the code for the Windows OS under this licesens for a few years now, but not on such a wide scale (only to big IS dept). So from the Mono view point, this indeed changes nothing. Dennis >mono-devel-list-request at lists.xiMessage: 4 >Date: Thu, 4 Oct 2007 00:53:31 +0200 >From: Tinco Andringa >Subject: [Mono-dev] .net library shared source >To: >Message-ID: >Content-Type: text/plain; charset="iso-8859-1" > >Hey guys, > >Have you read this? > >code-for-the-net-framework-libraries.aspx">http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source->code-for-the-net-framework-libraries.aspx > >How will this affect the mono project? Will we able to use it to make the >framework match more to microsoft's or is it information we already have >(from the spec)? --------------------------------- Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071003/2b5eac7c/attachment.html From cliff.brake at gmail.com Wed Oct 3 23:25:32 2007 From: cliff.brake at gmail.com (Cliff Brake) Date: Wed, 3 Oct 2007 23:25:32 -0400 Subject: [Mono-dev] Cross Compile for Embedded Linux PPC In-Reply-To: <4e2ed8510710021750p43bdc422qb568cdb4f0694a8e@mail.gmail.com> References: <4e2ed8510710021750p43bdc422qb568cdb4f0694a8e@mail.gmail.com> Message-ID: On 10/2/07, Dan Osawa wrote: > Hello, > > I'm trying to build a very minimal Mono (non-gui apps) for an embedded PPC > Linux system. I would like to cross compile it on my IA32 Fedora Core > system, which has the cross compiler tools located under /opt/Arabella. Are > there ./configure paramters that I can use to achieve this? As of today, Mono support in OpenEmbedded (cross compiling) is working for ARM. You may want to start with that as there has been a lot of work done (http://www.openembedded.org/filebrowser/org.openembedded.dev/packages/mono) to make Mono cross compile in a completely automated manner, and build the following packages: http://pastebin.ca/725080 I'm setting up a feed for the neo1973 phone, and will post details shortly. Cliff -- ======================= Cliff Brake http://bec-systems.com From atsushi at ximian.com Thu Oct 4 00:15:45 2007 From: atsushi at ximian.com (Atsushi Eno) Date: Thu, 04 Oct 2007 13:15:45 +0900 Subject: [Mono-dev] .net library shared source In-Reply-To: References: <1191433571.4160.106.camel@erandi.dom> <17c2d80b0710031617n542605a1r3278975e3359eed8@mail.gmail.com> Message-ID: <470468F1.6000507@ximian.com> Hello, I can understand your concern. When you enter into _some_ highly Visuao Studio oriented development (no, it's not about "whether I use VS.NET or not") you might happen to read those .NET source code like a some people do for MFC. However there is a lot more variants of those who use Visual Studio than you imagine, such as those people who knows that bugs are most usually in their own code and not in .NET Framework and hence no need to look at them. For example, after a few months since I started mono hacking, I stopped using Visual Studio and started to live only with text editors. And I felt my work-time productivity even grew up without VS. (Before that I always wondered my company mentor often said that with .NET we can live without IDE unlike VS6.) So, I don't think it is very hard for mono hackers and wanabees to not dig into .NET Framework sources by (sort of) experience. There must be lots of people who have read neither of Sun Java source code nor MFC sources. Atsushi Eno Tinco Andringa wrote: > If we can't even look at the source, it will make it virtually > impossible for .net developers to contribute to mono, since the source > viewing will be integrated with visual studio and will greatly enhance > debugging, it would be stupid not to use it for regular developing. Soon > everyone will have seen at least some part of the code. > > Date: Wed, 3 Oct 2007 19:17:05 -0400 > From: joncham at gmail.com > To: mail at tinco.nl > Subject: Re: [Mono-dev] .net library shared source > CC: mono-devel-list at lists.ximian.com > > See Miguel's blog post: http://tirania.org/blog/archive/2007/Oct-03.html > > Also, the rules for contributing are still in effect: > http://www.mono-project.com/Contributing > > "If you have looked at Microsoft's implementation of .NET or their > shared source code, you will not be able to contribute to Mono." > > - Jonathan > > On 10/3/07, *Tinco Andringa* < mail at tinco.nl > > wrote: > > Hey guys, > > Have you read this? > > http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx > > > How will this affect the mono project? Will we able to use it to > make the framework match more to microsoft's or is it > information we already have (from the spec)? > > > > From: miguel at novell.com > > To: aras at unity3d.com > > Date: Wed, 3 Oct 2007 13:46:11 -0400 > > CC: mono-devel-list at lists.ximian.com > > > Subject: Re: [Mono-dev] Incorrect trunc() definition for MSVC > in mono-compiler.h > > > > Hello, > > > > Thanks, I have commited a patch. > > > > > Hi, > > > > > > mono/utils/mono- compiler.h has incorrect trunc() > definition for Visual > > > Studio, causing overflow exceptions to be thrown from > int->float > > > conversions with negative inputs. > > > > > > Line 88 is: > > > #define trunc(x) floor((x)) > > > when it should be something like: > > > #define trunc(x) (((x) < 0) ? ceil((x)) : floor((x))) > > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > Express yourself instantly with MSN Messenger! MSN Messenger > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > Express yourself instantly with MSN Messenger! MSN Messenger > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From cliff.brake at gmail.com Thu Oct 4 00:23:27 2007 From: cliff.brake at gmail.com (Cliff Brake) Date: Thu, 4 Oct 2007 00:23:27 -0400 Subject: [Mono-dev] mono packages available for openmoko phone Message-ID: Henryk Pl?tz has done some excellent work on the mono build in openembedded, and as a result we now have a set of mono packages available for install on the NEO1973 phone. Eventually, we'll get the packages in the openmoko feeds, but for now you can install the packages from the following feed: add the following to a /etc/ipkg/*-feed.conf file: src/gz mono-armv4t http://dev.bec-systems.com/feed/openmoko/mono ipkg update ipkg install mono The packaging is fairly granular, so look at the listing in the above URL to see a complete list of what is available. Alternatively, you can build mono in the Openembedded build system. Cliff -- ======================= Cliff Brake http://bec-systems.com From tarzanarch at gmail.com Thu Oct 4 01:14:41 2007 From: tarzanarch at gmail.com (Archie Alafriz) Date: Wed, 3 Oct 2007 22:14:41 -0700 Subject: [Mono-dev] Apache and Mono Setup Message-ID: To: The Mono Development Head Team We are currently involved in the development of an application wherein we need to port our existing ASP.NET code under an open source environment. Our server platform is hosting an apache web server which is used to host PHP and other web services. With this in mind, our main concerns at the moment are: 1. Is it possible to install a parallel apache 2.0 service which can be dedicated to Mono? If possible then can we ask for resources that will point us on how this can be done? 2. How do we setup mysql 5 separately with the currently running mysql 4 service? Our aim is not to disrupt the currently running LAMP stack on the server and as much as possible do our transition without interrupting the services currently running. Thank you very much, hope you can help us regarding this matter. Anomalist Designs, LLC Web: http://www.anomalistdesign.com/ Email: info at anomalistdesign.com tarzanarch at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071003/8552b169/attachment.html From abirb at 2pirad.com Thu Oct 4 02:39:24 2007 From: abirb at 2pirad.com (Abir Bhattacharya) Date: Thu, 4 Oct 2007 12:09:24 +0530 Subject: [Mono-dev] calling native 'C' libraries Message-ID: <006b01c80651$4f0f75b0$40bcfea9@ABIRB> Hi all, Pls give me any ideas / refs related to invoking of native 'C' libraries in mono ? Regards Abir Bhattacharya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071004/f00fa459/attachment.html From nagappan at gmail.com Thu Oct 4 02:48:36 2007 From: nagappan at gmail.com (Nagappan A) Date: Thu, 4 Oct 2007 12:18:36 +0530 Subject: [Mono-dev] calling native 'C' libraries In-Reply-To: <006b01c80651$4f0f75b0$40bcfea9@ABIRB> References: <006b01c80651$4f0f75b0$40bcfea9@ABIRB> Message-ID: <9d0602eb0710032348o51bd8af2i5fc32f73ee079af3@mail.gmail.com> Hi, Hope this helps http://www.mono-project.com/Interop_with_Native_Libraries http://www.mono-project.com/Dllimport Thanks Nagappan On 10/4/07, Abir Bhattacharya wrote: > > > > > Hi all, > > > > Pls give me any ideas / refs related to invoking of native 'C' libraries in > mono ? > > > > Regards > > > > Abir Bhattacharya > > > -- Visit us at http://www.2pirad.com/ -- > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Linux Desktop Testing Project - http://ldtp.freedesktop.org http://nagappanal.blogspot.com From mbd at dbc.dk Thu Oct 4 03:16:19 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Thu, 4 Oct 2007 09:16:19 +0200 Subject: [Mono-dev] SVN does not compile In-Reply-To: <200710020926.22377.mbd@dbc.dk> References: <200710020926.22377.mbd@dbc.dk> Message-ID: <200710040916.19284.mbd@dbc.dk> tirsdag 02 Oktober 2007 skrev Mads Bondo Dydensborg: > Hi there > > Just a short message to let those responsible know, that svn has not compiled > for about three days now. Ahem. Turns out that a local patch conflicted with recent changes in svn. The responsible user has been appropiatly punished.. :-/ Sorry for the noise. Regards, Mads > > make[8]: Entering directory `/home/compile/Compile/Mono/mcs/class/System.Data' > ../../jay/jay -ct < ../../jay/skeleton.cs Mono.Data.SqlExpressions/Parser.jay > >Mono.Data.SqlExpressions/Parser.cs > ../../jay/jay: 1 shift/reduce conflict. > MONO_PATH="../../class/lib/default: > $MONO_PATH" /home/compile/Compile/Mono/mono/runtime/mono-wrapper ../../class/lib/default/mcs.exe /codepage:65001 -d:NET_1_1 -d:ONLY_1_1 -debug /noconfig -nowarn:649 -nowarn:169 -nowarn:219 -nowarn:168 -nowarn:1595 -unsafe -r:mscorlib.dll -r:../../class/lib/default/System.dll -r:System.Xml.dll -r:System.EnterpriseServices.dll -r:Mono.Data.Tds.dll -target:library -out:../../class/lib/default/System.Data.dll > Mono.Data.SqlExpressions/Parser.cs @System.Data.dll.sources > System.Data.Odbc/OdbcTransaction.cs(54,1): error CS1002: Expecting `;' > System.Data.Odbc/OdbcTransaction.cs(56,1): error CS1002: Expecting `;' > System.Data.Odbc/OdbcTransaction.cs(58,1): error CS1002: Expecting `;' > System.Data.Odbc/OdbcTransaction.cs(88,1): error CS1518: Expected `class', > `delegate', `enum', `interface', or `struct' > Compilation failed: 4 error(s), 0 warnings > > Regards, > > Mads > > -- > Med venlig hilsen/Regards > > Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg > Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 From neilc at opennetcf.com Thu Oct 4 04:18:47 2007 From: neilc at opennetcf.com (Neil Cowburn) Date: Thu, 4 Oct 2007 04:18:47 -0400 Subject: [Mono-dev] .net library shared source In-Reply-To: <470468F1.6000507@ximian.com> References: <1191433571.4160.106.camel@erandi.dom> <17c2d80b0710031617n542605a1r3278975e3359eed8@mail.gmail.com> <470468F1.6000507@ximian.com> Message-ID: <9BD8AA83B7777E478DA1EAFAFA133B1E146E38B1@CL4EXBE03.ad2.softcom.biz> > -----Original Message----- > From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list- > bounces at lists.ximian.com] On Behalf Of Atsushi Eno > Sent: Thursday, October 04, 2007 5:16 AM > To: Tinco Andringa > Cc: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] .net library shared source > > So, I don't think it is very hard for mono hackers and wanabees > to not dig into .NET Framework sources by (sort of) experience. > There must be lots of people who have read neither of Sun Java > source code nor MFC sources. > > Atsushi Eno > I'm totally with you on that. I've advised my team to *not* look at the source. When I install the VS 2008 RTM, the first thing I'm going to do is check that runtime source-level debugging is disabled. The reasons for this is exactly the same reasons as outlined in the rules for contributing: I don't want *any* MS prior art appearing in the Smart Device Framework. --Neil From aras at unity3d.com Mon Oct 1 13:43:52 2007 From: aras at unity3d.com (Aras Pranckevicius) Date: Mon, 1 Oct 2007 19:43:52 +0200 Subject: [Mono-dev] Incorrect trunc() definition for MSVC in mono-compiler.h Message-ID: Hi, mono/utils/mono-compiler.h has incorrect trunc() definition for Visual Studio, causing overflow exceptions to be thrown from int->float conversions with negative inputs. Line 88 is: #define trunc(x) floor((x)) when it should be something like: #define trunc(x) (((x) < 0) ? ceil((x)) : floor((x))) -- Aras Pranckevicius work: http://unity3d.com home: http://aras-p.info -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071001/1243ffa6/attachment.html From miguel at novell.com Thu Oct 4 10:31:25 2007 From: miguel at novell.com (Miguel de Icaza) Date: Thu, 04 Oct 2007 10:31:25 -0400 Subject: [Mono-dev] .net library shared source In-Reply-To: References: <1191433571.4160.106.camel@erandi.dom> <17c2d80b0710031617n542605a1r3278975e3359eed8@mail.gmail.com> Message-ID: <1191508285.4879.37.camel@erandi.dom> > If we can't even look at the source, it will make it virtually > impossible for .net developers to contribute to mono, since the source > viewing will be integrated with visual studio and will greatly enhance > debugging, it would be stupid not to use it for regular developing. > Soon everyone will have seen at least some part of the code. Then we will not accept their contributions. It is that easy. If you look at code in System.Net, it does not mean that you can not contribute to say System.Windows.Forms. So there is some nuance here. From mail at tinco.nl Thu Oct 4 10:37:29 2007 From: mail at tinco.nl (Tinco Andringa) Date: Thu, 4 Oct 2007 16:37:29 +0200 Subject: [Mono-dev] .net library shared source In-Reply-To: <1191508285.4879.37.camel@erandi.dom> References: <1191433571.4160.106.camel@erandi.dom> <17c2d80b0710031617n542605a1r3278975e3359eed8@mail.gmail.com> <1191508285.4879.37.camel@erandi.dom> Message-ID: Also, this might be a bit paranoid statement, but Microsoft will be able to tell from it's log wether a person has looked at a particular piece of source since the sourcecode will be provided as a webservice. When it would come to a courtcase (which I think is very unlikely) Microsoft probably will not hold back this kind of evidence. So caution really is necessary. > Subject: Re: [Mono-dev] .net library shared source> From: miguel at novell.com> To: mail at tinco.nl> CC: mono-devel-list at lists.ximian.com> Date: Thu, 4 Oct 2007 10:31:25 -0400> > > > If we can't even look at the source, it will make it virtually> > impossible for .net developers to contribute to mono, since the source> > viewing will be integrated with visual studio and will greatly enhance> > debugging, it would be stupid not to use it for regular developing.> > Soon everyone will have seen at least some part of the code.> > Then we will not accept their contributions. It is that easy.> > If you look at code in System.Net, it does not mean that you can not> contribute to say System.Windows.Forms. So there is some nuance here. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071004/397e617d/attachment.html From lupus at ximian.com Thu Oct 4 10:44:53 2007 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 4 Oct 2007 16:44:53 +0200 Subject: [Mono-dev] Cross Compile for Embedded Linux PPC In-Reply-To: References: <4e2ed8510710021750p43bdc422qb568cdb4f0694a8e@mail.gmail.com> Message-ID: <20071004144453.GX25385@debian.org> On 10/03/07 Cliff Brake wrote: > As of today, Mono support in OpenEmbedded (cross compiling) is working > for ARM. You may want to start with that as there has been a lot of > work done (http://www.openembedded.org/filebrowser/org.openembedded.dev/packages/mono) I took a quick look at the patches in the files directory there: *) cpu-arm.h: I hope you're not using this file as it is broken *) genmdesc-cpp.patch: applied to svn, though if a devel box doesn't have cpp installed it has big issues... *) mono-configure.patch: the fpu check change is obsolete (svn has the better fix) and the other two changes look like hacks *) mono-fix-libdir-path.patch: this is broken and should not be used unless you change also metadata/Makefile.am *) mono-mini-Makefile.patch is needed because mono-monoburg-Makefile.patch breaks the compilation of monoburg, AFAICS *) mono-mips-endian.patch: svn has a simplified version lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= Thu Oct 4 10:58:27 2007 From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=) Date: Thu, 04 Oct 2007 16:58:27 +0200 Subject: [Mono-dev] .net library shared source Message-ID: <4704FF93.8000702@gmail.com> Jae Stutzman escribi?: > On 10/3/07, Jonathan Chambers wrote: > >> See Miguel's blog post: http://tirania.org/blog/archive/2007/Oct-03.html >> >> Also, the rules for contributing are still in effect: http://www.mono-project.com/Contributing >> >> "If you have looked at Microsoft's implementation of .NET or their shared source code, you will not be able to contribute to Mono." >> >> - Jonathan > > (...)There is enough bad press from the folks that think mono is MS pandering(...) Yes. I suppose you're referring to things like this: http://www.eweek.com/article2/0,1895,2191754,00.asp Regards, Andr?s [ knocte ] -- From vlad.dimitrov at gmail.com Thu Oct 4 12:37:05 2007 From: vlad.dimitrov at gmail.com (Vladimir Dimitrov) Date: Thu, 4 Oct 2007 19:37:05 +0300 Subject: [Mono-dev] Any ideas about the crash in Glade# under windows (GTK# 2.10) Message-ID: <000901c806a4$ce00c7e0$4365a8c0@whitebook> Does anybody know if here is a fix or a workaround bug #323607? I had to upgrade to a newer version of GTK# (2.10 included with mono) under windows in order to avoid another bug that is fixed now, but I get an exception on Autoconnect of the Glade.XML. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071004/fc9b1b07/attachment.html From lupus at ximian.com Thu Oct 4 10:51:38 2007 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 4 Oct 2007 16:51:38 +0200 Subject: [Mono-dev] Apache and Mono Setup In-Reply-To: References: Message-ID: <20071004145137.GY25385@debian.org> On 10/03/07 Archie Alafriz wrote: > 1. Is it possible to install a parallel apache 2.0 service which can be > dedicated to Mono? If possible then can we ask for resources that will point > us on how this can be done? Yes, it can be done, see the documentation at www.apache.org. > 2. How do we setup mysql 5 separately with the currently running mysql 4 > service? You install it in a separate directory and make it use a different port, see the documentation at www.mysql.com. If you have any questions about mono feel free to use this list. Thanks! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Thu Oct 4 10:16:39 2007 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 4 Oct 2007 16:16:39 +0200 Subject: [Mono-dev] Cross Compile for Embedded Linux PPC In-Reply-To: <4e2ed8510710021750p43bdc422qb568cdb4f0694a8e@mail.gmail.com> References: <4e2ed8510710021750p43bdc422qb568cdb4f0694a8e@mail.gmail.com> Message-ID: <20071004141639.GW25385@debian.org> On 10/02/07 Dan Osawa wrote: > I'm trying to build a very minimal Mono (non-gui apps) for an embedded PPC > Linux system. I would like to cross compile it on my IA32 Fedora Core > system, which has the cross compiler tools located under /opt/Arabella. Are > there ./configure paramters that I can use to achieve this? You do it the same way as with any other autoconf-based program, there are several references on the web. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From wberrier at novell.com Fri Oct 5 14:08:04 2007 From: wberrier at novell.com (Wade Berrier) Date: Fri, 05 Oct 2007 12:08:04 -0600 Subject: [Mono-dev] Class Status pages for Olive Message-ID: <1191607684.26418.7.camel@wberrier.site> Hi, Status pages are generated for olive on monobuild. Here's the link (which is temporary for now because old builds get removed from mono.ximian.com): http://mono.ximian.com/monobuild/builds/HEAD/suse-100-i586/olive/86908/files/steps/api-diff/ Miguel mentioned that there are some missing assemblies (agclr, System.Silverlight, etc). Is the masterinfo information for those assemblies contained in this link? http://mono.ximian.com/masterinfos/masterinfos-3.0.tar.gz I'm assuming it's not, because it seems that each assembly has it's own corresponding xml file. Does the above masterinfo file need updating, or is there another set of masterinfos I should be using with olive? Wade -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071005/37e954e1/attachment.bin From atsushi at ximian.com Fri Oct 5 14:37:01 2007 From: atsushi at ximian.com (Atsushi Eno) Date: Sat, 06 Oct 2007 03:37:01 +0900 Subject: [Mono-dev] Class Status pages for Olive In-Reply-To: <1191607684.26418.7.camel@wberrier.site> References: <1191607684.26418.7.camel@wberrier.site> Message-ID: <4706844D.1060907@ximian.com> Hello, Wade Berrier wrote: > Hi, > > Status pages are generated for olive on monobuild. Here's the link > (which is temporary for now because old builds get removed from > mono.ximian.com): > > http://mono.ximian.com/monobuild/builds/HEAD/suse-100-i586/olive/86908/files/steps/api-diff/ Ohh, nice :-) Thanks for the work Wade. > Miguel mentioned that there are some missing assemblies (agclr, > System.Silverlight, etc). > > Is the masterinfo information for those assemblies contained in this > link? > > http://mono.ximian.com/masterinfos/masterinfos-3.0.tar.gz > > I'm assuming it's not, because it seems that each assembly has it's own > corresponding xml file. They aren't. On Windows if you have Silverlight installed, you will find those assemblies at %PROGRAMFILES%\Microsoft Silverlight . > Does the above masterinfo file need updating, or is there another set of > masterinfos I should be using with olive? Hence yes. They can be generated using mono-api-info against those MS assemblies. I believe olive contains almost all assemblies (except for MS.VB.dll) that correspond to non-OSS managed assemblies from Silverlight. Atsushi Eno From marcoscobena at gmail.com Fri Oct 5 14:47:29 2007 From: marcoscobena at gmail.com (=?UTF-8?Q?Marcos_Cobe=C3=B1a_Mori=C3=A1n?=) Date: Fri, 5 Oct 2007 20:47:29 +0200 Subject: [Mono-dev] Class Status pages for Olive In-Reply-To: <1191607684.26418.7.camel@wberrier.site> References: <1191607684.26418.7.camel@wberrier.site> Message-ID: <67c29c7c0710051147r5025cb2aoa5f21c6fbd9bf4c5@mail.gmail.com> Superb Wade, really thanks! I can proceed then and remove my own version for WCF. Thanks again. Regards, 2007/10/5, Wade Berrier : > Hi, > > Status pages are generated for olive on monobuild. Here's the link > (which is temporary for now because old builds get removed from > mono.ximian.com): > > http://mono.ximian.com/monobuild/builds/HEAD/suse-100-i586/olive/86908/files/steps/api-diff/ > > Miguel mentioned that there are some missing assemblies (agclr, > System.Silverlight, etc). > > Is the masterinfo information for those assemblies contained in this > link? > > http://mono.ximian.com/masterinfos/masterinfos-3.0.tar.gz > > I'm assuming it's not, because it seems that each assembly has it's own > corresponding xml file. > > Does the above masterinfo file need updating, or is there another set of > masterinfos I should be using with olive? > > Wade > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > -- Marcos - http://www.youcannoteatbits.org From xmlhacker at gmail.com Fri Oct 5 15:25:32 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Fri, 5 Oct 2007 13:25:32 -0600 Subject: [Mono-dev] System.Messaging: Anyone currently working on this? In-Reply-To: <47036DC8.50503@ximian.com> References: <67c29c7c0709290524s7cdc637cqd33a391fdd21901f@mail.gmail.com> <47036DC8.50503@ximian.com> Message-ID: Hi :) On 10/3/07, Atsushi Eno wrote: > > Hi, > > It is great that you are interested in hacking this area :-) > > You can start either based on unfinished SoC effort or from > scratch (as you wrote, the existing code is not advanced much). > > Also, since System.Messaging.dll is not part of our supported > component, you can directly work with mono svn. IMO even > trunk is still fine (I'll take care of the dll's metadata-wise > mismatch) but you might also want to create your own branch. Okay, I will do just that. (I noticed that the latest data loss disaster at the hosting > service I used also hit my code. That sucks!!! So the links at the wiki page > results in 404, but I could restore only the patch from archive.org > and it actually lacked OpenWireBridge.cs, though it should not be > hard to rewrite from scratch.) Yeah, it seems pretty straight forward, and in fact have already started in on getting some of the core functionality pieces pulled together. I am currently in "head down and code mode" getting ready to deliver this[1] platform (which, by the way, is a completely portable personal web communication and publishing system, the same system I've been building in stages for the last three and half years, built directly on top of and powered by Mono) which is powering this[2] site which will be launched in 11 days @ the College Music Journal Festival[3] in New York City on the 16th. When I get back from that event I will be placing all of my focus on building out System.Messaging, so expect to hear back from me in regards to both status and questions soon thereafter. Thanks, Eno! [1] http://nuxleus.googlecode.com/svn/trunk/nuxleus/ [2] http://amp.fm/ [3] http://cmj.com/marathon -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071005/8ac70d74/attachment.html From mono-devel at tlarson.com Fri Oct 5 20:32:09 2007 From: mono-devel at tlarson.com (Tyler Larson) Date: Fri, 05 Oct 2007 17:32:09 -0700 Subject: [Mono-dev] [PATCH] String.Split() broken behavior Message-ID: <4706D789.3060605@tlarson.com> Hey Mono team: This is my first time contributing, so please bear with me if I do something dumb. I've provided a patch for incorrect behavior in the String.Split() function. In particular, String.Split(char[],int,StringSplitOptions) behaves incorrectly when instructed to remove empty entries while also limiting the size of the resultant array. Take for example, the following code: ",a,,b,c".Split(new char[]{','},3,StringSplitOptions.RemoveEmptyEntries); The existing implementation split the string into the following 3 components: {[], [], [a,,b,c]} Then it scans the array and removes all empty entries, returning simply {[a,,b,c]} The correct behavior would be to remove empty entries while the string was being split, and always return the maximum number of elements possible. The *correct* result to the preceding example would be: {[a],[b],[c]} In order to do this correctly and efficiently, the InternalSplit function had to be modified to be able to remove empty entries during the split procedure; this included changing the signature to accept an "options" parameter. This patch also removes the need for further optimization of the String.Split() call. I'm a bit unsure about the coding style required; the .c file seemed to be a bit of a combination of a few coding styles all together. Also, the new InternalSplit function in this patch contains the line: remempty = options & 0x01; where 0x01 refers to the StringSplitOptions.RemoveEmptyEntries flag. I'm sure there's a "better" way of indicating this; either by referencing the enum somehow or with a #define somewhere. I don't know how you do that sort of thing here. The patch, as provided, DOES fix the broken code and works without any trouble, but I would appreciate it if someone more familiar with the Mono project would go over the changes and bring those style bits a bit more into conformance with what is expected. Cheers -Tyler Larson -------------- next part -------------- A non-text attachment was scrubbed... Name: stringsplit.patch Type: text/x-patch Size: 8504 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071005/99f00fad/attachment.bin From kumpera at gmail.com Fri Oct 5 22:51:27 2007 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Fri, 5 Oct 2007 23:51:27 -0300 Subject: [Mono-dev] [PATCH] String.Split() broken behavior In-Reply-To: <4706D789.3060605@tlarson.com> References: <4706D789.3060605@tlarson.com> Message-ID: <8cca42d80710051951r248c6640w896ca46294c55fc2@mail.gmail.com> Hi Tyler, I some coments about our patch, some are just minor details like formating issues. You can read about our coding guidelines in http://www.mono-project.com/Coding_Guidelines For the options it's a good idea to create an enum in the c side. "options & SPLIT_OPTIONS_REMOVE_EMPTY_ENTRIES", or something alika, is way better than "options & 0x01" - which uses some sort of magical number. Take a look at the GenericParameterAttributes enum in object-internals.h. + if (string_icall_is_in_array(separator, arrsize, src[i])) { + splitsize++; Please add a space after function name and array index, it should be something like: + if (string_icall_is_in_array (separator, arrsize, src [i])) { + splitsize++; + if (lastpos == 1) + { + splitsize++; + } Avoid braces for single line ifs. About fixing the broken code, we are going to need new unit tests for all this code. You could sent the patch for mcs/class/corlib/Test/System/StringTest.cs too ;) Cheers, Rodrigo On 10/5/07, Tyler Larson wrote: > > Hey Mono team: > > This is my first time contributing, so please bear with me if I do > something dumb. > > I've provided a patch for incorrect behavior in the String.Split() > function. In particular, String.Split(char[],int,StringSplitOptions) > behaves incorrectly when instructed to remove empty entries while also > limiting the size of the resultant array. > > Take for example, the following code: > ",a,,b,c".Split(new char[]{','},3,StringSplitOptions.RemoveEmptyEntries); > > The existing implementation split the string into the following 3 > components: {[], [], [a,,b,c]} > Then it scans the array and removes all empty entries, returning simply > {[a,,b,c]} > > The correct behavior would be to remove empty entries while the string > was being split, and always return the maximum number of elements > possible. The *correct* result to the preceding example would be: > {[a],[b],[c]} > > In order to do this correctly and efficiently, the InternalSplit > function had to be modified to be able to remove empty entries during > the split procedure; this included changing the signature to accept an > "options" parameter. > > This patch also removes the need for further optimization of the > String.Split() call. > > > I'm a bit unsure about the coding style required; the .c file seemed to > be a bit of a combination of a few coding styles all together. Also, the > new InternalSplit function in this patch contains the line: > remempty = options & 0x01; > > where 0x01 refers to the StringSplitOptions.RemoveEmptyEntries flag. I'm > sure there's a "better" way of indicating this; either by referencing > the enum somehow or with a #define somewhere. I don't know how you do > that sort of thing here. > > The patch, as provided, DOES fix the broken code and works without any > trouble, but I would appreciate it if someone more familiar with the > Mono project would go over the changes and bring those style bits a bit > more into conformance with what is expected. > > Cheers > > -Tyler Larson > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071005/4a82b22d/attachment.html From samanpa at gmail.com Sat Oct 6 00:43:29 2007 From: samanpa at gmail.com (Kojo Adams) Date: Sat, 6 Oct 2007 00:43:29 -0400 Subject: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) In-Reply-To: <1191358713.4626.7.camel@wberrier> References: <46F3D4D8.2070904@gmail.com> <1191297961.6069.16.camel@scherzo> <1191346252.4085.71.camel@erandi.dom> <1191350532.8413.15.camel@nightcrawler> <1191358580.11169.21.camel@erandi.dom> <1191358713.4626.7.camel@wberrier> Message-ID: <89ecfcee0710052143p30d593c8sd451508ef71dbcd5@mail.gmail.com> On 10/2/07, Wade Berrier wrote: > I build gtk# on windows with vs .net for the sole purpose of eventually > shipping gtk# for ms .net. > > I think it's ok to have separate installers, but we may want to > reconsider the overall picture if we move everything to .msi. > (Ie: maybe have an .msi installer for gtk+, or use someone elses, one > for core mono, another for gtk#, etc...) > > Wade Is it possible to compile gtk-sharp on windows with the mono toolchain? From alankila at bel.fi Sat Oct 6 04:12:36 2007 From: alankila at bel.fi (Antti S. Lankila) Date: Sat, 06 Oct 2007 11:12:36 +0300 Subject: [Mono-dev] 1.2.5 object initializers broken by 1.2.5.1? Message-ID: <47074374.1070309@bel.fi> Hello. It seems that throwing an exception with object initializers has broken. Specifically this code: throw new Foo() { x = 1, y = 2 }; behaves differently from: var foo = new Foo() { x = 1, y = 2; }; throw foo; It seems that x and y remain with null values. Also, initializing a dictionary from a list seems to have broken, as this does not compile: var foo = new Dictionary() { { "hip", null }, { "hop", null } }; but this used to compile and work with 1.2.5. -- Antti From marek.safar at seznam.cz Sat Oct 6 11:35:29 2007 From: marek.safar at seznam.cz (Marek Safar) Date: Sat, 06 Oct 2007 16:35:29 +0100 Subject: [Mono-dev] 1.2.5 object initializers broken by 1.2.5.1? In-Reply-To: <47074374.1070309@bel.fi> References: <47074374.1070309@bel.fi> Message-ID: <4707AB41.5060309@seznam.cz> Hello Antti, > It seems that throwing an exception with object initializers has broken. > Specifically this code: > > throw new Foo() { > x = 1, y = 2 > }; > > behaves differently from: > > var foo = new Foo() { > x = 1, y = 2; > }; > throw foo; > > It seems that x and y remain with null values. > > Also, initializing a dictionary from a list seems to have broken, as > this does not compile: > > var foo = new Dictionary() { > { "hip", null }, > { "hop", null } > }; > > but this used to compile and work with 1.2.5. > Please use SVN version of gmcs it contains significantly improved support of C# 3.0 and I was able to compile and run all your code samples. Also there was no compiler changes between 1.2.5 and 1.2.5.x Marek From miguel at novell.com Sat Oct 6 11:18:53 2007 From: miguel at novell.com (Miguel de Icaza) Date: Sat, 06 Oct 2007 11:18:53 -0400 Subject: [Mono-dev] Class Status pages for Olive In-Reply-To: <1191608657.5126.72.camel@erandi.dom> References: <1191608657.5126.72.camel@erandi.dom> Message-ID: <1191683933.3945.100.camel@erandi.dom> > http://mono.ximian.com/monobuild/builds/HEAD/suse-100-i586/olive/86908/files/steps/api-diff/ Lets get these listed in the /Resources page which is our go-to place for this stuff. > Miguel mentioned that there are some missing assemblies (agclr, > System.Silverlight, etc). > > Is the masterinfo information for those assemblies contained in this > link? > > http://mono.ximian.com/masterinfos/masterinfos-3.0.tar.gz > > I'm assuming it's not, because it seems that each assembly has it's own > corresponding xml file. > > Does the above masterinfo file need updating, or is there another set of > masterinfos I should be using with olive? > > Wade > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From miguel at novell.com Sat Oct 6 11:20:02 2007 From: miguel at novell.com (Miguel de Icaza) Date: Sat, 06 Oct 2007 11:20:02 -0400 Subject: [Mono-dev] 1.2.5 object initializers broken by 1.2.5.1? In-Reply-To: <47074374.1070309@bel.fi> References: <47074374.1070309@bel.fi> Message-ID: <1191684002.3945.102.camel@erandi.dom> Hello Antti, Please file bug reports for these issues. > Hello. > > It seems that throwing an exception with object initializers has broken. > Specifically this code: > > throw new Foo() { > x = 1, y = 2 > }; > > behaves differently from: > > var foo = new Foo() { > x = 1, y = 2; > }; > throw foo; > > It seems that x and y remain with null values. > > Also, initializing a dictionary from a list seems to have broken, as > this does not compile: > > var foo = new Dictionary() { > { "hip", null }, > { "hop", null } > }; > > but this used to compile and work with 1.2.5. > From mono-devel at tlarson.com Sun Oct 7 05:40:21 2007 From: mono-devel at tlarson.com (Tyler Larson) Date: Sun, 07 Oct 2007 02:40:21 -0700 Subject: [Mono-dev] [PATCH] String.Split() broken behavior In-Reply-To: <8cca42d80710051951r248c6640w896ca46294c55fc2@mail.gmail.com> References: <4706D789.3060605@tlarson.com> <8cca42d80710051951r248c6640w896ca46294c55fc2@mail.gmail.com> Message-ID: <4708A985.8000804@tlarson.com> Rodrigo Kumpera wrote: > Hi Tyler, > > I some coments about our patch, some are just minor details like > formating issues. You can read about our coding guidelines in > http://www.mono-project.com/Coding_Guidelines > > > For the options it's a good idea to create an enum in the c side. > "options & SPLIT_OPTIONS_REMOVE_EMPTY_ENTRIES", or something alika, is > way better than "options & 0x01" - which uses some sort of magical > number. Take a look at the GenericParameterAttributes enum in > object-internals.h. > > + if (string_icall_is_in_array(separator, arrsize, src[i])) { > + splitsize++; > > Please add a space after function name and array index, it should be > something like: > + if (string_icall_is_in_array (separator, arrsize, src [i])) { > + splitsize++; > > + if (lastpos == 1) > + { > + splitsize++; > + } > > Avoid braces for single line ifs. > > About fixing the broken code, we are going to need new unit tests for > all this code. You could sent the patch for > mcs/class/corlib/Test/System/StringTest.cs too ;) > > > Cheers, > Rodrigo > > Attached is a revised patch to the String.Split problem. This patch now includes code cleanup to bring it in conformance with the published coding standards as well as unit tests relevant to the changes I made. For what its worth, I would suspect that this function is probably the fastest basic tokenization mechanism available though the class libraries. The reason why I found the bugs in this code to begin with is because I always used this method to tokenize input strings. Indeed, I'm surprised that these bugs went unnoticed and unrepaired for so long (literally years) for such a critical core component as the system string library. Is there some other (perhaps faster) mechanism other people are using for string tokenization that I don't know about? -Tyler -------------- next part -------------- A non-text attachment was scrubbed... Name: stringsplit.patch Type: text/x-patch Size: 11802 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071007/a8fc2880/attachment.bin From alankila at bel.fi Sun Oct 7 09:18:29 2007 From: alankila at bel.fi (Antti S. Lankila) Date: Sun, 07 Oct 2007 16:18:29 +0300 Subject: [Mono-dev] 1.2.5 object initializers broken by 1.2.5.1? In-Reply-To: <4707AB41.5060309@seznam.cz> References: <470