From atsushi at ximian.com Tue Jul 1 02:11:10 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Tue, 01 Jul 2008 15:11:10 +0900 Subject: [Mono-dev] Fw: [Mono-patches] r106776 - in trunk/mcs/class/System.Configuration: System.Configuration Test/System.Configuration In-Reply-To: <006d01c8d8a9$15369370$3fa3ba50$@driesen@telenet.be> References: <846488.47860.qm@web30803.mail.mud.yahoo.com> <486564C0.9020701@ximian.com> <005d01c8d8a7$111c8940$33559bc0$@driesen@telenet.be> <48656E05.8040700@ximian.com> <006d01c8d8a9$15369370$3fa3ba50$@driesen@telenet.be> Message-ID: <4869CA7E.4070104@ximian.com> We had some email exchanges about this, and sorted out some agreement. - It indeed sounds insult when someone gives (negative) evaluation on others' personality in Japan, while it does not sound so in other areas (and of course Gert was not insulting *me* as a person). So, he had no malicious intent. - I admit that I should not have continued the war (note: from point of my objective view it was already started; for others I look like the starter because of the gap above) and wrote my apologies to Gert. - We had some other false pretensions filtered out (some by analysing positive sides, some by statistically). I can almost fully disclose our email exchanges from my side (I was thinking to forward it here instead, if it were written by myself). Those messages are friendly given. Atsushi Eno Gert Driesen wrote: > Atsushi, > > Is that an insult? I've scanned that post several times, and still can't > find the insult. > > I'm sure you can come up with something better than that, no? > > And no, you can't start insulting people and then just say "I stop posting > to this really fruitless thread". > > Gert > > -----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: zaterdag 28 juni 2008 0:48 > To: Gert Driesen > Cc: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] Fw: [Mono-patches] r106776 - in > trunk/mcs/class/System.Configuration: System.Configuration > Test/System.Configuration > > http://lists.ximian.com/pipermail/mono-devel-list/2008-June/028336.html > >> Atsushi, >> >> If you can find ANY, I mean, ANY insult I addressed to you then please > show >> me. >> >> Gert >> >> -----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: zaterdag 28 juni 2008 0:08 >> To: monodanmorg at yahoo.com >> Cc: mono-devel-list at lists.ximian.com >> Subject: Re: [Mono-dev] Fw: [Mono-patches] r106776 - in >> trunk/mcs/class/System.Configuration: System.Configuration >> Test/System.Configuration >> >> As usual, I didn't start insulting posts from my side. Though I'm >> pretty much positive to return the same (and more) words to the starter. >> >> Atsushi Eno >> >> Daniel Morgan wrote: >> >>> Comments from eno like the one below is one of the main reasons I no >>> >> longer felt motivated to contribute to mono. In particular, mono's > ado.net >> implementation. Not that my contributions were worth much, but still it >> belittles anyones' Non-Ximian/Novell contributions to mono... >> >>> --- On Fri, 6/27/08, Atsushi Enomoto (atsushi at ximian.com) >>> >> wrote: >> >>>> From: Atsushi Enomoto (atsushi at ximian.com) >>>> >> >> >>>> Subject: [Mono-patches] r106776 - in >>>> >> trunk/mcs/class/System.Configuration: System.Configuration >> Test/System.Configuration >> >>>> To: mono-patches at lists.ximian.com, ximian.monolist at gmail.com, >>>> >> mono-svn-patches-garchive-20758 at googlegroups.com >> >>>> Date: Friday, June 27, 2008, 4:45 PM >>>> Author: atsushi >>>> Date: 2008-06-27 16:45:49 -0400 (Fri, 27 Jun 2008) >>>> New Revision: 106776 >>>> >>>> Modified: >>>> >>>> trunk/mcs/class/System.Configuration/System.Configuration/ChangeLog >>>> >>>> >>>> > trunk/mcs/class/System.Configuration/System.Configuration/ConfigurationError >> sException.cs >> >>>> >>>> trunk/mcs/class/System.Configuration/Test/System.Configuration/ChangeLog >>>> >>>> >>>> > trunk/mcs/class/System.Configuration/Test/System.Configuration/Configuration >> ErrorsExceptionTest.cs >> >>>> Log: >>>> 2008-06-27 Atsushi Enomoto >>>> >>>> * ConfigurationErrorsException.cs : recover from >>>> silly change that tries to prevent debuggin by >>>> decreasing error location information. >>>> >>>> * ConfigurationErrorsExceptionTest.cs : mark couple >>>> of tests as [Ignore] that blocks us from decent >>>> implementation in the name of silly .NET >>>> compatibility. >>>> >>>> Maybe I'll remove more silliness later. >>>> >>>> >>>> >>>> Modified: >>>> trunk/mcs/class/System.Configuration/System.Configuration/ChangeLog >>>> =================================================================== >>>> --- >>>> trunk/mcs/class/System.Configuration/System.Configuration/ChangeLog >>>> >> 2008-06-27 >> >>>> 20:45:31 UTC (rev 106775) >>>> +++ >>>> trunk/mcs/class/System.Configuration/System.Configuration/ChangeLog >>>> >> 2008-06-27 >> >>>> 20:45:49 UTC (rev 106776) >>>> @@ -1,3 +1,9 @@ >>>> +2008-06-27 Atsushi Enomoto >>>> + >>>> + * ConfigurationErrorsException.cs : recover from >>>> + silly change that tries to prevent debuggin by >>>> + decreasing error location information. >>>> + >>>> 2008-06-26 Gert Driesen >>>> >>>> >>>> * ConfigurationElement.cs: Use >>>> ConfigurationErrorsException instead of >>>> >>>> Modified: >>>> >>>> > trunk/mcs/class/System.Configuration/System.Configuration/ConfigurationError >> sException.cs >> >>>> =================================================================== >>>> --- >>>> >>>> > trunk/mcs/class/System.Configuration/System.Configuration/ConfigurationError >> sException.cs 2008-06-27 >> >>>> 20:45:31 UTC (rev 106775) >>>> +++ >>>> >>>> > trunk/mcs/class/System.Configuration/System.Configuration/ConfigurationError >> sException.cs 2008-06-27 >> >>>> 20:45:49 UTC (rev 106776) >>>> @@ -143,18 +143,21 @@ >>>> // >>>> public static string GetFilename (XmlReader reader) >>>> { >>>> + // FIXME: eliminate this silly compatibility. >>>> if (reader is IConfigErrorInfo) >>>> return ((IConfigErrorInfo) reader).Filename; >>>> - else >>>> - return null; >>>> + >>>> + return reader != null ? reader.BaseURI : null; >>>> } >>>> >>>> public static int GetLineNumber (XmlReader reader) >>>> { >>>> + // FIXME: eliminate this silly compatibility. >>>> if (reader is IConfigErrorInfo) >>>> return ((IConfigErrorInfo) >>>> >> reader).LineNumber; >> >>>> - else >>>> - return 0; >>>> + >>>> + IXmlLineInfo li = reader as IXmlLineInfo; >>>> + return li != null ? li.LineNumber : 0; >>>> } >>>> >>>> public static string GetFilename (XmlNode node) >>>> >>>> Modified: >>>> trunk/mcs/class/System.Configuration/Test/System.Configuration/ChangeLog >>>> =================================================================== >>>> --- >>>> trunk/mcs/class/System.Configuration/Test/System.Configuration/ChangeLog >>>> >> 2008-06-27 >> >>>> 20:45:31 UTC (rev 106775) >>>> +++ >>>> trunk/mcs/class/System.Configuration/Test/System.Configuration/ChangeLog >>>> >> 2008-06-27 >> >>>> 20:45:49 UTC (rev 106776) >>>> @@ -1,3 +1,9 @@ >>>> +2008-06-27 Atsushi Enomoto >>>> + >>>> + * ConfigurationErrorsExceptionTest.cs : mark couple >>>> + of tests as [Ignore] that blocks us from decent >>>> + implementation in the name of silly .NET compatibility. >>>> + >>>> 2008-06-26 Gert Driesen >>>> >>>> >>>> * ConfigurationErrorsExceptionTest.cs: Added tests for >>>> ctors and >>>> >>>> Modified: >>>> >>>> > trunk/mcs/class/System.Configuration/Test/System.Configuration/Configuration >> ErrorsExceptionTest.cs >> >>>> =================================================================== >>>> --- >>>> >>>> > trunk/mcs/class/System.Configuration/Test/System.Configuration/Configuration >> ErrorsExceptionTest.cs 2008-06-27 >> >>>> 20:45:31 UTC (rev 106775) >>>> +++ >>>> >>>> > trunk/mcs/class/System.Configuration/Test/System.Configuration/Configuration >> ErrorsExceptionTest.cs 2008-06-27 >> >>>> 20:45:49 UTC (rev 106776) >>>> @@ -194,6 +194,7 @@ >>>> } >>>> >>>> [Test] // ctor (String, XmlReader) >>>> + [Ignore ("Asserting that the exception has less >>>> information is an idiot's way to go.")] >>>> public void Constructor5 () >>>> { >>>> string msg; >>>> @@ -311,6 +312,7 @@ >>>> } >>>> >>>> [Test] // ctor (String, Exception, XmlReader) >>>> + [Ignore ("Asserting that the exception has less >>>> information is an idiot's way to go.")] >>>> public void Constructor7 () >>>> { >>>> string msg; >>>> @@ -606,6 +608,7 @@ >>>> } >>>> >>>> [Test] // GetFilename (XmlReader) >>>> + [Ignore ("Asserting that the exception has less >>>> information is idiot's way to go.")] >>>> public void GetFilename1 () >>>> { >>>> string xmlfile = Path.Combine (foldername, >>>> "test.xml"); >>>> >>>> _______________________________________________ >>>> Mono-patches maillist - Mono-patches at lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-patches >>>> >>> >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >>> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ > 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 Tue Jul 1 03:54:38 2008 From: csaba.balazs at researchstudio.at (Csaba Balazs) Date: Tue, 01 Jul 2008 09:54:38 +0200 Subject: [Mono-dev] DirectFB and Mono In-Reply-To: References: <4863793E.6010803@ict.tuwien.ac.at> <1214488743.5276.37.camel@limestone> <20080626170253.gsw8gggc80c0s4w8@webmail.researchstudio.at> <20080630144947.gw044s00c0c4gcs0@webmail.researchstudio.at> Message-ID: <20080701095438.4gssock8gwwww40s@webmail.researchstudio.at> Thanks Robert! This was really a signal-handling problem. The DirectFB basically installs a signal handler. We can disable it in /etc/directfbrc file, using the "no-sighandler" or "dont-catch=" options. All-the-best, Csaba Quoting Robert Jordan : > Csaba Balazs wrote: >> The C# application inits first the DirectFB (with C++ library), and starts >> making with Proba_Function garbage string and printing then to screen. . >> If I use the DirectFBCreate command, the whole application fails and >> exit, when >> the mono GC starts, usually after 60-70 garbages. >> >> Why can it happen? The sources are enclosed. > > It seems that directfb is handling SIGXCPU (24) which is already taken > by mono's Boehm GC: > > http://preview.tinyurl.com/3tk3w5 > > There seems to be a "dont-catch=" option but I don't know > how to apply it. > > Robert > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From safknw at gmail.com Tue Jul 1 04:08:06 2008 From: safknw at gmail.com (Sharique uddin Ahmed Farooqui) Date: Tue, 1 Jul 2008 13:38:06 +0530 Subject: [Mono-dev] Linq, Nhibernate or subsonic ? In-Reply-To: <8a7a2d050806281651k6b5f37a8m9e21a7dd3e560793@mail.gmail.com> References: <4da6cf8d0802240327y5602b79exb8181c1fdfe1ba2a@mail.gmail.com> <8a7a2d050802240345q183d5427h6975c1810968dd80@mail.gmail.com> <18070501.post@talk.nabble.com> <4da6cf8d0806281259w66dc03ecq766fd174adde4683@mail.gmail.com> <8a7a2d050806281651k6b5f37a8m9e21a7dd3e560793@mail.gmail.com> Message-ID: <4da6cf8d0807010108y7c33b37am4de9e4e6341dae47@mail.gmail.com> Hi, My experience with NHibernate is not quite good. I spend a week but did not get it working. with subsonic I started working couple of hours. Why we should implement linq to sql. If we don't have it than a lot of applications won't be able to run on mono. On Sun, Jun 29, 2008 at 5:21 AM, Onur Gumus wrote: > yes I did try linq to sql. As a matter of fact at the very beggining > of this conversation, I did told those reflect my opinions only and I > did not want to start a flamewar. Yet I see you are offended. I > certainly understand your pain since it appears to be you love linq to > sql and may be waiting for it's implementation on mono and some guy > just came up and saying hey no need for linq to sql , we' got > nhibernate. > > Frankly side by side technical comparison I still consider nhibernate > superior. For the following reasons: > > NHibenate works with almost every database and you can develop true > database independent applications. For instance when you finish your > product's coding you can deliver it for different databases. Same > cannot be applied to linq to sql which only works for sql server. Sure > there are implementations for postgress as well but you stick to one > database and cannot further modify it. > > traditionally nhibernate uses criteria and hql based queries which > look weird compared to linq's static typing power. But then now we > have linq to nhibernate functional and running. > > Furthermore you are incorrect about xml because nhibernate supports > Attribute based mapping and another option is Castle ActiveRecord. > Where you can do the mapping with 0 XML. That's what I do. > > linq to sql is more data centric approach. You first create your > database and from there you generate your classes via sql metal. And > the generated code is messy. NHibernate uses domain driven approach > which is better for larger scale applications. Namely you totally > ignore the existence of your database and just write you classes > (including interfaces and your inheritence tree). Then you make your > mapping finally you tell nhibernate create the tables for you. It is > much more powerful than what linq to sql is capable of. Also linq to > sql can only have 1 type of mapping for inheritence where as > nhibernate supports 3 types . see how inheritence is applied to both. > And I don't think linq to sql supports persistance for your > "interfaces" > > For databinding to gui I use my modified object data source which is > just good. But there are other solutions like > http://www.codeproject.com/KB/aspnet/NHibernateDataSource.aspx for > web applications . > > that's just my 2 cents > > > > > > > On Sat, Jun 28, 2008 at 10:59 PM, Sharique uddin Ahmed Farooqui > wrote: >> Thanks nicole. >> I'm using sunsonic. It is quite easy to learn and it works with .net >> 2.0 and mono as well. >> I'll suggest Subsonic other as well. >> >> On Mon, Jun 23, 2008 at 8:01 PM, nicolasdiazaragon >> wrote: >>> >>> What do you mean by saying that not yet having linq to sql isn?t a big loss >>> and that it can be replaced by using nhibernate? >>> Have you tried linq to sql? have you compared it to using hibernate? >>> Maybe if all you code is meant to be part of some desktop application, then >>> you are fine with hibernate. But if you intend to build real enterprise >>> applications, then you should use linq to sql. Not only does it make code >>> more simple and easy to read, it gets things done faster than hibernate does >>> and you don't have to bother writing boring XML files. And it let?s you use >>> nameless class types while querying the data base. These nameless classes >>> can then be bound to a GUI control or used for further processing. Try doing >>> that with hibernate... you would have to perform very expensive castings >>> (all your query results are strongly typed in linq to sql, but not in >>> hibernate... everything returned by a hibernate query is just an >>> 'object'...) and there is absolutely no WAY to use nameless types while >>> querying the database with hibernate. >>> I've been writing java code since I was a 14 year old. I begun coding JEE at >>> the same time I became acquainted with the dot net framework. By the time >>> linq to sql was released (a couple of years later) I was very dissapointed >>> because I realized that the dot net framework had leaped light years ahead >>> of java (my personal favorite until then). >>> So no linq to sql support is a huge loss to me. If I were to code some >>> enterprise application without linq to sql support, I?d rather work on JEE >>> than on dot net. >>> >>> >>> reverse blade wrote: >>>> >>>> Before comparing the technical merits you should consider that "Linq to >>>> SQL" >>>> is not supported by mono at the moment.(Which is not a big loss for me >>>> anyway). Linq is the general name given to linq bindings and currently we >>>> have : Linq to Objects, Linq to Sql, Linq to XML, Linq to JSON, Linq to >>>> NHibernate, Linq to DB4O, etc ... bindings are available if I recall >>>> correctly. >>>> >>>> For subsonic and NHibernate , I never used subsonic on mono but I've read >>>> it >>>> was working on mono. On the other hand, I used NHibernate extensively on >>>> mono/linux/postgresql and I am quite happy with it. >>>> >>>> Finally, Nhibernate does support stored procs but triggers and views are >>>> not >>>> supported by any of these frameworks directly. NHibernate offers >>>> interceptors for intercepting your db transactions before it hits to db's >>>> so >>>> in a way it emulates triggers that way. Still however you can use triggers >>>> independently. Not sure how others handle it. Finally it took 1 full month >>>> for me to feel myself comfortable with NHibernate due to it's high >>>> complexity (or may be I am not smart enough), but it was well worth. >>>> >>>> >>>> >>>> just my 2 cents >>>> >>>> Onur >>>> >>>> 2008/2/24 Sharique uddin Ahmed Farooqui : >>>> >>>>> Hi, >>>>> >>>>> I'm planning to build an ERP for my organisation. We will use mono as >>>>> primary development platform. I'm a bit confused abt what should for DAL. >>>>> I >>>>> know little abt linq . >>>>> What I have decided for DAL is >>>>> 1. auto generated code must be extend able either in same class or as a >>>>> separate class. >>>>> 2. It must expose all databse views, triggers, stored procedures in DAL. >>>>> >>>>> >>>>> Pls help me find out the right thing. >>>>> >>>>> Thanks. >>>>> -- >>>>> Sharique uddin Ahmed Farooqui >>>>> (C++/C# Developer, IT Consultant) >>>>> A revolution is about to begin. >>>>> A world is about to change. >>>>> And you and I are "the initiator". >>>>> _______________________________________________ >>>>> Mono-devel-list mailing list >>>>> Mono-devel-list at lists.ximian.com >>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Mono-devel-list mailing list >>>> Mono-devel-list at lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> >>>> >>> >>> -- >>> View this message in context: http://www.nabble.com/Linq%2C-Nhibernate-or-subsonic---tp16138540p18070501.html >>> Sent from the Mono - Dev mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >> >> >> >> -- >> Sharique uddin Ahmed Farooqui >> (C++/C# Developer, IT Consultant) >> http://safknw.blogspot.com/ >> "Peace" is the Ultimate thing we want. >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > -- Sharique uddin Ahmed Farooqui (C++/C# Developer, IT Consultant) http://safknw.blogspot.com/ "Peace" is the Ultimate thing we want. From kornelpal at gmail.com Tue Jul 1 04:34:37 2008 From: kornelpal at gmail.com (=?ISO-8859-1?Q?Korn=E9l_P=E1l?=) Date: Tue, 01 Jul 2008 10:34:37 +0200 Subject: [Mono-dev] Fw: [Mono-patches] r106776 - in trunk/mcs/class/System.Configuration: System.Configuration Test/System.Configuration In-Reply-To: <4869CA7E.4070104@ximian.com> References: <846488.47860.qm@web30803.mail.mud.yahoo.com> <486564C0.9020701@ximian.com> <005d01c8d8a7$111c8940$33559bc0$@driesen@telenet.be> <48656E05.8040700@ximian.com> <006d01c8d8a9$15369370$3fa3ba50$@driesen@telenet.be> <4869CA7E.4070104@ximian.com> Message-ID: <4869EC1D.2030905@gmail.com> Hi, I know from my own experience that if two of us have a debate about something it's quite easy to take it personally but the other people just don't interfere because they know that this isn't really about personal insults. Anyway the problem that appears time to time is whether we should be 100% MS.NET compatible or should produce software that is superior to MS.NET even at the cost of incompatibility. Compatibility means functional compatibility not just implementing what is documented. And I think that this is what Gert tried to do. On the other hand - as I see - you defend that Mono is independent software that should function correctly. This latter point of view would be the best choice but Microsoft usually closes their bugs as "this is by design" or "we don't want to change this in the near future" so even if we correct bugs MS.NET will remain incompatible. MS.NET compatibility is one of our highest priority tasks but is a very difficult question but I think we still have no policy regarding MS.NET compatibility. Korn?l Atsushi Eno wrote: > We had some email exchanges about this, and sorted out some agreement. > - It indeed sounds insult when someone gives (negative) evaluation on > others' personality in Japan, while it does not sound so in other > areas (and of course Gert was not insulting *me* as a person). So, > he had no malicious intent. > - I admit that I should not have continued the war (note: from point > of my objective view it was already started; for others I look like > the starter because of the gap above) and wrote my apologies to Gert. > - We had some other false pretensions filtered out (some by > analysing positive sides, some by statistically). > > I can almost fully disclose our email exchanges from my side (I was > thinking to forward it here instead, if it were written by myself). > Those messages are friendly given. > > Atsushi Eno From gert.driesen at telenet.be Tue Jul 1 05:16:49 2008 From: gert.driesen at telenet.be (Gert Driesen) Date: Tue, 1 Jul 2008 11:16:49 +0200 Subject: [Mono-dev] Fw: [Mono-patches] r106776 - in trunk/mcs/class/System.Configuration: System.Configuration Test/System.Configuration In-Reply-To: <4869CA7E.4070104@ximian.com> References: <846488.47860.qm@web30803.mail.mud.yahoo.com> <486564C0.9020701@ximian.com> <005d01c8d8a7$111c8940$33559bc0$@driesen@telenet.be> <48656E05.8040700@ximian.com> <006d01c8d8a9$15369370$3fa3ba50$@driesen@telenet.be> <4869CA7E.4070104@ximian.com> Message-ID: <001d01c8db5b$3189cb00$949d6100$@driesen@telenet.be> Hey Atsushi, Let's forget about this incident, and focus our energy on the 2.0 release. Gert -----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: dinsdag 1 juli 2008 8:11 To: mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] Fw: [Mono-patches] r106776 - in trunk/mcs/class/System.Configuration: System.Configuration Test/System.Configuration We had some email exchanges about this, and sorted out some agreement. - It indeed sounds insult when someone gives (negative) evaluation on others' personality in Japan, while it does not sound so in other areas (and of course Gert was not insulting *me* as a person). So, he had no malicious intent. - I admit that I should not have continued the war (note: from point of my objective view it was already started; for others I look like the starter because of the gap above) and wrote my apologies to Gert. - We had some other false pretensions filtered out (some by analysing positive sides, some by statistically). I can almost fully disclose our email exchanges from my side (I was thinking to forward it here instead, if it were written by myself). Those messages are friendly given. Atsushi Eno Gert Driesen wrote: > Atsushi, > > Is that an insult? I've scanned that post several times, and still can't > find the insult. > > I'm sure you can come up with something better than that, no? > > And no, you can't start insulting people and then just say "I stop posting > to this really fruitless thread". > > Gert > > -----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: zaterdag 28 juni 2008 0:48 > To: Gert Driesen > Cc: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] Fw: [Mono-patches] r106776 - in > trunk/mcs/class/System.Configuration: System.Configuration > Test/System.Configuration > > http://lists.ximian.com/pipermail/mono-devel-list/2008-June/028336.html > >> Atsushi, >> >> If you can find ANY, I mean, ANY insult I addressed to you then please > show >> me. >> >> Gert >> >> -----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: zaterdag 28 juni 2008 0:08 >> To: monodanmorg at yahoo.com >> Cc: mono-devel-list at lists.ximian.com >> Subject: Re: [Mono-dev] Fw: [Mono-patches] r106776 - in >> trunk/mcs/class/System.Configuration: System.Configuration >> Test/System.Configuration >> >> As usual, I didn't start insulting posts from my side. Though I'm >> pretty much positive to return the same (and more) words to the starter. >> >> Atsushi Eno >> >> Daniel Morgan wrote: >> >>> Comments from eno like the one below is one of the main reasons I no >>> >> longer felt motivated to contribute to mono. In particular, mono's > ado.net >> implementation. Not that my contributions were worth much, but still it >> belittles anyones' Non-Ximian/Novell contributions to mono... >> >>> --- On Fri, 6/27/08, Atsushi Enomoto (atsushi at ximian.com) >>> >> wrote: >> >>>> From: Atsushi Enomoto (atsushi at ximian.com) >>>> >> >> >>>> Subject: [Mono-patches] r106776 - in >>>> >> trunk/mcs/class/System.Configuration: System.Configuration >> Test/System.Configuration >> >>>> To: mono-patches at lists.ximian.com, ximian.monolist at gmail.com, >>>> >> mono-svn-patches-garchive-20758 at googlegroups.com >> >>>> Date: Friday, June 27, 2008, 4:45 PM >>>> Author: atsushi >>>> Date: 2008-06-27 16:45:49 -0400 (Fri, 27 Jun 2008) >>>> New Revision: 106776 >>>> >>>> Modified: >>>> >>>> trunk/mcs/class/System.Configuration/System.Configuration/ChangeLog >>>> >>>> >>>> > trunk/mcs/class/System.Configuration/System.Configuration/ConfigurationError >> sException.cs >> >>>> >>>> trunk/mcs/class/System.Configuration/Test/System.Configuration/ChangeLog >>>> >>>> >>>> > trunk/mcs/class/System.Configuration/Test/System.Configuration/Configuration >> ErrorsExceptionTest.cs >> >>>> Log: >>>> 2008-06-27 Atsushi Enomoto >>>> >>>> * ConfigurationErrorsException.cs : recover from >>>> silly change that tries to prevent debuggin by >>>> decreasing error location information. >>>> >>>> * ConfigurationErrorsExceptionTest.cs : mark couple >>>> of tests as [Ignore] that blocks us from decent >>>> implementation in the name of silly .NET >>>> compatibility. >>>> >>>> Maybe I'll remove more silliness later. >>>> >>>> >>>> >>>> Modified: >>>> trunk/mcs/class/System.Configuration/System.Configuration/ChangeLog >>>> =================================================================== >>>> --- >>>> trunk/mcs/class/System.Configuration/System.Configuration/ChangeLog >>>> >> 2008-06-27 >> >>>> 20:45:31 UTC (rev 106775) >>>> +++ >>>> trunk/mcs/class/System.Configuration/System.Configuration/ChangeLog >>>> >> 2008-06-27 >> >>>> 20:45:49 UTC (rev 106776) >>>> @@ -1,3 +1,9 @@ >>>> +2008-06-27 Atsushi Enomoto >>>> + >>>> + * ConfigurationErrorsException.cs : recover from >>>> + silly change that tries to prevent debuggin by >>>> + decreasing error location information. >>>> + >>>> 2008-06-26 Gert Driesen >>>> >>>> >>>> * ConfigurationElement.cs: Use >>>> ConfigurationErrorsException instead of >>>> >>>> Modified: >>>> >>>> > trunk/mcs/class/System.Configuration/System.Configuration/ConfigurationError >> sException.cs >> >>>> =================================================================== >>>> --- >>>> >>>> > trunk/mcs/class/System.Configuration/System.Configuration/ConfigurationError >> sException.cs 2008-06-27 >> >>>> 20:45:31 UTC (rev 106775) >>>> +++ >>>> >>>> > trunk/mcs/class/System.Configuration/System.Configuration/ConfigurationError >> sException.cs 2008-06-27 >> >>>> 20:45:49 UTC (rev 106776) >>>> @@ -143,18 +143,21 @@ >>>> // >>>> public static string GetFilename (XmlReader reader) >>>> { >>>> + // FIXME: eliminate this silly compatibility. >>>> if (reader is IConfigErrorInfo) >>>> return ((IConfigErrorInfo) reader).Filename; >>>> - else >>>> - return null; >>>> + >>>> + return reader != null ? reader.BaseURI : null; >>>> } >>>> >>>> public static int GetLineNumber (XmlReader reader) >>>> { >>>> + // FIXME: eliminate this silly compatibility. >>>> if (reader is IConfigErrorInfo) >>>> return ((IConfigErrorInfo) >>>> >> reader).LineNumber; >> >>>> - else >>>> - return 0; >>>> + >>>> + IXmlLineInfo li = reader as IXmlLineInfo; >>>> + return li != null ? li.LineNumber : 0; >>>> } >>>> >>>> public static string GetFilename (XmlNode node) >>>> >>>> Modified: >>>> trunk/mcs/class/System.Configuration/Test/System.Configuration/ChangeLog >>>> =================================================================== >>>> --- >>>> trunk/mcs/class/System.Configuration/Test/System.Configuration/ChangeLog >>>> >> 2008-06-27 >> >>>> 20:45:31 UTC (rev 106775) >>>> +++ >>>> trunk/mcs/class/System.Configuration/Test/System.Configuration/ChangeLog >>>> >> 2008-06-27 >> >>>> 20:45:49 UTC (rev 106776) >>>> @@ -1,3 +1,9 @@ >>>> +2008-06-27 Atsushi Enomoto >>>> + >>>> + * ConfigurationErrorsExceptionTest.cs : mark couple >>>> + of tests as [Ignore] that blocks us from decent >>>> + implementation in the name of silly .NET compatibility. >>>> + >>>> 2008-06-26 Gert Driesen >>>> >>>> >>>> * ConfigurationErrorsExceptionTest.cs: Added tests for >>>> ctors and >>>> >>>> Modified: >>>> >>>> > trunk/mcs/class/System.Configuration/Test/System.Configuration/Configuration >> ErrorsExceptionTest.cs >> >>>> =================================================================== >>>> --- >>>> >>>> > trunk/mcs/class/System.Configuration/Test/System.Configuration/Configuration >> ErrorsExceptionTest.cs 2008-06-27 >> >>>> 20:45:31 UTC (rev 106775) >>>> +++ >>>> >>>> > trunk/mcs/class/System.Configuration/Test/System.Configuration/Configuration >> ErrorsExceptionTest.cs 2008-06-27 >> >>>> 20:45:49 UTC (rev 106776) >>>> @@ -194,6 +194,7 @@ >>>> } >>>> >>>> [Test] // ctor (String, XmlReader) >>>> + [Ignore ("Asserting that the exception has less >>>> information is an idiot's way to go.")] >>>> public void Constructor5 () >>>> { >>>> string msg; >>>> @@ -311,6 +312,7 @@ >>>> } >>>> >>>> [Test] // ctor (String, Exception, XmlReader) >>>> + [Ignore ("Asserting that the exception has less >>>> information is an idiot's way to go.")] >>>> public void Constructor7 () >>>> { >>>> string msg; >>>> @@ -606,6 +608,7 @@ >>>> } >>>> >>>> [Test] // GetFilename (XmlReader) >>>> + [Ignore ("Asserting that the exception has less >>>> information is idiot's way to go.")] >>>> public void GetFilename1 () >>>> { >>>> string xmlfile = Path.Combine (foldername, >>>> "test.xml"); >>>> >>>> _______________________________________________ >>>> Mono-patches maillist - Mono-patches at lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-patches >>>> >>> >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >>> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From atsushi at ximian.com Tue Jul 1 05:17:22 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Tue, 01 Jul 2008 18:17:22 +0900 Subject: [Mono-dev] Fw: [Mono-patches] r106776 - in trunk/mcs/class/System.Configuration: System.Configuration Test/System.Configuration In-Reply-To: <4869EC1D.2030905@gmail.com> References: <846488.47860.qm@web30803.mail.mud.yahoo.com> <486564C0.9020701@ximian.com> <005d01c8d8a7$111c8940$33559bc0$@driesen@telenet.be> <48656E05.8040700@ximian.com> <006d01c8d8a9$15369370$3fa3ba50$@driesen@telenet.be> <4869CA7E.4070104@ximian.com> <4869EC1D.2030905@gmail.com> Message-ID: <4869F622.9090808@ximian.com> Hello, Korn?l P?l wrote: > Hi, > > I know from my own experience that if two of us have a debate about > something it's quite easy to take it personally but the other people > just don't interfere because they know that this isn't really about > personal insults. It is not really the case (and hence your post look totally off topic). > Anyway the problem that appears time to time is whether we should be > 100% MS.NET compatible or should produce software that is superior to > MS.NET even at the cost of incompatibility. > > Compatibility means functional compatibility not just implementing what > is documented. And I think that this is what Gert tried to do. You didn't read relevant document this time. It is *me* who fixed the code to match the documentation. > On the other hand - as I see - you defend that Mono is independent > software that should function correctly. > > This latter point of view would be the best choice but Microsoft usually > closes their bugs as "this is by design" or "we don't want to change > this in the near future" so even if we correct bugs MS.NET will remain > incompatible. No. I agree there are some weird managers who reject fixing any bugs, but for others they have fair mind and glad to fix their bugs unlike you guess. Atsushi Eno From kornelpal at gmail.com Tue Jul 1 05:37:13 2008 From: kornelpal at gmail.com (=?ISO-8859-1?Q?Korn=E9l_P=E1l?=) Date: Tue, 01 Jul 2008 11:37:13 +0200 Subject: [Mono-dev] Fw: [Mono-patches] r106776 - in trunk/mcs/class/System.Configuration: System.Configuration Test/System.Configuration In-Reply-To: <4869F622.9090808@ximian.com> References: <846488.47860.qm@web30803.mail.mud.yahoo.com> <486564C0.9020701@ximian.com> <005d01c8d8a7$111c8940$33559bc0$@driesen@telenet.be> <48656E05.8040700@ximian.com> <006d01c8d8a9$15369370$3fa3ba50$@driesen@telenet.be> <4869CA7E.4070104@ximian.com> <4869EC1D.2030905@gmail.com> <4869F622.9090808@ximian.com> Message-ID: <4869FAC9.4020304@gmail.com> Hi, > You didn't read relevant document this time. It is *me* who fixed > the code to match the documentation. I'm sorry for that. > No. I agree there are some weird managers who reject fixing any bugs, > but for others they have fair mind and glad to fix their bugs unlike > you guess. Good for you. Unfortunately I haven't meet them. According to my experiences they gladly correct documentation but like to defer fixing bugs to later releases. Korn?l From emperon at gmail.com Tue Jul 1 06:32:58 2008 From: emperon at gmail.com (Onur Gumus) Date: Tue, 1 Jul 2008 13:32:58 +0300 Subject: [Mono-dev] Linq, Nhibernate or subsonic ? In-Reply-To: <4da6cf8d0807010108y7c33b37am4de9e4e6341dae47@mail.gmail.com> References: <4da6cf8d0802240327y5602b79exb8181c1fdfe1ba2a@mail.gmail.com> <8a7a2d050802240345q183d5427h6975c1810968dd80@mail.gmail.com> <18070501.post@talk.nabble.com> <4da6cf8d0806281259w66dc03ecq766fd174adde4683@mail.gmail.com> <8a7a2d050806281651k6b5f37a8m9e21a7dd3e560793@mail.gmail.com> <4da6cf8d0807010108y7c33b37am4de9e4e6341dae47@mail.gmail.com> Message-ID: <8a7a2d050807010332x7551b61ex5e08150c0cb100d3@mail.gmail.com> Because NHiberate is hard. I mean really hard. If you want something "install and go" try castle active record On Tue, Jul 1, 2008 at 11:08 AM, Sharique uddin Ahmed Farooqui wrote: > Hi, > My experience with NHibernate is not quite good. I spend a week but > did not get it working. with subsonic I started working couple of > hours. > Why we should implement linq to sql. If we don't have it than a lot of > applications won't be able to run on mono. > > On Sun, Jun 29, 2008 at 5:21 AM, Onur Gumus wrote: >> yes I did try linq to sql. As a matter of fact at the very beggining >> of this conversation, I did told those reflect my opinions only and I >> did not want to start a flamewar. Yet I see you are offended. I >> certainly understand your pain since it appears to be you love linq to >> sql and may be waiting for it's implementation on mono and some guy >> just came up and saying hey no need for linq to sql , we' got >> nhibernate. >> >> Frankly side by side technical comparison I still consider nhibernate >> superior. For the following reasons: >> >> NHibenate works with almost every database and you can develop true >> database independent applications. For instance when you finish your >> product's coding you can deliver it for different databases. Same >> cannot be applied to linq to sql which only works for sql server. Sure >> there are implementations for postgress as well but you stick to one >> database and cannot further modify it. >> >> traditionally nhibernate uses criteria and hql based queries which >> look weird compared to linq's static typing power. But then now we >> have linq to nhibernate functional and running. >> >> Furthermore you are incorrect about xml because nhibernate supports >> Attribute based mapping and another option is Castle ActiveRecord. >> Where you can do the mapping with 0 XML. That's what I do. >> >> linq to sql is more data centric approach. You first create your >> database and from there you generate your classes via sql metal. And >> the generated code is messy. NHibernate uses domain driven approach >> which is better for larger scale applications. Namely you totally >> ignore the existence of your database and just write you classes >> (including interfaces and your inheritence tree). Then you make your >> mapping finally you tell nhibernate create the tables for you. It is >> much more powerful than what linq to sql is capable of. Also linq to >> sql can only have 1 type of mapping for inheritence where as >> nhibernate supports 3 types . see how inheritence is applied to both. >> And I don't think linq to sql supports persistance for your >> "interfaces" >> >> For databinding to gui I use my modified object data source which is >> just good. But there are other solutions like >> http://www.codeproject.com/KB/aspnet/NHibernateDataSource.aspx for >> web applications . >> >> that's just my 2 cents >> >> >> >> >> >> >> On Sat, Jun 28, 2008 at 10:59 PM, Sharique uddin Ahmed Farooqui >> wrote: >>> Thanks nicole. >>> I'm using sunsonic. It is quite easy to learn and it works with .net >>> 2.0 and mono as well. >>> I'll suggest Subsonic other as well. >>> >>> On Mon, Jun 23, 2008 at 8:01 PM, nicolasdiazaragon >>> wrote: >>>> >>>> What do you mean by saying that not yet having linq to sql isn?t a big loss >>>> and that it can be replaced by using nhibernate? >>>> Have you tried linq to sql? have you compared it to using hibernate? >>>> Maybe if all you code is meant to be part of some desktop application, then >>>> you are fine with hibernate. But if you intend to build real enterprise >>>> applications, then you should use linq to sql. Not only does it make code >>>> more simple and easy to read, it gets things done faster than hibernate does >>>> and you don't have to bother writing boring XML files. And it let?s you use >>>> nameless class types while querying the data base. These nameless classes >>>> can then be bound to a GUI control or used for further processing. Try doing >>>> that with hibernate... you would have to perform very expensive castings >>>> (all your query results are strongly typed in linq to sql, but not in >>>> hibernate... everything returned by a hibernate query is just an >>>> 'object'...) and there is absolutely no WAY to use nameless types while >>>> querying the database with hibernate. >>>> I've been writing java code since I was a 14 year old. I begun coding JEE at >>>> the same time I became acquainted with the dot net framework. By the time >>>> linq to sql was released (a couple of years later) I was very dissapointed >>>> because I realized that the dot net framework had leaped light years ahead >>>> of java (my personal favorite until then). >>>> So no linq to sql support is a huge loss to me. If I were to code some >>>> enterprise application without linq to sql support, I?d rather work on JEE >>>> than on dot net. >>>> >>>> >>>> reverse blade wrote: >>>>> >>>>> Before comparing the technical merits you should consider that "Linq to >>>>> SQL" >>>>> is not supported by mono at the moment.(Which is not a big loss for me >>>>> anyway). Linq is the general name given to linq bindings and currently we >>>>> have : Linq to Objects, Linq to Sql, Linq to XML, Linq to JSON, Linq to >>>>> NHibernate, Linq to DB4O, etc ... bindings are available if I recall >>>>> correctly. >>>>> >>>>> For subsonic and NHibernate , I never used subsonic on mono but I've read >>>>> it >>>>> was working on mono. On the other hand, I used NHibernate extensively on >>>>> mono/linux/postgresql and I am quite happy with it. >>>>> >>>>> Finally, Nhibernate does support stored procs but triggers and views are >>>>> not >>>>> supported by any of these frameworks directly. NHibernate offers >>>>> interceptors for intercepting your db transactions before it hits to db's >>>>> so >>>>> in a way it emulates triggers that way. Still however you can use triggers >>>>> independently. Not sure how others handle it. Finally it took 1 full month >>>>> for me to feel myself comfortable with NHibernate due to it's high >>>>> complexity (or may be I am not smart enough), but it was well worth. >>>>> >>>>> >>>>> >>>>> just my 2 cents >>>>> >>>>> Onur >>>>> >>>>> 2008/2/24 Sharique uddin Ahmed Farooqui : >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm planning to build an ERP for my organisation. We will use mono as >>>>>> primary development platform. I'm a bit confused abt what should for DAL. >>>>>> I >>>>>> know little abt linq . >>>>>> What I have decided for DAL is >>>>>> 1. auto generated code must be extend able either in same class or as a >>>>>> separate class. >>>>>> 2. It must expose all databse views, triggers, stored procedures in DAL. >>>>>> >>>>>> >>>>>> Pls help me find out the right thing. >>>>>> >>>>>> Thanks. >>>>>> -- >>>>>> Sharique uddin Ahmed Farooqui >>>>>> (C++/C# Developer, IT Consultant) >>>>>> A revolution is about to begin. >>>>>> A world is about to change. >>>>>> And you and I are "the initiator". >>>>>> _______________________________________________ >>>>>> Mono-devel-list mailing list >>>>>> Mono-devel-list at lists.ximian.com >>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Mono-devel-list mailing list >>>>> Mono-devel-list at lists.ximian.com >>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: http://www.nabble.com/Linq%2C-Nhibernate-or-subsonic---tp16138540p18070501.html >>>> Sent from the Mono - Dev mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> Mono-devel-list mailing list >>>> Mono-devel-list at lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> >>> >>> >>> >>> -- >>> Sharique uddin Ahmed Farooqui >>> (C++/C# Developer, IT Consultant) >>> http://safknw.blogspot.com/ >>> "Peace" is the Ultimate thing we want. >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >> > > > > -- > Sharique uddin Ahmed Farooqui > (C++/C# Developer, IT Consultant) > http://safknw.blogspot.com/ > "Peace" is the Ultimate thing we want. > From gert.driesen at telenet.be Tue Jul 1 12:59:55 2008 From: gert.driesen at telenet.be (Gert Driesen) Date: Tue, 01 Jul 2008 18:59:55 +0200 Subject: [Mono-dev] [PATCH] HttpWebResponse: Add missing disposed checks Message-ID: <1214931595.24081.5.camel@brother.home.be> Hey, The attached patch adds several missing disposed checks, and initializes the contentLength field in the ctor. All changes are covered by unit tests that also pass on MS (1.1 SP1/2.0 SP1). Let me know if it's ok to commit. Gert -------------- next part -------------- A non-text attachment was scrubbed... Name: httpwebresponse.patch Type: text/x-patch Size: 24409 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080701/615b2622/attachment-0001.bin From davidiw at ufl.edu Tue Jul 1 13:21:18 2008 From: davidiw at ufl.edu (David Wolinsky) Date: Tue, 01 Jul 2008 13:21:18 -0400 Subject: [Mono-dev] Memory Model? Message-ID: <486A678E.2050208@ufl.edu> I am so entirely confused about what the memory model for Mono is. If we are using gmcs can we assume .Net 2.0 Framework or are we safe always falling back on what ECMA says? This article ( http://msdn.microsoft.com/en-us/magazine/cc163715.aspx ) makes me want to code for ECMA and not .Net, but we have a project that was already coded for the .Net memory model and it is having issues in Mono that are incredibly difficult to track down! This post ( http://lists.ximian.com/pipermail/mono-devel-list/2008-May/027885.html ) doesn't help but confuse me more. Is there somewhere where this is listed now, if not could you put up the memory models used by Mono on www.mono-project.org? Cheers, David From twiest at novell.com Tue Jul 1 14:30:56 2008 From: twiest at novell.com (Thomas Wiest) Date: Tue, 01 Jul 2008 12:30:56 -0600 Subject: [Mono-dev] [Ximian-mono-list] Moonlight-bugs list In-Reply-To: <1214860649.5276.88.camel@limestone> References: <1214860649.5276.88.camel@limestone> Message-ID: <486A77E0.1070906@novell.com> I have changed all of the Owner and QA Contact e-mail addresses for the Moonlight component over to the new moonlight-bugs list. Thomas Geoff Norton wrote: > Hey all, > > I've created a new list (moonlight-bugs at lists.ximian.com) at the > request of Rusty. In the near future all moonlight bugs emails will be > moved there so you likely want to subscribe now. > > If you have any problems please email me directly. > > -g > > > _______________________________________________ > Ximian-mono-list mailing list > Ximian-mono-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/ximian-mono-list > From miguel at novell.com Tue Jul 1 16:28:44 2008 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 01 Jul 2008 16:28:44 -0400 Subject: [Mono-dev] What is the status of the Windows x64 port? In-Reply-To: <37c5788d0806301355g787211berfcc12365894a0fc7@mail.gmail.com> References: <48691055.9040902@gmail.com> <17c2d80b0806301137w438bc02r4c0b5f1aa0100d39@mail.gmail.com> <37c5788d0806301355g787211berfcc12365894a0fc7@mail.gmail.com> Message-ID: <1214944124.19234.205.camel@frost> > Given the tentative release schedule from Miguel and the rate problems > are being addressed we will not be done with the x64 port at the > branch (July 14.) I have not spoke with anyone else on the team about > if work will be allowed to continue in the branch for the 2.0 release. It will depend on the nature of the changes; If they are isolated to the Windows/64 section of the code, we would likely just backport those changes. Miguel. From miguel at novell.com Tue Jul 1 16:39:25 2008 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 01 Jul 2008 16:39:25 -0400 Subject: [Mono-dev] .NET compatibility policy. In-Reply-To: <4869EC1D.2030905@gmail.com> References: <846488.47860.qm@web30803.mail.mud.yahoo.com> <486564C0.9020701@ximian.com> <005d01c8d8a7$111c8940$33559bc0$@driesen@telenet.be> <48656E05.8040700@ximian.com> <006d01c8d8a9$15369370$3fa3ba50$@driesen@telenet.be> <4869CA7E.4070104@ximian.com> <4869EC1D.2030905@gmail.com> Message-ID: <1214944765.19234.217.camel@frost> Hello, The following is extracted from an internal email discussion. As a policy, for .NET APIs, unless there is a *strong* reason not to be compatible, we should be compatible with the .NET APIs. And this means, that we need as a group to reach consensus on this, and not have one-off ad-hoc decisions. Some strong reasons to deviate from compatibility might include, but are not limited: * The mapping to Unix would be too difficult. * The API makes no sense in a cross-platform way. * A patent that we have to circumvent. Compatibility not only brings more applications to Linux and helps enhance the software ecosystem in Linux, it brings developers, it causes less surprises, it causes less problems for developers, it reduces our documentation, "FAQ" or "gotcha" problems. We need to have a really good reason to not be compatible in some area. We are completely free to innovate, create new solutions or go beyond what Microsoft has done and be better in our own stack, in the open source stack. Mono.ZeroConf, Mono.Addins, Mono.Cecil, Mono.WebBrowser are good examples of these things. Additionally, if we believe that there is a strong reason to offer an alternative road but that shares much of the code, we could share the code, but have a new assembly name and share the code through a mix of picking the right files for the build, partial classes or conditional compilation (similar to what is being done with DBLinq to support both System.Data.Linq and DBLinq's own database abstraction layer). Miguel. From calberto.cortez at gmail.com Tue Jul 1 15:23:38 2008 From: calberto.cortez at gmail.com (Carlos Alberto Cortez) Date: Tue, 01 Jul 2008 14:23:38 -0500 Subject: [Mono-dev] [Patch] Implement basic AutoComplete support for ComboBox Message-ID: <1214940218.4251.12.camel@heaven.site> Hey! Attached is a patch that implements support for ComboBox. The idea is to use the available support in TextBox, so the TextBox has direct access to our items. Since this is not the clearest approach, it's the better in terms of performance, since otherwise we should create a IList of item's text, and modifying or updating it as items are modified in ComboBox.Items collection. Observe that this patch only makes use of the basic properties of Auto complete in TextBox. As soon as I check in the keyboard navigation in TextBox for automplete, I will come with a second patch for ComboBox ;-) Carlos. -------------- next part -------------- A non-text attachment was scrubbed... Name: cb-autocomplete.patch Type: text/x-patch Size: 4044 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080701/7b771549/attachment.bin From monkey at jpobst.com Tue Jul 1 17:48:20 2008 From: monkey at jpobst.com (Jonathan Pobst) Date: Tue, 01 Jul 2008 16:48:20 -0500 Subject: [Mono-dev] [Patch] Implement basic AutoComplete support for ComboBox In-Reply-To: <1214940218.4251.12.camel@heaven.site> References: <1214940218.4251.12.camel@heaven.site> Message-ID: <486AA624.1020206@jpobst.com> Looks fine. Please commit. Jonathan Carlos Alberto Cortez wrote: > Hey! > > Attached is a patch that implements support for ComboBox. > > The idea is to use the available support in TextBox, so the TextBox has > direct access to our items. Since this is not the clearest approach, > it's the better in terms of performance, since otherwise we should > create a IList of item's text, and modifying or updating it as items are > modified in ComboBox.Items collection. > > Observe that this patch only makes use of the basic properties of Auto > complete in TextBox. As soon as I check in the keyboard navigation in > TextBox for automplete, I will come with a second patch for ComboBox ;-) > > Carlos. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From mono-devel at arnorehn.de Tue Jul 1 19:24:46 2008 From: mono-devel at arnorehn.de (Arno Rehn) Date: Wed, 2 Jul 2008 01:24:46 +0200 Subject: [Mono-dev] Segfault on mono_jit_cleanup Message-ID: <200807020124.46610.mono-devel@arnorehn.de> Hi, I hope this is the right place for this question: Currently I'm working on providing a Mono plugin factory for KDE. I've followed the instructions for embedding Mono in the wiki and it works quite well, up to the point where I want to call mono_jit_cleanup(). It segfaults with the following stacktrace: ** ** ERROR:(../../mono/io-layer/handles- private.h:160):_wapi_handle_set_signal_state: assertion failed: (thr_ret == 0) Stacktrace: Native stacktrace: /usr/lib64/pkgconfig/../../lib64/libmono.so.0 [0x2aaab171505e] /lib64/libpthread.so.0 [0x2b868685c340] /lib64/libc.so.6(gsignal+0x35) [0x2b868d67f535] /lib64/libc.so.6(abort+0x110) [0x2b868d6809e0] /usr/lib64/pkgconfig/../../lib64/libglib-2.0.so.0(g_assertion_message+0x104) [0x2aaab1d313c4] /usr/lib64/pkgconfig/../../lib64/libglib-2.0.so.0 [0x2aaab1d31842] /usr/lib64/pkgconfig/../../lib64/libmono.so.0 [0x2aaab17d9202] /usr/lib64/pkgconfig/../../lib64/libmono.so.0 [0x2aaab17d93b8] /usr/lib64/pkgconfig/../../lib64/libmono.so.0(mono_domain_finalize+0xed) [0x2aaab17791cd] /usr/lib64/pkgconfig/../../lib64/libmono.so.0 [0x2aaab16ca759] /usr/kde/trunk/lib/kde4/kimonopluginfactory.so [0x2aaab126b814] /usr/lib64/qt4/libQtCore.so.4(_ZN21QObjectCleanupHandler5clearEv+0x4f) [0x2b868657cb1f] /usr/lib64/qt4/libQtCore.so.4(_ZN21QObjectCleanupHandlerD0Ev+0x24) [0x2b868657cb84] /lib64/libc.so.6(exit+0x7e) [0x2b868d681fde] /lib64/libc.so.6(__libc_start_main+0xfb) [0x2b868d66c4ab] plasmoidviewer(_ZN13QGraphicsView15keyReleaseEventEP9QKeyEvent+0x41) [0x404979] Debug info from gdb: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 47856949390496 (LWP 7074)] [New Thread 1076005200 (LWP 7076)] [New Thread 1073903952 (LWP 7075)] 0x00002b868d70dc12 in select () from /lib64/libc.so.6 3 Thread 1073903952 (LWP 7075) 0x00002b868685bac1 in ?? () from /lib64/libpthread.so.0 2 Thread 1076005200 (LWP 7076) 0x00002b868685adc4 in __lll_lock_wait () from /lib64/libpthread.so.0 1 Thread 47856949390496 (LWP 7074) 0x00002b868d70dc12 in select () from /lib64/libc.so.6 Thread 3 (Thread 1073903952 (LWP 7075)): #0 0x00002b868685bac1 in ?? () from /lib64/libpthread.so.0 #1 0x00002aaab17d878f in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #2 0x00002b8686854067 in start_thread () from /lib64/libpthread.so.0 #3 0x00002b868d713edd in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 2 (Thread 1076005200 (LWP 7076)): #0 0x00002b868685adc4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00002b868685daaa in _L_cond_lock_51 () from /lib64/libpthread.so.0 #2 0x00002b868685d402 in __pthread_mutex_cond_lock () from /lib64/libpthread.so.0 #3 0x00002b86868589d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #4 0x00002aaab17dada5 in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #5 0x00002aaab17dd37b in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #6 0x00002aaab17ec50f in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #7 0x00002aaab1778471 in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #8 0x00002aaab1795d93 in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #9 0x00002aaab17eb043 in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #10 0x00002aaab1805722 in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #11 0x00002b8686854067 in start_thread () from /lib64/libpthread.so.0 #12 0x00002b868d713edd in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 1 (Thread 47856949390496 (LWP 7074)): #0 0x00002b868d70dc12 in select () from /lib64/libc.so.6 #1 0x00002aaab1d41f7a in g_spawn_sync () from /usr/lib64/pkgconfig/../../lib64/libglib-2.0.so.0 #2 0x00002aaab1d42358 in g_spawn_command_line_sync () from /usr/lib64/pkgconfig/../../lib64/libglib-2.0.so.0 #3 0x00002aaab17150ed in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #4 #5 0x00002b868d67f535 in raise () from /lib64/libc.so.6 #6 0x00002b868d6809e0 in abort () from /lib64/libc.so.6 #7 0x00002aaab1d313c4 in g_assertion_message () from /usr/lib64/pkgconfig/../../lib64/libglib-2.0.so.0 #8 0x00002aaab1d31842 in g_assertion_message_expr () from /usr/lib64/pkgconfig/../../lib64/libglib-2.0.so.0 #9 0x00002aaab17d9202 in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #10 0x00002aaab17d93b8 in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #11 0x00002aaab17791cd in mono_domain_finalize () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #12 0x00002aaab16ca759 in ?? () from /usr/lib64/pkgconfig/../../lib64/libmono.so.0 #13 0x00002aaab126b814 in ~KimonoPluginFactory (this=0x6def20) at /home/pumphaus/dev/KDE/kdebindings/csharp/kimono/src/kimonopluginfactory.cpp:93 #14 0x00002b868657cb1f in QObjectCleanupHandler::clear () from /usr/lib64/qt4/libQtCore.so.4 #15 0x00002b868657cb84 in QObjectCleanupHandler::~QObjectCleanupHandler () from /usr/lib64/qt4/libQtCore.so.4 #16 0x00002b868d681fde in exit () from /lib64/libc.so.6 #17 0x00002b868d66c4ab in __libc_start_main () from /lib64/libc.so.6 #18 0x0000000000404979 in _start () #0 0x00002b868d70dc12 in select () from /lib64/libc.so.6 ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Aborted I think this is connected to something the KDE/Qt internals do because if I try a simple example without all the KDE stuff, it works well. I'd like to fix it, but I don't really understand what the stacktrace wants to tell me. Especially I have no clue what Especially I have no clue what _wapi_handle_set_signal_state: assertion failed: (thr_ret == 0) means. Could anyone explain this to me? I could leave mono_jit_cleanup out and it would work nicely, but I guess this creates nasty memory leaks and stuff, so I better don't. Thanks in advance, -- Arno Rehn arno at arnorehn.de From robertj at gmx.net Wed Jul 2 04:18:55 2008 From: robertj at gmx.net (Robert Jordan) Date: Wed, 02 Jul 2008 10:18:55 +0200 Subject: [Mono-dev] Segfault on mono_jit_cleanup In-Reply-To: <200807020124.46610.mono-devel@arnorehn.de> References: <200807020124.46610.mono-devel@arnorehn.de> Message-ID: Arno Rehn wrote: > Hi, > > I hope this is the right place for this question: > Currently I'm working on providing a Mono plugin factory for KDE. I've > followed the instructions for embedding Mono in the wiki and it works quite > well, up to the point where I want to call mono_jit_cleanup(). It segfaults > with the following stacktrace: > > ** > ** ERROR:(../../mono/io-layer/handles- > private.h:160):_wapi_handle_set_signal_state: assertion failed: (thr_ret == 0) > Stacktrace: I believe this is caused by calling mono_jit_cleanup () twice. Robert From kumpera at gmail.com Wed Jul 2 07:31:13 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Wed, 2 Jul 2008 07:31:13 -0400 Subject: [Mono-dev] Memory Model? In-Reply-To: <486A678E.2050208@ufl.edu> References: <486A678E.2050208@ufl.edu> Message-ID: <8cca42d80807020431o10f007ddjff9c97073be7b161@mail.gmail.com> Hi David, This is a very hard subject, as validating a memory model is an incredible hard task. Right now we provide loose semantics close to ecma backed by the architecture you're running. This means we do a very different thing in, say, X86 and Itanium. Having a consistent memory model is a very hard task that requires a huge amount code reviewing and testing. Right now, as you can see, we haven't done all the required work. We still have work to do on the runtime itself (we have some racy code that deal with memory in a hazardous way); and work on the JIT as well. The JIT side is going to suffer a major change right after the 2.0 branch so we are not very inclined in spending much time chaising any possible corner case of the ecma memory model on the current one. Anyway, if you get reproducible bugs please fill bug reports so we can work on improving mono. Cheers, Rodrigo On Tue, Jul 1, 2008 at 1:21 PM, David Wolinsky wrote: > I am so entirely confused about what the memory model for Mono is. If > we are using gmcs can we assume .Net 2.0 Framework or are we safe always > falling back on what ECMA says? This article ( > http://msdn.microsoft.com/en-us/magazine/cc163715.aspx ) makes me want > to code for ECMA and not .Net, but we have a project that was already > coded for the .Net memory model and it is having issues in Mono that are > incredibly difficult to track down! > > > This post ( > http://lists.ximian.com/pipermail/mono-devel-list/2008-May/027885.html ) > doesn't help but confuse me more. Is there somewhere where this is > listed now, if not could you put up the memory models used by Mono on > www.mono-project.org? > > Cheers, > David > _______________________________________________ > 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/20080702/1d21edeb/attachment.html From mono-devel at arnorehn.de Wed Jul 2 08:35:23 2008 From: mono-devel at arnorehn.de (Arno Rehn) Date: Wed, 2 Jul 2008 14:35:23 +0200 Subject: [Mono-dev] Segfault on mono_jit_cleanup Message-ID: <200807021435.24023.mono-devel@arnorehn.de> On Wednesday 02 July 2008 10:18:55 Robert Jordan wrote: > Arno Rehn wrote: > > Hi, > > > > I hope this is the right place for this question: > > Currently I'm working on providing a Mono plugin factory for KDE. I've > > followed the instructions for embedding Mono in the wiki and it works > > quite well, up to the point where I want to call mono_jit_cleanup(). It > > segfaults with the following stacktrace: > > > > ** > > ** ERROR:(../../mono/io-layer/handles- > > private.h:160):_wapi_handle_set_signal_state: assertion failed: (thr_ret > > == 0) Stacktrace: > > I believe this is caused by calling mono_jit_cleanup () twice. I just tested that, it's definitely only called once. I tried calling it twice on purpose in an example app, the error for that is ** ** ERROR:(error.c:70):SetLastError: assertion failed: (ret == 0) Aborted Similar, but not the same. Thanks anyway. I'm gonna try Seo's suggestion, though I'd like to have a solution which doesn't require the end-user to recompile mono ;) -- Arno Rehn arno at arnorehn.de From monkey at jpobst.com Wed Jul 2 11:34:55 2008 From: monkey at jpobst.com (Jonathan Pobst) Date: Wed, 02 Jul 2008 10:34:55 -0500 Subject: [Mono-dev] One Version of Mono.Cairo Message-ID: <486BA01F.4020101@jpobst.com> Currently we ship 2 versions of Mono.Cairo.dll in Mono, a 1.0 and a 2.0 version. However, there is no difference in these versions. This can cause issues if different assemblies reference different versions and the runtime tries to load them both. I think we need to: - Not ship a 2.0 version. - Ship a policy file that maps both versions to the 1.0 version. This should allow existing programs to work while reducing us to only one version Mono.Cairo. Some other assemblies that we appear to ship 1.0 and 2.0 versions of without any differences between them (looking at the 1.9.1 Win/Mono Gac): - CustomMarshallers.dll - Mono.Data.dll - Mono.Data.SybaseClient.dll - Mono.Data.TdsClient.dll - Mono.Http.dll - Mono.Posix.dll - Mono.Security.Win32.dll - Novell.Directory.Ldap.dll - Npgsql.dll - OpenSystem.C.dll Jonathan From robertj at gmx.net Wed Jul 2 12:31:25 2008 From: robertj at gmx.net (Robert Jordan) Date: Wed, 02 Jul 2008 18:31:25 +0200 Subject: [Mono-dev] One Version of Mono.Cairo In-Reply-To: <486BA01F.4020101@jpobst.com> References: <486BA01F.4020101@jpobst.com> Message-ID: Hi Jonathan, Jonathan Pobst wrote: > Currently we ship 2 versions of Mono.Cairo.dll in Mono, a 1.0 and a 2.0 > version. However, there is no difference in these versions. This can > cause issues if different assemblies reference different versions and > the runtime tries to load them both. The assemblies you've listed are all using [assembly: AssemblyVersion (Consts.FxVersion)] consistently, so the assembly names are different. The mentioned issues could be caused by a runtime bug, though. Or by the Assembly.LoadWithPartialName and similar APIs. > I think we need to: > - Not ship a 2.0 version. This will break compatibility. > - Ship a policy file that maps both versions to the 1.0 version. This is better, but then we need symlinks from lib/mono/1.0/ to lib/mono/x.x/ to help gmcs in finding those assemblies. > This should allow existing programs to work while reducing us to only > one version Mono.Cairo. > > Some other assemblies that we appear to ship 1.0 and 2.0 versions of > without any differences between them (looking at the 1.9.1 Win/Mono Gac): > - CustomMarshallers.dll Just one probe: $ gacutil -l | grep Custom CustomMarshalers, Version=1.0.5000.0 ... CustomMarshalers, Version=2.0.0.0 ... They are different. > - Mono.Data.dll > - Mono.Data.SybaseClient.dll > - Mono.Data.TdsClient.dll > - Mono.Http.dll > - Mono.Posix.dll > - Mono.Security.Win32.dll > - Novell.Directory.Ldap.dll > - Npgsql.dll > - OpenSystem.C.dll Robert > Jonathan From meebey at meebey.net Wed Jul 2 12:50:42 2008 From: meebey at meebey.net (Mirco Bauer) Date: Wed, 02 Jul 2008 18:50:42 +0200 Subject: [Mono-dev] One Version of Mono.Cairo In-Reply-To: References: <486BA01F.4020101@jpobst.com> Message-ID: <1215017442.6291.4.camel@redbull.qnetp.net> On Wed, 2008-07-02 at 18:31 +0200, Robert Jordan wrote: > Hi Jonathan, > > Jonathan Pobst wrote: > > Currently we ship 2 versions of Mono.Cairo.dll in Mono, a 1.0 and a 2.0 > > version. However, there is no difference in these versions. This can > > cause issues if different assemblies reference different versions and > > the runtime tries to load them both. > > The assemblies you've listed are all using > > [assembly: AssemblyVersion (Consts.FxVersion)] > > consistently, so the assembly names are different. > > The mentioned issues could be caused by a runtime bug, though. > Or by the Assembly.LoadWithPartialName and similar APIs. Might be related to this bug: https://bugzilla.novell.com/show_bug.cgi?id=322760 AFAIK Mono does not load 2 different versions of libraries that are part of the runtmime (basicly everthing that is ?Consts.FxVersion). Instead it maps the assembly reference from 1.0.5 to 2.0 when the running runtime is 2.0. I don't know why this is really needed, but that's the way it currently is. So not sure if dropping the 2.0 libs would solve or rather cause any issues ;) -- 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: 315 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080702/ff351cdf/attachment.bin From gert.driesen at telenet.be Thu Jul 3 04:44:36 2008 From: gert.driesen at telenet.be (Gert Driesen) Date: Thu, 3 Jul 2008 10:44:36 +0200 Subject: [Mono-dev] HttpListener hangs with r106513 In-Reply-To: <1214348675.14476.10.camel@localhost> References: <1214348675.14476.10.camel@localhost> Message-ID: <000f01c8dce9$0640cd60$12c26820$@driesen@telenet.be> Hey Casey, Miguel prepared a fix for this issue (committed by Martin in r107127), and I've added a unit test based on your repro. Gert -----Original Message----- From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Casey Marshall Sent: woensdag 25 juni 2008 1:05 To: mono-devel Subject: [Mono-dev] HttpListener hangs with r106513 I've noticed that it recent SVN mono snapshots (r106513) using HttpListener and WebRequest in the same process hangs. This doesn't hang with 1.9.1, and didn't with less recent snapshots. I haven't tried having the client and server in different processes, and don't know if it reproduces there. Test case: using System; using System.IO; using System.Net; using System.Threading; class simplehttp { public static void Main(string[] argv) { simplehttp sh = new simplehttp(); Thread srv = new Thread(new ThreadStart(sh.ServerMain)); srv.Name = "HttpServer"; srv.Start(); for (;;) { HttpWebRequest req = (HttpWebRequest) WebRequest.Create ("http://localhost:8888/foobar/"); req.ServicePoint.Expect100Continue = false; req.ServicePoint.UseNagleAlgorithm = false; req.Method = "POST"; StreamWriter w = new StreamWriter(req.GetRequestStream()); w.WriteLine("Hello, server!"); w.Close(); HttpWebResponse resp = (HttpWebResponse) req.GetResponse(); StreamReader r = new StreamReader(resp.GetResponseStream()); System.Console.WriteLine("client reads: {0}", r.ReadToEnd()); r.Close(); } } private void ServerMain() { HttpListener listener = new HttpListener(); listener.Prefixes.Add("http://*:8888/foobar/"); listener.Start(); while (true) { HttpListenerContext ctx = listener.GetContext(); ThreadPool.QueueUserWorkItem(new WaitCallback(HandleConnection), ctx); } } private void HandleConnection(object state) { HttpListenerContext ctx = (HttpListenerContext) state; HttpListenerRequest req = ctx.Request; StreamReader r = new StreamReader(req.InputStream); System.Console.WriteLine ("server reads {0}", r.ReadToEnd()); HttpListenerResponse resp = ctx.Response; StreamWriter o = new StreamWriter(resp.OutputStream); o.WriteLine("Hello, world!"); o.Close(); } } Thanks. _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From gert.driesen at telenet.be Thu Jul 3 12:19:04 2008 From: gert.driesen at telenet.be (Gert Driesen) Date: Thu, 3 Jul 2008 18:19:04 +0200 Subject: [Mono-dev] [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data In-Reply-To: <20080703133809.B21219472C@mono-cvs.ximian.com> References: <20080703133809.B21219472C@mono-cvs.ximian.com> Message-ID: <002601c8dd28$82d69370$8883ba50$@driesen@telenet.be> Hey Veerapuram, I don't think this change is correct. I've done some more tests, and this is the behavior I'm seeing: * on 1.0 profile, you are never allowed to set value to NULL. * on 2.0 profile, you are only allowed to set value to NULL if the column is backed by a reference type. I'll add unit tests for this to DataRowTest2.cs in a few minutes, and mark them NotWorking. Let me know if you want me to submit a patch that changes our implementation accordingly. Gert -----Original Message----- From: mono-patches-bounces at lists.ximian.com [mailto:mono-patches-bounces at lists.ximian.com] On Behalf Of Veerapuram Varadhan (vvaradhan at novell.com) Sent: donderdag 3 juli 2008 15:38 To: mono-patches at lists.ximian.com; ximian.monolist at gmail.com; mono-svn-patches-garchive-20758 at googlegroups.com Subject: [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data Author: varadhan Date: 2008-07-03 09:38:09 -0400 (Thu, 03 Jul 2008) New Revision: 107145 Modified: trunk/mcs/class/System.Data/System.Data/ChangeLog trunk/mcs/class/System.Data/System.Data/DataRow.cs Log: Use DBNull value instead of throwing an exception Modified: trunk/mcs/class/System.Data/System.Data/ChangeLog =================================================================== --- trunk/mcs/class/System.Data/System.Data/ChangeLog 2008-07-03 13:37:14 UTC (rev 107144) +++ trunk/mcs/class/System.Data/System.Data/ChangeLog 2008-07-03 13:38:09 UTC (rev 107145) @@ -1,3 +1,7 @@ +2008-07-03 Marek Habersack + + * DataRow.cs (this []): Use DBNull instead of throwing an exception + 2008-07-01 Rodrigo Kumpera * DataTable.cs: Kill some foreach loops. Modified: trunk/mcs/class/System.Data/System.Data/DataRow.cs =================================================================== --- trunk/mcs/class/System.Data/System.Data/DataRow.cs 2008-07-03 13:37:14 UTC (rev 107144) +++ trunk/mcs/class/System.Data/System.Data/DataRow.cs 2008-07-03 13:38:09 UTC (rev 107145) @@ -178,9 +178,8 @@ DataColumn column = _table.Columns[columnIndex]; _table.ChangingDataColumn (this, column, value); - if (value == null && column.DataType != typeof(string)) { - throw new ArgumentException("Cannot set column " + column.ColumnName + " to be null, Please use DBNull instead"); - } + if (value == null && column.DataType != typeof(string)) + value = DBNull.Value; _rowChanged = true; CheckValue (value, column); _______________________________________________ Mono-patches maillist - Mono-patches at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-patches From cmarshall at pacificbiosciences.com Thu Jul 3 18:10:10 2008 From: cmarshall at pacificbiosciences.com (Casey Marshall) Date: Thu, 03 Jul 2008 15:10:10 -0700 Subject: [Mono-dev] HttpListener hangs with r106513 In-Reply-To: <000f01c8dce9$0640cd60$12c26820$@driesen@telenet.be> References: <1214348675.14476.10.camel@localhost> <000f01c8dce9$0640cd60$12c26820$@driesen@telenet.be> Message-ID: <1215123010.7552.65.camel@localhost> On Thu, 2008-07-03 at 10:44 +0200, Gert Driesen wrote: > Hey Casey, > > Miguel prepared a fix for this issue (committed by Martin in r107127), and > I've added a unit test based on your repro. > Works fine now, both in the test case and the real app. Thanks! From vlad.dimitrov at gmail.com Thu Jul 3 18:11:39 2008 From: vlad.dimitrov at gmail.com (Vladimir Dimitrov) Date: Fri, 4 Jul 2008 01:11:39 +0300 Subject: [Mono-dev] Mono.Addins suppress console window showing Message-ID: <486d4eac.3bf5220a.1d3a.ffffdc0e@mx.google.com> Hello guys, Recently I started using Mono.Addins in my application and it looks very good. But as the application is primary used under windows (should be working fine under Linux too) I get an annoying console window showing when I run: AddinManager.Initialize (); And then another one when I run: AddinManager.Registry.Rebuild (null); I noticed in the code that at some point the .dll executes itself in a separate process ??!?! So if we add the following line: process.StartInfo.CreateNoWindow = true; to the file Mono.Addins/Mono.Addins/Database/SetupProcess.cs this would suppress the window to show under Window and should not cause any other complications. Please let me know what you think. Best regards, Vladimir Dimitrov P.S. I tried compiling my own copy with the change but it didn't worked because when the process was trying to execute the .dll I compiled an exception was throws saying this is not a valid windows app. Maybe I need to compile it to .exe and just rename it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080704/3593ee35/attachment.html From martin at ximian.com Thu Jul 3 18:16:28 2008 From: martin at ximian.com (Martin Baulig) Date: Thu, 03 Jul 2008 18:16:28 -0400 Subject: [Mono-dev] HttpListener hangs with r106513 In-Reply-To: <000f01c8dce9$0640cd60$12c26820$@driesen@telenet.be> References: <1214348675.14476.10.camel@localhost> <000f01c8dce9$0640cd60$12c26820$@driesen@telenet.be> Message-ID: <1215123389.32074.1.camel@164-99-120-105.boston.ximian.com> On Thu, 2008-07-03 at 10:44 +0200, Gert Driesen wrote: > Miguel prepared a fix for this issue (committed by Martin in r107127), and > I've added a unit test based on your repro. Yeah, I run into the same issue yesterday and Miguel and me finally figured it out. Closing the output stream did not close the HttpResponse, so the connection never shut down. -- Martin Baulig - martin at novell.com Novell GmbH, D?sseldorf GF: Volker Smid, Djamel Souici; HRB 21108 (AG D?sseldorf) From zanagar at clockworkz.de Thu Jul 3 06:10:36 2008 From: zanagar at clockworkz.de (burning snow) Date: Thu, 3 Jul 2008 03:10:36 -0700 (PDT) Subject: [Mono-dev] Migrating Mono 2.0. Crossplatform GUI components. In-Reply-To: <48329ED1.8000500@terra.es> References: <482EF158.7070907@jpobst.com> <482FF90F.4080904@terra.es> <75751ca80805190710w19c2363cp14cf2310da6a078f@mail.gmail.com> <4831C81B.5070006@terra.es> <75751ca80805191142s6a930e99w1f0641400048eba0@mail.gmail.com> <48329ED1.8000500@terra.es> Message-ID: <18255999.post@talk.nabble.com> Hi Pablo, I just wanted to ask if there is any progress / date for releasing the library? PABLOSANTOSLUAC at terra.es wrote: > > Hi there, > > I've good news! > > We're going to release our I3 library (the cross-platform MWF controls) > as open source! > > I expect we'll be releasing it in about one or two weeks. > > > Regards, > > pablo > > > www.plasticscm.com > > > Debacker escribi?: >> Yes, please. I really love the look of your app. It would be great if >> you could publish your widgets :D >> >> Thanks >> Laurent. >> >> On Mon, May 19, 2008 at 8:34 PM, pablosantosluac at terra.es >> > > wrote: >> >> Hi, >> >> Well, it's not actually a product but an internal library we use. >> We don't sell it. Did you like how it looks like? If so I'll check >> here whether everyone agrees to make it open. >> >> pablo >> >> Debacker escribi?: >> >> Hi, >> >> Is the GUI part of Plastic SCM free/open-source? I only see >> marketing for your commercial package, which is a bit >> overskill if someone wants your widgets only. >> >> Regards, >> Laurent Debacker. >> >> On Sun, May 18, 2008 at 11:38 AM, pablosantosluac at terra.es >> >> > > > >> > >> wrote: >> >> Hi, >> >> We've developed a small set of controls for Plastic SCM to >> make >> our GUI >> fully portable using winforms. >> >> You can take a look at some screenshots here: >> >> >> http://www.flickr.com/photos/15875826 at N04/sets/72157603891722391/ >> >> >> pablo >> >> >> >> >> >> Jonathan Pobst escribi?: >> > I guess it depends on your requirements. .Net (and Mono) >> comes >> with a >> > toolbar, grid, and tree. So part of it will be figuring >> out what >> > additional functionality you need that you are getting from >> third party >> > controls. >> > >> > Right now, I do not know of any third party controls that >> work >> out of >> > the box with Mono. Hopefully, with the release of Mono 2.0, >> this will >> > change as we work with some third party vendors to get their >> controls >> > working on Mono. >> > >> > Jonathan >> > >> > >> > Yakov Danilov wrote: >> > >> >> Hi everyone. >> >> >> >> Because of Mono 2.0. release our firm has some plans >> about >> creation of crossplatorm client that could be used with >> .Net 2.0 >> on Windows and Mono 2.0 on Linux systems. >> >> >> >> Business logic can be used without any problem, but >> GUI has >> been created using Infragistics components that have too >> many Win >> Api calls and can be used only on Windows. >> >> >> >> Thats why we need components written in managed C# and >> WinForms that can be used on both platforms. Basically we need >> Toobar, Grid, Tree. At this time I find only SourceGrid. Can >> anybody advice us such components? Writing own components too >> laborious. >> >> >> >> p.s. Sorry if my English is not so well. >> >> _______________________________________________ >> >> Mono-devel-list mailing list >> >> Mono-devel-list at lists.ximian.com >> >> > > >> >> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> >> >> >> >> > >> > _______________________________________________ >> > Mono-devel-list mailing list >> > Mono-devel-list at lists.ximian.com >> >> > > >> >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > >> > >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> >> > > >> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> >> > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- View this message in context: http://www.nabble.com/Migrating-Mono-2.0.-Crossplatform-GUI-components.-tp17290400p18255999.html Sent from the Mono - Dev mailing list archive at Nabble.com. From meebey at meebey.net Thu Jul 3 19:52:27 2008 From: meebey at meebey.net (Mirco Bauer) Date: Fri, 04 Jul 2008 01:52:27 +0200 Subject: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System In-Reply-To: <20080703222354.8A9749472C@mono-cvs.ximian.com> References: <20080703222354.8A9749472C@mono-cvs.ximian.com> Message-ID: <1215129147.25219.39.camel@redbull.qnetp.net> On Thu, 2008-07-03 at 18:23 -0400, Andreas Nahr (ClassDevelopment at A-SoftTech.com) wrote: > Author: andreas > Date: 2008-07-03 18:23:54 -0400 (Thu, 03 Jul 2008) > New Revision: 107198 > > Modified: > trunk/mcs/class/corlib/System/ChangeLog > trunk/mcs/class/corlib/System/IntPtr.cs > Log: > 2008-07-04 Andreas Nahr > > * IntPtr: Fix parameter names, change internal name to accomodate for parameter changes > > Modified: trunk/mcs/class/corlib/System/ChangeLog > =================================================================== > --- trunk/mcs/class/corlib/System/ChangeLog 2008-07-03 22:22:43 UTC (rev 107197) > +++ trunk/mcs/class/corlib/System/ChangeLog 2008-07-03 22:23:54 UTC (rev 107198) > @@ -1,5 +1,9 @@ > 2008-07-04 Andreas Nahr > > + * IntPtr: Fix parameter names, change internal name to accomodate for parameter changes > + > +2008-07-04 Andreas Nahr > + > * Predicate.cs: > * Object.cs: > * Nullable.cs > > Modified: trunk/mcs/class/corlib/System/IntPtr.cs > =================================================================== > --- trunk/mcs/class/corlib/System/IntPtr.cs 2008-07-03 22:22:43 UTC (rev 107197) > +++ trunk/mcs/class/corlib/System/IntPtr.cs 2008-07-03 22:23:54 UTC (rev 107198) > @@ -57,44 +57,44 @@ > #endif > public unsafe struct IntPtr : ISerializable > { > - private void *value; > + private void *m_value; I am not sure, but doesn't this break binary serialization compatibility? > > public static readonly IntPtr Zero; > > #if NET_2_0 > [ReliabilityContract (Consistency.MayCorruptInstance, Cer.MayFail)] > #endif > - public IntPtr (int i32) > + public IntPtr (int value) > { > - value = (void *) i32; > + m_value = (void *) value; afaik the goal can also be archived using this.value = value; thats all, thanks. -- 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/ From joe.audette at gmail.com Thu Jul 3 20:23:29 2008 From: joe.audette at gmail.com (Joe Audette) Date: Thu, 3 Jul 2008 20:23:29 -0400 Subject: [Mono-dev] Mono.Data.Sqlite In-Reply-To: <18179121.post@talk.nabble.com> References: <18179121.post@talk.nabble.com> Message-ID: <27d75530807031723g3817684ub2ad1799f9b442ef@mail.gmail.com> Hi, My impression is that SQLite is not that great a choice for a multi threaded app. If you google sqlite mutli threading, in the first result which links to here: http://www.sqlite.org/cvstrac/wiki?p=MultiThreading you'll see: "It has never been safe to use the same database connection simultaneously in multiple threads." Sqlite is really meant to be a lightweight db for single threaded apps. Hope it helps, Joe On Sun, Jun 29, 2008 at 6:16 AM, Anders Aagaard wrote: > > Hi > > I've been using Mono.Data.Sqlite in a multi threaded application, since the > code says it's based on Robert Simpson's library I've been looking at his > page for documentation (as Mono.Data.Sqlite documentation seems extremely > sparse). > > My problem is that when using multiple threads, all writing to the database, > I get : > Unhandled Exception: Mono.Data.Sqlite.SqliteException: The database file is > locked > Every thread has it's own cloned SqliteConnection (during the creation of > the thread I call MasterConnection.Clone (), and only use the referenced > connection). The exception happens instantly when two threads begin a > transaction to the same database. > > Is the instructions for Robert Simpson's library not accurate for mono's > sqlite library, or am I hitting a bug? Any suggestions on how to cleanly > work around this problem? > > I have one file scanner that adds files to the database, one text file > scanner that scans all text files added and adds web links from them, and > one web updater that takes the links and updates that from an online > database. They are all seperate threads. The main thread will also > occasionally do a small commit, but it will mostly read from the database. > -- > View this message in context: http://www.nabble.com/Mono.Data.Sqlite-tp18179121p18179121.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Joe Audette Software Solutions Architect Source Tree Solutions, LLC PO Box 621861 Charlotte, NC 28262 704.323.8225 joe.audette at gmail.com http://www.sourcetreesolutions.com http://www.mojoportal.com From brad at getcoded.net Thu Jul 3 22:30:59 2008 From: brad at getcoded.net (Brad Taylor) Date: Thu, 03 Jul 2008 19:30:59 -0700 Subject: [Mono-dev] Mono.Addins suppress console window showing In-Reply-To: <486d4eac.3bf5220a.1d3a.ffffdc0e@mx.google.com> References: <486d4eac.3bf5220a.1d3a.ffffdc0e@mx.google.com> Message-ID: <1215138659.6486.1.camel@phoenix> Hey Vlad, > Recently I started using Mono.Addins in my application and it looks > very good. But as the application is primary used under windows > (should be working fine under Linux too) I get an annoying console > window showing when I run: You can also compile Mono.Addins as a "winexe" target to suppress the console. You'll probably have to rename it to a .dll afterwards if you compile under Windows. Hope this helps, -Brad From ClassDevelopment at A-SoftTech.com Fri Jul 4 02:59:14 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Fri, 4 Jul 2008 08:59:14 +0200 Subject: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System In-Reply-To: <1215129147.25219.39.camel@redbull.qnetp.net> References: <20080703222354.8A9749472C@mono-cvs.ximian.com> <1215129147.25219.39.camel@redbull.qnetp.net> Message-ID: <001201c8dda3$785bd0b0$69137210$@com> In Text > -----Urspr?ngliche Nachricht----- > Von: Mirco Bauer [mailto:meebey at meebey.net] > Gesendet: Freitag, 4. Juli 2008 01:52 > An: mono-devel-list at lists.ximian.com > Cc: ClassDevelopment at A-SoftTech.com > Betreff: Re: [Mono-patches] r107198 - trunk/mcs/class/corlib/System > > On Thu, 2008-07-03 at 18:23 -0400, Andreas Nahr > (ClassDevelopment at A-SoftTech.com) wrote: > > Author: andreas > > Date: 2008-07-03 18:23:54 -0400 (Thu, 03 Jul 2008) > > New Revision: 107198 > > > > Modified: > > trunk/mcs/class/corlib/System/ChangeLog > > trunk/mcs/class/corlib/System/IntPtr.cs > > Log: > > 2008-07-04 Andreas Nahr > > > > * IntPtr: Fix parameter names, change internal name to accomodate > for parameter changes > > > > Modified: trunk/mcs/class/corlib/System/ChangeLog > > =================================================================== > > --- trunk/mcs/class/corlib/System/ChangeLog 2008-07-03 22:22:43 UTC > (rev 107197) > > +++ trunk/mcs/class/corlib/System/ChangeLog 2008-07-03 22:23:54 UTC > (rev 107198) > > @@ -1,5 +1,9 @@ > > 2008-07-04 Andreas Nahr > > > > + * IntPtr: Fix parameter names, change internal name to accomodate > for parameter changes > > + > > +2008-07-04 Andreas Nahr > > + > > * Predicate.cs: > > * Object.cs: > > * Nullable.cs > > > > Modified: trunk/mcs/class/corlib/System/IntPtr.cs > > =================================================================== > > --- trunk/mcs/class/corlib/System/IntPtr.cs 2008-07-03 22:22:43 UTC > (rev 107197) > > +++ trunk/mcs/class/corlib/System/IntPtr.cs 2008-07-03 22:23:54 UTC > (rev 107198) > > @@ -57,44 +57,44 @@ > > #endif > > public unsafe struct IntPtr : ISerializable > > { > > - private void *value; > > + private void *m_value; > > I am not sure, but doesn't this break binary serialization > compatibility? It shouldn't. IntPtr has an explicit Serializer implementation that deals with setting correct names. I did not change those. > > > > public static readonly IntPtr Zero; > > > > #if NET_2_0 > > [ReliabilityContract (Consistency.MayCorruptInstance, > Cer.MayFail)] > > #endif > > - public IntPtr (int i32) > > + public IntPtr (int value) > > { > > - value = (void *) i32; > > + m_value = (void *) value; > > afaik the goal can also be archived using this.value = value; Did you try that? I actually had it this way and it refused to compile because the value was deemed not initialized. I've got to admit that I wasn't exactly sure why it didn't. Potential issue with the compiler maybe? > thats all, thanks. > > -- > 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/ From vlad.dimitrov at gmail.com Fri Jul 4 03:10:22 2008 From: vlad.dimitrov at gmail.com (Vladimir Dimitrov) Date: Fri, 4 Jul 2008 10:10:22 +0300 Subject: [Mono-dev] Mono.Addins suppress console window showing In-Reply-To: <1215138659.6486.1.camel@phoenix> References: <486d4eac.3bf5220a.1d3a.ffffdc0e@mx.google.com> <1215138659.6486.1.camel@phoenix> Message-ID: <486dccee.24035a0a.4ac0.4001@mx.google.com> Thanks Brad, Yes that worked and I don't see any problems with the line that I talked about being added so if the developer of this library is somewhere around he could add the change to the main source so everybody can get the fix. - Vlad -----Original Message----- From: Brad Taylor [mailto:brad at getcoded.net] Sent: Friday, July 04, 2008 5:31 AM To: Vladimir Dimitrov Cc: Mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] Mono.Addins suppress console window showing Hey Vlad, > Recently I started using Mono.Addins in my application and it looks > very good. But as the application is primary used under windows > (should be working fine under Linux too) I get an annoying console > window showing when I run: You can also compile Mono.Addins as a "winexe" target to suppress the console. You'll probably have to rename it to a .dll afterwards if you compile under Windows. Hope this helps, -Brad No virus found in this incoming message. Checked by AVG. Version: 8.0.134 / Virus Database: 270.4.4/1531 - Release Date: 02.7.2008 ?. 19:02 From ClassDevelopment at A-SoftTech.com Fri Jul 4 03:39:23 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Fri, 4 Jul 2008 09:39:23 +0200 Subject: [Mono-dev] Sortkey.cs weirdness in corlib In-Reply-To: <001201c8dda3$785bd0b0$69137210$@com> References: <20080703222354.8A9749472C@mono-cvs.ximian.com> <1215129147.25219.39.camel@redbull.qnetp.net> <001201c8dda3$785bd0b0$69137210$@com> Message-ID: <000001c8dda9$145b04e0$3d110ea0$@com> I've seen that the SortKey class in System.Globalization is not used/compiled at all. Instead a identically named class from Mono.Globalization is used. My suggestion would be to a) delete the SortKey in the System.Globalization directory of corlib b) move the class from Mono.Globalization to System.Globalization any objections? Happy Hacking Andreas From lluis at novell.com Fri Jul 4 05:26:24 2008 From: lluis at novell.com (Lluis Sanchez Gual) Date: Fri, 04 Jul 2008 11:26:24 +0200 Subject: [Mono-dev] Mono.Addins suppress console window showing In-Reply-To: <486dccee.24035a0a.4ac0.4001@mx.google.com> References: <486d4eac.3bf5220a.1d3a.ffffdc0e@mx.google.com> <1215138659.6486.1.camel@phoenix> <486dccee.24035a0a.4ac0.4001@mx.google.com> Message-ID: <1215163584.6866.78.camel@portador.aticatac-centre> ?I'll commit the fix. Thanks!!! El dv 04 de 07 de 2008 a les 10:10 +0300, en/na Vladimir Dimitrov va escriure: > Thanks Brad, > > Yes that worked and I don't see any problems with the line that I talked > about being added so if the developer of this library is somewhere around he > could add the change to the main source so everybody can get the fix. > > - Vlad > > -----Original Message----- > From: Brad Taylor [mailto:brad at getcoded.net] > Sent: Friday, July 04, 2008 5:31 AM > To: Vladimir Dimitrov > Cc: Mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] Mono.Addins suppress console window showing > > Hey Vlad, > > > Recently I started using Mono.Addins in my application and it looks > > very good. But as the application is primary used under windows > > (should be working fine under Linux too) I get an annoying console > > window showing when I run: > > > You can also compile Mono.Addins as a "winexe" target to suppress the > console. You'll probably have to rename it to a .dll afterwards if you > compile under Windows. > > Hope this helps, > > -Brad > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.134 / Virus Database: 270.4.4/1531 - Release Date: 02.7.2008 ?. > 19:02 > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From vvaradhan at novell.com Fri Jul 4 06:17:32 2008 From: vvaradhan at novell.com (Veerapuram Varadhan) Date: Fri, 04 Jul 2008 15:47:32 +0530 Subject: [Mono-dev] [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data In-Reply-To: <002601c8dd28$82d69370$8883ba50$@driesen@telenet.be> References: <20080703133809.B21219472C@mono-cvs.ximian.com> <002601c8dd28$82d69370$8883ba50$@driesen@telenet.be> Message-ID: <1215166652.31556.1.camel@vvaradhan-lap.blr.novell.com> Hi Gert, On Thu, 2008-07-03 at 18:19 +0200, Gert Driesen wrote: > Hey Veerapuram, > > I don't think this change is correct. I've done some more tests, and this is > the behavior I'm seeing: > > * on 1.0 profile, you are never allowed to set value to NULL. > * on 2.0 profile, you are only allowed to set value to NULL if the column is > backed by a reference type. > > I'll add unit tests for this to DataRowTest2.cs in a few minutes, and mark > them NotWorking. > > Let me know if you want me to submit a patch that changes our implementation > accordingly. > That would be great. Feel free to submit tests and the patch. Thanks, V. Varadhan > Gert > > -----Original Message----- > From: mono-patches-bounces at lists.ximian.com > [mailto:mono-patches-bounces at lists.ximian.com] On Behalf Of Veerapuram > Varadhan (vvaradhan at novell.com) > Sent: donderdag 3 juli 2008 15:38 > To: mono-patches at lists.ximian.com; ximian.monolist at gmail.com; > mono-svn-patches-garchive-20758 at googlegroups.com > Subject: [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data > > Author: varadhan > Date: 2008-07-03 09:38:09 -0400 (Thu, 03 Jul 2008) > New Revision: 107145 > > Modified: > trunk/mcs/class/System.Data/System.Data/ChangeLog > trunk/mcs/class/System.Data/System.Data/DataRow.cs > Log: > Use DBNull value instead of throwing an exception > > > Modified: trunk/mcs/class/System.Data/System.Data/ChangeLog > =================================================================== > --- trunk/mcs/class/System.Data/System.Data/ChangeLog 2008-07-03 13:37:14 > UTC (rev 107144) > +++ trunk/mcs/class/System.Data/System.Data/ChangeLog 2008-07-03 13:38:09 > UTC (rev 107145) > @@ -1,3 +1,7 @@ > +2008-07-03 Marek Habersack > + > + * DataRow.cs (this []): Use DBNull instead of throwing an exception > + > 2008-07-01 Rodrigo Kumpera > > * DataTable.cs: Kill some foreach loops. > > Modified: trunk/mcs/class/System.Data/System.Data/DataRow.cs > =================================================================== > --- trunk/mcs/class/System.Data/System.Data/DataRow.cs 2008-07-03 13:37:14 > UTC (rev 107144) > +++ trunk/mcs/class/System.Data/System.Data/DataRow.cs 2008-07-03 13:38:09 > UTC (rev 107145) > @@ -178,9 +178,8 @@ > DataColumn column = > _table.Columns[columnIndex]; > _table.ChangingDataColumn (this, column, > value); > > - if (value == null && column.DataType != > typeof(string)) { > - throw new ArgumentException("Cannot > set column " + column.ColumnName + " to be null, Please use DBNull > instead"); > - } > + if (value == null && column.DataType != > typeof(string)) > + value = DBNull.Value; > _rowChanged = true; > > CheckValue (value, column); > > _______________________________________________ > Mono-patches maillist - Mono-patches at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-patches > From fog at initd.org Fri Jul 4 06:31:09 2008 From: fog at initd.org (Federico Di Gregorio) Date: Fri, 04 Jul 2008 12:31:09 +0200 Subject: [Mono-dev] Streaming with Moonlight/Silverlight vs Flash Message-ID: <1215167469.5042.30.camel@mila.office.dinunzioedigregorio> Hi everybody, I am about to choose the technology that will be used during the next two years to build the ESOF2010 web site (if you're curious about ESOF just check this year website, http://www.esof2008.org/). The project for 2010 includes a lot of streaming using preferably open protocols and open source software (mandatory on the servers, the client code should work at least on Windows and Linux and may use proprietary plugins). The tools to create the streams should be free software. We choosed to use feng as the streaming server because it supports RTP/RTSP and RTMP (now mostly free) with fallback on HTTP encapsulation and a lot of different non-proprietary codecs. Looking at MS website for Silverlight specifications it seems to me that streaming using the standard protocols cited above is not supported and that only MS codecs (that we don't like to use) can be used. We also investigated the possibility of writing a a managed RTP implementation but it seems that UDP is not supported in Silverlight. And even if we manage to have a working implementation of RTP it is not clear how you can decode the data and send it to the multimedia part of the framework. So it seems that while we would much better like to work with Mono/Moonlight and keep compatibility with Silverlight in the end will be forced to use Adobe Flash (RTMP + one of the non-free codecs: at least there are open source tools to do the authoring and the encoding conversions). I am writing to this list because I _hope_ we missed something and that Silverlight/Moonlight can be used to play streams using open protocols and codecs. Thank you for your time, federico -- signify error: can't use imaginary (1+0.191071i) weight! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080704/62f79a20/attachment.bin From meebey at meebey.net Fri Jul 4 06:58:42 2008 From: meebey at meebey.net (Mirco Bauer) Date: Fri, 04 Jul 2008 12:58:42 +0200 Subject: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System In-Reply-To: <001201c8dda3$785bd0b0$69137210$@com> References: <20080703222354.8A9749472C@mono-cvs.ximian.com> <1215129147.25219.39.camel@redbull.qnetp.net> <001201c8dda3$785bd0b0$69137210$@com> Message-ID: <1215169122.6187.3.camel@redbull.qnetp.net> Hi Andreas, my reply is inline, see below. On Fri, 2008-07-04 at 08:59 +0200, Andreas Nahr wrote: > In Text > > > -----Urspr?ngliche Nachricht----- > > Von: Mirco Bauer [mailto:meebey at meebey.net] > > Gesendet: Freitag, 4. Juli 2008 01:52 > > An: mono-devel-list at lists.ximian.com > > Cc: ClassDevelopment at A-SoftTech.com > > Betreff: Re: [Mono-patches] r107198 - trunk/mcs/class/corlib/System > > > > On Thu, 2008-07-03 at 18:23 -0400, Andreas Nahr > > (ClassDevelopment at A-SoftTech.com) wrote: > > > Author: andreas > > > Date: 2008-07-03 18:23:54 -0400 (Thu, 03 Jul 2008) > > > New Revision: 107198 > > > > > > Modified: > > > trunk/mcs/class/corlib/System/ChangeLog > > > trunk/mcs/class/corlib/System/IntPtr.cs > > > Log: > > > 2008-07-04 Andreas Nahr > > > > > > * IntPtr: Fix parameter names, change internal name to accomodate > > for parameter changes > > > > > > Modified: trunk/mcs/class/corlib/System/ChangeLog > > > =================================================================== > > > --- trunk/mcs/class/corlib/System/ChangeLog 2008-07-03 22:22:43 UTC > > (rev 107197) > > > +++ trunk/mcs/class/corlib/System/ChangeLog 2008-07-03 22:23:54 UTC > > (rev 107198) > > > @@ -1,5 +1,9 @@ > > > 2008-07-04 Andreas Nahr > > > > > > + * IntPtr: Fix parameter names, change internal name to accomodate > > for parameter changes > > > + > > > +2008-07-04 Andreas Nahr > > > + > > > * Predicate.cs: > > > * Object.cs: > > > * Nullable.cs > > > > > > Modified: trunk/mcs/class/corlib/System/IntPtr.cs > > > =================================================================== > > > --- trunk/mcs/class/corlib/System/IntPtr.cs 2008-07-03 22:22:43 UTC > > (rev 107197) > > > +++ trunk/mcs/class/corlib/System/IntPtr.cs 2008-07-03 22:23:54 UTC > > (rev 107198) > > > @@ -57,44 +57,44 @@ > > > #endif > > > public unsafe struct IntPtr : ISerializable > > > { > > > - private void *value; > > > + private void *m_value; > > > > I am not sure, but doesn't this break binary serialization > > compatibility? > > It shouldn't. IntPtr has an explicit Serializer implementation that deals > with setting correct names. I did not change those. Oh ok, didn't see that (from the patch). > > > > > > > public static readonly IntPtr Zero; > > > > > > #if NET_2_0 > > > [ReliabilityContract (Consistency.MayCorruptInstance, > > Cer.MayFail)] > > > #endif > > > - public IntPtr (int i32) > > > + public IntPtr (int value) > > > { > > > - value = (void *) i32; > > > + m_value = (void *) value; > > > > afaik the goal can also be archived using this.value = value; > > Did you try that? I actually had it this way and it refused to compile > because the value was deemed not initialized. I've got to admit that I > wasn't exactly sure why it didn't. Potential issue with the compiler maybe? At least for me it works, using gmcs 1.9.1: meebey at redbull:~$ cat test.cs using System; class Test { int value; Test(int value) { this.value = value; } public static void Main () { Test t = new Test(123); Console.WriteLine(t.value); } } meebey at redbull:~$ mono test.exe 123 meebey at redbull:~$ I just find a bit intrusive/overkill to rename class members because of parameter names of some ctor or method... (especially when they come from MS .NET) as it might have side-effects like serialization comp for classes that don't have an explicit implementation. Thanks for your effort. -- 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: 315 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080704/a09c889d/attachment.bin From fejj at novell.com Fri Jul 4 10:32:17 2008 From: fejj at novell.com (Jeffrey Stedfast) Date: Fri, 04 Jul 2008 10:32:17 -0400 Subject: [Mono-dev] Streaming with Moonlight/Silverlight vs Flash In-Reply-To: <1215167469.5042.30.camel@mila.office.dinunzioedigregorio> References: <1215167469.5042.30.camel@mila.office.dinunzioedigregorio> Message-ID: <1215181937.32066.12.camel@serenity> On Fri, 2008-07-04 at 12:31 +0200, Federico Di Gregorio wrote: > Hi everybody, > > I am about to choose the technology that will be used during the next > two years to build the ESOF2010 web site (if you're curious about ESOF > just check this year website, http://www.esof2008.org/). The project for > 2010 includes a lot of streaming using preferably open protocols and > open source software (mandatory on the servers, the client code should > work at least on Windows and Linux and may use proprietary plugins). The > tools to create the streams should be free software. > > We choosed to use feng as the streaming server because it supports > RTP/RTSP and RTMP (now mostly free) with fallback on HTTP encapsulation > and a lot of different non-proprietary codecs. > > Looking at MS website for Silverlight specifications it seems to me that > streaming using the standard protocols cited above is not supported and > that only MS codecs (that we don't like to use) can be used. We also > investigated the possibility of writing a a managed RTP implementation > but it seems that UDP is not supported in Silverlight. And even if we > manage to have a working implementation of RTP it is not clear how you > can decode the data and send it to the multimedia part of the framework. > > So it seems that while we would much better like to work with > Mono/Moonlight and keep compatibility with Silverlight in the end will > be forced to use Adobe Flash (RTMP + one of the non-free codecs: at > least there are open source tools to do the authoring and the encoding > conversions). > > I am writing to this list because I _hope_ we missed something and that > Silverlight/Moonlight can be used to play streams using open protocols > and codecs. I /believe/ that Silverlight/Moonlight can do RTSP and RSTPT (and obviously MMS), but I'm not 100% sure. I don't know too much about the protocols but at one point I was helping out with the media streaming code and noticed code to handle those 2 protocol schemes (although it's possible that the code just did immediate fallback to http or something, I can't remember). Hopefully one of the moonlight media people can answer this more accurately. However, in the end, if you aren't happy with the codecs that Silverlight supports, then even if we add support for your preferred codec into Moonlight, it wouldn't solve your codec problem. Out of curiosity, which codec do you plan on using? Jeff From ClassDevelopment at A-SoftTech.com Fri Jul 4 10:53:55 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Fri, 4 Jul 2008 16:53:55 +0200 Subject: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System In-Reply-To: <1215169122.6187.3.camel@redbull.qnetp.net> References: <20080703222354.8A9749472C@mono-cvs.ximian.com> <1215129147.25219.39.camel@redbull.qnetp.net> <001201c8dda3$785bd0b0$69137210$@com> <1215169122.6187.3.camel@redbull.qnetp.net> Message-ID: <002501c8dde5$c83ed770$58bc8650$@com> > -----Urspr?ngliche Nachricht----- > Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list- > bounces at lists.ximian.com] Im Auftrag von Mirco Bauer > Gesendet: Freitag, 4. Juli 2008 12:59 > An: Andreas Nahr > Cc: mono-devel-list at lists.ximian.com > Betreff: Re: [Mono-dev] [Mono-patches] r107198 - > trunk/mcs/class/corlib/System > > > > > > > > public static readonly IntPtr Zero; > > > > > > > > #if NET_2_0 > > > > [ReliabilityContract (Consistency.MayCorruptInstance, > > > Cer.MayFail)] > > > > #endif > > > > - public IntPtr (int i32) > > > > + public IntPtr (int value) > > > > { > > > > - value = (void *) i32; > > > > + m_value = (void *) value; > > > > > > afaik the goal can also be archived using this.value = value; > > > > Did you try that? I actually had it this way and it refused to > compile > > because the value was deemed not initialized. I've got to admit that > I > > wasn't exactly sure why it didn't. Potential issue with the compiler > maybe? > > At least for me it works, using gmcs 1.9.1: > > meebey at redbull:~$ cat test.cs > using System; > > class Test > { > int value; > > Test(int value) > { > this.value = value; > } > > public static void Main () > { > Test t = new Test(123); > Console.WriteLine(t.value); > } > } Are you trying to make a joke? ;) Of course this works with "normal" types. This is used thousands of times throughout the class libraries. But in *THIS* case with void * it does not seem to work. So this was the easiest way to fix the problem. Greetings Andreas P.S. If you want to make further "tests" maybe mail me private and not through the list to keep the noise low. From meebey at meebey.net Fri Jul 4 13:01:21 2008 From: meebey at meebey.net (Mirco Bauer) Date: Fri, 04 Jul 2008 19:01:21 +0200 Subject: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System In-Reply-To: <002501c8dde5$c83ed770$58bc8650$@com> References: <20080703222354.8A9749472C@mono-cvs.ximian.com> <1215129147.25219.39.camel@redbull.qnetp.net> <001201c8dda3$785bd0b0$69137210$@com> <1215169122.6187.3.camel@redbull.qnetp.net> <002501c8dde5$c83ed770$58bc8650$@com> Message-ID: <1215190881.6187.18.camel@redbull.qnetp.net> On Fri, 2008-07-04 at 16:53 +0200, Andreas Nahr wrote: > > > -----Urspr?ngliche Nachricht----- > > Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list- > > bounces at lists.ximian.com] Im Auftrag von Mirco Bauer > > Gesendet: Freitag, 4. Juli 2008 12:59 > > An: Andreas Nahr > > Cc: mono-devel-list at lists.ximian.com > > Betreff: Re: [Mono-dev] [Mono-patches] r107198 - > > trunk/mcs/class/corlib/System > > > > > > > > > > public static readonly IntPtr Zero; > > > > > > > > > > #if NET_2_0 > > > > > [ReliabilityContract (Consistency.MayCorruptInstance, > > > > Cer.MayFail)] > > > > > #endif > > > > > - public IntPtr (int i32) > > > > > + public IntPtr (int value) > > > > > { > > > > > - value = (void *) i32; > > > > > + m_value = (void *) value; > > > > > > > > afaik the goal can also be archived using this.value = value; > > > > > > Did you try that? I actually had it this way and it refused to > > compile > > > because the value was deemed not initialized. I've got to admit that > > I > > > wasn't exactly sure why it didn't. Potential issue with the compiler > > maybe? > > > > At least for me it works, using gmcs 1.9.1: > > > > meebey at redbull:~$ cat test.cs > > using System; > > > > class Test > > { > > int value; > > > > Test(int value) > > { > > this.value = value; > > } > > > > public static void Main () > > { > > Test t = new Test(123); > > Console.WriteLine(t.value); > > } > > } > > Are you trying to make a joke? ;) > Of course this works with "normal" types. I didn't test exactly the same situation, but I prooved the way it should work like. > This is used thousands of times throughout the class libraries. > But in *THIS* case with void * it does not seem to work. So this was the easiest way to fix the problem. Ok, I used a class and int as type. So here a test using an unsafe struct and void* as member, just like IntPtr does: meebey at redbull:~$ cat test.cs using System; unsafe class Test { int value; Test(int value) { this.value = value; } public static void Main () { Test t = new Test(123); Console.WriteLine(t.value); AnotherTest at = new AnotherTest(123); Console.WriteLine((int) at.value); } } public unsafe struct AnotherTest { internal void* value; public AnotherTest(int value) { this.value = (void*) value; } } meebey at redbull:~$ mono test.exe 123 123 > > Greetings Andreas > > P.S. If you want to make further "tests" maybe mail me private and not through the list to keep the noise low. I don't think this is noise as you had issues with a possible compiler bug, so allow other developers to join the discussion and comment on the test-code. -- 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: 315 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080704/02a96593/attachment.bin From ClassDevelopment at A-SoftTech.com Fri Jul 4 13:50:15 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Fri, 4 Jul 2008 19:50:15 +0200 Subject: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System In-Reply-To: <1215190881.6187.18.camel@redbull.qnetp.net> References: <20080703222354.8A9749472C@mono-cvs.ximian.com> <1215129147.25219.39.camel@redbull.qnetp.net> <001201c8dda3$785bd0b0$69137210$@com> <1215169122.6187.3.camel@redbull.qnetp.net> <002501c8dde5$c83ed770$58bc8650$@com> <1215190881.6187.18.camel@redbull.qnetp.net> Message-ID: <003a01c8ddfe$6aa662e0$3ff328a0$@com> > > This is used thousands of times throughout the class libraries. > > But in *THIS* case with void * it does not seem to work. So this was > the easiest way to fix the problem. > > Ok, I used a class and int as type. So here a test using an unsafe > struct and void* as member, just like IntPtr does: > > meebey at redbull:~$ cat test.cs > using System; > > unsafe class Test > { > int value; > > Test(int value) > { > this.value = value; > } > > public static void Main () > { > Test t = new Test(123); > Console.WriteLine(t.value); > > AnotherTest at = new AnotherTest(123); > Console.WriteLine((int) at.value); > } > } > > public unsafe struct AnotherTest > { > internal void* value; > > public AnotherTest(int value) > { > this.value = (void*) value; > } > } > > meebey at redbull:~$ mono test.exe > 123 > 123 Although it is interesting that this seems to work (by the way the problem was that I couldn't even compile it). I still do not see the use of showing a test that shows that there are situations in which it works. If you want to reproduce the problem then I suggest that you take the Version of IntPtr (it?s a small and simple type anyways) before my changes and then change the values accordingly and then you will hopefully see the problem. Then reduce it to the smallest case possible. Then you would have to analyze the reason for it. That (which could easily take one or more days) then leads you to maybe fix a corner-case that probably nobody ever used (well exaggerating a little bit ;) except the IntPtr struct. > > > > Greetings Andreas > > > > P.S. If you want to make further "tests" maybe mail me private and > not through the list to keep the noise low. > > I don't think this is noise as you had issues with a possible compiler > bug, so allow other developers to join the discussion and comment on > the test-code. I will not research any further here because imho it's just not worth my time and there are far more important things to fix. Feel free to do if you like. From gert.driesen at telenet.be Fri Jul 4 15:35:50 2008 From: gert.driesen at telenet.be (Gert Driesen) Date: Fri, 4 Jul 2008 21:35:50 +0200 Subject: [Mono-dev] [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data In-Reply-To: <1215166652.31556.1.camel@vvaradhan-lap.blr.novell.com> References: <20080703133809.B21219472C@mono-cvs.ximian.com> <002601c8dd28$82d69370$8883ba50$@driesen@telenet.be> <1215166652.31556.1.camel@vvaradhan-lap.blr.novell.com> Message-ID: <004501c8de0d$2a497f20$7edc7d60$@driesen@telenet.be> Hey Veerapuram, I've attached a patch for the changes I mentioned. However, I found out that on the 1.0 profile we should still allow the value to be set to null if the datatype of the column is string. This matches the behavior before r107145. Let me know if it's ok to commit. Gert -----Original Message----- From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Veerapuram Varadhan Sent: vrijdag 4 juli 2008 12:18 To: Gert Driesen Cc: 'mono-devel-list' Subject: Re: [Mono-dev] [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data Hi Gert, On Thu, 2008-07-03 at 18:19 +0200, Gert Driesen wrote: > Hey Veerapuram, > > I don't think this change is correct. I've done some more tests, and this is > the behavior I'm seeing: > > * on 1.0 profile, you are never allowed to set value to NULL. > * on 2.0 profile, you are only allowed to set value to NULL if the column is > backed by a reference type. > > I'll add unit tests for this to DataRowTest2.cs in a few minutes, and mark > them NotWorking. > > Let me know if you want me to submit a patch that changes our implementation > accordingly. > That would be great. Feel free to submit tests and the patch. Thanks, V. Varadhan > Gert > > -----Original Message----- > From: mono-patches-bounces at lists.ximian.com > [mailto:mono-patches-bounces at lists.ximian.com] On Behalf Of Veerapuram > Varadhan (vvaradhan at novell.com) > Sent: donderdag 3 juli 2008 15:38 > To: mono-patches at lists.ximian.com; ximian.monolist at gmail.com; > mono-svn-patches-garchive-20758 at googlegroups.com > Subject: [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data > > Author: varadhan > Date: 2008-07-03 09:38:09 -0400 (Thu, 03 Jul 2008) > New Revision: 107145 > > Modified: > trunk/mcs/class/System.Data/System.Data/ChangeLog > trunk/mcs/class/System.Data/System.Data/DataRow.cs > Log: > Use DBNull value instead of throwing an exception > > > Modified: trunk/mcs/class/System.Data/System.Data/ChangeLog > =================================================================== > --- trunk/mcs/class/System.Data/System.Data/ChangeLog 2008-07-03 13:37:14 > UTC (rev 107144) > +++ trunk/mcs/class/System.Data/System.Data/ChangeLog 2008-07-03 13:38:09 > UTC (rev 107145) > @@ -1,3 +1,7 @@ > +2008-07-03 Marek Habersack > + > + * DataRow.cs (this []): Use DBNull instead of throwing an exception > + > 2008-07-01 Rodrigo Kumpera > > * DataTable.cs: Kill some foreach loops. > > Modified: trunk/mcs/class/System.Data/System.Data/DataRow.cs > =================================================================== > --- trunk/mcs/class/System.Data/System.Data/DataRow.cs 2008-07-03 13:37:14 > UTC (rev 107144) > +++ trunk/mcs/class/System.Data/System.Data/DataRow.cs 2008-07-03 13:38:09 > UTC (rev 107145) > @@ -178,9 +178,8 @@ > DataColumn column = > _table.Columns[columnIndex]; > _table.ChangingDataColumn (this, column, > value); > > - if (value == null && column.DataType != > typeof(string)) { > - throw new ArgumentException("Cannot > set column " + column.ColumnName + " to be null, Please use DBNull > instead"); > - } > + if (value == null && column.DataType != > typeof(string)) > + value = DBNull.Value; > _rowChanged = true; > > CheckValue (value, column); > > _______________________________________________ > Mono-patches maillist - Mono-patches at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-patches > _______________________________________________ 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: datarow.patch Type: application/octet-stream Size: 12502 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080704/8e6a3d9f/attachment.obj From pablosantosluac at terra.es Fri Jul 4 17:57:22 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Fri, 04 Jul 2008 23:57:22 +0200 Subject: [Mono-dev] problem compiling 1.9.1 on OpenBSD In-Reply-To: <14923D53-A91A-4A2D-ADFE-38CAF28C2488@web.de> References: <4857E8A3.9000104@nnt.lt> <4857EC24.1000500@nnt.lt> <14923D53-A91A-4A2D-ADFE-38CAF28C2488@web.de> Message-ID: <486E9CC2.20003@terra.es> Were you able to build it? pablo Andreas F?rber escribi?: > Hello, > > Try configuring --with-gc=none first. Then try --with-gc=boehm and use > a recent Boehm GC such as 7.1 or 7.0 (with appropriate CPPFLAGS and > LDFLAGS if necessary). If the "sigaltstack" feature is enabled by > default, try --with-sigaltstack=no. That's some of the things I needed > to do on Solaris. > > libgdiplus has definitely nothing to do with this. > > Andreas > > Am 17.06.2008 um 18:53 schrieb Genadijus Paleckis: > > >> Forgot to mention that when build freezes when mini-mono compiling >> something it consumes 100% CPU. >> >> Genadijus Paleckis wrote: >> >>> Hello list. >>> >>> I have a problem while compiling 1.9.1 on OpenBSD 4.3. >>> >>> I must say that I am compiling it without having libgdiplus (because >>> /Compiling_Mono says I must have it as other dependencies, I think >>> it is >>> not big deal because I don't want to have any drawing support, >>> well... >>> at least for now). >>> >>> because it is running from OpenBSD ports subsystem I will display >>> what >>> ENV it is using now. >>> >>> configure script is running with environment: >>> CC="cc" >>> ac_cv_path_CC="cc" >>> CFLAGS="-O2 -pipe" >>> CXX="c++" >>> ac_cv_path_CXX="c++" >>> CXXFLAGS="-O2 -pipe" >>> INSTALL="/usr/bin/install -c -o root -g bin" >>> ac_given_INSTALL="/usr/bin/install -c -o root -g bin" >>> INSTALL_PROGRAM="install -c -s -o root -g bin -m 555 >>> INSTALL_MAN="install -c -o root -g bin -m 444" >>> INSTALL_SCRIPT="install -c -o root -g bin -m 555" >>> INSTALL_DATA="install -c -o root