From igorz at mainsoft.com Sun Jul 1 07:17:58 2007 From: igorz at mainsoft.com (Igor Zelmanovich) Date: Sun, 1 Jul 2007 04:17:58 -0700 Subject: [Mono-dev] GridView patches In-Reply-To: <007601c7b958$73d70340$f265a8c0@laptopdban> References: <007601c7b958$73d70340$f265a8c0@laptopdban> Message-ID: Hi there. I commited the patches and corresponding tests. Take a look for r81138 and r81139 Thanks. From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Dumitru Ban Sent: Thursday, June 28, 2007 10:47 AM To: mono-devel-list at lists.ximian.com Subject: [Mono-dev] GridView patches Hi, ? I have 2 patches for the GridView. They are the result of trying to customize the pager of the GridView. I've created a CustomGridView derived from System.Web.UI.WebControls.GridView. To customize the pager I'm using a?pager template and override the InitializePager of the GridView: protected override void InitializePager(GridViewRow row, int columnSpan, PagedDataSource pagedDataSource) { ??? if (this.ExtendedPager) ??? { ??? ??? ExtendedPagerTemplate pagerTemplate = new ExtendedPagerTemplate(this.PageIndex, this.PageCount, this.PageSize, pagedDataSource.DataSourceCount, PagerStyle); ??? ??? base.PagerTemplate = pagerTemplate; ??? } ??? base.InitializePager(row, columnSpan, pagedDataSource); } ? Here is where the first problem appears. Because the GridView.PagerTemplare looks like this public virtual ITemplate PagerTemplate { ??? get { return pagerTemplate; } ??? set { pagerTemplate = value; RequireBinding (); } } ? we will have infinte recursion. The RequireBinding() in the PagerTemplare should not be there. GridView_1.patch should fix this problem. ? Also, I want the pager to be visible even if there is only one page. For this I override the CreateChildControls method of the GridView: protected override int CreateChildControls(System.Collections.IEnumerable dataSource, bool dataBinding) { ??? int res = base.CreateChildControls(dataSource, dataBinding); ??? if (PagerSettings.Visible == true) ??? { ??? ??? if (PagerSettings.Position == PagerPosition.Bottom || PagerSettings.Position == PagerPosition.TopAndBottom) ??? ??? ??? if (BottomPagerRow != null) ??? ??? ??? ??? BottomPagerRow.Visible = true; ??? ??? if (PagerSettings.Position == PagerPosition.Top || PagerSettings.Position == PagerPosition.TopAndBottom) ??? ??? ??? if (TopPagerRow != null) ??? ??? ??? ??? TopPagerRow.Visible = true; ??? } ??? return res; } ? This works fine using Microsoft .NET.?I've made some debugging and I saw that the pager is created even if there is only one page, but is not visible. The code written in the overridden CreateChildControls makes the pager to be visible. With MONO the pager is not created at all and the code written in the overridden CreateChildControls doesn't do anything because BottomPagerRow/TopPagerRow are null when only 1 page exists. GridView_2.patch should fix this problem. The patch also takes into account the value of PagerSetting.Visible for the pager creation. ? Please review and apply them. ? Thanks & best regards, Dumi. From olivier.duff at gmail.com Sun Jul 1 18:18:32 2007 From: olivier.duff at gmail.com (olivier dufour) Date: Mon, 2 Jul 2007 00:18:32 +0200 Subject: [Mono-dev] ref and out for param in override methode Message-ID: Hi all, 1) I have a strange bug in my javascript compiler. When I run unit test on Optionsparser of javascript compiler of moonlight, I see a strange behaviour: The base methode is GetHelp (out usage, out optionsParsertext, out environlentVariables, out comments). But in the derived class of MS JavaScript compiler I have options.GetHelp (ref usage, ref optionsParsertext, ref environlentVariables, ref comments); But if I override it in my code compiler only want ref to overide "ref param" and not "out param" whereas MS dll done it. How it can be possible and how do it? 2) Miguel talked about regular unit test for javascript compiler. Is it Mozilla javascript test? For moment I have only my own test to test all statement and some basic expression. 3) I am near end of JScript compiler and I have a lot of little issue to make unit test on some nested methode of my class (private override and sealed class). If someone know a solution to do unit test of this kind of properties/methodes... Thanks for help, Olivier Dufour, bye -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070702/f20919b2/attachment.html From calberto.cortez at gmail.com Sun Jul 1 21:52:08 2007 From: calberto.cortez at gmail.com (Carlos Alberto Cortez) Date: Sun, 01 Jul 2007 20:52:08 -0500 Subject: [Mono-dev] SerialPort - patch waiting to apply In-Reply-To: <23a15590706280844x69eb099bsa30138af343a3d04@mail.gmail.com> References: <23a15590706280844x69eb099bsa30138af343a3d04@mail.gmail.com> Message-ID: <1183341128.3304.1.camel@localhost.localdomain> El jue, 28-06-2007 a las 17:44 +0200, Leszek Ciesielski escribi?: > http://bugzilla.ximian.com/show_bug.cgi?id=78911 > > There's a patch and Miguel's positive comment - can someone apply this, please? Sorry, I thought I had applied it already. This is now in SVN. Thanks for the remainder. From miguel at novell.com Sun Jul 1 23:13:33 2007 From: miguel at novell.com (Miguel de Icaza) Date: Sun, 01 Jul 2007 23:13:33 -0400 Subject: [Mono-dev] ref and out for param in override methode In-Reply-To: References: Message-ID: <1183346013.30505.172.camel@erandi.dom> Hello Olivier, > 1) I have a strange bug in my javascript compiler. When I run unit > test on Optionsparser of javascript compiler of moonlight, I see a > strange behaviour: > The base methode is GetHelp (out usage, out optionsParsertext, out > environlentVariables, out comments). But in the derived class of MS > JavaScript compiler I have options.GetHelp (ref usage, ref > optionsParsertext, ref environlentVariables, ref comments); > But if I override it in my code compiler only want ref to overide "ref > param" and not "out param" whereas MS dll done it. How it can be > possible and how do it? This could be a bug in our compiler. If you have a small test case, please file a bug report with the test case. In the meantime, is it possible to avoid this construct? > 2) Miguel talked about regular unit test for javascript compiler. Is > it Mozilla javascript test? For moment I have only my own test to test > all statement and some basic expression. Yes, that test suite. I think we adapted it in the past for jsc (we talked online about that one). There might be a newer version of the test suite, and ideally we could use that. Miguel. From miguel at novell.com Sun Jul 1 23:14:00 2007 From: miguel at novell.com (Miguel de Icaza) Date: Sun, 01 Jul 2007 23:14:00 -0400 Subject: [Mono-dev] ref and out for param in override methode In-Reply-To: References: Message-ID: <1183346040.30505.175.camel@erandi.dom> Hello Olivier, Do you keep a "to-do" list or a task list of things that are missing in the compiler and areas where people could work or assist? MIguel. From olivier.duff at gmail.com Mon Jul 2 02:02:39 2007 From: olivier.duff at gmail.com (olivier dufour) Date: Mon, 2 Jul 2007 08:02:39 +0200 Subject: [Mono-dev] ref and out for param in override methode In-Reply-To: <1183346040.30505.175.camel@erandi.dom> References: <1183346040.30505.175.camel@erandi.dom> Message-ID: Hello, In fact, I have not a real TODO list because all TODO is mainly unit tested class ( the AST and Token class is just properties with a Ctor with param of properties) so not really needed but a lot of other class need it! I have some class to finished as Engine and RowanGenerator and all is easy to see in code with the throw NotImplementedExeception or the TODO in comment or MONOTODO in attribute... The next big point is integrate Mozilla unit test. the current TODO list is : - Do unit test for expression part of parser and all class not tested Compiler.cs IdentifierMappingTable.cs JavaScriptCompiler.cs TokenCategorizer.cs Table.cs String.cs CommandLine.cs RowanGenerator.cs Engine.cs - Fill the throw NotImplementedException(); of Engine.cs, RowanGenerator.cs, Strings.cs and CommandLine.cs - Fill the MonoTODO : TokenCategorizer.cs For the compiler issue, MS compiler done the same so I really do not understand... There is a trick somewhere to do that... bye, Olivier Dufour 2007/7/2, Miguel de Icaza : > > Hello Olivier, > > Do you keep a "to-do" list or a task list of things that are missing > in the compiler and areas where people could work or assist? > > MIguel. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070702/fa518041/attachment.html From dev.malst at apsystems.it Mon Jul 2 10:26:03 2007 From: dev.malst at apsystems.it (APS) Date: Mon, 02 Jul 2007 16:26:03 +0200 Subject: [Mono-dev] Cannot load Mono.Security.dll In-Reply-To: <1183141776.3848.39.camel@poupou.home> References: <7.0.0.16.0.20070628172558.01d0c5c8@apsystems.it> <1183141776.3848.39.camel@poupou.home> Message-ID: <7.0.0.16.0.20070702143336.01d82010@apsystems.it> Hi, thanks for the answer. I searched "man mono" but I was not able to find how to have a log with where assemblies are searched for. Btw when I launch the gacutil command I receive Mono.Security, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 Mono.Security, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 so they're present in the gac and there shouldn't be problems on path. I gathered infos about the system, hoping that may helps # cat /proc/version Linux version 2.6.9-5.ELsmp (bhcompile at thor.perf.redhat.com) (gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) # mono --version Mono JIT compiler version 1.1.17.2, (C) 2002-2006 Novell, Inc and Contributors. www.mono-project.com TLS: __thread GC: Included Boehm (with typed GC) SIGSEGV: altstack Disabled: none # mcs --version Mono C# compiler version 1.1.17.2 Some other hint? :-) At 20.29 29/06/2007, Sebastien Pouliot wrote: >On Fri, 2007-06-29 at 12:41 +0200, APS wrote: > > I'm in doubt that my mails are blocked by antispam filters on ML > > users client machines. > > You can confirm that my mail was received... > >Yes it is. However it lacks many details that could help us help you. >E.g. your environment, like the OS, Mono version number, Fx version >being used... > > > and maybe give me some hint? :-) > >see below > > > At 10.53 27/06/2007, you wrote: > > >Hi, I've a problem on sending mail with SSL auth. > > >When sending mail I obtain > > > > > >Cannot load Mono.Security.dll ---> System.Web.Mail.SmtpException: > > >Cannot load Mono.Security.dll > > > at System.Web.Mail.SmtpClient.ChangeToSSLSocket () [0x00000] > > > at System.Web.Mail.SmtpClient.StartSend > > >(System.Web.Mail.MailMessageWrapper msg) [0x00000] > > > at System.Web.Mail.SmtpClient.Send > > >(System.Web.Mail.MailMessageWrapper msg) [0x00000] > > > at System.Web.Mail.SmtpMail.Send (System.Web.Mail.MailMessage > > >message) [0x00000] --- End of inner exception stack trace --- > > > > > >I checked that mono.security.dll is present on the machine both on > > >1.0 and 2.0 directories. > >That's unclear as it could mean more than one location (e.g. build dir >versus gac). > >Hint: Try the following to see if the assembly is installed > > gacutil -l | grep Mono.Security > >Hint#2: Try "man mono" and you'll see the options to log where >Mono.Security is being looked for. > > > >I'm missing something? > >Of course, otherwise it would work ;-) > >-- >Sebastien Pouliot >Blog: http://pages.infinit.net/ctech/ From contacto at darioquintana.com.ar Mon Jul 2 11:38:01 2007 From: contacto at darioquintana.com.ar (Dario Quintana) Date: Mon, 2 Jul 2007 12:38:01 -0300 Subject: [Mono-dev] issue with delegate and annonymous methods Message-ID: Hi people, I'm using mono1.2.4, and I got this error when I run this application: http://darioquintana.com.ar/temp/monosms.zip [csc] D:\monosms\src\Mono.Sms\Main.cs(281,49): error CS0103: The name `Age nda' does not exist in the context of `<>c__CompilerGenerated0' [csc] Compilation failed: 1 error(s), 0 warnings The zip include the NAnt build file to compile. The class http://monosms.googlecode.com/svn/trunk/src/Mono.Sms/Main.cs works fine with this method: private void btnAddContact_Click(object sender, EventArgs e) { Contacts frm = new Contacts(); frm.Operation = Operation.Add; //bug en gmcs: //frm.ContactsEventHandler += delegate(Contact contact, Operation op) // { // Agenda.AddContact(contact); // LoadContacts(); // }; //Uso esto hasta que lo reparen ! frm.ContactsEventHandler += AddContact; frm.ShowDialog(); } But with this I got the named exception: private void btnAddContact_Click(object sender, EventArgs e) { Contacts frm = new Contacts(); frm.Operation = Operation.Add; //bug en gmcs: frm.ContactsEventHandler += delegate(Contact contact, Operation op) { Agenda.AddContact(contact); LoadContacts(); }; //Uso esto hasta que lo reparen ! //frm.ContactsEventHandler += AddContact; frm.ShowDialog(); } -- Dario Quintana From marek.safar at seznam.cz Mon Jul 2 12:05:55 2007 From: marek.safar at seznam.cz (Marek Safar) Date: Mon, 02 Jul 2007 17:05:55 +0100 Subject: [Mono-dev] issue with delegate and annonymous methods In-Reply-To: References: Message-ID: <46892263.3020304@seznam.cz> Hello Dario, I could not reproduce the issue with SVN version of gmcs. Can you try to use SVN version of gmcs ? Regards, Marek > I'm using mono1.2.4, and I got this error when I run this application: > http://darioquintana.com.ar/temp/monosms.zip > > [csc] D:\monosms\src\Mono.Sms\Main.cs(281,49): error CS0103: The name `Age > nda' does not exist in the context of `<>c__CompilerGenerated0' > [csc] Compilation failed: 1 error(s), 0 warnings > > The zip include the NAnt build file to compile. > > The class http://monosms.googlecode.com/svn/trunk/src/Mono.Sms/Main.cs > works fine with this method: > > private void btnAddContact_Click(object sender, EventArgs e) > { > Contacts frm = new Contacts(); > frm.Operation = Operation.Add; > > //bug en gmcs: > //frm.ContactsEventHandler += delegate(Contact contact, > Operation op) > // { > // Agenda.AddContact(contact); > // LoadContacts(); > // }; > > //Uso esto hasta que lo reparen ! > frm.ContactsEventHandler += AddContact; > > frm.ShowDialog(); > } > > But with this I got the named exception: > > private void btnAddContact_Click(object sender, EventArgs e) > { > Contacts frm = new Contacts(); > frm.Operation = Operation.Add; > > //bug en gmcs: > frm.ContactsEventHandler += delegate(Contact contact, Operation op) > { > Agenda.AddContact(contact); > LoadContacts(); > }; > > //Uso esto hasta que lo reparen ! > //frm.ContactsEventHandler += AddContact; > > frm.ShowDialog(); > } > > From contacto at darioquintana.com.ar Mon Jul 2 12:09:51 2007 From: contacto at darioquintana.com.ar (Dario Quintana) Date: Mon, 2 Jul 2007 13:09:51 -0300 Subject: [Mono-dev] issue with delegate and annonymous methods In-Reply-To: <46892263.3020304@seznam.cz> References: <46892263.3020304@seznam.cz> Message-ID: Ok I gonna try to use the svn version. Now I'm using the Ubuntu package for Mono 1.2.4, maybe it's fixed. Regards On 7/2/07, Marek Safar wrote: > Hello Dario, > > I could not reproduce the issue with SVN version of gmcs. > Can you try to use SVN version of gmcs ? > > Regards, > Marek > > I'm using mono1.2.4, and I got this error when I run this application: > > http://darioquintana.com.ar/temp/monosms.zip > > > > [csc] D:\monosms\src\Mono.Sms\Main.cs(281,49): error CS0103: The name `Age > > nda' does not exist in the context of `<>c__CompilerGenerated0' > > [csc] Compilation failed: 1 error(s), 0 warnings > > > > The zip include the NAnt build file to compile. > > > > The class http://monosms.googlecode.com/svn/trunk/src/Mono.Sms/Main.cs > > works fine with this method: > > > > private void btnAddContact_Click(object sender, EventArgs e) > > { > > Contacts frm = new Contacts(); > > frm.Operation = Operation.Add; > > > > //bug en gmcs: > > //frm.ContactsEventHandler += delegate(Contact contact, > > Operation op) > > // { > > // Agenda.AddContact(contact); > > // LoadContacts(); > > // }; > > > > //Uso esto hasta que lo reparen ! > > frm.ContactsEventHandler += AddContact; > > > > frm.ShowDialog(); > > } > > > > But with this I got the named exception: > > > > private void btnAddContact_Click(object sender, EventArgs e) > > { > > Contacts frm = new Contacts(); > > frm.Operation = Operation.Add; > > > > //bug en gmcs: > > frm.ContactsEventHandler += delegate(Contact contact, Operation op) > > { > > Agenda.AddContact(contact); > > LoadContacts(); > > }; > > > > //Uso esto hasta que lo reparen ! > > //frm.ContactsEventHandler += AddContact; > > > > frm.ShowDialog(); > > } > > > > > > > -- Dario Quintana http://blog.darioquintana.com.ar From joe at otee.dk Mon Jul 2 16:19:33 2007 From: joe at otee.dk (Joachim Ante) Date: Mon, 2 Jul 2007 22:19:33 +0200 Subject: [Mono-dev] Walking all managed objects Message-ID: Hi, Is there any way from managed or unmanaged code to iterate through all allocated managed objects? I presume the Garbage collector must have this data somewhere? I basically want to see which objects are being referenced and then unload some unmanaged data based on it. I don't want to override the finalizer for performance reasons. In our situation there are specific times where i can just spend a bunch of time on cleanup. Joachim Ante From kumpera at gmail.com Mon Jul 2 16:46:33 2007 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Mon, 2 Jul 2007 17:46:33 -0300 Subject: [Mono-dev] Walking all managed objects In-Reply-To: References: Message-ID: <8cca42d80707021346y3b086461jbcdb5a2431d3b60@mail.gmail.com> Joachim, Heap walking is not supported AFAIK. You could, in theory, implement this feature by extending the garbage collector, but this would require some big mono hacking, which I think you should avoid. >From the performance point of view, using finalizer is make for sense for what you require, since the GC only have to worry about a small bunch of objects and your application won't perform full heap scan, which is a operation with a high cost. Using finalizer should be even better once mono ships with sgen as default. Sgen is a generational garbage collector and most of time it only scans a fraction of the heap. This means that it would process finalizers at a lower cost than performing the full heap scans you have sugested. Anyway, it's not a good practice to rely on the GC to perform resources management, as it doesn't provide any hard guarantees about when they will be freed. This could lead to file descriptor exaction or sub-optimal system performance. The best way is to let the application do manual resource management. It's not that hard and produces better result. In your example, it could have a queue that it's processed at specific times. Cheers, Rodrigo Kumpera On 7/2/07, Joachim Ante wrote: > > Hi, > > Is there any way from managed or unmanaged code to iterate through > all allocated managed objects? > I presume the Garbage collector must have this data somewhere? > > I basically want to see which objects are being referenced and then > unload some unmanaged data based on it. > I don't want to override the finalizer for performance reasons. In > our situation there are specific times where i can just spend a bunch > of time on cleanup. > > Joachim Ante > _______________________________________________ > 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/20070702/59923acf/attachment.html From contacto at darioquintana.com.ar Mon Jul 2 17:23:02 2007 From: contacto at darioquintana.com.ar (Dario Quintana) Date: Mon, 2 Jul 2007 18:23:02 -0300 Subject: [Mono-dev] issue with delegate and annonymous methods In-Reply-To: References: <46892263.3020304@seznam.cz> Message-ID: I've update mono from the SVN. Now, 1 question, you have tested the example with NAnt or Monovelop ? Because with monodevelop it's working, but when I run NAnt I still got the message: [csc] /home/dario/monosms/src/Mono.Sms/Main.cs(281,49): error CS0103: The name `Agenda' does not exist in the context of `<>c__CompilerGenerated0' Thanks and regards On 7/2/07, Dario Quintana wrote: > Ok I gonna try to use the svn version. Now I'm using the Ubuntu > package for Mono 1.2.4, maybe it's fixed. > > Regards > > On 7/2/07, Marek Safar wrote: > > Hello Dario, > > > > I could not reproduce the issue with SVN version of gmcs. > > Can you try to use SVN version of gmcs ? > > > > Regards, > > Marek > > > I'm using mono1.2.4, and I got this error when I run this application: > > > http://darioquintana.com.ar/temp/monosms.zip > > > > > > [csc] D:\monosms\src\Mono.Sms\Main.cs(281,49): error CS0103: The name `Age > > > nda' does not exist in the context of `<>c__CompilerGenerated0' > > > [csc] Compilation failed: 1 error(s), 0 warnings > > > > > > The zip include the NAnt build file to compile. > > > > > > The class http://monosms.googlecode.com/svn/trunk/src/Mono.Sms/Main.cs > > > works fine with this method: > > > > > > private void btnAddContact_Click(object sender, EventArgs e) > > > { > > > Contacts frm = new Contacts(); > > > frm.Operation = Operation.Add; > > > > > > //bug en gmcs: > > > //frm.ContactsEventHandler += delegate(Contact contact, > > > Operation op) > > > // { > > > // Agenda.AddContact(contact); > > > // LoadContacts(); > > > // }; > > > > > > //Uso esto hasta que lo reparen ! > > > frm.ContactsEventHandler += AddContact; > > > > > > frm.ShowDialog(); > > > } > > > > > > But with this I got the named exception: > > > > > > private void btnAddContact_Click(object sender, EventArgs e) > > > { > > > Contacts frm = new Contacts(); > > > frm.Operation = Operation.Add; > > > > > > //bug en gmcs: > > > frm.ContactsEventHandler += delegate(Contact contact, Operation op) > > > { > > > Agenda.AddContact(contact); > > > LoadContacts(); > > > }; > > > > > > //Uso esto hasta que lo reparen ! > > > //frm.ContactsEventHandler += AddContact; > > > > > > frm.ShowDialog(); > > > } > > > > > > > > > > > > > > > -- > Dario Quintana > http://blog.darioquintana.com.ar > -- Dario Quintana http://blog.darioquintana.com.ar From cedricv at neonux.com Mon Jul 2 17:30:47 2007 From: cedricv at neonux.com (Cedric Vivier) Date: Mon, 2 Jul 2007 23:30:47 +0200 Subject: [Mono-dev] Walking all managed objects In-Reply-To: <8cca42d80707021346y3b086461jbcdb5a2431d3b60@mail.gmail.com> References: <8cca42d80707021346y3b086461jbcdb5a2431d3b60@mail.gmail.com> Message-ID: On 7/2/07, Rodrigo Kumpera wrote: > Heap walking is not supported AFAIK. You could, in theory, implement this > feature by extending the garbage collector, but this would require some big > mono hacking, which I think you should avoid. Hi! Doesn't heapshot[1] already implement this in some way? (or at least it should be a good start) [1] http://www.mono-project.com/HeapShot From marek.safar at seznam.cz Mon Jul 2 17:30:55 2007 From: marek.safar at seznam.cz (Marek Safar) Date: Mon, 02 Jul 2007 22:30:55 +0100 Subject: [Mono-dev] issue with delegate and annonymous methods In-Reply-To: References: <46892263.3020304@seznam.cz> Message-ID: <46896E8F.7010506@seznam.cz> Hello, > I've update mono from the SVN. Now, 1 question, you have tested the > example with NAnt or Monovelop ? > I used MonoDevelop project because I have some very old NAnt version. What is the difference ? Marek From joe at joeshaw.org Mon Jul 2 17:51:23 2007 From: joe at joeshaw.org (Joe Shaw) Date: Mon, 2 Jul 2007 17:51:23 -0400 Subject: [Mono-dev] Walking all managed objects In-Reply-To: References: <8cca42d80707021346y3b086461jbcdb5a2431d3b60@mail.gmail.com> Message-ID: Hi, On 7/2/07, Cedric Vivier wrote: > On 7/2/07, Rodrigo Kumpera wrote: > > Heap walking is not supported AFAIK. You could, in theory, implement this > > feature by extending the garbage collector, but this would require some big > > mono hacking, which I think you should avoid. > > Doesn't heapshot[1] already implement this in some way? (or at least > it should be a good start) > > [1] http://www.mono-project.com/HeapShot Yeah, as does heap-buddy. To do this you need to write a profiler which hooks into the allocation and GC functions and keep track of the objects yourself. The heap-shot code for this is pretty straightforward; everything you need is in heap-shot.c. Joe From m.j.hutchinson at gmail.com Mon Jul 2 17:54:19 2007 From: m.j.hutchinson at gmail.com (Michael Hutchinson) Date: Mon, 2 Jul 2007 22:54:19 +0100 Subject: [Mono-dev] issue with delegate and annonymous methods In-Reply-To: <46892263.3020304@seznam.cz> References: <46892263.3020304@seznam.cz> Message-ID: On 7/2/07, Marek Safar wrote: > Hello Dario, > > I could not reproduce the issue with SVN version of gmcs. > Can you try to use SVN version of gmcs ? I can confirm I had a very similar issue with gmcs in Mono 1.2.4 on Ubuntu Feisty (sorry I didn't have time to report it at the time). I had to patch MD to work around it: http://anonsvn.mono-project.com/viewcvs/trunk/monodevelop/Core/src/MonoDevelop.Ide/MonoDevelop.Ide.StandardHeader/StandardHeaderPanel.cs?rev=80375&view=markup It wasn't just me either: http://lists.ximian.com/pipermail/monodevelop-list/2007-June/006133.html However, I can't repro it (now on Gutsy) with a small testcase, so it may be more complicated than it looks, or an issue with Ubuntu... -- Michael Hutchinson http://mjhutchinson.com From contacto at darioquintana.com.ar Mon Jul 2 18:09:35 2007 From: contacto at darioquintana.com.ar (Dario Quintana) Date: Mon, 2 Jul 2007 19:09:35 -0300 Subject: [Mono-dev] issue with delegate and annonymous methods In-Reply-To: <46896E8F.7010506@seznam.cz> References: <46892263.3020304@seznam.cz> <46896E8F.7010506@seznam.cz> Message-ID: I don't know the difference, but with monodevelop it's ok, but with NAnt I got the exception :s very strange I dont know what it's wrong :s because I have 1 file gmcs.exe in my linux, I deleted the rest...what can I do :) Then NAnt/MD are using the same compiler. Some Clue ? On 7/2/07, Marek Safar wrote: > Hello, > > I've update mono from the SVN. Now, 1 question, you have tested the > > example with NAnt or Monovelop ? > > > I used MonoDevelop project because I have some very old NAnt version. What > is the difference ? > > Marek > > > -- Dario Quintana http://blog.darioquintana.com.ar From kumpera at gmail.com Mon Jul 2 19:03:43 2007 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Mon, 2 Jul 2007 20:03:43 -0300 Subject: [Mono-dev] [PATCH] move access check code from mini/mini.c to metadata/class.c Message-ID: <8cca42d80707021603g31897bcblbc66cadd772f7d4d@mail.gmail.com> Hi guys The attached patch moves can_access_field and can_access_method from mini.cto class.c. The reason behind this change is to allow code sharing between verifier and JIT as access checks are meat to be exactly the same between the two. The current patch just move the code and makes no modification. Following patches will implement the TODO items. Cheers, Rodrigo Kumpera -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070702/82643182/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: access_check.patch Type: application/octet-stream Size: 8359 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070702/82643182/attachment.obj From joncham at gmail.com Mon Jul 2 23:03:54 2007 From: joncham at gmail.com (Jonathan Chambers) Date: Mon, 2 Jul 2007 23:03:54 -0400 Subject: [Mono-dev] mono crashing on windows In-Reply-To: <67c29c7c0706290302y4053a06bgba52eb6e7f9a7811@mail.gmail.com> References: <17c2d80b0706241829o111d9c31xc2f87bcfff2b2224@mail.gmail.com> <17c2d80b0706250401y6b6a7897t2559b95100859745@mail.gmail.com> <67c29c7c0706270425o56d5cb06jc081ea9c399fe7a5@mail.gmail.com> <67c29c7c0706271050y47650d54r2daae8af9d840711@mail.gmail.com> <17c2d80b0706280624j3c58029t10feb9415a8d0fa8@mail.gmail.com> <67c29c7c0706290302y4053a06bgba52eb6e7f9a7811@mail.gmail.com> Message-ID: <17c2d80b0707022003p5d857495n27ba50d502712594@mail.gmail.com> Just to close this issue, the problem seems to be with r80012 (I tracked it down to this rev this morning). I think it's the same issue Atsushi points out here: http://bugzilla.ximian.com/show_bug.cgi?id=77596 Thanks, Jonathan On 6/29/07, Marcos Cobe?a Mori?n wrote: > > Hello Jonathan, > > It's true it's not fully fixed, but at least let me keep on working > (make doesn't notice about it, so keeps building). Mono keeps crashing > after a successful build, but I've noticed it's only when building 2.0 > assemblies from bootstrap with gmcs. > > Please, let us know the root when you'll find it. > > Thanks. > > Regards, > > 2007/6/28, Jonathan Chambers : > > Marcos, > > That didn't seem to help me unfortunately. I am still bisecting > > previous versions to find when this problem started for me. Just takes a > > while to build on windows... > > > > - Jonathan > > > > > > On 6/27/07, Marcos Cobe?a Mori?n wrote: > > > Hello again, > > > > > > Atsushi Eno has given me the magic command: make maintainer-clean > > > (under mono). It seems to have solved, for now, the issue. > > > > > > Thanks Atsushi! > > > > > > Regards, > > > > > > 2007/6/27, Marcos Cobe?a Mori?n < marcoscobena at gmail.com>: > > > > Hello there, > > > > > > > > Same behavior for me. However, I could build mcs/mono/olive > > > > successfully, although it keeps crashing. I'm also using GCC under > > > > Cygwin. > > > > > > > > Jonathan, did you find the root? > > > > > > > > Thanks in advance. > > > > > > > > Regards, > > > > > > > > 2007/6/25, Jonathan Chambers : > > > > > Hello, > > > > > Using gcc. I am working my way back trough the revs to see if I > can > > pinpoint > > > > > when it start happening for me. > > > > > > > > > > - Jonathan > > > > > > > > > > > > > > > On 6/25/07, Robert Jordan wrote: > > > > > > Hi Jonathan, > > > > > > > > > > > > Jonathan Chambers wrote: > > > > > > > Hello, > > > > > > > mono is crashing for me (randomly) during building the class > > libraries. > > > > > I > > > > > > > think this started last week sometime. The buildbot is bad > from > > last > > > > > > > > > > > > How did you build the runtime? VC or gcc? With gcc I did not > > > > > > encounter any problems. > > > > > > > > > > > > Robert > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > -- > > > > Marcos - http://www.youcannoteatbits.org > > > > > > > > > > > > > -- > > > Marcos - http://www.youcannoteatbits.org > > > _______________________________________________ > > > Mono-devel-list mailing list > > > Mono-devel-list at lists.ximian.com > > > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > > > > -- > Marcos - http://www.youcannoteatbits.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070702/fead9922/attachment.html From contacto at darioquintana.com.ar Tue Jul 3 02:02:29 2007 From: contacto at darioquintana.com.ar (Dario Quintana) Date: Tue, 3 Jul 2007 03:02:29 -0300 Subject: [Mono-dev] issue with delegate and annonymous methods In-Reply-To: References: <46892263.3020304@seznam.cz> <46896E8F.7010506@seznam.cz> Message-ID: Using explicit namespaces the problem it's solve. And I think that MD and NAnt do something different in the compilation time, some parameter maybe, don't know. But the issue still remain. I can not reproduce the issue in a simple class too :s The unique example that I have it's the past named example: http://darioquintana.com.ar/temp/monosms.zip On 7/2/07, Dario Quintana wrote: > I don't know the difference, but with monodevelop it's ok, but with > NAnt I got the exception :s very strange > > I dont know what it's wrong :s because I have 1 file gmcs.exe in my > linux, I deleted the rest...what can I do :) Then NAnt/MD are using > the same compiler. > > Some Clue ? > > > > On 7/2/07, Marek Safar wrote: > > Hello, > > > I've update mono from the SVN. Now, 1 question, you have tested the > > > example with NAnt or Monovelop ? > > > > > I used MonoDevelop project because I have some very old NAnt version. What > > is the difference ? > > > > Marek > > > > > > > > > -- > Dario Quintana > http://blog.darioquintana.com.ar > -- Dario Quintana http://blog.darioquintana.com.ar From lupus at ximian.com Tue Jul 3 04:57:25 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 3 Jul 2007 10:57:25 +0200 Subject: [Mono-dev] [PATCH] move access check code from mini/mini.c to metadata/class.c In-Reply-To: <8cca42d80707021603g31897bcblbc66cadd772f7d4d@mail.gmail.com> References: <8cca42d80707021603g31897bcblbc66cadd772f7d4d@mail.gmail.com> Message-ID: <20070703085725.GA32215@debian.org> On 07/02/07 Rodrigo Kumpera wrote: > The attached patch moves can_access_field and can_access_method from > mini.cto > class.c. The reason behind this change is to allow code sharing between > verifier and JIT as access checks are meat to be exactly the same between > the two. The current patch just move the code and makes no modification. > Following patches will implement the TODO items. > Index: metadata/class.h > =================================================================== > --- metadata/class.h (revision 81207) > +++ metadata/class.h (working copy) > @@ -258,6 +258,12 @@ > char * > mono_class_name_from_token (MonoImage *image, guint32 type_token); > > +gboolean > +can_access_field (MonoMethod *method, MonoClassField *field); > + > +gboolean > +can_access_method (MonoMethod *method, MonoMethod *called); > + > G_END_DECLS > > #endif /* _MONO_CLI_CLASS_H_ */ metadata/class.h is a public API header: any function exported there must obey the naming rules, in particular avoiding the pollution of the user namespace. All the public mono functions must have a "mono_" prefix. Also, in the spirit of C-based OOP code the functions that can be considered instance methods for a type should have a prefix that matches the type name (but lowercase and with underscores inserted in lowercase->uppercase transitions). In this case the function names should be: mono_method_can_access_field and mono_method_can_access_method With this change the patch can be committed. Thanks! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Tue Jul 3 05:07:48 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 3 Jul 2007 11:07:48 +0200 Subject: [Mono-dev] Interpreter? In-Reply-To: <7DC91315-255F-4270-8BF9-581A08C7D47A@web.de> References: <7DC91315-255F-4270-8BF9-581A08C7D47A@web.de> Message-ID: <20070703090748.GB32215@debian.org> On 06/30/07 Andreas F?rber wrote: > I am aware that the interpreter is not officially supported, but > having been updated this month shouldn't it at least compile? I get No, unsupported means we're not doing any work on it ourselves, we just don't actively prevent people from fixing it by removing it completely from svn. > I am stuck with my ppc64 port of the JIT so I was hoping to test the > interpreter to see if that works. Event if the interpreter compiled, it wouldn't work on ppc64. It would be better if you detailed the issues you have with the ppc64 port instead because we could help you with that. Thanks! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Tue Jul 3 05:27:17 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 3 Jul 2007 11:27:17 +0200 Subject: [Mono-dev] Walking all managed objects In-Reply-To: References: Message-ID: <20070703092717.GC32215@debian.org> On 07/02/07 Joachim Ante wrote: > Is there any way from managed or unmanaged code to iterate through > all allocated managed objects? > I presume the Garbage collector must have this data somewhere? It does, but the way it does it is not exposed and it will never be exposed (because it's an internal detail and the user can't perform the same traversal safely). You can implement something similar using reflection or the embedded API, by looking at the fields and iterating their values, though handling recursive references would be a pain in managed code and not really safe if done in unmanaged code (you can't stop the world and this means the mutator threads can change references under you or a GC can happen or many other things can go wrong...). You'll be able to do this only for GC root you keep track of yourself, though. > I basically want to see which objects are being referenced and then > unload some unmanaged data based on it. > I don't want to override the finalizer for performance reasons. In > our situation there are specific times where i can just spend a bunch > of time on cleanup. It sounds like you want to get weak references to the interesting objects (mono_gchandle_new_weakref() in the embedded API or the low-level GCHandle in managed code) and put them in an array: when the time comes you iterate the handles and check the ones that have a null target, meaning the object was collected and perform your cleanup, including freeing the GC handle. This lets you decide when to do the cleanup which seems to be one of your concerns (this solution should be a little cheaper than finalizers and definitely cheaper than doing the tarversal yourself or using the profiler interface as was suggested which have the additional issues detailed above). lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Tue Jul 3 05:29:28 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 3 Jul 2007 11:29:28 +0200 Subject: [Mono-dev] Problems trying to compile Plastic on Linux In-Reply-To: <028901c7ba73$f67c86f0$d001a8c0@beardtongue> References: <028901c7ba73$f67c86f0$d001a8c0@beardtongue> Message-ID: <20070703092928.GD32215@debian.org> On 06/29/07 pablosantosluac wrote: > I'm trying to compile the plastic server on linux using mono + NANT. > > It compiles all the .dll and even the .exe targets, but at the end it > fails: [...] > [al] Starting mono ("al.exe" > @"/tmp/tmp3e9e47fd.tmp" > /embed:"/home/CODICE/pablo/wk_pablo_juno/01nerva/src/server/loader/loaderTranslations.es.resources",loader.loaderTranslations.es.resources)' > in '/home/CODICE/pablo/wk_pablo_juno/01nerva/' > [al] ALINK: error A1044: Couldn't open > '/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server' key file. > > BUILD FAILED - 0 non-fatal error(s), 45 warning(s) > > External Program Failed: al.exe (return code was 1): > NAnt.Core.BuildException: External Program Failed: al.exe > (return code was 1) > at NAnt.Core.Tasks.ExternalProgramBase.ExecuteTask () > [0x00000] [...] > We do use a signed assembly but it is a .dll (the first one to be compiled, > and it seems without problems). > > I guess it must be very simple, but I don't understand what key file ALINK > is complaining about.... Provide a tarball with a simple test case reproducing the issue and file a bug in bugzilla. Thanks! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From pablosantosluac at terra.es Tue Jul 3 05:36:16 2007 From: pablosantosluac at terra.es (pablosantosluac) Date: Tue, 3 Jul 2007 11:36:16 +0200 Subject: [Mono-dev] Problems trying to compile Plastic on Linux References: <028901c7ba73$f67c86f0$d001a8c0@beardtongue> <20070703092928.GD32215@debian.org> Message-ID: <028701c7bd55$9ad18280$0302a8c0@beardtongue> Ok, I'll try but I'm afraid it won't be that easy. I guess a simple application will work. The problem can be with our big projects: 7 dlls, some .exe, >100KLOC... Yes, size shouldn't be the problem but understand it is not that easy to reproduce... ----- Original Message ----- From: "Paolo Molaro" To: Sent: Tuesday, July 03, 2007 11:29 AM Subject: Re: [Mono-dev] Problems trying to compile Plastic on Linux > On 06/29/07 pablosantosluac wrote: >> I'm trying to compile the plastic server on linux using mono + NANT. >> >> It compiles all the .dll and even the .exe targets, but at the end it >> fails: > [...] >> [al] Starting mono ("al.exe" >> @"/tmp/tmp3e9e47fd.tmp" >> /embed:"/home/CODICE/pablo/wk_pablo_juno/01nerva/src/server/loader/loaderTranslations.es.resources",loader.loaderTranslations.es.resources)' >> in '/home/CODICE/pablo/wk_pablo_juno/01nerva/' >> [al] ALINK: error A1044: Couldn't open >> '/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server' key file. >> >> BUILD FAILED - 0 non-fatal error(s), 45 warning(s) >> >> External Program Failed: al.exe (return code was 1): >> NAnt.Core.BuildException: External Program Failed: al.exe >> (return code was 1) >> at NAnt.Core.Tasks.ExternalProgramBase.ExecuteTask () >> [0x00000] > [...] >> We do use a signed assembly but it is a .dll (the first one to be >> compiled, >> and it seems without problems). >> >> I guess it must be very simple, but I don't understand what key file >> ALINK >> is complaining about.... > > Provide a tarball with a simple test case reproducing the issue and file > a bug in bugzilla. > Thanks! > > lupus > > -- > ----------------------------------------------------------------- > lupus at debian.org debian/rules > lupus at ximian.com Monkeys do it better > _______________________________________________ > 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 Tue Jul 3 05:43:43 2007 From: gert.driesen at telenet.be (Gert Driesen) Date: Tue, 3 Jul 2007 11:43:43 +0200 Subject: [Mono-dev] Problems trying to compile Plastic on Linux References: <028901c7ba73$f67c86f0$d001a8c0@beardtongue> <20070703092928.GD32215@debian.org> Message-ID: <00c601c7bd56$a4decb10$d9071fac@cegekanv.corp.local> ----- Original Message ----- From: "Paolo Molaro" To: Sent: Tuesday, July 03, 2007 11:29 AM Subject: Re: [Mono-dev] Problems trying to compile Plastic on Linux > On 06/29/07 pablosantosluac wrote: >> I'm trying to compile the plastic server on linux using mono + NANT. >> >> It compiles all the .dll and even the .exe targets, but at the end it >> fails: > [...] >> [al] Starting mono ("al.exe" >> @"/tmp/tmp3e9e47fd.tmp" >> /embed:"/home/CODICE/pablo/wk_pablo_juno/01nerva/src/server/loader/loaderTranslations.es.resources",loader.loaderTranslations.es.resources)' >> in '/home/CODICE/pablo/wk_pablo_juno/01nerva/' >> [al] ALINK: error A1044: Couldn't open >> '/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server' key file. >> >> BUILD FAILED - 0 non-fatal error(s), 45 warning(s) >> >> External Program Failed: al.exe (return code was 1): >> NAnt.Core.BuildException: External Program Failed: al.exe >> (return code was 1) >> at NAnt.Core.Tasks.ExternalProgramBase.ExecuteTask () >> [0x00000] > [...] >> We do use a signed assembly but it is a .dll (the first one to be >> compiled, >> and it seems without problems). >> >> I guess it must be very simple, but I don't understand what key file >> ALINK >> is complaining about.... Can you check what the value of the AssemblyKeyFile attribute is in the assembly for which you're creating the satellite assembly ? AL will use that value to load the key from if the keyfile argument is not specified on the commandline (by NAnt). Also, what version of NAnt are you using ? Gert From pablosantosluac at terra.es Tue Jul 3 05:56:53 2007 From: pablosantosluac at terra.es (pablosantosluac) Date: Tue, 3 Jul 2007 11:56:53 +0200 Subject: [Mono-dev] Problems trying to compile Plastic on Linux References: <028901c7ba73$f67c86f0$d001a8c0@beardtongue><20070703092928.GD32215@debian.org> <00c601c7bd56$a4decb10$d9071fac@cegekanv.corp.local> Message-ID: <02e501c7bd58$7c38fdf0$0302a8c0@beardtongue> Hi, The assembly info doesn't contain a key file. using System.Reflection; using System.Runtime.CompilerServices; [assembly: AssemblyDescription("BL063")] [assembly: AssemblyConfiguration("")] [assembly: AssemblyCompany("Codice Software, S.L.")] [assembly: AssemblyProduct("Plastic")] [assembly: AssemblyCopyright("2007")] [assembly: AssemblyTrademark("2007")] [assembly: AssemblyCulture("")] [assembly: AssemblyVersion("1.5.63.0")] [assembly: AssemblyDelaySign(false)] [assembly: AssemblyKeyFile("")] The NANT Version is quite old: NAnt 0.85 (Build 0.85.1932.0; rc3; 16/04/2005) But I tried with the last one included in one of the latest Mono VMWare machines and it fails too. pablo ----- Original Message ----- From: "Gert Driesen" To: "Paolo Molaro" ; Sent: Tuesday, July 03, 2007 11:43 AM Subject: Re: [Mono-dev] Problems trying to compile Plastic on Linux > > ----- Original Message ----- > From: "Paolo Molaro" > To: > Sent: Tuesday, July 03, 2007 11:29 AM > Subject: Re: [Mono-dev] Problems trying to compile Plastic on Linux > > >> On 06/29/07 pablosantosluac wrote: >>> I'm trying to compile the plastic server on linux using mono + NANT. >>> >>> It compiles all the .dll and even the .exe targets, but at the end it >>> fails: >> [...] >>> [al] Starting mono ("al.exe" >>> @"/tmp/tmp3e9e47fd.tmp" >>> /embed:"/home/CODICE/pablo/wk_pablo_juno/01nerva/src/server/loader/loaderTranslations.es.resources",loader.loaderTranslations.es.resources)' >>> in '/home/CODICE/pablo/wk_pablo_juno/01nerva/' >>> [al] ALINK: error A1044: Couldn't open >>> '/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server' key file. >>> >>> BUILD FAILED - 0 non-fatal error(s), 45 warning(s) >>> >>> External Program Failed: al.exe (return code was 1): >>> NAnt.Core.BuildException: External Program Failed: al.exe >>> (return code was 1) >>> at NAnt.Core.Tasks.ExternalProgramBase.ExecuteTask () >>> [0x00000] >> [...] >>> We do use a signed assembly but it is a .dll (the first one to be >>> compiled, >>> and it seems without problems). >>> >>> I guess it must be very simple, but I don't understand what key file >>> ALINK >>> is complaining about.... > > Can you check what the value of the AssemblyKeyFile attribute is in the > assembly for which you're creating the satellite assembly ? > > AL will use that value to load the key from if the keyfile argument is not > specified on the commandline (by NAnt). > > Also, what version of NAnt are you using ? > > Gert > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From lupus at ximian.com Tue Jul 3 06:18:43 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 3 Jul 2007 12:18:43 +0200 Subject: [Mono-dev] Cannot load Mono.Security.dll In-Reply-To: <7.0.0.16.0.20070702143336.01d82010@apsystems.it> References: <7.0.0.16.0.20070628172558.01d0c5c8@apsystems.it> <1183141776.3848.39.camel@poupou.home> <7.0.0.16.0.20070702143336.01d82010@apsystems.it> Message-ID: <20070703101843.GE32215@debian.org> On 07/02/07 APS wrote: > # mono --version > > Mono JIT compiler version 1.1.17.2, (C) 2002-2006 Novell, Inc and [...] > Some other hint? :-) No need: the above is enough to tell us you're using an ages old mono: use mono 1.2.4. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From andreas.faerber at web.de Tue Jul 3 08:31:08 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Tue, 3 Jul 2007 14:31:08 +0200 Subject: [Mono-dev] Interpreter? In-Reply-To: <20070703090748.GB32215@debian.org> References: <7DC91315-255F-4270-8BF9-581A08C7D47A@web.de> <20070703090748.GB32215@debian.org> Message-ID: <38544E7B-9D8C-4050-8231-BB933A4EE3A1@web.de> Hi Paolo, >> I am stuck with my ppc64 port of the JIT so I was hoping to test the >> interpreter to see if that works. > > Event if the interpreter compiled, it wouldn't work on ppc64. > It would be better if you detailed the issues you have with the ppc64 > port instead because we could help you with that. > Thanks! Due to its size I uploaded my unfinished patch to Bugzilla: http://bugzilla.ximian.com/show_bug.cgi?id=81455 PATCH: First, it includes changes to eglib/configure.in to make it compile on OS X and adds VPATH support to facilitate compiling for ppc and ppc64. configure.in is patched to define POWERPC or POWERPC64 depending on the pointer size (and a workaround fixes building monoburg w/eglib on OS X for now). Next, it reorganizes the ppc-codegen.h (header still needs some changes Miguel requested) - instructions are now listed alphabetically separated from the mnemonics with additions and updates for the 64-bit and 32-bit-only instructions. Then, the mini and arch ppc files were updated with #ifdefs for ppc64 doing all kinds of necessary changes. I have some FIXMEs/CHECKMEs in there, especially some numeric offsets and alignments are unclear to me. This is where I suspect the most issues. Finally, all occurrences of ppc in the sources were checked and adapted. CONFIGURATION: I configure Mono --with-gc=none --with-glib=embedded --with-ikvm- native=no while exporting CC="gcc -arch ppc64" (as well as setting ACLOCAL_FLAGS, PKG_CONFIG, PKG_CONFIG_PATH, CPPFLAGS, LDFLAGS appropriately), using a ppc Mono installation of the same revision for bootstrapping. (configuring without GC first to rule that out as a source of errors) TEST ENVIRONMENT AND RESULTS: Test system was a PowerMac G5 dual-core with OS X v10.4.8/9/10. The ppc Mono is symlinked from /Library/Mono.framework and used "for production" - it works fine with this patch applied as far as I can tell. There are no other potentially conflicting Mono installations. The ppc64 Mono runtime compiles fine. Fixing some earlier bugs it now runs like a normal app so I can kill it using Ctrl+C. However, on compilation of System.dll using the new mono (or on execution of a hello world assembly) it aborts with empty stacktrace: MONO_PATH="../../class/lib/basic:$MONO_PATH" /Users/andreas/Mono/mono- ppc64/mono/runtime/mono-wrapper ../../class/lib/basic/mcs.exe / codepage:65001 -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB - debug /noconfig -define:XML_DEP -r:System.Xml.dll -target:library - out:System.dll @System.dll.sources Stacktrace: make[8]: *** [../../class/lib/basic/System.dll] Abort trap $ mono/mini/mono ../../../testassembly.exe Stacktrace: Abort trap According to gdb and some printfs it appeared to enter an infinite loop on exception handling during JIT initialization leading to, I assume, stack overflow: $ gdb mono/mini/mono GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:54:33 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ... done (gdb) run ../../../testassembly.exe Starting program: /Users/andreas/Mono/mono-ppc64/mono/mono/mini/ mono ../../../testassembly.exe Reading symbols for shared libraries .++ done Program received signal SIGBUS, Bus error. 0x0000000000000000 in ?? () (gdb) I haven't been able to locate the error(s) for several months now and would appreciate any hints that could lead to some more progress. Thanks, Andreas From dev.malst at apsystems.it Tue Jul 3 08:50:39 2007 From: dev.malst at apsystems.it (APS) Date: Tue, 03 Jul 2007 14:50:39 +0200 Subject: [Mono-dev] Cannot load Mono.Security.dll In-Reply-To: <20070703101843.GE32215@debian.org> References: <7.0.0.16.0.20070628172558.01d0c5c8@apsystems.it> <1183141776.3848.39.camel@poupou.home> <7.0.0.16.0.20070702143336.01d82010@apsystems.it> <20070703101843.GE32215@debian.org> Message-ID: <7.0.0.16.0.20070703144815.01cd6d78@apsystems.it> Just to know, what is the way to log the path where mono search for assemblies? At 12.18 03/07/2007, you wrote: >On 07/02/07 APS wrote: > > # mono --version > > > > Mono JIT compiler version 1.1.17.2, (C) 2002-2006 Novell, Inc and >[...] > > Some other hint? :-) > >No need: the above is enough to tell us you're using an ages old mono: >use mono 1.2.4. > >lupus > >-- >----------------------------------------------------------------- >lupus at debian.org debian/rules >lupus at ximian.com Monkeys do it better >_______________________________________________ >Mono-devel-list mailing list >Mono-devel-list at lists.ximian.com >http://lists.ximian.com/mailman/listinfo/mono-devel-list From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= Tue Jul 3 09:26:56 2007 From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=) Date: Tue, 03 Jul 2007 15:26:56 +0200 Subject: [Mono-dev] Problems trying to compile Plastic on Linux In-Reply-To: <028701c7bd55$9ad18280$0302a8c0@beardtongue> References: <028901c7ba73$f67c86f0$d001a8c0@beardtongue> <20070703092928.GD32215@debian.org> <028701c7bd55$9ad18280$0302a8c0@beardtongue> Message-ID: <468A4EA0.3050201@gmail.com> pablosantosluac escribi?: > I'll try but I'm afraid it won't be that easy. I guess a simple application > will work. The problem can be with our big projects: 7 dlls, some .exe, > >100KLOC... Yes, size shouldn't be the problem but understand it is not that > easy to reproduce... Hugh, don't want to sound rude but in my case we have > 60 dlls, and reducing Mono bugs to simple testcases still don't suppose a big task. My last example is bug 81951. Regards, Andr?s [ knocte ] -- From sebastien.pouliot at gmail.com Tue Jul 3 10:55:46 2007 From: sebastien.pouliot at gmail.com (Sebastien Pouliot) Date: Tue, 03 Jul 2007 10:55:46 -0400 Subject: [Mono-dev] Cannot load Mono.Security.dll In-Reply-To: <7.0.0.16.0.20070703144815.01cd6d78@apsystems.it> References: <7.0.0.16.0.20070628172558.01d0c5c8@apsystems.it> <1183141776.3848.39.camel@poupou.home> <7.0.0.16.0.20070702143336.01d82010@apsystems.it> <20070703101843.GE32215@debian.org> <7.0.0.16.0.20070703144815.01cd6d78@apsystems.it> Message-ID: <1183474546.3848.103.camel@poupou.home> On Tue, 2007-07-03 at 14:50 +0200, APS wrote: > Just to know, what is the way to log the path where mono search for assemblies? As stated earlier "man mono" has a lot of debugging options for you. You can try this one to see from where mono loads the default (e.g. mscorlib) assemblies. MONO_LOG_LEVEL="info" MONO_LOG_MASK="asm" mono youapp.exe But as Paolo said, do yourself a favor and update to a more recent version of mono. There's been a lot of changes recently (some may not have been released yet) in the code you're trying to use. > > At 12.18 03/07/2007, you wrote: > >On 07/02/07 APS wrote: > > > # mono --version > > > > > > Mono JIT compiler version 1.1.17.2, (C) 2002-2006 Novell, Inc and > >[...] > > > Some other hint? :-) > > > >No need: the above is enough to tell us you're using an ages old mono: > >use mono 1.2.4. > > > >lupus > > > >-- > >----------------------------------------------------------------- > >lupus at debian.org debian/rules > >lupus at ximian.com Monkeys do it better > >_______________________________________________ > >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 vargaz at gmail.com Tue Jul 3 11:48:31 2007 From: vargaz at gmail.com (Zoltan Varga) Date: Tue, 3 Jul 2007 17:48:31 +0200 Subject: [Mono-dev] Interpreter? In-Reply-To: <38544E7B-9D8C-4050-8231-BB933A4EE3A1@web.de> References: <7DC91315-255F-4270-8BF9-581A08C7D47A@web.de> <20070703090748.GB32215@debian.org> <38544E7B-9D8C-4050-8231-BB933A4EE3A1@web.de> Message-ID: <295e750a0707030848h20772fear2de088e8b4dd7a87@mail.gmail.com> Hi, My guess is that this needs some low level debugging through machine code. I.e. first find out where the execution is last transferred to JIT generated code before the crash, then single step from there with gdb. Zoltan > > > I haven't been able to locate the error(s) for several months now and > would appreciate any hints that could lead to some more progress. > > Thanks, > > Andreas > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From vargaz at gmail.com Tue Jul 3 11:53:00 2007 From: vargaz at gmail.com (Zoltan Varga) Date: Tue, 3 Jul 2007 17:53:00 +0200 Subject: [Mono-dev] Interpreter? In-Reply-To: <295e750a0707030848h20772fear2de088e8b4dd7a87@mail.gmail.com> References: <7DC91315-255F-4270-8BF9-581A08C7D47A@web.de> <20070703090748.GB32215@debian.org> <38544E7B-9D8C-4050-8231-BB933A4EE3A1@web.de> <295e750a0707030848h20772fear2de088e8b4dd7a87@mail.gmail.com> Message-ID: <295e750a0707030853x6f35f4f2u8e512719227f10f0@mail.gmail.com> Also, trying to run hello, world is too much for a new port. Try compiling the JIT regression tests on a separate machine, then run them using make rcheck in the mini directory. Finding errors in the JIT tests is much easier since the tests are small. You might need to disable parts of the JIT initialization in mini_init () for a while, since that will invoke JIT compiled code for creating exception objects. There are ifdefs in that function for this purpose. Zoltan On 7/3/07, Zoltan Varga wrote: > Hi, > > My guess is that this needs some low level debugging through machine > code. I.e. > first find out where the execution is last transferred to JIT > generated code before > the crash, then single step from there with gdb. > > Zoltan > > > > > > > I haven't been able to locate the error(s) for several months now and > > would appreciate any hints that could lead to some more progress. > > > > Thanks, > > > > Andreas > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > From lupus at ximian.com Tue Jul 3 11:55:53 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 3 Jul 2007 17:55:53 +0200 Subject: [Mono-dev] Interpreter? In-Reply-To: References: <7DC91315-255F-4270-8BF9-581A08C7D47A@web.de> <20070703090748.GB32215@debian.org> Message-ID: <20070703155553.GG32215@debian.org> On 07/03/07 Andreas F?rber wrote: > First, it includes changes to eglib/configure.in to make it compile > on OS X and adds VPATH support to facilitate compiling for ppc and > ppc64. I suggest sending the eglib changes separately (note that the vararg changes need to be inside a #ifdef conditional). > Next, it reorganizes the ppc-codegen.h (header still needs some > changes Miguel requested) - instructions are now listed I'm sorry you have been led to do this kind of change: it is not acceptable to do extensive cleanups together with code changes: please send us only the code changes so we can actually review them (this will also remove one third from the patch length). > Then, the mini and arch ppc files were updated with #ifdefs for ppc64 > doing all kinds of necessary changes. I have some FIXMEs/CHECKMEs in > there, especially some numeric offsets and alignments are unclear to > me. This is where I suspect the most issues. > Finally, all occurrences of ppc in the sources were checked and adapted. I gave a very quick read of the changes, here are a few suggestions: *) you shold minimize the number of inserted #ifdefs. A patch that does: +#ifdef __ppc64__ + offset += 8; +#else offset += 4; +#endif is not acceptable, while if it did: - offset += 4; + offset += sizeof (gpointer); it would be applied right away. Similar issues are with changes like: +#ifdef __ppc64__ + __asm__ volatile("ld %0,0(r1)" : "=r" (sframe)); +#else __asm__ volatile("lwz %0,0(r1)" : "=r" (sframe)); +#endif Just add to the header something like: #ifdef __ppc64__ #define PPC_LOAD_REG_INS "ld" #else #define PPC_LOAD_REG_INS "lwz" #endif and replace the asm statements with: __asm__ volatile (PPC_LOAD_REG_INS " %0,0(r1)" : "=r" (sframe)); Something similar should be done also for the native code emitting macros. Instead of: +#ifdef __ppc64__ + ppc_ld (buf, ppc_r0, (guint16)G_STRUCT_OFFSET(MonoLMF, previous_lmf) >> 2, ppc_r3); + ppc_std (buf, ppc_r0, (guint16)G_STRUCT_OFFSET(MonoLMF, previous_lmf) >> 2, ppc_r11); +#else ppc_lwz (buf, ppc_r0, G_STRUCT_OFFSET(MonoLMF, previous_lmf), ppc_r3); ppc_stw (buf, ppc_r0, G_STRUCT_OFFSET(MonoLMF, previous_lmf), ppc_r11); +#endif define in ppc_codegen: #ifdef __ppc64__ #define ppc_load_reg(a,b,c,d) ppc_ld(a,b,(((c) >> 2) & 0xffff),d) #define ppc_store_reg(a,b,c,d) ppc_std(a,b,(((c) >> 2) & 0xffff),d) #else #define ppc_load_reg(a,b,c,d) ppc_lwz(a,b,c,d) #define ppc_store_reg(a,b,c,d) ppc_stw(a,b,c,d) #endif This will make the changes so much cleaner that it will be possible to more easily review them and find the issues (and it will also allow us to commit them incrementally to svn). *) cpu-g5.md should become cpu-ppc64.md *) the ppc_load changes are not acceptable: add a ppc_load_sequence or something like that that will emit lis/ori on 32 and the full sequence on 64 bit and use that where it is required. *) mono/io-layer/atomic.h: the changes here can't be skipped, they are used in many parts of the runtime and without the 64 bit support there can be memory corruption. *) the emit_tls_access optimizations should likely be removed unless they have been tested explicitly (they look a bit bogus). > compilation of System.dll using the new mono (or on execution of a > hello world assembly) it aborts with empty stacktrace: > > MONO_PATH="../../class/lib/basic:$MONO_PATH" /Users/andreas/Mono/mono- > ppc64/mono/runtime/mono-wrapper ../../class/lib/basic/mcs.exe / > codepage:65001 -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB - > debug /noconfig -define:XML_DEP -r:System.Xml.dll -target:library - > out:System.dll @System.dll.sources > Stacktrace: [...] > (gdb) run ../../../testassembly.exe > Starting program: /Users/andreas/Mono/mono-ppc64/mono/mono/mini/ > mono ../../../testassembly.exe > Reading symbols for shared libraries .++ done > > Program received signal SIGBUS, Bus error. > 0x0000000000000000 in ?? () This looks like the result of a jump to NULL. What are the results of running make rcheck in mini/? That is the first thing that needs checking. If it fails in the same way before starting the tests it is likely related to something earlier on in the initialization. The first thing that comes to mind is: doesn't ppc64 on OSX use function descriptors like all the other ppc64 platforms? If it does use them this would be the first thing to fix as any indirect call would pretty much fail. > I haven't been able to locate the error(s) for several months now and Well, I've been here and I don't remember seeing any jit-related request for help:) Follow the above suggestions for now and we can both try to get the changes in svn and get the bugs fixed. Thanks! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From joe at otee.dk Tue Jul 3 12:00:37 2007 From: joe at otee.dk (Joachim Ante) Date: Tue, 3 Jul 2007 18:00:37 +0200 Subject: [Mono-dev] Walking all managed objects In-Reply-To: <20070703092717.GC32215@debian.org> References: <20070703092717.GC32215@debian.org> Message-ID: Hi Paolo, > It sounds like you want to get weak references to the interesting > objects (mono_gchandle_new_weakref() in the embedded API or the > low-level GCHandle in managed code) * We do a bunch of "temporary memory" allocations which will be cleaned up by the gc immediately afterwards when eg. leaving the function that allocated the memory. Those allocations have to be really fast and i don't want to incur any extra performance penalty during normal operation. * When loading a new level, we have a bunch of time to unload unused objects. We are doing a full gc_collect at this point already anyway, so walking it one more time isn't gonna make a big difference me thinks. i'll gladly go with mono_gchandle_new_weakref solution you mentioned, if you think there is no real overhead in our use case. Basically i would need to know that mono_gchandle_new_weakref has no noticable overhead when the primary use case is quickly allocating temporary memory (Those are always wrapper objects containing 8 bytes of data) and letting it be garbage collected shortly after. > It does, but the way it does it is not exposed and it will never be > exposed (because it's an internal detail and the user can't perform > the same traversal safely). Modifying the mono code for this is not a problem. Is there some piece of code i could look at to see how to do this? Best regards, Joachim Ante From jonathan.gagnon at croesus.com Tue Jul 3 13:48:15 2007 From: jonathan.gagnon at croesus.com (Jonathan Gagnon) Date: Tue, 3 Jul 2007 13:48:15 -0400 Subject: [Mono-dev] DeflateStream : bit length overflow Message-ID: <010001c7bd9a$58234c30$1b36a8c0@PROG159> Hi, I posted this on the mono list a few weeks ago and I got no answer, so I'm trying to repost it here. Is it the right list to talk about that kind of problems? Thanks, Jonathan _____ De : mono-list-bounces at lists.ximian.com [mailto:mono-list-bounces at lists.ximian.com] De la part de Jonathan Gagnon Envoy? : Wednesday, June 20, 2007 2:31 PM ? : 'List Mono' Objet : [Mono-list] DeflateStream : bit length overflow Hi, The following messages are sent to the console when using the DeflateStream class in Mono : bit length overflow code 4 bits 6->7 The compression is working correctly, so it seems like some kind of debug trace. I did a grep on the sources to see where it comes from, and I found this line inside the mono/support/trees.c file : Trace((stderr,"\nbit length overflow\n")); Is this something that shouldn't have been checked in? Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070703/ca4e51af/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00348.txt Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070703/ca4e51af/attachment.txt From andreas.faerber at web.de Tue Jul 3 14:05:56 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Tue, 3 Jul 2007 20:05:56 +0200 Subject: [Mono-dev] ppc64 port [was: Interpreter?] In-Reply-To: <20070703155553.GG32215@debian.org> References: <7DC91315-255F-4270-8BF9-581A08C7D47A@web.de> <20070703090748.GB32215@debian.org> <20070703155553.GG32215@debian.org> Message-ID: <8CAF6819-572D-4260-B448-54B1E4B7CC74@web.de> Hey, >> First, it includes changes to eglib/configure.in to make it compile >> on OS X and adds VPATH support to facilitate compiling for ppc and >> ppc64. > > I suggest sending the eglib changes separately (note that the vararg > changes need to be inside a #ifdef conditional). This is not a patch that anyone was supposed to apply. Also, I don't see an easy way of separating changes within one file that can go in from those that are not yet ready? I *did* file eglib issues separately (#81456), unfortunately Jonathan soon after started to commit his own duplicating/conflicting Windows eglib patches that made this more difficult (see list). The vararg stuff is an uncommited patch supplied by Jonathan available from my #81520; it made eglib compile again at all. You opposed his patch and demanded that *I* add tests first to have it reverted, in a scenario where exactly those tests were not running for me due to the ppc-ppc64 cross-compilation - I made that clear but to date nobody has stepped up with a solution (you will see that in my ppc64 patch eglib currently tests itself against itself so the tests probably are effectively useless). Although not yet having used varargs in C myself, to me it looks wrong that the mandatory format argument is being dropped... So maybe there is a better way to patch where we don't need further ifdefs? >> Next, it reorganizes the ppc-codegen.h (header still needs some >> changes Miguel requested) - instructions are now listed > > I'm sorry you have been led to do this kind of change: it is not > acceptable to do extensive cleanups together with code changes: > please send us only the code changes so we can actually review them > (this will also remove one third from the patch length). I don't see the point in reverting those changes. Mine are trivial: 64-bit instructions were added and are distinguishable by corresponding #ifdefs, for existing instructions only #ifndefs were added. Nothing was changed on the old instructions, and few of them are actually used anywhere at all! The new ordering is the only way the instructions can be checked sensibly because that's the order they are in the various manuals. I specifically asked Miguel about that file and he had only minor objections regarding the use of (c) vs. Copyright. So, might it be acceptable for you to try to split this up into one reordering patch and an addition/change patch? >> Then, the mini and arch ppc files were updated with #ifdefs for ppc64 >> doing all kinds of necessary changes. I have some FIXMEs/CHECKMEs in >> there, especially some numeric offsets and alignments are unclear to >> me. This is where I suspect the most issues. >> Finally, all occurrences of ppc in the sources were checked and >> adapted. > > I gave a very quick read of the changes, here are a few suggestions: > *) you shold minimize the number of inserted #ifdefs. A patch that > does: Again this was not submitted for application. Were it clear in all places that this were actually intended I could have done so, yes. Unfortunately I am not sure everywhere that four equals sizeof (gpointer). Having it in one file during development simplifies comparison of before/after for me, avoiding the use of non-graphical svn diff (svnX's use of Apple's FileMerge tool rarely works for me). > +#ifdef __ppc64__ > + offset += 8; > +#else > offset += 4; > +#endif > > is not acceptable, while if it did: > > - offset += 4; > + offset += sizeof (gpointer); > > it would be applied right away. > Similar issues are with changes like: > +#ifdef __ppc64__ > + __asm__ volatile("ld %0,0(r1)" : "=r" (sframe)); > +#else > __asm__ volatile("lwz %0,0(r1)" : "=r" (sframe)); > +#endif > > Just add to the header something like: > #ifdef __ppc64__ > #define PPC_LOAD_REG_INS "ld" > #else > #define PPC_LOAD_REG_INS "lwz" > #endif > > and replace the asm statements with: > __asm__ volatile (PPC_LOAD_REG_INS " %0,0(r1)" : > "=r" (sframe)); > > Something similar should be done also for the native code emitting > macros. Instead of: > > +#ifdef __ppc64__ > + ppc_ld (buf, ppc_r0, (guint16)G_STRUCT_OFFSET > (MonoLMF, previous_lmf) >> 2, ppc_r3); > + ppc_std (buf, ppc_r0, (guint16)G_STRUCT_OFFSET > (MonoLMF, previous_lmf) >> 2, ppc_r11); > +#else > ppc_lwz (buf, ppc_r0, G_STRUCT_OFFSET(MonoLMF, > previous_lmf), ppc_r3); > ppc_stw (buf, ppc_r0, G_STRUCT_OFFSET(MonoLMF, > previous_lmf), ppc_r11); > +#endif > > define in ppc_codegen: > > #ifdef __ppc64__ > #define ppc_load_reg(a,b,c,d) ppc_ld(a,b,(((c) >> 2) & 0xffff),d) > #define ppc_store_reg(a,b,c,d) ppc_std(a,b,(((c) >> 2) & 0xffff),d) > #else > #define ppc_load_reg(a,b,c,d) ppc_lwz(a,b,c,d) > #define ppc_store_reg(a,b,c,d) ppc_stw(a,b,c,d) > #endif > > This will make the changes so much cleaner that it will be possible to > more easily review them and find the issues (and it will also allow > us to commit them incrementally to svn). These requested changes make sense but will take some more weeks and months which I can unlikely spend at this time... > *) cpu-g5.md should become cpu-ppc64.md In that case cpu-g4.md should also become cpu-ppc.md and the variable name in mini(?) should be changed, too. > *) the ppc_load changes are not acceptable: add a ppc_load_sequence > or something like that that will emit lis/ori on 32 and the full > sequence on 64 bit and use that where it is required. That I don't understand, please explain. ppc_load is one logical operation and is ifdef'ed as the lis/ori for 32, isn't it? All occurrences of manual lis/ori for trampolines were checked and updated and appear to work on ppc as is. So why would I need a ppc_load_sequence when there's no difference to ppc_load? The trampolines need 64-bit support in some places so we cannot say trampolines use 32-bit ppc_load and the rest 64-bit ppc_load_sequence. > *) mono/io-layer/atomic.h: the changes here can't be skipped, they are > used in many parts of the runtime and without the 64 bit support there > can be memory corruption. I will probably need more info than just "can't be skipped" to actually do that. :-) > *) the emit_tls_access optimizations should likely be removed unless > they have been tested explicitly (they look a bit bogus). Not sure what optimizations you mean? Obviously I have to update the code for ppc64 and can't just remove that part of the patch. The only "optimization" I'm aware of is removing the G4 case as the G4 to my knowledge is 32-bit by nature. >> compilation of System.dll using the new mono (or on execution of a >> hello world assembly) it aborts with empty stacktrace: >> >> MONO_PATH="../../class/lib/basic:$MONO_PATH" /Users/andreas/Mono/ >> mono- >> ppc64/mono/runtime/mono-wrapper ../../class/lib/basic/mcs.exe / >> codepage:65001 -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB - >> debug /noconfig -define:XML_DEP -r:System.Xml.dll -target:library - >> out:System.dll @System.dll.sources >> Stacktrace: > [...] >> (gdb) run ../../../testassembly.exe >> Starting program: /Users/andreas/Mono/mono-ppc64/mono/mono/mini/ >> mono ../../../testassembly.exe >> Reading symbols for shared libraries .++ done >> >> Program received signal SIGBUS, Bus error. >> 0x0000000000000000 in ?? () > > This looks like the result of a jump to NULL. > What are the results of running make rcheck in mini/? That is the > first > thing that needs checking. If it fails in the same way before starting > the tests it is likely related to something earlier on in the > initialization. I was not aware of a make rcheck, I only knew the standard make check, which fails with a similar error at the first compilation. > The first thing that comes to mind is: doesn't ppc64 on OSX > use function descriptors like all the other ppc64 platforms? If it > does > use them this would be the first thing to fix as any indirect call > would > pretty much fail. I had found no information on this. An IBM page described those for the Linux ABI, but the OS X ABI as we know differs in some points and did not talk about functions/descriptors. I don't have a ppc64 Linux running so couldn't check. My port was only targetted at OS X, for Linux some additional changes will need to be made and tested (different processor defines, offsets, the usual suspects). > Well, I've been here and I don't remember seeing any jit-related > request > for help:) Follow the above suggestions for now and we can both try to > get the changes in svn and get the bugs fixed. I'd be happy to share this with other users through SVN but as stated before the changes requested above are non-trivial and will take some time; I started the port for an AI competition of our university but didn't finish in time. ;-) I wasn't able to work on it much lately, just merged some eglib conflicts and checked that no conflicting JIT changes were introduced and played with some of the unclear offset/ etc. values. I did not ask earlier about atomic changes because I am in most cases a fan of test-driven development and did not dare submitting untested JIT changes for inclusion in SVN, the only successful tests so far being those of the ppc-codegen.h instruction macros. Andreas From miguel at novell.com Tue Jul 3 12:21:16 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 03 Jul 2007 12:21:16 -0400 Subject: [Mono-dev] Walking all managed objects In-Reply-To: References: <20070703092717.GC32215@debian.org> Message-ID: <1183479676.32680.43.camel@erandi.dom> > i'll gladly go with mono_gchandle_new_weakref solution you mentioned, > if you think there is no real overhead in our use case. > Basically i would need to know that mono_gchandle_new_weakref has no > noticable overhead when the primary use case is quickly allocating > temporary memory (Those are always wrapper objects containing 8 bytes > of data) and letting it be garbage collected shortly after. If you are only wrapping 8 bytes of data, have you considering using structs, and declaring those variables on the method entry point? That would allocate those objects on the stack. From miguel at novell.com Tue Jul 3 12:20:00 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 03 Jul 2007 12:20:00 -0400 Subject: [Mono-dev] Interpreter? In-Reply-To: <20070703155553.GG32215@debian.org> References: <7DC91315-255F-4270-8BF9-581A08C7D47A@web.de> <20070703090748.GB32215@debian.org> <20070703155553.GG32215@debian.org> Message-ID: <1183479600.32680.41.camel@erandi.dom> > Well, I've been here and I don't remember seeing any jit-related request > for help:) Follow the above suggestions for now and we can both try to > get the changes in svn and get the bugs fixed. I wanted to point out that for the changes to be committed to SVN, we need to either get a copyright assignment form for them (as the are beyond the trivial limit, 10-15 lines) or the code must be explicitly contributed under the MIT X11 license. Miguel. From pablosantosluac at terra.es Tue Jul 3 14:40:52 2007 From: pablosantosluac at terra.es (pablosantosluac) Date: Tue, 3 Jul 2007 20:40:52 +0200 Subject: [Mono-dev] Problems trying to compile Plastic on Linux References: <028901c7ba73$f67c86f0$d001a8c0@beardtongue> <20070703092928.GD32215@debian.org><028701c7bd55$9ad18280$0302a8c0@beardtongue> <468A4EA0.3050201@gmail.com> Message-ID: <012d01c7bda1$b00e73f0$0302a8c0@beardtongue> Ok, I'll try it :-P But I'm afraid it is not a bug but just something I'm doing wrong with Mono... We're also filing testcases for winforms but I expected it to be harder... Ok, I'll try... :-P ----- Original Message ----- From: ""Andr?s G. Aragoneses [ knocte ]"" To: Sent: Tuesday, July 03, 2007 3:26 PM Subject: Re: [Mono-dev] Problems trying to compile Plastic on Linux pablosantosluac escribi?: > I'll try but I'm afraid it won't be that easy. I guess a simple > application > will work. The problem can be with our big projects: 7 dlls, some .exe, > >100KLOC... Yes, size shouldn't be the problem but understand it is not > that > easy to reproduce... Hugh, don't want to sound rude but in my case we have > 60 dlls, and reducing Mono bugs to simple testcases still don't suppose a big task. My last example is bug 81951. Regards, Andr?s [ knocte ] -- _______________________________________________ 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 Tue Jul 3 16:19:47 2007 From: gert.driesen at telenet.be (Gert Driesen) Date: Tue, 3 Jul 2007 22:19:47 +0200 Subject: [Mono-dev] issue with delegate and annonymous methods In-Reply-To: Message-ID: <20070703201950.2003712404F@hoboe2bl1.telenet-ops.be> Hi, I've created a small repro for this issue and submitted a bug report for it: http://bugzilla.ximian.com/show_bug.cgi?id=82003 Gert -----Original Message----- From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Dario Quintana Sent: maandag 2 juli 2007 23:23 To: Marek Safar Cc: mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] issue with delegate and annonymous methods I've update mono from the SVN. Now, 1 question, you have tested the example with NAnt or Monovelop ? Because with monodevelop it's working, but when I run NAnt I still got the message: [csc] /home/dario/monosms/src/Mono.Sms/Main.cs(281,49): error CS0103: The name `Agenda' does not exist in the context of `<>c__CompilerGenerated0' Thanks and regards On 7/2/07, Dario Quintana wrote: > Ok I gonna try to use the svn version. Now I'm using the Ubuntu > package for Mono 1.2.4, maybe it's fixed. > > Regards > > On 7/2/07, Marek Safar wrote: > > Hello Dario, > > > > I could not reproduce the issue with SVN version of gmcs. > > Can you try to use SVN version of gmcs ? > > > > Regards, > > Marek > > > I'm using mono1.2.4, and I got this error when I run this application: > > > http://darioquintana.com.ar/temp/monosms.zip > > > > > > [csc] D:\monosms\src\Mono.Sms\Main.cs(281,49): error CS0103: > > > The name `Age nda' does not exist in the context of `<>c__CompilerGenerated0' > > > [csc] Compilation failed: 1 error(s), 0 warnings > > > > > > The zip include the NAnt build file to compile. > > > > > > The class > > > http://monosms.googlecode.com/svn/trunk/src/Mono.Sms/Main.cs > > > works fine with this method: > > > > > > private void btnAddContact_Click(object sender, EventArgs e) > > > { > > > Contacts frm = new Contacts(); > > > frm.Operation = Operation.Add; > > > > > > //bug en gmcs: > > > //frm.ContactsEventHandler += delegate(Contact > > > contact, Operation op) > > > // { > > > // Agenda.AddContact(contact); > > > // LoadContacts(); > > > // }; > > > > > > //Uso esto hasta que lo reparen ! > > > frm.ContactsEventHandler += AddContact; > > > > > > frm.ShowDialog(); > > > } > > > > > > But with this I got the named exception: > > > > > > private void btnAddContact_Click(object sender, EventArgs e) > > > { > > > Contacts frm = new Contacts(); > > > frm.Operation = Operation.Add; > > > > > > //bug en gmcs: > > > frm.ContactsEventHandler += delegate(Contact contact, Operation op) > > > { > > > Agenda.AddContact(contact); > > > LoadContacts(); > > > }; > > > > > > //Uso esto hasta que lo reparen ! > > > //frm.ContactsEventHandler += AddContact; > > > > > > frm.ShowDialog(); > > > } > > > > > > > > > > > > > > > -- > Dario Quintana > http://blog.darioquintana.com.ar > -- Dario Quintana http://blog.darioquintana.com.ar _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From steveb at mindtouch.com Tue Jul 3 16:35:17 2007 From: steveb at mindtouch.com (Steve Bjorg) Date: Tue, 3 Jul 2007 13:35:17 -0700 Subject: [Mono-dev] issue with delegate and annonymous methods In-Reply-To: <20070703201950.2003712404F@hoboe2bl1.telenet-ops.be> References: <20070703201950.2003712404F@hoboe2bl1.telenet-ops.be> Message-ID: <4D06C946-9B69-4605-90FE-5B4F66C8CBA6@mindtouch.com> Thanks for figuring out the repro steps. We've been battling this issue for months, but couldn't come up with a small enough case to submit a bug. The work-around is to use fully-qualified type name, which we did. Hope this issue gets addressed in the next release! Cheers, - Steve -------------- Steve G. Bjorg http://www.mindtouch.com http://www.opengarden.org On Jul 3, 2007, at 1:19 PM, Gert Driesen wrote: > Hi, > > I've created a small repro for this issue and submitted a bug > report for it: > http://bugzilla.ximian.com/show_bug.cgi?id=82003 > > Gert > > -----Original Message----- > From: mono-devel-list-bounces at lists.ximian.com > [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Dario > Quintana > Sent: maandag 2 juli 2007 23:23 > To: Marek Safar > Cc: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] issue with delegate and annonymous methods > > I've update mono from the SVN. Now, 1 question, you have tested the > example > with NAnt or Monovelop ? > Because with monodevelop it's working, but when I run NAnt I still > got the > message: > [csc] /home/dario/monosms/src/Mono.Sms/Main.cs(281,49): error CS0103: > The name `Agenda' does not exist in the context of > `<>c__CompilerGenerated0' > > Thanks and regards > > On 7/2/07, Dario Quintana wrote: >> Ok I gonna try to use the svn version. Now I'm using the Ubuntu >> package for Mono 1.2.4, maybe it's fixed. >> >> Regards >> >> On 7/2/07, Marek Safar wrote: >>> Hello Dario, >>> >>> I could not reproduce the issue with SVN version of gmcs. >>> Can you try to use SVN version of gmcs ? >>> >>> Regards, >>> Marek >>>> I'm using mono1.2.4, and I got this error when I run this >>>> application: >>>> http://darioquintana.com.ar/temp/monosms.zip >>>> >>>> [csc] D:\monosms\src\Mono.Sms\Main.cs(281,49): error CS0103: >>>> The name `Age nda' does not exist in the context of > `<>c__CompilerGenerated0' >>>> [csc] Compilation failed: 1 error(s), 0 warnings >>>> >>>> The zip include the NAnt build file to compile. >>>> >>>> The class >>>> http://monosms.googlecode.com/svn/trunk/src/Mono.Sms/Main.cs >>>> works fine with this method: >>>> >>>> private void btnAddContact_Click(object sender, EventArgs e) >>>> { >>>> Contacts frm = new Contacts(); >>>> frm.Operation = Operation.Add; >>>> >>>> //bug en gmcs: >>>> //frm.ContactsEventHandler += delegate(Contact >>>> contact, Operation op) >>>> // { >>>> // > Agenda.AddContact(contact); >>>> // LoadContacts(); >>>> // }; >>>> >>>> //Uso esto hasta que lo reparen ! >>>> frm.ContactsEventHandler += AddContact; >>>> >>>> frm.ShowDialog(); >>>> } >>>> >>>> But with this I got the named exception: >>>> >>>> private void btnAddContact_Click(object sender, EventArgs e) >>>> { >>>> Contacts frm = new Contacts(); >>>> frm.Operation = Operation.Add; >>>> >>>> //bug en gmcs: >>>> frm.ContactsEventHandler += delegate(Contact contact, > Operation op) >>>> { >>>> > Agenda.AddContact(contact); >>>> LoadContacts(); >>>> }; >>>> >>>> //Uso esto hasta que lo reparen ! >>>> //frm.ContactsEventHandler += AddContact; >>>> >>>> frm.ShowDialog(); >>>> } >>>> >>>> >>> >>> >>> >> >> >> -- >> Dario Quintana >> http://blog.darioquintana.com.ar >> > > > -- > Dario Quintana > http://blog.darioquintana.com.ar > _______________________________________________ > 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 marek.safar at seznam.cz Tue Jul 3 16:58:01 2007 From: marek.safar at seznam.cz (Marek Safar) Date: Tue, 03 Jul 2007 21:58:01 +0100 Subject: [Mono-dev] issue with delegate and annonymous methods In-Reply-To: <20070703201950.2003712404F@hoboe2bl1.telenet-ops.be> References: <20070703201950.2003712404F@hoboe2bl1.telenet-ops.be> Message-ID: <468AB859.9000007@seznam.cz> Hello Gert, > I've created a small repro for this issue and submitted a bug report for it: > http://bugzilla.ximian.com/show_bug.cgi?id=82003 > Awesome ! Thank you, Marek From james.fitzsimons at gmail.com Tue Jul 3 17:02:59 2007 From: james.fitzsimons at gmail.com (James Fitzsimons) Date: Tue, 03 Jul 2007 22:02:59 +0100 Subject: [Mono-dev] Spring and NHibernate support Message-ID: <1183496579.6086.7.camel@Athos> Hi all, I've recently started a major new project and intend to use spring.net and NHibernate as core parts of the architecture. I've started running into a few issues and to my dismay running MoMA over these projects yields a number of MonoTodo's and not implemented exceptions. Notable candidates are: void EmitCreateDelegateInstance(ILGenerator, Type, MethodInfo) void XmlValidatingReader.set_ValidationType(ValidationType) ConnectionStringSettingsCollection ConfigurationManager.get_ConnectionStrings() Just wondering if there are any imminent plans to support these two (fairly high profile and incredibly useful) .NET projects on Mono? If the answer isn't "It's fixed in svn" (I should be so lucky ;) then I may just get desperate enough start hacking on the missing methods myself. Thanks and regards, James Fitzsimons -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070703/9abd6d62/attachment.bin From fog at initd.org Tue Jul 3 17:06:21 2007 From: fog at initd.org (Federico Di Gregorio) Date: Tue, 03 Jul 2007 23:06:21 +0200 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <1183496579.6086.7.camel@Athos> References: <1183496579.6086.7.camel@Athos> Message-ID: <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> Il giorno mar, 03/07/2007 alle 22.02 +0100, James Fitzsimons ha scritto: > I've recently started a major new project and intend to use spring.net > and NHibernate as core parts of the architecture. I've started running > into a few issues and to my dismay running MoMA over these projects > yields a number of MonoTodo's and not implemented exceptions. Notable > candidates are: Last time I checked (1.2.3.x) mono was not able to run nhibernate 1.2. We're still using 1.0 here [and waiting for the DLinq stuff, that is much better than nhibernate imho. ;)] federico -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developer fog at debian.org INIT.D Developer fog at initd.org We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. -- D.E.Knuth -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070703/2ffe37ab/attachment.bin From joe at otee.dk Tue Jul 3 17:50:06 2007 From: joe at otee.dk (Joachim Ante) Date: Tue, 3 Jul 2007 23:50:06 +0200 Subject: [Mono-dev] Walking all managed objects In-Reply-To: <1183479676.32680.43.camel@erandi.dom> References: <20070703092717.GC32215@debian.org> <1183479676.32680.43.camel@erandi.dom> Message-ID: Hi, > If you are only wrapping 8 bytes of data, have you considering using > structs, and declaring those variables on the method entry point? > That > would allocate those objects on the stack. Unfortunately they are using inheritance. I'd love to be able to have them in structs otherwise. Joachim Ante From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= Tue Jul 3 18:47:04 2007 From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=) Date: Wed, 04 Jul 2007 00:47:04 +0200 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> Message-ID: <468AD1E8.3010305@gmail.com> Federico Di Gregorio escribi?: > Il giorno mar, 03/07/2007 alle 22.02 +0100, James Fitzsimons ha scritto: >> I've recently started a major new project and intend to use spring.net >> and NHibernate as core parts of the architecture. I've started running >> into a few issues and to my dismay running MoMA over these projects >> yields a number of MonoTodo's and not implemented exceptions. Notable >> candidates are: > > Last time I checked (1.2.3.x) mono was not able to run nhibernate 1.2. > We're still using 1.0 here [and waiting for the DLinq stuff, that is > much better than nhibernate imho. ;)] > I tracked down recently a bug[1] in Mono running NHib 1.2, but the problem is: - I haven't had much time to dig more into it, even for writing the unit tests. - As Sebastien points out in the bug, the change would break some things in Mono that are now relying on that behaviour, and thus it would involve more work and complexity for cooking a complete patch. - Perhaps fixing this and running NHib again, it would yield more bugs :( Hopefully not. BTW, check NHiberLINQ out, it seems a good combination of both worlds ;) Regards, Andr?s [ knocte ] -- [1] http://bugzilla.ximian.com/show_bug.cgi?id=80225 From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= Tue Jul 3 18:47:32 2007 From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=) Date: Wed, 04 Jul 2007 00:47:32 +0200 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> Message-ID: <468AD204.7040101@gmail.com> Federico Di Gregorio escribi?: > Il giorno mar, 03/07/2007 alle 22.02 +0100, James Fitzsimons ha scritto: >> I've recently started a major new project and intend to use spring.net >> and NHibernate as core parts of the architecture. I've started running >> into a few issues and to my dismay running MoMA over these projects >> yields a number of MonoTodo's and not implemented exceptions. Notable >> candidates are: > > Last time I checked (1.2.3.x) mono was not able to run nhibernate 1.2. > We're still using 1.0 here [and waiting for the DLinq stuff, that is > much better than nhibernate imho. ;)] > I tracked down recently a bug[1] in Mono running NHib 1.2, but the problem is: - I haven't had much time to dig more into it, even for writing the unit tests. - As Sebastien points out in the bug, the change would break some things in Mono that are now relying on that behaviour, and thus it would involve more work and complexity for cooking a complete patch. - Perhaps fixing this and running NHib again, it would yield more bugs :( Hopefully not. BTW, check NHiberLINQ out, it seems a good combination of both worlds ;) Regards, Andr?s [ knocte ] -- [1] http://bugzilla.ximian.com/show_bug.cgi?id=80225 From andreas.faerber at web.de Tue Jul 3 19:19:22 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Wed, 4 Jul 2007 01:19:22 +0200 Subject: [Mono-dev] ppc64 port [was: Interpreter?] In-Reply-To: <8CAF6819-572D-4260-B448-54B1E4B7CC74@web.de> References: <7DC91315-255F-4270-8BF9-581A08C7D47A@web.de> <20070703090748.GB32215@debian.org> <20070703155553.GG32215@debian.org> <8CAF6819-572D-4260-B448-54B1E4B7CC74@web.de> Message-ID: <43E67CB0-503A-49EA-9736-877A348C6853@web.de> Hello, >> What are the results of running make rcheck in mini/? That is the >> first >> thing that needs checking. If it fails in the same way before >> starting >> the tests it is likely related to something earlier on in the >> initialization. > > I was not aware of a make rcheck, I only knew the standard make > check, which fails with a similar error at the first compilation. If I copy over the .dll and .exe files from my ppc directory like Zoltan suggested I get the following: $ make rcheck echo '// DO NOT EDIT: This file has been generated from iltests.il.in' > iltests.il cpp -Darch=__ppc__ < ../../../../mono/mono/mini/iltests.il.in | sed 's/^#.*//' >> iltests.il MONO_PATH=../../../../mono/../mcs/class/lib/default ../../runtime/ mono-wrapper ../../../../mono/../mcs/class/lib/default/ilasm.exe - output=iltests.exe iltests.il Stacktrace: make: *** [iltests.exe] Abort trap If I copy over iltests.exe again I get: $ make rcheck MONO_PATH=../../../../mono/../mcs/class/lib/default ../../runtime/ mono-wrapper --regression basic.exe arrays.exe basic-float.exe basic- math.exe basic-long.exe objects.exe basic-calls.exe iltests.exe exceptions.exe bench.exe devirtualization.exe Stacktrace: make: *** [rcheck] Abort trap So nothing new... Andreas From mbd at dbc.dk Wed Jul 4 02:41:20 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Wed, 4 Jul 2007 08:41:20 +0200 Subject: [Mono-dev] Mono and NMock2 - failing to run NMock2 with mono svn In-Reply-To: <200706291622.39718.mbd@dbc.dk> References: <200706291622.39718.mbd@dbc.dk> Message-ID: <200707040841.20715.mbd@dbc.dk> fredag 29 juni 2007 16:22 skrev Mads Bondo Dydensborg: > Hi there Hi there - just a repost to raise this issue again. Any feedback will be most appreciated. Regards, Mads > > I have observed that my nmock2 tests have started to fail with the version of > mono I compile from svn. Running this command: > > $ echo $MONO_PATH > /home/madsdyd/xintegra/trunk/Components/Bin/:/home/madsdyd/xintegra/trunk/Lib/NUnit:/home/madsdyd/xintegra/trunk/Lib/NMock:/home/madsdyd/xintegra/trunk/Lib/NLog/Mono > $ which mono > /usr/local/mono-svn/bin/mono > $ mono --version > Mono JIT compiler version 1.2.4 (/trunk/ r81006) > Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com > TLS: __thread > GC: Included Boehm (with typed GC) > SIGSEGV: normal > Architecture: x86 > Disabled: none > $ > mono --debug /home/madsdyd/xintegra/trunk/Lib/NUnit/nunit-console.exe ../Bin/Debug/DBC.ORM.dll > > fails with: > > Failures: > 1) SQLBuilderTest.SelectOrAndSQL : System.InvalidCastException : Cannot cast > from source type to destination type. > at SQLBuilderTest.SetUp () [0x00035] > in /home/madsdyd/xintegra/trunk/Components/DBC.ORM/UnitTest/SQLBuilderTest.cs:90 > at <0x00000> > at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke > (object,object[]) > at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags > invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, > System.Globalization.CultureInfo culture) [0x00056] > in /home/compile/Compile/Mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:146 > > The offending statement is: > > mockProvider = mocks.NewMock(); > > AFAICT the assignment does not matter, the failure is somewhere in NewMock(?) > > However, running with stable mono: > > $ mono --version > Mono JIT compiler version 1.2.3.1, (C) 2002-2006 Novell, Inc and Contributors. > www.mono-project.com > TLS: __thread > GC: Included Boehm (with typed GC) > SIGSEGV: normal > Architecture: x86 > Disabled: none > > The test passes as expected - with no fails (neither from NUnit or Mono). In > both cases, the compilation of my source tree has been using the svn version > of mono/gmcs. > > So, two questions: > > a) Is anyone else experiencing this issue? > b) Any advise on resolving it? > > Thanks in advance, and regards, > > Mads > > -- > Med venlig hilsen/Regards > > Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg > Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 From sanxiyn at gmail.com Wed Jul 4 03:20:44 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 4 Jul 2007 16:20:44 +0900 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <468AD1E8.3010305@gmail.com> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> <468AD1E8.3010305@gmail.com> Message-ID: <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> 2007/7/4, "Andr?s G. Aragoneses [ knocte ]" : > I tracked down recently a bug[1] in Mono running NHib 1.2 > [1] http://bugzilla.ximian.com/show_bug.cgi?id=80225 From looking at the bug, it could be easily workaround on NHibernate side. So why not file a bug there? -- Seo Sanghyeon From knocte at gmail.com Wed Jul 4 03:39:48 2007 From: knocte at gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyBbIGtub2N0ZSBdIg==?=) Date: Wed, 04 Jul 2007 09:39:48 +0200 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> <468AD1E8.3010305@gmail.com> <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> Message-ID: <468B4EC4.5090308@gmail.com> Sanghyeon Seo escribi?: > 2007/7/4, "Andr?s G. Aragoneses [ knocte ]" : >> I tracked down recently a bug[1] in Mono running NHib 1.2 >> [1] http://bugzilla.ximian.com/show_bug.cgi?id=80225 > > From looking at the bug, it could be easily workaround on NHibernate > side. So why not file a bug there? You may do it but, as I said on the bug, "I don't think NHibernate developers would like to patch their work in order to work with Mono (perhaps yes as only a temporal workaround), or then we could get into a similar world as the web developers are in, where they have to take care of each browser that exists in the world." If we put a workaround in NHibernate, tomorrow we will have to patch another library. Regards, Andr?s [ knocte ] -- From atsushi at ximian.com Wed Jul 4 04:22:16 2007 From: atsushi at ximian.com (Atsushi Eno) Date: Wed, 04 Jul 2007 17:22:16 +0900 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <468B4EC4.5090308@gmail.com> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> <468AD1E8.3010305@gmail.com> <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> <468B4EC4.5090308@gmail.com> Message-ID: <468B58B8.50303@ximian.com> I totally agree with Sanghyeon. Why do we apply your broken patch, nor deny any improvements with internal changes from Microsoft (yes, of course your opinion logically denies it as well). I'm pretty sure that you haven't even asked NHibernate people about this. I think they'd rather choose to apply a tiny change in their code to have their code running under Mono 1.2.4. Why do you think they should lose their "market" in Mono land? Atsushi Eno Andr?s G. Aragoneses [ knocte ] wrote: > Sanghyeon Seo escribi?: >> 2007/7/4, "Andr?s G. Aragoneses [ knocte ]" : >>> I tracked down recently a bug[1] in Mono running NHib 1.2 >>> [1] http://bugzilla.ximian.com/show_bug.cgi?id=80225 >> From looking at the bug, it could be easily workaround on NHibernate >> side. So why not file a bug there? > > You may do it but, as I said on the bug, "I don't think NHibernate > developers would like to patch their work in order to work with Mono > (perhaps yes as only a temporal workaround), or then we could get into a > similar world as the web developers are in, where they have to take care > of each browser that exists in the world." > > If we put a workaround in NHibernate, tomorrow we will have to patch > another library. > > Regards, > > Andr?s [ knocte ] > From knocte at gmail.com Wed Jul 4 04:47:10 2007 From: knocte at gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyBbIGtub2N0ZSBdIg==?=) Date: Wed, 04 Jul 2007 10:47:10 +0200 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <468B58B8.50303@ximian.com> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> <468AD1E8.3010305@gmail.com> <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> <468B4EC4.5090308@gmail.com> <468B58B8.50303@ximian.com> Message-ID: <468B5E8E.50109@gmail.com> Atsushi Eno escribi?: > I totally agree with Sanghyeon. Why do we apply your broken patch, > nor deny any improvements with internal changes from Microsoft (yes, > of course your opinion logically denies it as well). No, please, that patch is not valid, don't consider it to be so. I'm sorry but the bugzilla at ximian.com hasn't got the feature of marking patches as obsolete. > I'm pretty sure that you haven't even asked NHibernate people > about this. I think they'd rather choose to apply a tiny change > in their code to have their code running under Mono 1.2.4. Why > do you think they should lose their "market" in Mono land? I haven't asked. I'm just saying that I'm not going to ask them because of my opinion. Do yourself if you want. But I guess this is not the only bug that's preventing NH to lose the Mono "market" ;) Regards, Andr?s [ knocte ] -- From atsushi at ximian.com Wed Jul 4 05:03:02 2007 From: atsushi at ximian.com (Atsushi Eno) Date: Wed, 04 Jul 2007 18:03:02 +0900 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <468B5E8E.50109@gmail.com> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> <468AD1E8.3010305@gmail.com> <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> <468B4EC4.5090308@gmail.com> <468B58B8.50303@ximian.com> <468B5E8E.50109@gmail.com> Message-ID: <468B6246.3030309@ximian.com> > I haven't asked. I'm just saying that I'm not going to ask them because > of my opinion. As I have already pointed out, your opinion is *broken*. You rather don't appreciate NHibernate enough to give any feedback to them. Atsushi Eno From skolima at gmail.com Wed Jul 4 05:33:49 2007 From: skolima at gmail.com (Leszek Ciesielski) Date: Wed, 4 Jul 2007 11:33:49 +0200 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <468B6246.3030309@ximian.com> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> <468AD1E8.3010305@gmail.com> <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> <468B4EC4.5090308@gmail.com> <468B58B8.50303@ximian.com> <468B5E8E.50109@gmail.com> <468B6246.3030309@ximian.com> Message-ID: <23a15590707040233g316a52e4j1424aec8c6cabbe0@mail.gmail.com> As per Spring.Net part - the answer is 'is is fixed in svn'. From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= Wed Jul 4 05:33:49 2007 From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=) Date: Wed, 04 Jul 2007 11:33:49 +0200 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <468B6246.3030309@ximian.com> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> <468AD1E8.3010305@gmail.com> <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> <468B4EC4.5090308@gmail.com> <468B58B8.50303@ximian.com> <468B5E8E.50109@gmail.com> <468B6246.3030309@ximian.com> Message-ID: <468B697D.9020202@gmail.com> Atsushi Eno escribi?: >> I haven't asked. I'm just saying that I'm not going to ask them because >> of my opinion. > > As I have already pointed out, your opinion is *broken*. You rather > don't appreciate NHibernate enough to give any feedback to them. Hahaha, that's funny. Opinions are broken :) Regards, Andr?s [ knocte ] -- From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= Wed Jul 4 05:40:29 2007 From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=) Date: Wed, 04 Jul 2007 11:40:29 +0200 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <468B6246.3030309@ximian.com> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> <468AD1E8.3010305@gmail.com> <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> <468B4EC4.5090308@gmail.com> <468B58B8.50303@ximian.com> <468B5E8E.50109@gmail.com> <468B6246.3030309@ximian.com> Message-ID: <468B6B0D.8010508@gmail.com> Atsushi Eno escribi?: >> I haven't asked. I'm just saying that I'm not going to ask them because >> of my opinion. > > As I have already pointed out, your opinion is *broken*. You rather > don't appreciate NHibernate enough to give any feedback to them. BTW, some more comments about this. I really appreciate NHibernate. However, I also appreciate web developers (I was one of them once-upon-a-time :D) and that's why I'm so affected by the idea of the hacks/workarounds. And BTW, NHib guys are too "VSified" guys, I advert to you, and consider Mono bugs to be "a dirty job to track". I just don't want to bug them, because I don't want to be bugged by them. Regards, Andr?s [ knocte ] -- From atsushi at ximian.com Wed Jul 4 07:49:28 2007 From: atsushi at ximian.com (Atsushi Eno) Date: Wed, 04 Jul 2007 20:49:28 +0900 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <468B6B0D.8010508@gmail.com> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> <468AD1E8.3010305@gmail.com> <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> <468B4EC4.5090308@gmail.com> <468B58B8.50303@ximian.com> <468B5E8E.50109@gmail.com> <468B6246.3030309@ximian.com> <468B6B0D.8010508@gmail.com> Message-ID: <468B8948.1060408@ximian.com> Not really. You just don't want to lose your face when those NHibernate guys say "ok, that's totally cosmetic thing we can change to support mono". I keep saying that because I would do the same when other people ask for cosmetic harmless changes to make my libraries work with .NET. Only moronic people reject such rational choice. Atsushi Eno Andr?s G. Aragoneses [ knocte ] wrote: > Atsushi Eno escribi?: >>> I haven't asked. I'm just saying that I'm not going to ask them because >>> of my opinion. >> As I have already pointed out, your opinion is *broken*. You rather >> don't appreciate NHibernate enough to give any feedback to them. > > BTW, some more comments about this. > > I really appreciate NHibernate. However, I also appreciate web > developers (I was one of them once-upon-a-time :D) and that's why I'm so > affected by the idea of the hacks/workarounds. And BTW, NHib guys are > too "VSified" guys, I advert to you, and consider Mono bugs to be "a > dirty job to track". I just don't want to bug them, because I don't want > to be bugged by them. > > Regards, > > Andr?s [ knocte ] > From mbd at dbc.dk Wed Jul 4 08:28:49 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Wed, 4 Jul 2007 14:28:49 +0200 Subject: [Mono-dev] Question about encodings - possible documentation bug? Message-ID: <200707041428.49133.mbd@dbc.dk> Hi there It is my understanding, that mono strings are always UTF16 internally. But, what encoding does the source files needs to be? The documentation (man gmcs) suggest this: "By default files will be processed in the Latin-1 code page." It happens to be, that I have some source files in Latin1. My locale is en_US.UTF-8. It appears that some characters gets to be ignored, when strings are constructed: string test = "foo ??? bar"; (Middle three characters are Danish chars, with binary rep e6 f8 e5 in Latin1, aka the encoding of the sourcefile. ) The string test will, on runtime, be printed (and I have checked this by traversing the string) as "foo bar". Now, using gmcs, with -codepage:28591 (Latin1) makes a string, that _does_ have the characters, sugggesting that the documentation are in error. So, isn't this a bug in the docs, and should (g)mcs not complain, if it finds chars not supported? Regards, Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= Wed Jul 4 09:13:05 2007 From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=) Date: Wed, 04 Jul 2007 15:13:05 +0200 Subject: [Mono-dev] Spring and NHibernate support In-Reply-To: <468B8948.1060408@ximian.com> References: <1183496579.6086.7.camel@Athos> <1183496781.11460.18.camel@mila.office.dinunzioedigregorio> <468AD1E8.3010305@gmail.com> <5b0248170707040020qc4c87f4q3659b8ac21a89870@mail.gmail.com> <468B4EC4.5090308@gmail.com> <468B58B8.50303@ximian.com> <468B5E8E.50109@gmail.com> <468B6246.3030309@ximian.com> <468B6B0D.8010508@gmail.com> <468B8948.1060408@ximian.com> Message-ID: <468B9CE1.4030603@gmail.com> Atsushi Eno escribi?: > Not really. You just don't want to lose your face when those > NHibernate guys say "ok, that's totally cosmetic thing we can > change to support mono". > > I keep saying that because I would do the same when other people > ask for cosmetic harmless changes to make my libraries work with > .NET. Only moronic people reject such rational choice. If NHibernate guys don't even want to test if it works on Mono, I do because I am interested. I think it's positive in an open source project to work on what you *want* to do. I don't want to bug them for writing workarounds for Mono, so if anyone is interested in that, just do it. BTW, this is the first workaround, but what will happen if after that we need 2 or 3 more?, this is also a matter of appearance: perhaps they are potential mono users in the future, and many people try a version of Mono and if it doesn't work for them, they don't try next time until years have passed, and on all that time they keep bashing about how bad Mono is; that's why I think it's better to fix Mono than to fix NHibernate (even if the fix in NHibernate or other project is so small). There are more moronic people than you think. Regards, Andr?s [ knocte ] -- From lupus at ximian.com Wed Jul 4 09:55:49 2007 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 4 Jul 2007 15:55:49 +0200 Subject: [Mono-dev] DeflateStream : bit length overflow In-Reply-To: <010001c7bd9a$58234c30$1b36a8c0@PROG159> References: <010001c7bd9a$58234c30$1b36a8c0@PROG159> Message-ID: <20070704135549.GA11258@debian.org> On 07/03/07 Jonathan Gagnon wrote: > The following messages are sent to the console when using the DeflateStream > class in Mono : > > bit length overflow > code 4 bits 6->7 > > The compression is working correctly, so it seems like some kind of debug > trace. > > I did a grep on the sources to see where it comes from, and I found this > line inside the mono/support/trees.c file : > > Trace((stderr,"\nbit length overflow\n")); > > Is this something that shouldn't have been checked in? What version of mono are you using? What is the output of: ldd /path/to/libMonoPosixHelper.so That message is some debug output that should happen only if you compile with the DEBUG #define enabled, which we don't. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From jonathan.gagnon at croesus.com Wed Jul 4 10:44:43 2007 From: jonathan.gagnon at croesus.com (Jonathan Gagnon) Date: Wed, 4 Jul 2007 10:44:43 -0400 Subject: [Mono-dev] DeflateStream : bit length overflow In-Reply-To: <20070704135549.GA11258@debian.org> References: <010001c7bd9a$58234c30$1b36a8c0@PROG159> <20070704135549.GA11258@debian.org> Message-ID: <011b01c7be49$df474b30$1b36a8c0@PROG159> I'm using mono 1.2.3.1. I installed the followin rpms : mono-data-1.2.3.1-0.novell mono-core-1.2.3.1-0.novell The output of 'ldd /usr/lib/libMonoPosixHelper.so' is : linux-gate.so.1 => (0xffffe000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x55587000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x5558b000) libdl.so.2 => /lib/libdl.so.2 (0x55606000) libpthread.so.0 => /lib/tls/i686/libpthread.so.0 (0x5560a000) libm.so.6 => /lib/tls/i686/libm.so.6 (0x5561b000) libc.so.6 => /lib/tls/i686/libc.so.6 (0x5563e000) /lib/ld-linux.so.2 (0x56555000) Thanks, Jonathan -----Message d'origine----- De : mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] De la part de Paolo Molaro Envoy? : Wednesday, July 04, 2007 9:56 AM ? : mono-devel-list at lists.ximian.com Objet : Re: [Mono-dev] DeflateStream : bit length overflow On 07/03/07 Jonathan Gagnon wrote: > The following messages are sent to the console when using the > DeflateStream class in Mono : > > bit length overflow > code 4 bits 6->7 > > The compression is working correctly, so it seems like some kind of > debug trace. > > I did a grep on the sources to see where it comes from, and I found > this line inside the mono/support/trees.c file : > > Trace((stderr,"\nbit length overflow\n")); > > Is this something that shouldn't have been checked in? What version of mono are you using? What is the output of: ldd /path/to/libMonoPosixHelper.so That message is some debug output that should happen only if you compile with the DEBUG #define enabled, which we don't. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From mbd at dbc.dk Wed Jul 4 10:45:47 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Wed, 4 Jul 2007 16:45:47 +0200 Subject: [Mono-dev] Possible multiple errors/bugs in Odbc stack, regarding handling of strings with non-ascii characters Message-ID: <200707041645.48048.mbd@dbc.dk> Hi there I believe I have spotted an issue with the mono Odbc stack, regarding the handling of strings with characters, that give rise to multibyte representations in utf8. What I have seen, when talking to an Odbc database, is that strings passed to the database, loose their tail, when they contain e.g. the danish letter ?, which has the multibyte representation 'c3 a6' in utf8. An example: the following request is send to the odbc stack: "UPDATE PublishingJob SET Name = 'foo' WHERE JobId = 2.000000" This appears in the odbctrace identical to this string. However, when changing foo to fo?, the string appears as: "UPDATE PublishingJob SET Name = 'fo' WHERE JobId = 2.00000" "fo?" appears as "fo" - I believe this is due to a limitation in the log mechanism, as the value is correctly set in the database. Note, however, the change from "2.000000" to "2.00000". This is no problem in this query, but this query: "UPDATE PublishingJob SET Name = '????????' WHERE JobId = 2.000000" is traced to this: "UPDATE PublishingJob SET Name = '' WHERE JobId = " and, the odbc driver/database wont accept that as valid sql... I believe the issue is with OdbcCommand.cs, the method ExecSQL, and quite possibly, other places: libodbc.cs: [DllImport("odbc32.dll")] internal static extern OdbcReturn SQLExecDirect (IntPtr StatementHandle, string StatementText, int TextLength); OdbcCommand.cs: private void ExecSQL(string sql) { OdbcReturn ret; ... ret=libodbc.SQLExecDirect(hstmt, sql, sql.Length); The issue here is, that the sql string is formatted by System.Runtime.Interop, eventually into a char*, possibly containing multiby representations of the chars of sql. However, the sql.Length call, returns the number of Chars of sql, which must be a lower bound on the length of the char* that sql eventually is transformed into. FYI: