From listaccount at e-tobi.net Wed Oct 1 03:17:37 2008 From: listaccount at e-tobi.net (Tobi) Date: Wed, 01 Oct 2008 09:17:37 +0200 Subject: [Mono-dev] ERROR:(mini-exceptions.c:760):get_exception_catch_class In-Reply-To: <295e750a0809301841o4d81a036u224c21983596fda8@mail.gmail.com> References: <48E2C27C.8090706@e-tobi.net> <295e750a0809301841o4d81a036u224c21983596fda8@mail.gmail.com> Message-ID: <48E32411.7030502@e-tobi.net> Zoltan Varga wrote: > Try to create a test case and attach it to a bug report. I would have done this, but it's not so easy to find the code causing this error, because the stack trace is pretty useless. Just thought, someone has a hint for me. Seems I just need to try harder to find the problem. Tobias From franz.struwig at gmail.com Wed Oct 1 07:15:09 2008 From: franz.struwig at gmail.com (znarF) Date: Wed, 1 Oct 2008 04:15:09 -0700 (PDT) Subject: [Mono-dev] System.Data.SQLite changes that may interest Mono users In-Reply-To: <00b701c8f80c$ba7fe8e0$2f7fbaa0$@com> References: <00b701c8f80c$ba7fe8e0$2f7fbaa0$@com> Message-ID: <1222859709442-1131170.post@n2.nabble.com> Hi Robert, I'm trying to use the managed libraries of the updated version of System.Data.Sqlite in FreeBSD with mono. I've updated my ports tree - using SQLite version 3.5.6. When running my sqlite tests, I get the following exception when trying to access the database: System.Data.SQLite.UnsafeNativeMethods:sqlite3_next_stmt at System.Data.SQLite.SQLiteBase.ResetConnection at ...CloseConnection at ...ReleaseHandle at ...Dispose at ...Sqlite3.Close at ...SqliteConnection.Close at ...SqliteConnection.Open Doing an nm on the shared object library shows that this symbol (sqlite3_next_stmt) is missing. Is the updated version only workable with SQLite 3.6.1? Thanks Robert Simpson wrote: > > I just posted version 1.0.55.0 of the System.Data.SQLite provider here: > > http://sqlite.phxsoftware.com > > > > Included in this update is an option to recompile the managed provider > portion of the code with a SQLITE_STANDARD preprocessor symbol defined. > If > set, the provider will compile as managed only and p/invoke against the > stock "sqlite3" library with about 99% functionality of my modified > version. > > > > I also added the URI connection string from Marek's mono modifications. I > *think* that at this point all you'd have to do is rename the namespace > and > re-case the class names to get my provider sync'd up to the > Mono.Data.Sqlite > provider. > > > > If anyone's interested in working on that and giving me feedback, I'd be > happy to make any other changes needed in my version to help keep the mono > edition as easy to maintain for you guys as possible. > > > > One major caveat: Dr. Hipp only just this version (3.6.1) added > precompiled > binary support for several metadata API functions. The Mono.Data.Sqlite > provider was p/invoking these functions already, but the default binary > from > sqlite.org did not export them. They included > sqlite3_table_column_metadata(), sqlite3_column_orig(), and several other > metadata-related functions. > > > > As such, the only version of System.Data.SQLite (and in fact any version > of > the Mono.Data.Sqlite provider) that will pass a complete round of unit > tests > is when backed to SQLite 3.6.1. > > > > Robert > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- View this message in context: http://n2.nabble.com/System.Data.SQLite-changes-that-may-interest-Mono-users-tp677121p1131170.html Sent from the Mono - Dev mailing list archive at Nabble.com. From franz.struwig at gmail.com Wed Oct 1 07:37:50 2008 From: franz.struwig at gmail.com (znarF) Date: Wed, 1 Oct 2008 04:37:50 -0700 (PDT) Subject: [Mono-dev] System.Data.SQLite changes that may interest Mono users In-Reply-To: <1222859709442-1131170.post@n2.nabble.com> References: <00b701c8f80c$ba7fe8e0$2f7fbaa0$@com> <1222859709442-1131170.post@n2.nabble.com> Message-ID: <1222861070133-1131210.post@n2.nabble.com> Disregard my previous post - I misread the sqlite version. Now using Sqlite 3.6.3, and getting less errors. Seems to be an issue with the fill command, and the sqlite3_column_origin_name symbol is missing. Mmm, maybe you weren't kidding when you said 3.6.1 is the only working one at this point... I'll give it a shot. znarF wrote: > > Hi Robert, > I'm trying to use the managed libraries of the updated version of > System.Data.Sqlite in FreeBSD with mono. > > I've updated my ports tree - using SQLite version 3.5.6. When running my > sqlite tests, I get the following exception when trying to access the > database: > System.Data.SQLite.UnsafeNativeMethods:sqlite3_next_stmt at > System.Data.SQLite.SQLiteBase.ResetConnection at > ...CloseConnection at > ...ReleaseHandle at > ...Dispose at > ...Sqlite3.Close at > ...SqliteConnection.Close at > ...SqliteConnection.Open > > Doing an nm on the shared object library shows that this symbol > (sqlite3_next_stmt) is missing. > > Is the updated version only workable with SQLite 3.6.1? > Thanks > > > Robert Simpson wrote: >> >> I just posted version 1.0.55.0 of the System.Data.SQLite provider here: >> >> http://sqlite.phxsoftware.com >> >> >> >> Included in this update is an option to recompile the managed provider >> portion of the code with a SQLITE_STANDARD preprocessor symbol defined. >> If >> set, the provider will compile as managed only and p/invoke against the >> stock "sqlite3" library with about 99% functionality of my modified >> version. >> >> >> >> I also added the URI connection string from Marek's mono modifications. >> I >> *think* that at this point all you'd have to do is rename the namespace >> and >> re-case the class names to get my provider sync'd up to the >> Mono.Data.Sqlite >> provider. >> >> >> >> If anyone's interested in working on that and giving me feedback, I'd be >> happy to make any other changes needed in my version to help keep the >> mono >> edition as easy to maintain for you guys as possible. >> >> >> >> One major caveat: Dr. Hipp only just this version (3.6.1) added >> precompiled >> binary support for several metadata API functions. The Mono.Data.Sqlite >> provider was p/invoking these functions already, but the default binary >> from >> sqlite.org did not export them. They included >> sqlite3_table_column_metadata(), sqlite3_column_orig(), and several other >> metadata-related functions. >> >> >> >> As such, the only version of System.Data.SQLite (and in fact any version >> of >> the Mono.Data.Sqlite provider) that will pass a complete round of unit >> tests >> is when backed to SQLite 3.6.1. >> >> >> >> Robert >> >> >> >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> > > -- View this message in context: http://n2.nabble.com/System.Data.SQLite-changes-that-may-interest-Mono-users-tp677121p1131210.html Sent from the Mono - Dev mailing list archive at Nabble.com. From franz.struwig at gmail.com Wed Oct 1 08:37:12 2008 From: franz.struwig at gmail.com (znarF) Date: Wed, 1 Oct 2008 05:37:12 -0700 (PDT) Subject: [Mono-dev] System.Data.SQLite changes that may interest Mono users In-Reply-To: <1222861070133-1131210.post@n2.nabble.com> References: <00b701c8f80c$ba7fe8e0$2f7fbaa0$@com> <1222859709442-1131170.post@n2.nabble.com> <1222861070133-1131210.post@n2.nabble.com> Message-ID: <1222864632111-1131303.post@n2.nabble.com> This link http://www.sqlite.org/c3ref/column_database_name.html helped me a bit. You need to have the SQLITE_ENABLE_COLUMN_METADATA preprocessor directive defined when building SQLite. Case closed. znarF wrote: > > Disregard my previous post - I misread the sqlite version. > > Now using Sqlite 3.6.3, and getting less errors. Seems to be an issue > with the fill command, and the sqlite3_column_origin_name symbol is > missing. > > Mmm, maybe you weren't kidding when you said 3.6.1 is the only working one > at this point... > > I'll give it a shot. > > > > znarF wrote: >> >> Hi Robert, >> I'm trying to use the managed libraries of the updated version of >> System.Data.Sqlite in FreeBSD with mono. >> >> I've updated my ports tree - using SQLite version 3.5.6. When running my >> sqlite tests, I get the following exception when trying to access the >> database: >> System.Data.SQLite.UnsafeNativeMethods:sqlite3_next_stmt at >> System.Data.SQLite.SQLiteBase.ResetConnection at >> ...CloseConnection at >> ...ReleaseHandle at >> ...Dispose at >> ...Sqlite3.Close at >> ...SqliteConnection.Close at >> ...SqliteConnection.Open >> >> Doing an nm on the shared object library shows that this symbol >> (sqlite3_next_stmt) is missing. >> >> Is the updated version only workable with SQLite 3.6.1? >> Thanks >> >> >> Robert Simpson wrote: >>> >>> I just posted version 1.0.55.0 of the System.Data.SQLite provider here: >>> >>> http://sqlite.phxsoftware.com >>> >>> >>> >>> Included in this update is an option to recompile the managed provider >>> portion of the code with a SQLITE_STANDARD preprocessor symbol defined. >>> If >>> set, the provider will compile as managed only and p/invoke against the >>> stock "sqlite3" library with about 99% functionality of my modified >>> version. >>> >>> >>> >>> I also added the URI connection string from Marek's mono modifications. >>> I >>> *think* that at this point all you'd have to do is rename the namespace >>> and >>> re-case the class names to get my provider sync'd up to the >>> Mono.Data.Sqlite >>> provider. >>> >>> >>> >>> If anyone's interested in working on that and giving me feedback, I'd be >>> happy to make any other changes needed in my version to help keep the >>> mono >>> edition as easy to maintain for you guys as possible. >>> >>> >>> >>> One major caveat: Dr. Hipp only just this version (3.6.1) added >>> precompiled >>> binary support for several metadata API functions. The Mono.Data.Sqlite >>> provider was p/invoking these functions already, but the default binary >>> from >>> sqlite.org did not export them. They included >>> sqlite3_table_column_metadata(), sqlite3_column_orig(), and several >>> other >>> metadata-related functions. >>> >>> >>> >>> As such, the only version of System.Data.SQLite (and in fact any version >>> of >>> the Mono.Data.Sqlite provider) that will pass a complete round of unit >>> tests >>> is when backed to SQLite 3.6.1. >>> >>> >>> >>> Robert >>> >>> >>> >>> >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >>> >> >> > > -- View this message in context: http://n2.nabble.com/System.Data.SQLite-changes-that-may-interest-Mono-users-tp677121p1131303.html Sent from the Mono - Dev mailing list archive at Nabble.com. From sqlite_list at bcsft.com Wed Oct 1 10:39:37 2008 From: sqlite_list at bcsft.com (Robert Simpson) Date: Wed, 1 Oct 2008 07:39:37 -0700 Subject: [Mono-dev] System.Data.SQLite changes that may interest Mono users In-Reply-To: <1222864632111-1131303.post@n2.nabble.com> References: <00b701c8f80c$ba7fe8e0$2f7fbaa0$@com> <1222859709442-1131170.post@n2.nabble.com> <1222861070133-1131210.post@n2.nabble.com> <1222864632111-1131303.post@n2.nabble.com> Message-ID: <000601c923d3$87c7a710$9756f530$@com> Glad to hear it :) -----Original Message----- From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of znarF Sent: Wednesday, October 01, 2008 5:37 AM To: mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] System.Data.SQLite changes that may interest Mono users This link http://www.sqlite.org/c3ref/column_database_name.html helped me a bit. You need to have the SQLITE_ENABLE_COLUMN_METADATA preprocessor directive defined when building SQLite. Case closed. From mark.probst at gmail.com Wed Oct 1 11:04:58 2008 From: mark.probst at gmail.com (Mark Probst) Date: Wed, 01 Oct 2008 17:04:58 +0200 Subject: [Mono-dev] Patch: Fast virtual generic method calls In-Reply-To: <1222365063.455.24.camel@newton> References: <1222365063.455.24.camel@newton> Message-ID: <1222873498.10317.13.camel@newton> Hello again, Here's the patch again, updated with code to keep track of how many times a generic virtual method is invoked and to insert it in the thunk only if a threshold (currently 100) is reached. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: fast_virtual_generic_calls_new.diff Type: text/x-patch Size: 37575 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081001/e96b817c/attachment-0001.bin From lupus at ximian.com Wed Oct 1 11:07:30 2008 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 1 Oct 2008 17:07:30 +0200 Subject: [Mono-dev] What is the state of mono interpreter ? In-Reply-To: <48E120F0.9020606@mansionfamily.plus.com> References: <8cca42d80809261740y53a502b0h284822182d10143@mail.gmail.com> <8cca42d80809270632r4dd5e3c5k6f18a3b312b5f47@mail.gmail.com> <8cca42d80809291050u4538661fp74b94a05fd5db237@mail.gmail.com> <48E120F0.9020606@mansionfamily.plus.com> Message-ID: <20081001150730.GA27246@debian.org> On 09/29/08 James Mansion wrote: > Rodrigo Kumpera wrote: > > These are shortcomings of the current AOT implementation of mono > > that are easier to fix than implement a fast interpreter. > Who said anything about fast? The mono interpreter already operated on a different internal representation, not on IL code directly, so it's not jit-fast, but still not as slow as Rodrigo would imply with his message. The main issue is that a few people showed interest in bringing the intepreter back to life, saying it was important to them, but they never dedicated 1 man hour to the task (or if they did, they didn't share the code). So, if those people that claim an interpreter is importnat didn't dedicate 1 man hour, why should we? (Note I'm not pointing figers to anyone here, several people wanted an interpreter but were unwilling to spend anything on it, money, man hours or anything else except email postings:). lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From kumpera at gmail.com Wed Oct 1 11:47:46 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Wed, 1 Oct 2008 12:47:46 -0300 Subject: [Mono-dev] What is the state of mono interpreter ? In-Reply-To: <20081001150730.GA27246@debian.org> References: <8cca42d80809261740y53a502b0h284822182d10143@mail.gmail.com> <8cca42d80809270632r4dd5e3c5k6f18a3b312b5f47@mail.gmail.com> <8cca42d80809291050u4538661fp74b94a05fd5db237@mail.gmail.com> <48E120F0.9020606@mansionfamily.plus.com> <20081001150730.GA27246@debian.org> Message-ID: <8cca42d80810010847k16222326nd18acbf2a565b5c7@mail.gmail.com> On Wed, Oct 1, 2008 at 12:07 PM, Paolo Molaro wrote: > On 09/29/08 James Mansion wrote: > > Rodrigo Kumpera wrote: > > > These are shortcomings of the current AOT implementation of mono > > > that are easier to fix than implement a fast interpreter. > > Who said anything about fast? > > The mono interpreter already operated on a different internal > representation, not on IL code directly, so it's not jit-fast, > but still not as slow as Rodrigo would imply with his message. > > The main issue is that a few people showed interest in bringing the > intepreter back to life, saying it was important to them, but they never > dedicated 1 man hour to the task (or if they did, they didn't share the > code). > > So, if those people that claim an interpreter is importnat didn't dedicate > 1 man hour, why should we? (Note I'm not pointing figers to anyone here, > several people wanted an interpreter but were unwilling to spend > anything on it, money, man hours or anything else except email > postings:). > > Paolo has a good point, the mono team has other priorities, but if someone is willing to take up on bringing the interpreter back, just say so and we will sure give help and review the code. And if the idea is to have a small footprint interpreter, then ruling out CLR 2.0 would be advisable, as generics impose a significant footprint in terms of binary and runtime size. Cheers, Rodrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081001/a09ef624/attachment.html From miguel at novell.com Wed Oct 1 14:04:44 2008 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 01 Oct 2008 14:04:44 -0400 Subject: [Mono-dev] What is the state of mono interpreter ? In-Reply-To: <48E120F0.9020606@mansionfamily.plus.com> References: <8cca42d80809261740y53a502b0h284822182d10143@mail.gmail.com> <8cca42d80809270632r4dd5e3c5k6f18a3b312b5f47@mail.gmail.com> <8cca42d80809291050u4538661fp74b94a05fd5db237@mail.gmail.com> <48E120F0.9020606@mansionfamily.plus.com> Message-ID: <1222884284.4390.80.camel@erandi.site> Hello, > I would value an interpreter not as a replacement for JIT in a full mono > stack, but as a way to create a very small footprint runner for CLR > code, with a really cut-down runtime. This would be competing more > with a Lua usecase than anything else. The memory consumed by the JIT is fairly small, the actual overhead of running Mono applications comes from the class library stack. An interpreter would save only a minor amount of memory, and most likely would consume as much or more than the JIT. Here is why: Interpreters for CIL code are not every efficient due to the fact that CIL instructions do not have type annotations, so the type annotations have to be fetched from the stack, which further slows down execution. Additionally token lookups (for fields, methods, types) are very expensive. So an effective interpreter ends up compiling from CIL code into a different bytecode, one that has most of these expensive operations "resolved", so you end up keeping this information around, very much like you would end up keeping the code around. Miguel. From lupus at ximian.com Wed Oct 1 14:12:04 2008 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 1 Oct 2008 20:12:04 +0200 Subject: [Mono-dev] Patch: Fast virtual generic method calls In-Reply-To: <1222873498.10317.13.camel@newton> References: <1222365063.455.24.camel@newton> <1222873498.10317.13.camel@newton> Message-ID: <20081001181204.GB27246@debian.org> On 10/01/08 Mark Probst wrote: > Here's the patch again, updated with code to keep track of how many > times a generic virtual method is invoked and to insert it in the thunk > only if a threshold (currently 100) is reached. 100 seems high, especially since the lookup can be a O(n) list walk. Maybe 10 is more appropriate. > Index: metadata/object.c > =================================================================== > --- metadata/object.c (revision 114206) > +++ metadata/object.c (working copy) > +static void > +init_thunk_free_lists (MonoDomain *domain) > +{ > + if (domain->thunk_free_lists) > + return; > + domain->thunk_free_lists = mono_mempool_alloc0 (domain->mp, sizeof (gpointer) * NUM_FREE_LISTS); mono_domain_alloc0 () should be used, so that all the domain allocations are properly tracked. > +/* > + * LOCKING: The domain lock must be held. > + */ > +static void > +invalidate_generic_virtual_thunk (MonoDomain *domain, gpointer code) > +{ > + guint32 *p = code; > + MonoThunkFreeList *l = (MonoThunkFreeList*)(p - 1); > + > + init_thunk_free_lists (domain); > + > + while (domain->thunk_free_lists [0] && domain->thunk_free_lists [0]->length >= MAX_WAIT_LENGTH) { > + MonoThunkFreeList *item = domain->thunk_free_lists [0]; > + int length = item->length; > + int i; > + > + /* unlink the first item from the wait list */ > + domain->thunk_free_lists [0] = item->next; > + domain->thunk_free_lists [0]->length = length - 1; > + > + i = list_index_for_size (item->size); > + > + g_print ("putting thunk of size %d in list %d\n", item->size, i); Leftover. > +/** > + * mono_method_add_generic_virtual_case: Maybe invocation is better than case? Any other suggestion? > +void > +mono_method_add_generic_virtual_case (MonoDomain *domain, gpointer *vtable_slot, > + MonoGenericInst *method_inst, gpointer code) > +{ > + static gboolean inited = FALSE; > + static int num_added = 0; > + > + GenericVirtualCase *gvc, *list; > + MonoImtBuilderEntry *entries; > + int i; > + GPtrArray *sorted; > + > + mono_domain_lock (domain); > + if (!domain->generic_virtual_cases) > + domain->generic_virtual_cases = g_hash_table_new (mono_aligned_addr_hash, NULL); > + > + /* Check whether the case was already added */ > + gvc = g_hash_table_lookup (domain->generic_virtual_cases, vtable_slot); > + while (gvc) { > + if (gvc->inst == method_inst) > + break; > + gvc = gvc->next; > + } This is the O(n) loop I mentioned. It shouldn't be a big deal, though. > + > + /* If not found, make a new one */ > + if (!gvc) { > + gvc = mono_mempool_alloc (domain->mp, sizeof (GenericVirtualCase)); mono_domain_alloc () here. > Index: metadata/domain-internals.h > =================================================================== > --- metadata/domain-internals.h (revision 114206) > +++ metadata/domain-internals.h (working copy) > @@ -141,6 +141,12 @@ > MONO_APPDOMAIN_UNLOADED > } MonoAppDomainState; > > +typedef struct _MonoThunkFreeList { > + guint32 size; > + struct _MonoThunkFreeList *next; > + int length; /* only valid for the wait list */ Put the pointer first, so sie and length fit inside the other 8 bytes on 64 bit systems and the total size will be 16 instead of 24. > --- mini/tramp-x86.c (revision 114206) > +++ mini/tramp-x86.c (working copy) > @@ -94,7 +94,7 @@ > } else { > printf ("Invalid trampoline sequence: %x %x %x %x %x %x %x\n", code [0], code [1], code [2], code [3], > code [4], code [5], code [6]); > - g_assert_not_reached (); > + //g_assert_not_reached (); Leftover. The rest of the code looks fine to me. It would be nice to also see some speedup numbers from this change:) Thanks! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From eddyk832005 at gmail.com Wed Oct 1 14:47:52 2008 From: eddyk832005 at gmail.com (Karel Tamayo) Date: Wed, 1 Oct 2008 14:47:52 -0400 Subject: [Mono-dev] Question about AjaxToolkit and System.Web.Extensions on Mono Message-ID: <7c7272260810011147o19fc170eh663430d529bea4a2@mail.gmail.com> Hi everybody: I'd be glad if anyone could help me here. I'm running a web application on mono. I did port it from asp.net using moma and although I was using VS 2008 I was targeting .net framework 2.0 to be OK with compatibility issues. I got the System.Web.Extensions.dll for the mono framework and copied in Bin folder of my application. The application runs perfectly but the Ajax stuff are not working at all. I mean, I can load the page in which I have 2 linked dropdowns with states and municipalities data but, the update panel in which both are contained doesn't work. My page is making a full postback to the server every time I change the selected item of the states dropdown. I checked the error console and then I sow that the initialization script is setting this error message: *Error: ASP.NET Ajax client-side framework failed to load.* Where do I have to copy the toolkit, the extensions? What am I missing??? Any help will be much appreciated. Thanks in advance, Karel. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081001/39bae37c/attachment.html From emperon at gmail.com Wed Oct 1 16:22:34 2008 From: emperon at gmail.com (Onur Gumus) Date: Wed, 1 Oct 2008 23:22:34 +0300 Subject: [Mono-dev] Question about AjaxToolkit and System.Web.Extensions on Mono In-Reply-To: <7c7272260810011147o19fc170eh663430d529bea4a2@mail.gmail.com> References: <7c7272260810011147o19fc170eh663430d529bea4a2@mail.gmail.com> Message-ID: <8a7a2d050810011322g22141f20s3264e788b2c9b10b@mail.gmail.com> I remember even last year Ajax and Ajax Control Toolkit was working flawlessly on mono and linux. Thanks to Marek. The thing is you cannot use .NET System.Web.Extension (and it would be illegal to do so). Mono has own assembly with the same name. Try that. I ensure you it was working even 1 year ago. So you should be missing something Good luck 2008/10/1 Karel Tamayo : > Hi everybody: > > I'd be glad if anyone could help me here. > > I'm running a web application on mono. I did port it from asp.net using > moma and although I was using VS 2008 I was targeting .net framework 2.0 to > be OK with compatibility issues. > > I got the System.Web.Extensions.dll for the mono framework and copied in > Bin folder of my application. > > The application runs perfectly but the Ajax stuff are not working at all. > I mean, I can load the page in which I have 2 linked dropdowns with states > and municipalities data but, the update panel in which both are contained > doesn't work. My page is making a full postback to the server every time I > change the selected item of the states dropdown. > > I checked the error console and then I sow that the initialization script > is setting this error message: > Error: ASP.NET Ajax client-side framework failed to load. > > Where do I have to copy the toolkit, the extensions? What am I missing??? > > Any help will be much appreciated. > > Thanks in advance, > Karel. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From listaccount at e-tobi.net Wed Oct 1 21:14:13 2008 From: listaccount at e-tobi.net (Tobi) Date: Thu, 02 Oct 2008 03:14:13 +0200 Subject: [Mono-dev] ERROR:(mini-exceptions.c:760):get_exception_catch_class In-Reply-To: <295e750a0809301841o4d81a036u224c21983596fda8@mail.gmail.com> References: <48E2C27C.8090706@e-tobi.net> <295e750a0809301841o4d81a036u224c21983596fda8@mail.gmail.com> Message-ID: <48E42065.6010901@e-tobi.net> Zoltan Varga wrote: > Try to create a test case and attach it to a bug report. Sorry, but I wasn't able to create a small enough test case for a bug report. The code that produces this error is just too complex and for some reason, I can reproduce the problem only with NUnit. An exe calling exactly the same code from the library, works without a problem. It's definitely a runtime problem. The exact same binaries work fine on MS.NET. I'll publish the source soon, if you want to try it yourself. Because I couldn't create a descent test case, I tried to track the problem down in the SVN history. The commit that introduces the problem was r114108 (just a one-liner). The current SVN trunk (r114643) works fine, If I just reverse this single commit with: svn merge -c -114108 . Without reverting this commit, the assert from mini-exceptions.c:770 is triggered: g_assert (!class->generic_container && class == method_container_class); I checked the assert condition and figured out, that class->generic_container is false and class != method_container_class resulting in g_assert(1 && 0). Hope this helps. Tobias From vargaz at gmail.com Wed Oct 1 21:23:01 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Thu, 2 Oct 2008 03:23:01 +0200 Subject: [Mono-dev] ERROR:(mini-exceptions.c:760):get_exception_catch_class In-Reply-To: <48E42065.6010901@e-tobi.net> References: <48E2C27C.8090706@e-tobi.net> <295e750a0809301841o4d81a036u224c21983596fda8@mail.gmail.com> <48E42065.6010901@e-tobi.net> Message-ID: <295e750a0810011823k2c3b1ff0j270d37508d8057d6@mail.gmail.com> Hi, As a workaround you can run mono with MONO_GENERIC_SHARING=corlib. Zoltan On Thu, Oct 2, 2008 at 3:14 AM, Tobi wrote: > Zoltan Varga wrote: > >> Try to create a test case and attach it to a bug report. > > Sorry, but I wasn't able to create a small enough test case for a bug > report. The code that produces this error is just too complex and for some > reason, I can reproduce the problem only with NUnit. An exe calling > exactly the same code from the library, works without a problem. > > It's definitely a runtime problem. The exact same binaries work fine on > MS.NET. > > I'll publish the source soon, if you want to try it yourself. > > Because I couldn't create a descent test case, I tried to track the > problem down in the SVN history. The commit that introduces the problem > was r114108 (just a one-liner). > > The current SVN trunk (r114643) works fine, If I just reverse this single > commit with: > > svn merge -c -114108 . > > Without reverting this commit, the assert from mini-exceptions.c:770 is > triggered: > > g_assert (!class->generic_container && class == method_container_class); > > I checked the assert condition and figured out, that > class->generic_container is false and class != method_container_class > resulting in g_assert(1 && 0). > > Hope this helps. > > Tobias > > From dean at brettle.com Thu Oct 2 01:36:39 2008 From: dean at brettle.com (Dean Brettle) Date: Wed, 1 Oct 2008 22:36:39 -0700 Subject: [Mono-dev] Strong-named assembly built with Linux Mono not working with Windows VB Web Application In-Reply-To: <01c401c922d5$6b8e8310$42ab8930$@com> References: <01c401c922d5$6b8e8310$42ab8930$@com> Message-ID: On Tue, Sep 30, 2008 at 1:20 AM, Rolf Bjarne Kvinge wrote: > This seems to be a MS bug (their VB compiler refuses to accept an > assembly their own tools say is valid, and only under certain > circumstances), > I'm not so sure. See below... > in any case here is a couple of ideas how to debug: > > 1. You say the C# assembly is built and signed using Mono, but > happens if you build with Mono and sign with MS (and vice versa)? > I get the same error. > 2. Use ildasm (MS tool) to dump both C# assemblies to disk and > compare the files. You'll probably get a lot of noise here though. > To cut down on the noise, I replicated the problem with an assembly that just contains an absolutely minimal custom web control. I then compared monodis output on versions built with both Mono and with .NET. With no options, the output is essentially the same (modulo ordering). However, when using monodis --assembly, I noticed the following difference: [mono20] ~/tmp/mywebcontrol @ monodis --assembly MyWebControlProject.Mono.dll | grep Flags Flags: 0x00000000 [mono20] ~/tmp/mywebcontrol @ monodis --assembly MyWebControlProject.Net.dll | grep Flags Flags: 0x00000001 Since this is a strong-named assembly containing the public key, isn't 0x00000001 the correct value for Flags? If MS's VB.NET compiler requires that flag to be set for strong-named assemblies, then that would explain the problem. I'd like to test that hypothesis by changing the Flags value, but I don't know how to do that off-hand. Using .NET's sn.exe to resign the assembly built with Mono, didn't change the Flags value. > 3. Try to compile the VB Web Site Project from the command line > and/or using codedom to see if you can replicate the issue. > At this point, I'm using a minimal VB Web Application project and web control and the problem is very reproducible, so I don't think going to the command line and/or codedom is likely to be worth the effort. > 4. File a bug with MS (good luck with this one J) > Seems more likely to be a Mono bug at the moment... That's good news to me, since that greatly increases the odds of it getting fixed. :-) Anyway, can someone point me to the code that creates/writes the assembly table, so I can try making the necessary change and seeing if it solves the problem? Thanks, --Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081001/db87e2ea/attachment.html From vladhociota at yahoo.com Thu Oct 2 01:44:11 2008 From: vladhociota at yahoo.com (Vlad Hociota) Date: Wed, 1 Oct 2008 22:44:11 -0700 (PDT) Subject: [Mono-dev] [PATCH] Add async operations to UnixListener Message-ID: <959608.68594.qm@web50102.mail.re2.yahoo.com> Hello everybody, This patch adds to UnixListener async operations similar to those found on TcpListener : BeginAcceptSocket, BeginAcceptUnixClient, EndAcceptSocket, EndAcceptUnixClient The code is pretty basic, nothin' fancy about it. Best, Vlad -------------- next part -------------- A non-text attachment was scrubbed... Name: UnixListener_new.diff Type: text/x-patch Size: 1125 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081001/f11fde4f/attachment.bin From dean at brettle.com Thu Oct 2 02:09:23 2008 From: dean at brettle.com (Dean Brettle) Date: Wed, 1 Oct 2008 23:09:23 -0700 Subject: [Mono-dev] Strong-named assembly built with Linux Mono not working with Windows VB Web Application In-Reply-To: References: <01c401c922d5$6b8e8310$42ab8930$@com> Message-ID: On Wed, Oct 1, 2008 at 10:36 PM, Dean Brettle wrote: > I noticed the following difference: > > [mono20] ~/tmp/mywebcontrol @ monodis --assembly > MyWebControlProject.Mono.dll | grep Flags > Flags: 0x00000000 > [mono20] ~/tmp/mywebcontrol @ monodis --assembly > MyWebControlProject.Net.dll | grep Flags > Flags: 0x00000001 > > Since this is a strong-named assembly containing the public key, isn't > 0x00000001 the correct value for Flags? If MS's VB.NET compiler requires > that flag to be set for strong-named assemblies, then that would explain the > problem. > > I'd like to test that hypothesis by changing the Flags value, but I don't > know how to do that off-hand. Using .NET's sn.exe to resign the assembly > built with Mono, didn't change the Flags value. > Adding the following to AssemblyInfo.cs did change Flags to 0x00000001, and DID allow the custom control to be used in a VB.NET Web Application project. [assembly: AssemblyFlags(AssemblyNameFlags.PublicKey)] So, is the fact that this is necessary a bug in mcs, MonoDevelop, or something else? --Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081001/c0ce64ca/attachment.html From grendel at twistedcode.net Thu Oct 2 02:23:53 2008 From: grendel at twistedcode.net (Marek Habersack) Date: Thu, 2 Oct 2008 08:23:53 +0200 Subject: [Mono-dev] Question about AjaxToolkit and System.Web.Extensions on Mono In-Reply-To: <7c7272260810011147o19fc170eh663430d529bea4a2@mail.gmail.com> References: <7c7272260810011147o19fc170eh663430d529bea4a2@mail.gmail.com> Message-ID: <20081002082353.0d2cb0d5@twistedcode.net> On Wed, 1 Oct 2008 14:47:52 -0400 "Karel Tamayo" wrote: > Hi everybody: > > I'd be glad if anyone could help me here. > > I'm running a web application on mono. I did port it from asp.net using > moma and although I was using VS 2008 I was targeting .net framework 2.0 to > be OK with compatibility issues. > > I got the System.Web.Extensions.dll for the mono framework and copied in > Bin folder of my application. > > The application runs perfectly but the Ajax stuff are not working at all. > I mean, I can load the page in which I have 2 linked dropdowns with states > and municipalities data but, the update panel in which both are contained > doesn't work. My page is making a full postback to the server every time I > change the selected item of the states dropdown. > > I checked the error console and then I sow that the initialization script > is setting this error message: > *Error: ASP.NET Ajax client-side framework failed to load.* > > Where do I have to copy the toolkit, the extensions? What am I missing??? You don't need the Microsoft System.Web.Extensions.dll, Mono ships its own version. All you need to do is to is to provide appropriate Web.config options. To add them to your existing config or create a new Web.config, issue this command (assuming you're running Mono 1.9 or later): mconfig af -t:web AJAX As for the Ajax Control Toolkit - download their demos, but make sure you're downloading the version for .NET 2.0, the 3.5 version might still give problems. Run xsp2 in the toolkit demos toplevel dir and everything should work as expected. regards, marek From mark.probst at gmail.com Thu Oct 2 06:31:25 2008 From: mark.probst at gmail.com (Mark Probst) Date: Thu, 2 Oct 2008 12:31:25 +0200 Subject: [Mono-dev] Patch: Fast virtual generic method calls In-Reply-To: <20081001181204.GB27246@debian.org> References: <1222365063.455.24.camel@newton> <1222873498.10317.13.camel@newton> <20081001181204.GB27246@debian.org> Message-ID: On Wed, Oct 1, 2008 at 8:12 PM, Paolo Molaro wrote: > It would be nice to also see some speedup numbers from this change:) Running the same benchmark (attached again) that I did on my first, memory-eating implementation of fast virtual generic method calls I get these numbers: no calls: 16.82306 non-generic calls: 21.41356 generic calls: 29.7909 non-generic call cost: 4.5905 generic call cost: 12.96784 Compared to our previous, slow implementation (note that these numbers are different from the ones I posted back when I wrote about my first implementation, which I tested on the old JIT, whereas these are with Linear IL): no calls: 16.63622 non-generic calls: 21.50949 generic calls: 1067.2657 non-generic call cost: 4.87327 generic call cost: 1050.62948 Compared to Microsoft's: no calls: 18.90625 non-generic calls: 31.40625 generic calls: 52.96875 non-generic call cost: 12.5 generic call cost: 34.0625 As for performance differences with the threshold change I can only offer a very contrived benchmark (also attached). What it does is call the same virtual generic method with a huge number of different type arguments. Calling each different instantiation once, without the threshold change the program takes 45 seconds, whereas with the threshold change it only takes 1.2 seconds (because no thunks are created). However, by changing the number of calls to each invocation I can get different performance. If I call each different instantiation 10 times (which is the threshold number) then without the threshold change it still takes only 45 seconds, whereas with the threshold change it now also takes 45 seconds. Pretty much what's to be expected. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: vgmbench.cs Type: application/octet-stream Size: 2899 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081002/79f4166a/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: vgm2.cs Type: application/octet-stream Size: 709 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081002/79f4166a/attachment-0003.obj From mpfj at mimc.co.uk Thu Oct 2 06:42:59 2008 From: mpfj at mimc.co.uk (Mark Jackson) Date: Thu, 02 Oct 2008 11:42:59 +0100 Subject: [Mono-dev] Mono.zeroconf timeouts or refresh / rescan ? Message-ID: <48E4A5B3.8080602@mimc.co.uk> I'm using mono.zeroconf under XP + bonjour. My simple application lists particular devices as and when they appear on our network. These devices are Linux boxes running avahi, and when they are powered up / down correctly my application adds / removes the devices from a list. However, if the power is simply removed from one of the devices (i.e. avahi does *not* shut itself down nicely on the device), that device's services remain visible. I can detect this by pinging the devices and removing them from the list if I get a ping timeout / etc. But is there a nice "zeroconf" way to detect that a device has disappeared ? Can I ask zeroconf to rescan / rebrowse the network ? Or is ping / timeout the only method available ? Thanks Mark From eddyk832005 at gmail.com Thu Oct 2 10:03:21 2008 From: eddyk832005 at gmail.com (Karel Tamayo) Date: Thu, 2 Oct 2008 09:33:21 -0430 Subject: [Mono-dev] [Solved] Question about AjaxToolkit and System.Web.Extensions on Mono In-Reply-To: <20081002082353.0d2cb0d5@twistedcode.net> References: <7c7272260810011147o19fc170eh663430d529bea4a2@mail.gmail.com> <20081002082353.0d2cb0d5@twistedcode.net> Message-ID: <7c7272260810020703q3d10387bje742791875a0f2d6@mail.gmail.com> Thanks to Onur Gumus and Marek for the fast reply and support. The problem I was facing was not so hard. I'm posting my experience to the list just in case that some novice on mono, like me, is having the same issue. The problem is that I was using a System.Web.Extensions.dll version that I had when I downloaded mojoPortal some time ago. So, the website was working and no exceptions were thrown but the script resources were not loading properly to the browser. That's why the Firefox Error Console was showing the exception message generated by the toolkit: The Asp.NET Ajax Client Side Framework could not be load! So thanks again everybody for the tips. :-) Best regards and good luck, Karel. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081002/d427fe7a/attachment.html From pablosantosluac at terra.es Thu Oct 2 11:43:51 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Thu, 02 Oct 2008 17:43:51 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work Message-ID: <48E4EC37.2000906@terra.es> Hi there, I've been bothering Zoltan, Geoff and Mark all they trying to get my Solaris x86 to build latest mono correctly. But I'm stopped now and maybe someone can help. First mistake I had is I was using packages from sunfreeware instead of blastwave. Getting rid of the first ones (gcc, automake, autogen, libtool, glib, glib2) and using the ones from blastwave seems to be much better. Well, I've configured, run make, and I get to the point where I need monolite. I did make get-monolite-latest and run make again. Here's my problem now: Making all in runtime gmake[2]: Entering directory `/home/pablo/mono/trunk/mono/runtime' if test -w ../../mcs; then :; else chmod -R +w ../../mcs; fi cd ../../mcs && gmake NO_DIR_CHECK=1 PROFILES='default net_2_0 net_3_5net_2_1' CC='gcc' all-profiles gmake[3]: Entering directory `/home/pablo/mono/trunk/mcs' gmake profile-do--default--all profile-do--net_2_0--all profile-do--net_3_5--all profile-do--net_2_1--all gmake[4]: Entering directory `/home/pablo/mono/trunk/mcs' gmake PROFILE=basic all gmake[5]: Entering directory `/home/pablo/mono/trunk/mcs' usage: mcs [-cdpVz] [-a string] [-n name] file ... gmake[6]: *** [build/deps/basic-profile-check.exe] Error 1 gmake[6]: Entering directory `/home/pablo/mono/trunk/mcs' *** The compiler 'mcs' doesn't appear to be usable. *** Trying the 'monolite' directory. gmake[7]: Entering directory `/home/pablo/mono/trunk/mcs' GC Warning: Large stack limit(133464064): only scanning 8 MB gmake[8]: *** [build/deps/basic-profile-check.exe] Error 1 gmake[8]: Entering directory `/home/pablo/mono/trunk/mcs' *** The contents of your 'monolite' directory may be out-of-date *** You may want to try 'make get-monolite-latest' gmake[8]: *** [do-profile-check-monolite] Error 1 gmake[8]: Leaving directory `/home/pablo/mono/trunk/mcs' gmake[7]: *** [do-profile-check] Error 2 gmake[7]: Leaving directory `/home/pablo/mono/trunk/mcs' gmake[6]: *** [do-profile-check-monolite] Error 2 gmake[6]: Leaving directory `/home/pablo/mono/trunk/mcs' gmake[5]: *** [do-profile-check] Error 2 gmake[5]: Leaving directory `/home/pablo/mono/trunk/mcs' gmake[4]: *** [profile-do--basic--all] Error 2 gmake[4]: Leaving directory `/home/pablo/mono/trunk/mcs' gmake[3]: *** [profiles-do--all] Error 2 gmake[3]: Leaving directory `/home/pablo/mono/trunk/mcs' gmake[2]: *** [all-local] Error 2 gmake[2]: Leaving directory `/home/pablo/mono/trunk/mono/runtime' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/pablo/mono/trunk/mono' *** Error code 2 make: Fatal error: Command failed for target `all' As Geoff pointed out: it appears the runtime is crashing according to: GC Warning: Large stack limit(133464064): only scanning 8 MB gmake[8]: *** [build/deps/basic-profile-check.exe] Error 1 He asked to run the .exe independently with gdb to find out what the problem is... But I can't find this basic-profile-check.exe anywhere... I guess I'm doing something prettry wrong, but any help would be appreciated. Regards, pablo From twiest at novell.com Thu Oct 2 15:47:07 2008 From: twiest at novell.com (Thomas Wiest) Date: Thu, 02 Oct 2008 13:47:07 -0600 Subject: [Mono-dev] Mono 2.0 RC4 is out!! Message-ID: <48E5253B.5040901@novell.com> Hey Everyone, We've just released Mono 2.0 RC4 today! Please help us out by giving it a try with your applications. We are hopeful that this will be the gold master for Mono 2.0. At this point, we'll only be fixing critical / blocker bugs. Unfortunately, the Mac installer is still delayed, so the one included here is from RC1. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them! http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.0 here: https://bugzilla.novell.com/buglist.cgi?bug_file_loc_type=allwordssubstr&bug_file_loc=http%3A%2F%2Fwww.go-mono.com%2Farchive%2F2.0%2F&order=bugs.bug_status%20 The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you tag the summary of the bug with [Regression], then it is much more likely your bug will get fixed. Please help the Mono team to make 2.0 the best ever. Thanks again! Mono QA From andreas.faerber at web.de Thu Oct 2 16:22:59 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Thu, 2 Oct 2008 22:22:59 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <48E4EC37.2000906@terra.es> References: <48E4EC37.2000906@terra.es> Message-ID: <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> Hi Pablo, Am 02.10.2008 um 17:43 schrieb pablosantosluac at terra.es: > First mistake I had is I was using packages from sunfreeware instead > of > blastwave. Getting rid of the first ones (gcc, automake, autogen, > libtool, glib, glib2) and using the ones from blastwave seems to be > much > better. I'd recommend the ones from Solaris' Companion CD, they worked fine. Blastwave pulls in its own 'parallel' tree of dependencies. > Making all in runtime > gmake[2]: Entering directory `/home/pablo/mono/trunk/mono/runtime' > if test -w ../../mcs; then :; else chmod -R +w ../../mcs; fi > cd ../../mcs && gmake NO_DIR_CHECK=1 PROFILES='default net_2_0 > net_3_5net_2_1' CC='gcc' all-profiles > gmake[3]: Entering directory `/home/pablo/mono/trunk/mcs' > gmake profile-do--default--all profile-do--net_2_0--all > profile-do--net_3_5--all profile-do--net_2_1--all > gmake[4]: Entering directory `/home/pablo/mono/trunk/mcs' > gmake PROFILE=basic all > gmake[5]: Entering directory `/home/pablo/mono/trunk/mcs' > usage: mcs [-cdpVz] [-a string] [-n name] file ... This probably means you still have Sun's mcs tool in the PATH. > gmake[6]: *** [build/deps/basic-profile-check.exe] Error 1 > gmake[6]: Entering directory `/home/pablo/mono/trunk/mcs' > *** The compiler 'mcs' doesn't appear to be usable. > *** Trying the 'monolite' directory. > gmake[7]: Entering directory `/home/pablo/mono/trunk/mcs' > GC Warning: Large stack limit(133464064): only scanning 8 MB Don't use Mono's libgc. Use a recent Boehm GC. Cf. http://www.mono-project.com/Mono:Solaris And make sure sigaltstack is disabled, it will crash, too. > gmake[8]: *** [build/deps/basic-profile-check.exe] Error 1 > gmake[8]: Entering directory `/home/pablo/mono/trunk/mcs' > *** The contents of your 'monolite' directory may be out-of-date > *** You may want to try 'make get-monolite-latest' > gmake[8]: *** [do-profile-check-monolite] Error 1 > gmake[8]: Leaving directory `/home/pablo/mono/trunk/mcs' > gmake[7]: *** [do-profile-check] Error 2 > gmake[7]: Leaving directory `/home/pablo/mono/trunk/mcs' > gmake[6]: *** [do-profile-check-monolite] Error 2 > gmake[6]: Leaving directory `/home/pablo/mono/trunk/mcs' > gmake[5]: *** [do-profile-check] Error 2 > gmake[5]: Leaving directory `/home/pablo/mono/trunk/mcs' > gmake[4]: *** [profile-do--basic--all] Error 2 > gmake[4]: Leaving directory `/home/pablo/mono/trunk/mcs' > gmake[3]: *** [profiles-do--all] Error 2 > gmake[3]: Leaving directory `/home/pablo/mono/trunk/mcs' > gmake[2]: *** [all-local] Error 2 > gmake[2]: Leaving directory `/home/pablo/mono/trunk/mono/runtime' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/home/pablo/mono/trunk/mono' > *** Error code 2 > make: Fatal error: Command failed for target `all' > I can't find this basic-profile-check.exe anywhere... mcs is trying to build it and failing! ;-) Regards, Andreas From vargaz at gmail.com Thu Oct 2 17:02:11 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Thu, 2 Oct 2008 23:02:11 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> Message-ID: <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> Hi, > > Don't use Mono's libgc. Use a recent Boehm GC. Cf. http://www.mono-project.com/Mono:Solaris > No need for that, the bundled gc will work fine. The stack size warning is probably harmless. Zoltan From pablosantosluac at terra.es Thu Oct 2 18:10:19 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Fri, 03 Oct 2008 00:10:19 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> Message-ID: <48E546CB.5080300@terra.es> Ok, I'm using the included one but, any clue why I can't get the monolite to work? If I can't figure it out I'll try to continue compiling using a pre-installed (and old) mono, but I'd really like to figure out what's going on... Thanks pablo Zoltan Varga escribi?: > Hi, > >> Don't use Mono's libgc. Use a recent Boehm GC. Cf. http://www.mono-project.com/Mono:Solaris >> >> > > No need for that, the bundled gc will work fine. The stack size > warning is probably harmless. > > Zoltan > > From paul at all-the-johnsons.co.uk Thu Oct 2 20:33:33 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 03 Oct 2008 01:33:33 +0100 Subject: [Mono-dev] PPC64 - is it any closer Message-ID: <1222994013.6325.8.camel@PB3.Linux> Hi, Just a quick question. Is there a "true" PPC64 version of Mono and not just a PPC32 running on PPC64? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081003/362a4006/attachment-0001.bin From ajorgensen at novell.com Thu Oct 2 22:14:25 2008 From: ajorgensen at novell.com (Andrew Jorgensen) Date: Thu, 02 Oct 2008 20:14:25 -0600 Subject: [Mono-dev] PPC64 - is it any closer Message-ID: <48E52BA1020000400003FAC6@lucius.provo.novell.com> It's in the works. The mono team and some of the SuSE folks are working on it. I cannot promise anything regarding how long it will take. It's not trivial. >>> Paul 10/02/08 6:40 PM >>> Hi, Just a quick question. Is there a "true" PPC64 version of Mono and not just a PPC32 running on PPC64? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! From andreas.faerber at web.de Fri Oct 3 06:33:10 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Fri, 3 Oct 2008 12:33:10 +0200 Subject: [Mono-dev] Mono support on Fedora, Ubuntu, Solaris, etc. In-Reply-To: <48CFB7DD020000400003D6D9@lucius.provo.novell.com> References: <48CFB7DD020000400003D6D9@lucius.provo.novell.com> Message-ID: <0ADEDC16-EE02-423D-AA03-617A55FD8507@web.de> Am 16.09.2008 um 21:42 schrieb Andrew Jorgensen: > What I'm trying to do for solaris is start maintaining the packages on > Blastwave.org. They have a build infrastructure and lots of packagers > to help us with packaging and build difficulties. Go to > http://wiki.blastwave.org/ and click on the "Join Us" link. Mention > in > the "Additional Notes" that you want to help maintain the mono > packages. > > If you had something else in mind let me know, but I think that > hosting > it on blastwave will give it the best exposure inside the solaris > community. I believe the best exposure would be by getting into one of the Indiana-style software repositories for OpenSolaris, and last time I checked Blastwave didn't have one. There was one on pkg.sunfreeware.com though. For Blastwave's pkg-get you need to know what you are searching for, whereas the new ipkg system comes with a graphical tool to browse and search available packages. But having more recent packages for Blastwave users would be beneficial as well, of course. Jonel as past maintainer didn't react to mails via blastwave some time ago. Andreas From andreas.faerber at web.de Fri Oct 3 07:42:13 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Fri, 3 Oct 2008 13:42:13 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> Message-ID: Hi, Am 02.10.2008 um 23:02 schrieb Zoltan Varga: >> >> Don't use Mono's libgc. Use a recent Boehm GC. Cf. http://www.mono-project.com/Mono:Solaris >> > > No need for that, the bundled gc will work fine. The stack size > warning is probably harmless. The bundled one did not work on Solaris/amd64 recently, and I was told it would not be fixed in Mono's libgc. It may work on Solaris/x86, apart from the warning. The stack size warning by itself would be harmless - however, many scripts check for stdout/stderr output and fail when that warning is emitted before the expected text. So it needs to be suppressed, either by patching Mono's libgc or by using an upstream Boehm GC. I believe I encountered issues when trying to compile MonoDevelop and its dependencies, for instance. Andreas From bassraf at gmail.com Fri Oct 3 08:19:00 2008 From: bassraf at gmail.com (BaSS) Date: Fri, 03 Oct 2008 14:19:00 +0200 Subject: [Mono-dev] VB.NET under Mono 2.0-RX In-Reply-To: Message-ID: <4f81b99c.1c92552.16cacb75.29@gmail.com> Can anyone tell me if even the most simple VB.NET application is running ie: MessageBox.Show() under Mono 2.0-RX ? I'm using this from the embedding API, it was working under 1.9.1, but now it only gives me "0: Error ID: VBNC_CRASH,''" Regards, Bas From andreas.faerber at web.de Fri Oct 3 08:44:03 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Fri, 3 Oct 2008 14:44:03 +0200 Subject: [Mono-dev] PPC64 - is it any closer In-Reply-To: <48E52BA1020000400003FAC6@lucius.provo.novell.com> References: <48E52BA1020000400003FAC6@lucius.provo.novell.com> Message-ID: <250D8FA2-912D-4FC5-B34A-AAAA774B9577@web.de> Hi Paul et al., I have been offline for some weeks. Some smaller patches were posted before that time, but there has still been no review yet to my knowledge. This includes my long-standing enhancements to ppc(64) code generation [2], some signedness changes for OSX, some guint32 -> gulong changes (e.g., [1]), and Olaf posted a ppc64-related patch to use GCC 4.1's new built-in atomic ops when available [3]. There is a ticket tracking ppc64 progress: https://bugzilla.novell.com/show_bug.cgi?id=324134 I have multiple Git branches on repo.or.cz: http://repo.or.cz/w/mono/afaerber.git - ppc64-cleanup includes cosmetic changes that help with our changes and their review - ppc64-functional includes functional ppc changes in addition to the cosmetic ones - ppc64 tracks the "final" work-in-progress (Two patches from Olaf's branch I still need to apply there.) - ppc64-todo sometimes has changes on top of ppc64, to keep TODOs out of the patches Getting rebased all the time, I admit they are not comfortable to read log-wise but the patches posted in Bugzilla can be extracted by `git diff master2..ppc64-cleanup`, `git diff ppc64-cleanup..ppc64- functional` etc. Regarding the time frame, I've worked on the port since Q2 2007 as time permits, and the big obvious hurdles have been taken; now it's mostly rebasing against breaking changes in trunk and about debugging. Any help and ideas where the crashes/hangs/whatever-it's-currently may stem from are highly appreciated. If we could get an okay to apply some of our smaller non-intrusive changes (below) to trunk, it would greatly help our porting effort and Geoff, Paolo or whomever with the review of the "real" JIT changes. Regards, Andreas [1] http://lists.ximian.com/pipermail/mono-devel-list/2008-August/028757.html [2] http://lists.ximian.com/pipermail/mono-devel-list/2008-January/026484.html (slightly updated in Git, but pending since 2007) [3] http://lists.ximian.com/pipermail/mono-devel-list/2008-August/028755.html (non-libgc part) [4] http://lists.ximian.com/pipermail/mono-devel-list/2008-August/028760.html (generic) Am 03.10.2008 um 04:14 schrieb Andrew Jorgensen: > It's in the works. The mono team and some of the SuSE folks are > working > on it. I cannot promise anything regarding how long it will take. > It's > not trivial. > >>>> Paul 10/02/08 6:40 PM >>> > Hi, > > Just a quick question. Is there a "true" PPC64 version of Mono and not > just a PPC32 running on PPC64? > > TTFN > > Paul > -- > Sie k?nnen mich aufreizen und wirklich hei? machen! > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From paul at all-the-johnsons.co.uk Fri Oct 3 09:10:58 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 03 Oct 2008 14:10:58 +0100 Subject: [Mono-dev] VB.NET under Mono 2.0-RX In-Reply-To: <4f81b99c.1c92552.16cacb75.29@gmail.com> References: <4f81b99c.1c92552.16cacb75.29@gmail.com> Message-ID: <1223039458.6325.24.camel@PB3.Linux> Hi, > Can anyone tell me if even the most simple VB.NET application is running ie: MessageBox.Show() under Mono 2.0-RX ? > I'm using this from the embedding API, it was working under 1.9.1, but now it only gives me "0: Error ID: VBNC_CRASH,''" Can you give us a small example of the code you're trying to compile please? It would make bug chasing much simpler. Also, which platform (and distro) are you using? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081003/f3c4c458/attachment.bin From andreas.faerber at web.de Fri Oct 3 09:23:35 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Fri, 3 Oct 2008 15:23:35 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <48E546CB.5080300@terra.es> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> Message-ID: Pablo, Am 03.10.2008 um 00:10 schrieb pablosantosluac at terra.es: > Ok, I'm using the included one but, any clue why I can't get the > monolite to work? I did post some suggestions already that you haven't reported back on... * Use --with-sigaltstack=no - it tried to use it on my boxes and crashed at runtime * Try without libgc - if you don't want to try vanilla Boehm GC, use -- with-gc=none (it's the only way to rule out the GC as source of errors) * Rename Sun's `mcs` executable (Modular... whatever) or remove it from $PATH so that it's not detected in the first place You can use monolite, I did so myself on Solarises. You can't get it to work however because in your configuration the Mono runtime crashes while trying to execute mcs.exe from monolite to compile basic-profile- check.exe. Copying over assemblies from elsewhere or compiling new assemblies with an old runtime will not fix your new runtime. Trust me, you do need to recompile the runtime with some set of options that makes it work. If you don't want to play with those options, then please don't complain. ;) Andreas From lupus at ximian.com Fri Oct 3 09:54:06 2008 From: lupus at ximian.com (Paolo Molaro) Date: Fri, 3 Oct 2008 15:54:06 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <48E546CB.5080300@terra.es> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> Message-ID: <20081003135406.GE27246@debian.org> On 10/03/08 pablosantosluac at terra.es wrote: > Ok, I'm using the included one but, any clue why I can't get the > monolite to work? monolite should simply not be used, it's an expert option that is not fool proof and is not guaranteed to work, there are too many issues with it that are not even worth solving. Always start from a released mono tarball as the build instructions say.. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From rolflists at ya.com Fri Oct 3 10:49:09 2008 From: rolflists at ya.com (Rolf Bjarne Kvinge) Date: Fri, 3 Oct 2008 16:49:09 +0200 Subject: [Mono-dev] VB.NET under Mono 2.0-RX In-Reply-To: <4f81b99c.1c92552.16cacb75.29@gmail.com> References: <4f81b99c.1c92552.16cacb75.29@gmail.com> Message-ID: <02c401c92567$337366f0$9a5a34d0$@com> Hi, > Can anyone tell me if even the most simple VB.NET application is > running ie: MessageBox.Show() under Mono 2.0-RX ? > I'm using this from the embedding API, it was working under 1.9.1, but > now it only gives me "0: Error ID: VBNC_CRASH,''" This is a compiler crash, but I'd need a reproducible test case to find the error. Rolf > > Regards, > Bas > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From rolflists at ya.com Fri Oct 3 10:51:32 2008 From: rolflists at ya.com (Rolf Bjarne Kvinge) Date: Fri, 3 Oct 2008 16:51:32 +0200 Subject: [Mono-dev] Strong-named assembly built with Linux Mono not working with Windows VB Web Application In-Reply-To: References: <01c401c922d5$6b8e8310$42ab8930$@com> Message-ID: <02c501c92567$88824df0$9986e9d0$@com> Hi, Please file a bug report at bugzilla.novell.com, my guess would be that it's a bug in mcs (but I've been wrong before J) Rolf From: dean.brettle at gmail.com [mailto:dean.brettle at gmail.com] On Behalf Of Dean Brettle Sent: jueves, 02 de octubre de 2008 8:09 To: Rolf Bjarne Kvinge Cc: mono-devel-list Subject: Re: [Mono-dev] Strong-named assembly built with Linux Mono not working with Windows VB Web Application On Wed, Oct 1, 2008 at 10:36 PM, Dean Brettle wrote: I noticed the following difference: [mono20] ~/tmp/mywebcontrol @ monodis --assembly MyWebControlProject.Mono.dll | grep Flags Flags: 0x00000000 [mono20] ~/tmp/mywebcontrol @ monodis --assembly MyWebControlProject.Net.dll | grep Flags Flags: 0x00000001 Since this is a strong-named assembly containing the public key, isn't 0x00000001 the correct value for Flags? If MS's VB.NET compiler requires that flag to be set for strong-named assemblies, then that would explain the problem. I'd like to test that hypothesis by changing the Flags value, but I don't know how to do that off-hand. Using .NET's sn.exe to resign the assembly built with Mono, didn't change the Flags value. Adding the following to AssemblyInfo.cs did change Flags to 0x00000001, and DID allow the custom control to be used in a VB.NET Web Application project. [assembly: AssemblyFlags(AssemblyNameFlags.PublicKey)] So, is the fact that this is necessary a bug in mcs, MonoDevelop, or something else? --Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081003/0ea11352/attachment.html From james.bird at realtimeworlds.com Fri Oct 3 13:36:12 2008 From: james.bird at realtimeworlds.com (james.bird at realtimeworlds.com) Date: Fri, 3 Oct 2008 18:36:12 +0100 Subject: [Mono-dev] Cross-compiling 32-bit mono on AMD64 machine on Linux Message-ID: Before I begin, I must say that I am quite a novice when it comes to Linux, so I could quite possibly have made a trivial mistake somewhere. My machine is running the 64-bit version of Ubuntu (installed using Wubi). However, I would like to run the latest release candidate of Mono 2.0 under 32-bit as the programs that I am running are not compatible with 64-bit Mono. I have obtained the sources and managed to compile 64-bit without any problems by just running the following commands: ./configure make make install When I run "mono -V", it says that I am running on amd64 architecture. So I assume the way I would run my programs under 32-bit is by cross compiling for x86. To do this, I first try running the 'configure' command with the following syntax: ./configure --host=i386-pc-linux --build=x86_64-pc-linux However, this fails to complete successfully, and produces the following output (I've attached the 'config.log'): Checking for preceeding underscore in symbols... configure: error: cannot run test program while cross compiling I also tried running the following command: ./configure --target=i386-pc-linux This was successful, and I managed to compile and install. However, when I run mono it still says I am running under amd64. Any help would be greatly appreciated, Thanks, James Bird. ____________________________________________________________________ DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081003/a523e30a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.zip Type: application/x-zip-compressed Size: 14638 bytes Desc: config.zip Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081003/a523e30a/attachment-0001.bin From cetin.sert at gmail.com Fri Oct 3 17:01:10 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Fri, 3 Oct 2008 23:01:10 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <20081003135406.GE27246@debian.org> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> <20081003135406.GE27246@debian.org> Message-ID: <1ff5dedc0810031401y4b9a2723pa5f7d71257935e0c@mail.gmail.com> I'm also trying to build mono on opensolaris 10 x86-64 and got this message: when I run ./configure --with-gc=boehm checking gc.h usability... no checking gc.h presence... no checking for gc.h... no checking gc/gc.h usability... no checking gc/gc.h presence... no checking for gc/gc.h... no checking for GC_malloc in -lgc... no configure: error: "GC requested but libgc not found! Install libgc or run configure with --with-gc=none." I had built and installed the latest boehm gc I could find. I think it was version 7.sth. Anyone knows what to do now? And if I configure mono using --with--gc=none how can I add a gc later? o_O?? Best Regards, Cetin Sert 2008/10/3 Paolo Molaro > On 10/03/08 pablosantosluac at terra.es wrote: > > Ok, I'm using the included one but, any clue why I can't get the > > monolite to work? > > monolite should simply not be used, it's an expert option > that is not fool proof and is not guaranteed to work, > there are too many issues with it that are not even worth solving. > Always start from a released mono tarball as the build instructions say.. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081003/7cd0e2b6/attachment.html From pablosantosluac at terra.es Fri Oct 3 18:54:50 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sat, 04 Oct 2008 00:54:50 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> Message-ID: <48E6A2BA.7060602@terra.es> Hi Andreas, Sorry, I didn't see your suggestions before!! Don't know what has happened! I will try them and come back to you! Thanks, pablo Andreas F?rber escribi?: > Pablo, > > Am 03.10.2008 um 00:10 schrieb pablosantosluac at terra.es: > >> Ok, I'm using the included one but, any clue why I can't get the >> monolite to work? > > I did post some suggestions already that you haven't reported back on... > > * Use --with-sigaltstack=no - it tried to use it on my boxes and > crashed at runtime > * Try without libgc - if you don't want to try vanilla Boehm GC, use > --with-gc=none (it's the only way to rule out the GC as source of errors) > * Rename Sun's `mcs` executable (Modular... whatever) or remove it > from $PATH so that it's not detected in the first place > > You can use monolite, I did so myself on Solarises. You can't get it > to work however because in your configuration the Mono runtime crashes > while trying to execute mcs.exe from monolite to compile > basic-profile-check.exe. Copying over assemblies from elsewhere or > compiling new assemblies with an old runtime will not fix your new > runtime. Trust me, you do need to recompile the runtime with some set > of options that makes it work. If you don't want to play with those > options, then please don't complain. ;) > > Andreas > > From pablosantosluac at terra.es Fri Oct 3 18:57:01 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sat, 04 Oct 2008 00:57:01 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <1ff5dedc0810031401y4b9a2723pa5f7d71257935e0c@mail.gmail.com> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> <20081003135406.GE27246@debian.org> <1ff5dedc0810031401y4b9a2723pa5f7d71257935e0c@mail.gmail.com> Message-ID: <48E6A33D.7060405@terra.es> I will try with --with-gc=boehm and check what it says... Cetin Sert escribi?: > I'm also trying to build mono on opensolaris 10 x86-64 and got this > message: > > when I run ./configure --with-gc=boehm > checking gc.h usability... no > checking gc.h presence... no > checking for gc.h... no > > checking gc/gc.h usability... no > checking gc/gc.h presence... no > checking for gc/gc.h... no > checking for GC_malloc in -lgc... no > configure: error: "GC requested but libgc not found! Install libgc or run > > configure with --with-gc=none." > I had built and installed the latest boehm gc I could find. I think it > was version 7.sth. > > Anyone knows what to do now? And if I configure mono using > --with--gc=none how can I add a gc later? o_O?? > > Best Regards, > Cetin Sert > > 2008/10/3 Paolo Molaro > > > On 10/03/08 pablosantosluac at terra.es > wrote: > > Ok, I'm using the included one but, any clue why I can't get the > > monolite to work? > > monolite should simply not be used, it's an expert option > that is not fool proof and is not guaranteed to work, > there are too many issues with it that are not even worth solving. > Always start from a released mono tarball as the build > instructions say.. > > 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 pablosantosluac at terra.es Fri Oct 3 18:58:54 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sat, 04 Oct 2008 00:58:54 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <20081003135406.GE27246@debian.org> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> <20081003135406.GE27246@debian.org> Message-ID: <48E6A3AE.3070004@terra.es> Ok, got it! but... is there a way to learn how to use it? I mean, I'd like to try to build mono on a HP-UX box next (I already have one just for this purpose), so I think it would be great to gain some understanding on the whole process to avoid bothering you in the future... pablo Paolo Molaro escribi?: > On 10/03/08 pablosantosluac at terra.es wrote: > >> Ok, I'm using the included one but, any clue why I can't get the >> monolite to work? >> > > monolite should simply not be used, it's an expert option > that is not fool proof and is not guaranteed to work, > there are too many issues with it that are not even worth solving. > Always start from a released mono tarball as the build instructions say.. > > lupus > > From pablosantosluac at terra.es Fri Oct 3 19:44:45 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sat, 04 Oct 2008 01:44:45 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> Message-ID: <48E6AE6D.2020704@terra.es> Hi Andreas, Got rid of the included "mcs" command. Then I was able to get a little bit further... (the first option --with-sigaltstack=no was not yet tried) Now the "Makefile" inside mcs seems to have a problem or something: make: Fatal error in reader: Makefile, line 2: Unexpected end of line seen Andreas F?rber escribi?: > Pablo, > > Am 03.10.2008 um 00:10 schrieb pablosantosluac at terra.es: > >> Ok, I'm using the included one but, any clue why I can't get the >> monolite to work? > > I did post some suggestions already that you haven't reported back on... > > * Use --with-sigaltstack=no - it tried to use it on my boxes and > crashed at runtime > * Try without libgc - if you don't want to try vanilla Boehm GC, use > --with-gc=none (it's the only way to rule out the GC as source of errors) > * Rename Sun's `mcs` executable (Modular... whatever) or remove it > from $PATH so that it's not detected in the first place > > You can use monolite, I did so myself on Solarises. You can't get it > to work however because in your configuration the Mono runtime crashes > while trying to execute mcs.exe from monolite to compile > basic-profile-check.exe. Copying over assemblies from elsewhere or > compiling new assemblies with an old runtime will not fix your new > runtime. Trust me, you do need to recompile the runtime with some set > of options that makes it work. If you don't want to play with those > options, then please don't complain. ;) > > Andreas > > From pablosantosluac at terra.es Fri Oct 3 20:07:49 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sat, 04 Oct 2008 02:07:49 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <48E6AE6D.2020704@terra.es> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> <48E6AE6D.2020704@terra.es> Message-ID: <48E6B3D5.9030108@terra.es> Ok, wrong "make". Using Sun's but not gmake... On to the next one pablosantosluac at terra.es escribi?: > Hi Andreas, > > Got rid of the included "mcs" command. > > Then I was able to get a little bit further... (the first option > --with-sigaltstack=no was not yet tried) > > > Now the "Makefile" inside mcs seems to have a problem or something: > > make: Fatal error in reader: Makefile, line 2: Unexpected end of line seen > > > > > Andreas F?rber escribi?: > >> Pablo, >> >> Am 03.10.2008 um 00:10 schrieb pablosantosluac at terra.es: >> >> >>> Ok, I'm using the included one but, any clue why I can't get the >>> monolite to work? >>> >> I did post some suggestions already that you haven't reported back on... >> >> * Use --with-sigaltstack=no - it tried to use it on my boxes and >> crashed at runtime >> * Try without libgc - if you don't want to try vanilla Boehm GC, use >> --with-gc=none (it's the only way to rule out the GC as source of errors) >> * Rename Sun's `mcs` executable (Modular... whatever) or remove it >> from $PATH so that it's not detected in the first place >> >> You can use monolite, I did so myself on Solarises. You can't get it >> to work however because in your configuration the Mono runtime crashes >> while trying to execute mcs.exe from monolite to compile >> basic-profile-check.exe. Copying over assemblies from elsewhere or >> compiling new assemblies with an old runtime will not fix your new >> runtime. Trust me, you do need to recompile the runtime with some set >> of options that makes it work. If you don't want to play with those >> options, then please don't complain. ;) >> >> Andreas >> >> >> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From andreas.faerber at web.de Sat Oct 4 07:42:38 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sat, 4 Oct 2008 13:42:38 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <1ff5dedc0810031401y4b9a2723pa5f7d71257935e0c@mail.gmail.com> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> <20081003135406.GE27246@debian.org> <1ff5dedc0810031401y4b9a2723pa5f7d71257935e0c@mail.gmail.com> Message-ID: <885A9942-4347-4695-8BA3-AA0773413CC5@web.de> Hi Cetin! Am 03.10.2008 um 23:01 schrieb Cetin Sert: > I'm also trying to build mono on opensolaris 10 x86-64 and got this > message: > > when I run ./configure --with-gc=boehm > checking gc.h usability... no > checking gc.h presence... no > checking for gc.h... no > > checking gc/gc.h usability... no > checking gc/gc.h presence... no > checking for gc/gc.h... no > checking for GC_malloc in -lgc... no > configure: error: "GC requested but libgc not found! Install libgc > or run > > configure with --with-gc=none." > I had built and installed the latest boehm gc I could find. I think > it was version 7.sth. Did you add appropriate CPPFLAGS and LDFLAGS arguments for configure, to tell it about your installation location? > And if I configure mono using --with--gc=none how can I add a gc > later? o_O?? Well, the --with-gc=none workflow would be compiling without first, then reconfiguring and recompiling with some other --with-gc= option later on. On x86-64 OpenSolaris, you can use --with-gc=boehm right away, worked nicely with Boehm GC 7.1 for me. If there is a compilation problem in Boehm GC, you may need to install a more recent build (some in the low 90 range was broken). Best regards, Andreas From pablosantosluac at terra.es Sat Oct 4 07:55:31 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sat, 04 Oct 2008 13:55:31 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <885A9942-4347-4695-8BA3-AA0773413CC5@web.de> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> <20081003135406.GE27246@debian.org> <1ff5dedc0810031401y4b9a2723pa5f7d71257935e0c@mail.gmail.com> <885A9942-4347-4695-8BA3-AA0773413CC5@web.de> Message-ID: <48E759B3.2030204@terra.es> Hi Andreas, I'm afraid I'm not still close. I got rid of the mcs binary and I tried (after make get-monolite-latest) and then ./configure --with-prefix=/home/pablo/monobin --with-sigaltstack=no --with-sigaltstack=no; make And get: gmake[2]: Entering directory `/home/pablo/mono/mono/runtime' d=`cd ../support && pwd`; \ sed 's,target="libMonoPosixHelper[^"]*",target="'$d/libMonoPosixHelper.la'",' ../data/config > etc/mono/configt if test -z ""; then :; else \ sed 's,,& ,' etc/mono/configt > etc/mono/configtt; \ mv -f etc/mono/configtt etc/mono/configt; fi mv -f etc/mono/configt etc/mono/config /bin/bash /home/pablo/mono/mono/install-sh -d _tmpinst/bin cp mono-wrapper _tmpinst/bin/mono echo '#! /bin/sh' > _tmpinst/bin/mcs ; \ r=`pwd`; m=`cd ../../mcs && pwd`; \ echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/default/mcs.exe"'" "$@"' >> _tmpinst/bin/mcs ; \ chmod +x _tmpinst/bin/mcs echo '#! /bin/sh' > _tmpinst/bin/ilasm ; \ r=`pwd`; m=`cd ../../mcs && pwd`; \ echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/ilasm/ilasm.exe"'" "$@"' >> _tmpinst/bin/ilasm ; \ chmod +x _tmpinst/bin/ilasm echo '#! /bin/sh' > _tmpinst/bin/gmcs ; \ r=`pwd`; m=`cd ../../mcs && pwd`; \ echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/net_2_0/gmcs.exe"'" "$@"' >> _tmpinst/bin/gmcs ; \ chmod +x _tmpinst/bin/gmcs if test -w ../../mcs; then :; else chmod -R +w ../../mcs; fi cd ../../mcs && gmake NO_DIR_CHECK=1 PROFILES='default net_2_0 net_3_5 net_2_1' CC='gcc' all-profiles gmake[3]: Entering directory `/home/pablo/mono/mcs' gmake profile-do--default--all profile-do--net_2_0--all profile-do--net_3_5--all profile-do--net_2_1--all gmake[4]: Entering directory `/home/pablo/mono/mcs' gmake PROFILE=basic all gmake[5]: Entering directory `/home/pablo/mono/mcs' gmake[6]: mcs: Command not found gmake[6]: *** [build/deps/basic-profile-check.exe] Error 127 gmake[6]: Entering directory `/home/pablo/mono/mcs' *** The compiler 'mcs' doesn't appear to be usable. *** Trying the 'monolite' directory. gmake[7]: Entering directory `/home/pablo/mono/mcs' GC Warning: Large stack limit(133464064): only scanning 8 MB gmake[8]: *** [build/deps/basic-profile-check.exe] Error 1 gmake[8]: Entering directory `/home/pablo/mono/mcs' *** The contents of your 'monolite' directory may be out-of-date *** You may want to try 'make get-monolite-latest' gmake[8]: *** [do-profile-check-monolite] Error 1 gmake[8]: Leaving directory `/home/pablo/mono/mcs' gmake[7]: *** [do-profile-check] Error 2 gmake[7]: Leaving directory `/home/pablo/mono/mcs' gmake[6]: *** [do-profile-check-monolite] Error 2 gmake[6]: Leaving directory `/home/pablo/mono/mcs' gmake[5]: *** [do-profile-check] Error 2 gmake[5]: Leaving directory `/home/pablo/mono/mcs' gmake[4]: *** [profile-do--basic--all] Error 2 gmake[4]: Leaving directory `/home/pablo/mono/mcs' gmake[3]: *** [profiles-do--all] Error 2 gmake[3]: Leaving directory `/home/pablo/mono/mcs' gmake[2]: *** [all-local] Error 2 gmake[2]: Leaving directory `/home/pablo/mono/mono/runtime' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/pablo/mono/mono' gmake: *** [all] Error 2 Andreas F?rber escribi?: > Hi Cetin! > > Am 03.10.2008 um 23:01 schrieb Cetin Sert: > > >> I'm also trying to build mono on opensolaris 10 x86-64 and got this >> message: >> >> when I run ./configure --with-gc=boehm >> checking gc.h usability... no >> checking gc.h presence... no >> checking for gc.h... no >> >> checking gc/gc.h usability... no >> checking gc/gc.h presence... no >> checking for gc/gc.h... no >> checking for GC_malloc in -lgc... no >> configure: error: "GC requested but libgc not found! Install libgc >> or run >> >> configure with --with-gc=none." >> I had built and installed the latest boehm gc I could find. I think >> it was version 7.sth. >> > > Did you add appropriate CPPFLAGS and LDFLAGS arguments for configure, > to tell it about your installation location? > > > >> And if I configure mono using --with--gc=none how can I add a gc >> later? o_O?? >> > > Well, the --with-gc=none workflow would be compiling without first, > then reconfiguring and recompiling with some other --with-gc= option > later on. > > On x86-64 OpenSolaris, you can use --with-gc=boehm right away, worked > nicely with Boehm GC 7.1 for me. If there is a compilation problem in > Boehm GC, you may need to install a more recent build (some in the low > 90 range was broken). > > Best regards, > > Andreas > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From andreas.faerber at web.de Sat Oct 4 08:55:42 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sat, 4 Oct 2008 14:55:42 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <48E759B3.2030204@terra.es> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> <20081003135406.GE27246@debian.org> <1ff5dedc0810031401y4b9a2723pa5f7d71257935e0c@mail.gmail.com> <885A9942-4347-4695-8BA3-AA0773413CC5@web.de> <48E759B3.2030204@terra.es> Message-ID: For anyone fighting with --with-gc=none, I just filed a patch to make it work again: https://bugzilla.novell.com/show_bug.cgi?id=432306 Andreas From joe at unity3d.com Sat Oct 4 09:26:37 2008 From: joe at unity3d.com (Joachim Ante) Date: Sat, 4 Oct 2008 15:26:37 +0200 Subject: [Mono-dev] Extract method name from IEnumerator Message-ID: <83725221-E322-4E87-B710-A7A687C37C82@unity3d.com> Hi, Is there any way to extract the method name from an IEnumerator object when using iterators? Our users do this: IEnumerator MyMethod () { yield return 0; .... } StartCoroutine(MyMethod ()); StartCoroutine passes the IEnumerator down to c code and schedules MoveNext from C code. We use this kind of setup a lot for game code. This all works great, the problem is profiling. When profiling the method name that shows up is always MoveNext. I would like to replace MoveNext with the actual method name. I am looking for a way to extract it using the embedding API. Relying on specific implementation details of the gmcs is perfectly fine. Best regards, Joachim Ante From jb at nurv.fr Sat Oct 4 09:35:59 2008 From: jb at nurv.fr (Jb Evain) Date: Sat, 4 Oct 2008 15:35:59 +0200 Subject: [Mono-dev] Extract method name from IEnumerator In-Reply-To: <83725221-E322-4E87-B710-A7A687C37C82@unity3d.com> References: <83725221-E322-4E87-B710-A7A687C37C82@unity3d.com> Message-ID: <69f7d8470810040635rdad971eh5db5c2db52d54059@mail.gmail.com> Hey Joachim, On 10/4/08, Joachim Ante wrote: > Is there any way to extract the method name from an IEnumerator > object when using iterators? > > Our users do this: > > IEnumerator MyMethod () > { > yield return 0; > .... > } > > StartCoroutine(MyMethod ()); > > StartCoroutine passes the IEnumerator down to c code and schedules > MoveNext from C code. > > > > We use this kind of setup a lot for game code. This all works great, > the problem is profiling. > > When profiling the method name that shows up is always MoveNext. I > would like to replace MoveNext with the actual method name. The method's name is always MoveNext to conform to System.Collections.IEnumerator, but the declaring type of the method will be named after the original method. For example: class Test { static IEnumerable Foo () { yield return 42; } } The enumerator's type will be named `c__IteratorN`. The issue is that this name can probably be changed as will by gmcs, but it looks like you can get the method's original name from its generated type name. -- Jb Evain From Brian.D.Low at hawaii.gov Sat Oct 4 10:01:13 2008 From: Brian.D.Low at hawaii.gov (Brian.D.Low at hawaii.gov) Date: Sat, 4 Oct 2008 04:01:13 -1000 Subject: [Mono-dev] Brian D Low is out of the office. Message-ID: I will be out of the office starting 10/04/2008 and will not return until 10/13/2008. I will respond to your message when I return. From pablosantosluac at terra.es Sat Oct 4 11:42:06 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sat, 04 Oct 2008 17:42:06 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <48E759B3.2030204@terra.es> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> <20081003135406.GE27246@debian.org> <1ff5dedc0810031401y4b9a2723pa5f7d71257935e0c@mail.gmail.com> <885A9942-4347-4695-8BA3-AA0773413CC5@web.de> <48E759B3.2030204@terra.es> Message-ID: <48E78ECE.7040002@terra.es> Hi again, When I try to run mcs.exe (monolite) this is what I get: ../mono/runtime/mono-wrapper class/lib/monolite/mcs.exe The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `/usr/local/lib/mono/1.0/mscorlib.dll' directory. I don't know whether it is related to the problem below (not being able to compile the simplest c# code at all). Setting LD_LIBRARY_PATH or MONO_PATH doesn't help either... Help? pablo pablosantosluac at terra.es escribi?: > Hi Andreas, > > I'm afraid I'm not still close. > > I got rid of the mcs binary and I tried (after make get-monolite-latest) > and then > > ./configure --with-prefix=/home/pablo/monobin --with-sigaltstack=no > --with-sigaltstack=no; make > > > And get: > > gmake[2]: Entering directory `/home/pablo/mono/mono/runtime' > d=`cd ../support && pwd`; \ > sed > 's,target="libMonoPosixHelper[^"]*",target="'$d/libMonoPosixHelper.la'",' > ../data/config > etc/mono/configt > if test -z ""; then :; else \ > sed 's,,& />,' etc/mono/configt > etc/mono/configtt; \ > mv -f etc/mono/configtt etc/mono/configt; fi > mv -f etc/mono/configt etc/mono/config > /bin/bash /home/pablo/mono/mono/install-sh -d _tmpinst/bin > cp mono-wrapper _tmpinst/bin/mono > echo '#! /bin/sh' > _tmpinst/bin/mcs ; \ > r=`pwd`; m=`cd ../../mcs && pwd`; \ > echo 'exec "'"$r/_tmpinst/bin/mono"'" > "'"$m/class/lib/default/mcs.exe"'" "$@"' >> _tmpinst/bin/mcs ; \ > chmod +x _tmpinst/bin/mcs > echo '#! /bin/sh' > _tmpinst/bin/ilasm ; \ > r=`pwd`; m=`cd ../../mcs && pwd`; \ > echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/ilasm/ilasm.exe"'" > "$@"' >> _tmpinst/bin/ilasm ; \ > chmod +x _tmpinst/bin/ilasm > echo '#! /bin/sh' > _tmpinst/bin/gmcs ; \ > r=`pwd`; m=`cd ../../mcs && pwd`; \ > echo 'exec "'"$r/_tmpinst/bin/mono"'" > "'"$m/class/lib/net_2_0/gmcs.exe"'" "$@"' >> _tmpinst/bin/gmcs ; \ > chmod +x _tmpinst/bin/gmcs > if test -w ../../mcs; then :; else chmod -R +w ../../mcs; fi > cd ../../mcs && gmake NO_DIR_CHECK=1 PROFILES='default net_2_0 net_3_5 > net_2_1' CC='gcc' all-profiles > gmake[3]: Entering directory `/home/pablo/mono/mcs' > gmake profile-do--default--all profile-do--net_2_0--all > profile-do--net_3_5--all profile-do--net_2_1--all > gmake[4]: Entering directory `/home/pablo/mono/mcs' > gmake PROFILE=basic all > gmake[5]: Entering directory `/home/pablo/mono/mcs' > gmake[6]: mcs: Command not found > gmake[6]: *** [build/deps/basic-profile-check.exe] Error 127 > gmake[6]: Entering directory `/home/pablo/mono/mcs' > *** The compiler 'mcs' doesn't appear to be usable. > *** Trying the 'monolite' directory. > gmake[7]: Entering directory `/home/pablo/mono/mcs' > GC Warning: Large stack limit(133464064): only scanning 8 MB > gmake[8]: *** [build/deps/basic-profile-check.exe] Error 1 > gmake[8]: Entering directory `/home/pablo/mono/mcs' > *** The contents of your 'monolite' directory may be out-of-date > *** You may want to try 'make get-monolite-latest' > gmake[8]: *** [do-profile-check-monolite] Error 1 > gmake[8]: Leaving directory `/home/pablo/mono/mcs' > gmake[7]: *** [do-profile-check] Error 2 > gmake[7]: Leaving directory `/home/pablo/mono/mcs' > gmake[6]: *** [do-profile-check-monolite] Error 2 > gmake[6]: Leaving directory `/home/pablo/mono/mcs' > gmake[5]: *** [do-profile-check] Error 2 > gmake[5]: Leaving directory `/home/pablo/mono/mcs' > gmake[4]: *** [profile-do--basic--all] Error 2 > gmake[4]: Leaving directory `/home/pablo/mono/mcs' > gmake[3]: *** [profiles-do--all] Error 2 > gmake[3]: Leaving directory `/home/pablo/mono/mcs' > gmake[2]: *** [all-local] Error 2 > gmake[2]: Leaving directory `/home/pablo/mono/mono/runtime' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/home/pablo/mono/mono' > gmake: *** [all] Error 2 > > > > Andreas F?rber escribi?: > >> Hi Cetin! >> >> Am 03.10.2008 um 23:01 schrieb Cetin Sert: >> >> >> >>> I'm also trying to build mono on opensolaris 10 x86-64 and got this >>> message: >>> >>> when I run ./configure --with-gc=boehm >>> checking gc.h usability... no >>> checking gc.h presence... no >>> checking for gc.h... no >>> >>> checking gc/gc.h usability... no >>> checking gc/gc.h presence... no >>> checking for gc/gc.h... no >>> checking for GC_malloc in -lgc... no >>> configure: error: "GC requested but libgc not found! Install libgc >>> or run >>> >>> configure with --with-gc=none." >>> I had built and installed the latest boehm gc I could find. I think >>> it was version 7.sth. >>> >>> >> Did you add appropriate CPPFLAGS and LDFLAGS arguments for configure, >> to tell it about your installation location? >> >> >> >> >>> And if I configure mono using --with--gc=none how can I add a gc >>> later? o_O?? >>> >>> >> Well, the --with-gc=none workflow would be compiling without first, >> then reconfiguring and recompiling with some other --with-gc= option >> later on. >> >> On x86-64 OpenSolaris, you can use --with-gc=boehm right away, worked >> nicely with Boehm GC 7.1 for me. If there is a compilation problem in >> Boehm GC, you may need to install a more recent build (some in the low >> 90 range was broken). >> >> Best regards, >> >> Andreas >> >> _______________________________________________ >> 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 andreas.faerber at web.de Sat Oct 4 12:02:10 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sat, 4 Oct 2008 18:02:10 +0200 Subject: [Mono-dev] problem building mono, can't get monolite to work In-Reply-To: <48E78ECE.7040002@terra.es> References: <48E4EC37.2000906@terra.es> <6CDCC1B6-2113-4B00-A201-9DB5B40DED09@web.de> <295e750a0810021402s2ad9d92es27dc9f294737ac55@mail.gmail.com> <48E546CB.5080300@terra.es> <20081003135406.GE27246@debian.org> <1ff5dedc0810031401y4b9a2723pa5f7d71257935e0c@mail.gmail.com> <885A9942-4347-4695-8BA3-AA0773413CC5@web.de> <48E759B3.2030204@terra.es> <48E78ECE.7040002@terra.es> Message-ID: Hi, Am 04.10.2008 um 17:42 schrieb pablosantosluac at terra.es: > When I try to run mcs.exe (monolite) this is what I get: > > ../mono/runtime/mono-wrapper class/lib/monolite/mcs.exe > The assembly mscorlib.dll was not found or could not be loaded. > It should have been installed in the `/usr/local/lib/mono/1.0/ > mscorlib.dll' directory. > > I don't know whether it is related to the problem below (not being > able to compile the simplest c# code at all). Setting > LD_LIBRARY_PATH or MONO_PATH doesn't help either... See http://ports.haiku-files.org/wiki/dev-lang/mono/2.x/1 for an example how to manually execute an assembly with monolite. Andreas From pablosantosluac at terra.es Sat Oct 4 12:03:27 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sat, 04 Oct 2008 18:03:27 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap Message-ID: <48E793CF.4070204@terra.es> Hi, I've just installed the *latest* mono from blastwave (which is an old 1.1.13.8) Tried to build the 2.0 branch, but (again) it can't build the libraries. -bash-3.00$ mono --version Mono JIT compiler version 1.1.13.8, (C) 2002-2005 Novell, Inc and Contributors. www.mono-project.com TLS: normal GC: Included Boehm (with typed GC) SIGSEGV : normal -bash-3.00$ echo $MONO_PATH /opt/csw/lib/mono gmake[8]: Entering directory `/home/pablo/mono/mcs/class/System' ** Warning: System.dll built without parts that depend on: System.Xml.dll MONO_PATH="../../class/lib/basic:$MONO_PATH" /home/pablo/mono/mono/runtime/mono-wrapper ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -target:library -out:System.dll @System.dll.sources GC Warning: Large stack limit(133464064): only scanning 8 MB The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `/usr/local/lib/mono/1.0/mscorlib.dll' directory. gmake[8]: *** [../../class/lib/basic/System.dll] Error 1 gmake[8]: Leaving directory `/home/pablo/mono/mcs/class/System' gmake[7]: *** [do-all] Error 2 gmake[7]: Leaving directory `/home/pablo/mono/mcs/class/System' gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory `/home/pablo/mono/mcs/class' gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory `/home/pablo/mono/mcs' gmake[4]: *** [profile-do--basic--all] Error 2 gmake[4]: Leaving directory `/home/pablo/mono/mcs' gmake[3]: *** [profiles-do--all] Error 2 gmake[3]: Leaving directory `/home/pablo/mono/mcs' gmake[2]: *** [all-local] Error 2 gmake[2]: Leaving directory `/home/pablo/mono/mono/runtime' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/pablo/mono/mono' gmake: *** [all] Error 2 Any help would be more than welcome! :-) pablo From cetin.sert at gmail.com Sat Oct 4 12:24:51 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Sat, 4 Oct 2008 18:24:51 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48E793CF.4070204@terra.es> References: <48E793CF.4070204@terra.es> Message-ID: <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> Try it with the binaries from my blog: http://corsis.de/blog I've got two more recent versions there: 1.9 1.2.6 1.2.5 (dead link sorry) Hope one of them could help you... also trying to build mono on solaris would highly appreciate if you could document each and every step of the process and publish it somewhere in the form of instructions. I messed up a few Solaris OSes I had installed as virtual machines and do not feel like trying it again until tomorrow now. Best Regards, Cetin 2008/10/4 pablosantosluac at terra.es > Hi, > > I've just installed the *latest* mono from blastwave (which is an old > 1.1.13.8) > > Tried to build the 2.0 branch, but (again) it can't build the libraries. > > -bash-3.00$ mono --version > Mono JIT compiler version 1.1.13.8, (C) 2002-2005 Novell, Inc and > Contributors. www.mono-project.com > TLS: normal > GC: Included Boehm (with typed GC) > SIGSEGV : normal > > -bash-3.00$ echo $MONO_PATH > /opt/csw/lib/mono > > > > gmake[8]: Entering directory `/home/pablo/mono/mcs/class/System' > ** Warning: System.dll built without parts that depend on: System.Xml.dll > MONO_PATH="../../class/lib/basic:$MONO_PATH" > /home/pablo/mono/mono/runtime/mono-wrapper > ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 > -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -target:library > -out:System.dll @System.dll.sources > GC Warning: Large stack limit(133464064): only scanning 8 MB > The assembly mscorlib.dll was not found or could not be loaded. > It should have been installed in the > `/usr/local/lib/mono/1.0/mscorlib.dll' directory. > gmake[8]: *** [../../class/lib/basic/System.dll] Error 1 > gmake[8]: Leaving directory `/home/pablo/mono/mcs/class/System' > gmake[7]: *** [do-all] Error 2 > gmake[7]: Leaving directory `/home/pablo/mono/mcs/class/System' > gmake[6]: *** [all-recursive] Error 1 > gmake[6]: Leaving directory `/home/pablo/mono/mcs/class' > gmake[5]: *** [all-recursive] Error 1 > gmake[5]: Leaving directory `/home/pablo/mono/mcs' > gmake[4]: *** [profile-do--basic--all] Error 2 > gmake[4]: Leaving directory `/home/pablo/mono/mcs' > gmake[3]: *** [profiles-do--all] Error 2 > gmake[3]: Leaving directory `/home/pablo/mono/mcs' > gmake[2]: *** [all-local] Error 2 > gmake[2]: Leaving directory `/home/pablo/mono/mono/runtime' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/home/pablo/mono/mono' > gmake: *** [all] Error 2 > > > > Any help would be more than welcome! :-) > > > pablo > _______________________________________________ > 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/20081004/8fa6ae9c/attachment.html From pablosantosluac at terra.es Sat Oct 4 13:22:56 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sat, 04 Oct 2008 19:22:56 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> Message-ID: <48E7A670.1050001@terra.es> Certin, If I manage to build it, take if for granted I'll publish a tutorial. I *need* to run MWF on Solaris, so I need to go through all the build process first. pablo Cetin Sert escribi?: > Try it with the binaries from my blog: http://corsis.de/blog > > I've got two more recent versions there: > 1.9 > 1.2.6 > > 1.2.5 (dead link sorry) > > Hope one of them could help you... also trying to build mono on > solaris would highly appreciate if you could document each and every > step of the process and publish it somewhere in the form of > instructions. I messed up a few Solaris OSes I had installed as > virtual machines and do not feel like trying it again until tomorrow now. > > Best Regards, > Cetin > > 2008/10/4 pablosantosluac at terra.es > > > > Hi, > > I've just installed the *latest* mono from blastwave (which is an old > 1.1.13.8 ) > > Tried to build the 2.0 branch, but (again) it can't build the > libraries. > > -bash-3.00$ mono --version > Mono JIT compiler version 1.1.13.8 , (C) > 2002-2005 Novell, Inc and > Contributors. www.mono-project.com > TLS: normal > GC: Included Boehm (with typed GC) > SIGSEGV : normal > > -bash-3.00$ echo $MONO_PATH > /opt/csw/lib/mono > > > > gmake[8]: Entering directory `/home/pablo/mono/mcs/class/System' > ** Warning: System.dll built without parts that depend on: > System.Xml.dll > MONO_PATH="../../class/lib/basic:$MONO_PATH" > /home/pablo/mono/mono/runtime/mono-wrapper > ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 > -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -target:library > -out:System.dll @System.dll.sources > GC Warning: Large stack limit(133464064): only scanning 8 MB > The assembly mscorlib.dll was not found or could not be loaded. > It should have been installed in the > `/usr/local/lib/mono/1.0/mscorlib.dll' directory. > gmake[8]: *** [../../class/lib/basic/System.dll] Error 1 > gmake[8]: Leaving directory `/home/pablo/mono/mcs/class/System' > gmake[7]: *** [do-all] Error 2 > gmake[7]: Leaving directory `/home/pablo/mono/mcs/class/System' > gmake[6]: *** [all-recursive] Error 1 > gmake[6]: Leaving directory `/home/pablo/mono/mcs/class' > gmake[5]: *** [all-recursive] Error 1 > gmake[5]: Leaving directory `/home/pablo/mono/mcs' > gmake[4]: *** [profile-do--basic--all] Error 2 > gmake[4]: Leaving directory `/home/pablo/mono/mcs' > gmake[3]: *** [profiles-do--all] Error 2 > gmake[3]: Leaving directory `/home/pablo/mono/mcs' > gmake[2]: *** [all-local] Error 2 > gmake[2]: Leaving directory `/home/pablo/mono/mono/runtime' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/home/pablo/mono/mono' > gmake: *** [all] Error 2 > > > > Any help would be more than welcome! :-) > > > pablo > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From kornelpal at gmail.com Sat Oct 4 14:22:40 2008 From: kornelpal at gmail.com (=?ISO-8859-1?Q?Korn=E9l_P=E1l?=) Date: Sat, 04 Oct 2008 20:22:40 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48E7A670.1050001@terra.es> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> Message-ID: <48E7B470.3030202@gmail.com> Hi, You only have to build the runtime (C code). You can copy the class library (C# code) form an other system because CIL is platform independent. This may help if you can build a working runtime but have no working C# compiler. Korn?l pablosantosluac at terra.es wrote: > Certin, > > If I manage to build it, take if for granted I'll publish a tutorial. > > I *need* to run MWF on Solaris, so I need to go through all the build > process first. > > pablo > > Cetin Sert escribi?: >> Try it with the binaries from my blog: http://corsis.de/blog >> >> I've got two more recent versions there: >> 1.9 >> 1.2.6 >> >> 1.2.5 (dead link sorry) >> >> Hope one of them could help you... also trying to build mono on >> solaris would highly appreciate if you could document each and every >> step of the process and publish it somewhere in the form of >> instructions. I messed up a few Solaris OSes I had installed as >> virtual machines and do not feel like trying it again until tomorrow now. >> >> Best Regards, >> Cetin >> >> 2008/10/4 pablosantosluac at terra.es >> > >> >> Hi, >> >> I've just installed the *latest* mono from blastwave (which is an old >> 1.1.13.8 ) >> >> Tried to build the 2.0 branch, but (again) it can't build the >> libraries. >> >> -bash-3.00$ mono --version >> Mono JIT compiler version 1.1.13.8 , (C) >> 2002-2005 Novell, Inc and >> Contributors. www.mono-project.com >> TLS: normal >> GC: Included Boehm (with typed GC) >> SIGSEGV : normal >> >> -bash-3.00$ echo $MONO_PATH >> /opt/csw/lib/mono >> >> >> >> gmake[8]: Entering directory `/home/pablo/mono/mcs/class/System' >> ** Warning: System.dll built without parts that depend on: >> System.Xml.dll >> MONO_PATH="../../class/lib/basic:$MONO_PATH" >> /home/pablo/mono/mono/runtime/mono-wrapper >> ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 >> -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -target:library >> -out:System.dll @System.dll.sources >> GC Warning: Large stack limit(133464064): only scanning 8 MB >> The assembly mscorlib.dll was not found or could not be loaded. >> It should have been installed in the >> `/usr/local/lib/mono/1.0/mscorlib.dll' directory. >> gmake[8]: *** [../../class/lib/basic/System.dll] Error 1 >> gmake[8]: Leaving directory `/home/pablo/mono/mcs/class/System' >> gmake[7]: *** [do-all] Error 2 >> gmake[7]: Leaving directory `/home/pablo/mono/mcs/class/System' >> gmake[6]: *** [all-recursive] Error 1 >> gmake[6]: Leaving directory `/home/pablo/mono/mcs/class' >> gmake[5]: *** [all-recursive] Error 1 >> gmake[5]: Leaving directory `/home/pablo/mono/mcs' >> gmake[4]: *** [profile-do--basic--all] Error 2 >> gmake[4]: Leaving directory `/home/pablo/mono/mcs' >> gmake[3]: *** [profiles-do--all] Error 2 >> gmake[3]: Leaving directory `/home/pablo/mono/mcs' >> gmake[2]: *** [all-local] Error 2 >> gmake[2]: Leaving directory `/home/pablo/mono/mono/runtime' >> gmake[1]: *** [all-recursive] Error 1 >> gmake[1]: Leaving directory `/home/pablo/mono/mono' >> gmake: *** [all] Error 2 >> >> >> >> Any help would be more than welcome! :-) >> >> >> pablo >> _______________________________________________ >> 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 andreas.faerber at web.de Sat Oct 4 14:44:39 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sat, 4 Oct 2008 20:44:39 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48E7A670.1050001@terra.es> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> Message-ID: <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> Am 04.10.2008 um 19:22 schrieb pablosantosluac at terra.es: > Certin, > > If I manage to build it, take if for granted I'll publish a tutorial. Cetin actually mentioned OpenSolaris as opposed to Solaris 10. When OpenSolaris 2008.05 was released I posted the following mini-guide: http://lists.ximian.com/pipermail/mono-list/2008-May/038584.html It was actually supposed to avoid questions later on. ;) The Boehm GC 7.1 libatomic_ops issue mentioned there was fixed in a later OpenSolaris build. Also, it's not really necessary to install the 'entire' package, pkg-config is hidden in some GNOME development package. And most importantly many workarounds for Solaris 10 are not necessary on OpenSolaris. The often-referenced http://www.mono-project.com/Mono:Solaris page contains a link to another post of mine, for Solaris 10: http://lists.ximian.com/pipermail/mono-list/2007-January/034101.html HTH, Andreas > I *need* to run MWF on Solaris, so I need to go through all the build > process first. P.S. Never tried MWF there... From pablosantosluac at terra.es Sat Oct 4 19:13:13 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sun, 05 Oct 2008 01:13:13 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> Message-ID: <48E7F889.7030603@terra.es> Andreas, Thanks for all the input and help. Well, it seems building the "core" is not hard if you make sure (on Solaris 10) that you use GNU packages and not the SUN ones (gmake, libtool, and everything else). I can build "mono" from trunk or 2-0. but the problems start with mcs... I'm now following the instructions sent by Geoff (basically using http://mono.ximian.com/monobuild/preview/sources/mono/mono-2.0.tar.bz2). >> Certin, >> >> If I manage to build it, take if for granted I'll publish a tutorial. > I'll also publish the VMWare box so anyone can try :-) > Cetin actually mentioned OpenSolaris as opposed to Solaris 10. When > OpenSolaris 2008.05 was released I posted the following mini-guide: > http://lists.ximian.com/pipermail/mono-list/2008-May/038584.html > > It was actually supposed to avoid questions later on. ;) > Following this guide the only thing I realize I missed is the LDFLAGS stuff? Is it the reason why mcs.exe can't be run? > The Boehm GC 7.1 libatomic_ops issue mentioned there was fixed in a > later OpenSolaris build. Also, it's not really necessary to install > the 'entire' package, pkg-config is hidden in some GNOME development > package. And most importantly many workarounds for Solaris 10 are not > necessary on OpenSolaris. > > The often-referenced http://www.mono-project.com/Mono:Solaris page > contains a link to another post of mine, for Solaris 10: > http://lists.ximian.com/pipermail/mono-list/2007-January/034101.html > Yes, this guide was helpful building 1.1.13 (almost two years ago already), but now all those tricks are not needed anymore... You can get the whole c code build easily... The "problem" (or mine, at least) seems to be the classes From pablosantosluac at terra.es Sat Oct 4 19:15:13 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sun, 05 Oct 2008 01:15:13 +0200 Subject: [Mono-dev] LRU cache Message-ID: <48E7F901.4060401@terra.es> Hi, Is there any LRU cache implementation somewhere in the mono sources? I found an implementation at CodeProject (http://www.codeproject.com/KB/recipes/LRUCache.aspx) but I wonder if there's something already built in somewhere? Thanks pablo From mathflair at gmail.com Wed Oct 1 21:54:30 2008 From: mathflair at gmail.com (Mathflair) Date: Wed, 1 Oct 2008 18:54:30 -0700 (PDT) Subject: [Mono-dev] Re flection not working with System.Runtime.Remoting.Channels.CoreChannel Message-ID: <19772228.post@talk.nabble.com> I am having a problem with the following line of code: Type coreChannelType = binaryServerFormatterSinkProvider.GetType().Assembly.GetType("System.Runtime.Remoting.Channels.CoreChannel"); This returns a null reference pointer. I can't figure out why this would happen. My only guess is that the reflection libraries are not properly grabbing the class since it is an internal class. Any help on getting this working would be great. -- View this message in context: http://www.nabble.com/Reflection-not-working-with-System.Runtime.Remoting.Channels.CoreChannel-tp19772228p19772228.html Sent from the Mono - Dev mailing list archive at Nabble.com. From bwbrowning at gmail.com Thu Oct 2 20:21:22 2008 From: bwbrowning at gmail.com (Brian Browning) Date: Thu, 2 Oct 2008 19:21:22 -0500 Subject: [Mono-dev] [PATCH] bug 431001: Exception using XmlTextReader Message-ID: This is my first time contributing to mono, so let me know if this looks ok, or if I did something wrong please. This patch handles the exception, passes the test case given in the bug report, and it passes all current tests. My only fear is that there is some detail of XmlSchema and XmlTextReader that I am overlooking that needs to be handled. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081002/1a1cac33/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 431001.diff Type: text/x-patch Size: 792 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081002/1a1cac33/attachment.bin From adam1piano at gmail.com Sat Oct 4 14:57:49 2008 From: adam1piano at gmail.com (Adam Shapiro) Date: Sat, 4 Oct 2008 11:57:49 -0700 (PDT) Subject: [Mono-dev] Unable To Read Using SerialPort Class Message-ID: <19815631.post@talk.nabble.com> Hi, I'm currently trying to use the System.IO.Ports.SerialPort class to communicate with a microcontroller, however I can't seem to read from the port in any way in OS X. After much searching it looks like the DataReceived event is not functional in Mono yet and that the suggested method is to poll the port using the ReadByte function, but no matter which read method I try (I've tried Read, ReadByte, and ReadExisting, as well as the DataReceived event), I always end up getting timeout exceptions. I'm checking the BytesToRead value before issuing a read and it's returning expected values for what the controller is outputting, I just can't seem to retrieve the data from the buffer. I'm attempting the read with the following code: byte[] bytes=new byte[byteCount]; int i=0; bytes[i++]=(byte)port.ReadByte(); I am sure that the port is reading (if I use a serial terminal I can see the data), and the port is readable if I compile the code in Visual Studio in Windows - I haven't tried Mono in Windows yet. Any help you can give is much appreciated. Thanks. -- View this message in context: http://www.nabble.com/Unable-To-Read-Using-SerialPort-Class-tp19815631p19815631.html Sent from the Mono - Dev mailing list archive at Nabble.com. From knocte at gmail.com Sat Oct 4 23:41:18 2008 From: knocte at gmail.com (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses=22?=) Date: Sat, 04 Oct 2008 23:41:18 -0400 Subject: [Mono-dev] Re flection not working with System.Runtime.Remoting.Channels.CoreChannel In-Reply-To: <19772228.post@talk.nabble.com> References: <19772228.post@talk.nabble.com> Message-ID: Mathflair wrote: > I am having a problem with the following line of code: > > Type coreChannelType = > binaryServerFormatterSinkProvider.GetType().Assembly.GetType("System.Runtime.Remoting.Channels.CoreChannel"); > > This returns a null reference pointer. I can't figure out why this would > happen. My only guess is that the reflection libraries are not properly > grabbing the class since it is an internal class. > > Any help on getting this working would be great. Mono only follows public APIs, so if your code relies on internal bits, it won't work outside MS.NET. Regards, Andr?s -- From mike at middlesoft.co.uk Sun Oct 5 01:43:51 2008 From: mike at middlesoft.co.uk (Michael Barker) Date: Sun, 5 Oct 2008 18:43:51 +1300 Subject: [Mono-dev] Message stuck in moderation. Message-ID: <80d1dfde0810042243l686556fcgf630e10d16d6ed67@mail.gmail.com> Hi I posted a message with a few patch files to the mono-devel list 1 week ago (Subject: AMQP/System.Messaging implementation, this time with RabbitMQ) and it still seems to stuck in moderation. Would it be possible for one of the moderators to push the email through? I admit the email was fairly big (2MB) and I had forgotten to add "Patch" to the subject line. I can resubmit the email if required. Regards, Michael Barker. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081005/5e77dc78/attachment.html From andreas.faerber at web.de Sun Oct 5 04:00:36 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 5 Oct 2008 10:00:36 +0200 Subject: [Mono-dev] Message stuck in moderation. In-Reply-To: <80d1dfde0810042243l686556fcgf630e10d16d6ed67@mail.gmail.com> References: <80d1dfde0810042243l686556fcgf630e10d16d6ed67@mail.gmail.com> Message-ID: Hi, Am 05.10.2008 um 07:43 schrieb Michael Barker: > I posted a message with a few patch files to the mono-devel list 1 > week ago (Subject: AMQP/System.Messaging implementation, this time > with RabbitMQ) and it still seems to stuck in moderation. Would it > be possible for one of the moderators to push the email through? I > admit the email was fairly big (2MB) and I had forgotten to add > "Patch" to the subject line. I can resubmit the email if required. If it's such a large patch, better create a Bugzilla ticket (with [PATCH] in the subject) and add it as attachment there. You can post a link to it then, relieving our inboxes. ;) Andreas From marek.safar at seznam.cz Sun Oct 5 04:57:04 2008 From: marek.safar at seznam.cz (Marek Safar) Date: Sun, 05 Oct 2008 09:57:04 +0100 Subject: [Mono-dev] Extract method name from IEnumerator In-Reply-To: <69f7d8470810040635rdad971eh5db5c2db52d54059@mail.gmail.com> References: <83725221-E322-4E87-B710-A7A687C37C82@unity3d.com> <69f7d8470810040635rdad971eh5db5c2db52d54059@mail.gmail.com> Message-ID: <48E88160.6090609@seznam.cz> Hello Joachim, >> Is there any way to extract the method name from an IEnumerator >> object when using iterators? >> >> Our users do this: >> >> IEnumerator MyMethod () >> { >> yield return 0; >> .... >> } >> >> StartCoroutine(MyMethod ()); >> >> StartCoroutine passes the IEnumerator down to c code and schedules >> MoveNext from C code. >> >> >> >> We use this kind of setup a lot for game code. This all works great, >> the problem is profiling. >> >> When profiling the method name that shows up is always MoveNext. I >> would like to replace MoveNext with the actual method name. >> > > The method's name is always MoveNext to conform to > System.Collections.IEnumerator, but the declaring type of the method > will be named after the original method. > > For example: > > class Test { > static IEnumerable Foo () > { > yield return 42; > } > } > > The enumerator's type will be named `c__IteratorN`. The issue is > that this name can probably be changed as will by gmcs, but it looks > like you can get the method's original name from its generated type > name. > JB summarized it nicely, you can use name inside <.> as original method name, there is couple of issue with it though. It may change in the future and it ignores generic method and method overloads. Therefore if you need better name mapping you have to use our debug symbol file. Marek From andreas.faerber at web.de Sun Oct 5 07:15:09 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 05 Oct 2008 13:15:09 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48E7F889.7030603@terra.es> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E7F889.7030603@terra.es> Message-ID: <48E8A1BD.20600@web.de> pablosantosluac at terra.es schrieb: > Well, it seems building the "core" is not hard if you make sure (on > Solaris 10) that you use GNU packages and not the SUN ones (gmake, > libtool, and everything else). I can build "mono" from trunk or 2-0. > but the problems start with mcs... I'm now following the instructions > sent by Geoff (basically using > http://mono.ximian.com/monobuild/preview/sources/mono/mono-2.0.tar.bz2). Having the runtime compile does not imply it'll work at runtime... Whether you use a tarball or monolite usually doesn't matter, but if you can, a tarball is "safer". Fwiw, I've just finished compiling mono at r114845+mcs@r114882 from mono at r109531+mcs@r109587 (all trunk) on OpenSolaris build 95 for i86 using exactly this: ../mono/configure --prefix=/opt/mono --with-gc=boehm \ --with-sigaltstack=no \ CPPFLAGS="-I/opt/mono-gc/include" \ LDFLAGS="-L/opt/mono-gc/lib -R/opt/mono/lib" where /opt/mono-gc is the prefix of Boehm GC 7.1, compiled with: ../gc-7.1/configure --prefix=/opt/mono-gc Works nicely there. Don't have access to S10 from here though to fetch my scripts or to try the latest revs there. On OpenSolaris/amd64, I use these on top: PREFIX=/opt/mono-gc ../gc-7.1/configure --prefix=$PREFIX --libdir=$PREFIX/lib/amd64 \ CPPFLAGS=-m64 CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 and: PREFIX=/opt/mono ../mono/configure --prefix=$PREFIX --bindir=$PREFIX/bin/amd64 --libdir=$PREFIX/lib/amd64 \ --with-gc=boehm --with-sigaltstack=no --enable-big-arrays --enable-dtrace --disable-mcs-build \ CPPFLAGS="-m64 -I/opt/mono-gc/include" CFLAGS="-m64" \ LDFLAGS="-m64 -L/opt/mono-gc/lib/amd64 -R/opt/mono/lib/amd64" \ PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig:$PKG_CONFIG_PATH" (Obviously I'm skipping mcs build in this script, but I've done full amd64 bootstraps before with post-2.0 revisions.) Note that I use dedicated /opt subdirs because that's where 3rdparty packages are often installed on Solarises, making it easy to rename or remove. $prefix/{bin,lib}/amd64 is where Sun places their amd64 files. Using a monolite from 12:05 GMT+02:00 today (with Sun's `mcs` renamed), there are no problems on OSol/i86 either. So it's definitely not mcs's or monolite's fault!!! >> Cetin actually mentioned OpenSolaris as opposed to Solaris 10. When >> OpenSolaris 2008.05 was released I posted the following mini-guide: >> http://lists.ximian.com/pipermail/mono-list/2008-May/038584.html >> >> It was actually supposed to avoid questions later on. ;) >> > Following this guide the only thing I realize I missed is the LDFLAGS > stuff? Is it the reason why mcs.exe can't be run? In case you mean LDFLAGS=-R/path then no, it has no influence on mcs. It helps with MD (libPosixHelper.so et al.). >> The often-referenced http://www.mono-project.com/Mono:Solaris page >> contains a link to another post of mine, for Solaris 10: >> http://lists.ximian.com/pipermail/mono-list/2007-January/034101.html >> > Yes, this guide was helpful building 1.1.13 (almost two years ago > already), but now all those tricks are not needed anymore... You can > get the whole c code build easily... If you build using Blastwave tools you don't need some of the environment variables; otherwise you still do on Solaris 10. The only thing outdated in that post to my knowledge is CFLAGS=-D_POSIX_PTHREAD_SEMANTICS and possibly the mono-service issue. Jonel's blog on the -mt pkg-config issue is almost three years old and mostly still applies due to the long lifetime of S10. :) AS=gas for instance was only needed for running `make check` so you won't notice during plain `make`. Andreas From joe at unity3d.com Sun Oct 5 07:18:45 2008 From: joe at unity3d.com (Joachim Ante) Date: Sun, 5 Oct 2008 13:18:45 +0200 Subject: [Mono-dev] Extract method name from IEnumerator In-Reply-To: <69f7d8470810040635rdad971eh5db5c2db52d54059@mail.gmail.com> References: <83725221-E322-4E87-B710-A7A687C37C82@unity3d.com> <69f7d8470810040635rdad971eh5db5c2db52d54059@mail.gmail.com> Message-ID: <3DCB1DAC-FB2E-413F-A9FC-D012E4BEBD51@unity3d.com> > The method's name is always MoveNext to conform to > System.Collections.IEnumerator, but the declaring type of the method > will be named after the original method. > > For example: > > class Test { > static IEnumerable Foo () > { > yield return 42; > } > } > > The enumerator's type will be named `c__IteratorN`. The issue is > that this name can probably be changed as will by gmcs, but it looks > like you can get the method's original name from its generated type > name. Has the behaviour of this changed? With Mono 1.2.5 I am getting "Test +<>c__CompilerGenerated0 > JB summarized it nicely, you can use name inside <.> as original > method name, there is couple of issue with it though. > It may change in the future and it ignores generic method and > method overloads. Therefore if you need better name mapping you > have to use our debug symbol file. Are there functions i can call to do a lookup of the function name, should i parse the whole file myself or add some function to mono to do it? Best regards, Joachim Ante From robertj at gmx.net Sun Oct 5 07:21:04 2008 From: robertj at gmx.net (Robert Jordan) Date: Sun, 05 Oct 2008 13:21:04 +0200 Subject: [Mono-dev] Re flection not working with System.Runtime.Remoting.Channels.CoreChannel In-Reply-To: <19772228.post@talk.nabble.com> References: <19772228.post@talk.nabble.com> Message-ID: Mathflair wrote: > I am having a problem with the following line of code: > > Type coreChannelType = > binaryServerFormatterSinkProvider.GetType().Assembly.GetType("System.Runtime.Remoting.Channels.CoreChannel"); > > This returns a null reference pointer. I can't figure out why this would > happen. My only guess is that the reflection libraries are not properly > grabbing the class since it is an internal class. Mono does not provide this class. Change your code to not depend on MS.NET runtime internals. Robert From marek.safar at seznam.cz Sun Oct 5 07:30:20 2008 From: marek.safar at seznam.cz (Marek Safar) Date: Sun, 05 Oct 2008 12:30:20 +0100 Subject: [Mono-dev] Extract method name from IEnumerator In-Reply-To: <3DCB1DAC-FB2E-413F-A9FC-D012E4BEBD51@unity3d.com> References: <83725221-E322-4E87-B710-A7A687C37C82@unity3d.com> <69f7d8470810040635rdad971eh5db5c2db52d54059@mail.gmail.com> <3DCB1DAC-FB2E-413F-A9FC-D012E4BEBD51@unity3d.com> Message-ID: <48E8A54C.8000000@seznam.cz> Hello, >> The method's name is always MoveNext to conform to >> System.Collections.IEnumerator, but the declaring type of the method >> will be named after the original method. >> >> For example: >> >> class Test { >> static IEnumerable Foo () >> { >> yield return 42; >> } >> } >> >> The enumerator's type will be named `c__IteratorN`. The issue is >> that this name can probably be changed as will by gmcs, but it looks >> like you can get the method's original name from its generated type >> name. >> > > Has the behaviour of this changed? With Mono 1.2.5 I am getting "Test > +<>c__CompilerGenerated0 > > Good point. New naming convention is available since Mono 2.0. > >> JB summarized it nicely, you can use name inside <.> as original >> method name, there is couple of issue with it though. >> It may change in the future and it ignores generic method and >> method overloads. Therefore if you need better name mapping you >> have to use our debug symbol file. >> > > Are there functions i can call to do a lookup of the function name, > should i parse the whole file myself or add some function to mono to > do it? > I think Martin has to do exactly same thing, but I am not sure whether he exposed it anywhere except in a debugger. It would be better to ask him directly. Marek From james at mansionfamily.plus.com Sun Oct 5 07:57:47 2008 From: james at mansionfamily.plus.com (James Mansion) Date: Sun, 05 Oct 2008 12:57:47 +0100 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> Message-ID: <48E8ABBB.6010005@mansionfamily.plus.com> Andreas F?rber wrote: > package. And most importantly many workarounds for Solaris 10 are not > necessary on OpenSolaris. > For any practical production use though, its necessary to support real Solaris 10, even if its only the latest version. Is there a list anywhere of the problematic bits of the system? Lots of Solaris users are still in production on Solaris 8, too. I'd dearly like to be able to consider Mono for real projects but that can't happen until it works properly on Sol8 sparc and Sol10 (sparc and AMD). James From cetin.sert at gmail.com Sun Oct 5 09:28:03 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Sun, 5 Oct 2008 15:28:03 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48E8ABBB.6010005@mansionfamily.plus.com> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> Message-ID: <1ff5dedc0810050628i7bac4a1era3046e7d748b6667@mail.gmail.com> I do suppose that OpenSolaris and Solaris would be able to run the same mono binaries right, once one has succeeded in compiling the runtime and so on I mean. 2008/10/5 James Mansion > Andreas F?rber wrote: > > package. And most importantly many workarounds for Solaris 10 are not > > necessary on OpenSolaris. > > > For any practical production use though, its necessary to support real > Solaris 10, even if its > only the latest version. > > Is there a list anywhere of the problematic bits of the system? > > > Lots of Solaris users are still in production on Solaris 8, too. I'd > dearly like to be able to > consider Mono for real projects but that can't happen until it works > properly on Sol8 > sparc and Sol10 (sparc and AMD). > > James > > _______________________________________________ > 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/20081005/f390ebd1/attachment.html From andreas.faerber at web.de Sun Oct 5 10:16:20 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 5 Oct 2008 16:16:20 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48E8ABBB.6010005@mansionfamily.plus.com> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> Message-ID: <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> Am 05.10.2008 um 13:57 schrieb James Mansion: > Andreas F?rber wrote: >> package. And most importantly many workarounds for Solaris 10 are not >> necessary on OpenSolaris. >> > For any practical production use though, its necessary to support real > Solaris 10, even if its > only the latest version. You've probably not followed the whole discussion. I have post-2.0 Mono running on real Solaris 10 amd64, it works fine. Some others have reported class library bugs for Solaris 9 sparc, so it would in general seem to work there, too. And there used to be Solaris 8 packages from Novell. No one has been arguing for one or the other system here, the instructions are simply different for the two. > Is there a list anywhere of the problematic bits of the system? In the S10 resources pointed to recently, there's for instance... - Sun's tar which doesn't extract long file names correctly (use GNU tar for tarballs) - Sun's make (use GNU make instead, MAKE=gmake) - Sun's C compiler (Mono requires gcc, CC=gcc etc.) - Sun's mcs command (conflicts with Mono's mcs bootstrap when in $PATH) - Solaris' GLib pkg-config files which are incompatible with gcc (replace -mt appropriately) - pthreads was not correctly detected or passed on (specify --with- tls=pthread) There also used to be some shell scripts incompatible with S10's Bourne shell (e.g., `export A=b` vs. `A=b; export A`). Hopefully that's fixed now. > Lots of Solaris users are still in production on Solaris 8, too. I'd > dearly like to be able to > consider Mono for real projects but that can't happen until it works > properly on Sol8 > sparc and Sol10 (sparc and AMD). Unfortunately, sparc is hard to test without access to the hardware. The only sparc emulator appeared to be QEMU, whose qemu-system-sparc is 32-bit only (sun4m), whereas Solaris 10 and Mono seem to expect sparcv9. I have a local branch where I once tried to make it work on a sparcv8 QEMU VM running Debian Etch, but the emulated compilation took much too long to get far. As someone with access to the hardware, please tell us what the problem is on your Solaris 8 boxes. If you have submitted bug reports consider posting links here since the Solaris users among us are not automatically cc'ed in Bugzilla. Only few sparc users have been around the last few years, so waiting is unlikely to bring a solution. Is there a problem with Linear IR for instance or has that already been ported to sparc? Andreas From pablosantosluac at terra.es Sun Oct 5 14:48:56 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sun, 05 Oct 2008 20:48:56 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <1ff5dedc0810050628i7bac4a1era3046e7d748b6667@mail.gmail.com> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <1ff5dedc0810050628i7bac4a1era3046e7d748b6667@mail.gmail.com> Message-ID: <48E90C18.5030508@terra.es> I never had problems with compiled binaries even with an old Solaris if I remember correctly. Once I manage to produce Sol10 releases regularly (will I? :-P) we can move to Sol8 Cetin Sert escribi?: > I do suppose that OpenSolaris and Solaris would be able to run the > same mono binaries right, once one has succeeded in compiling the > runtime and so on I mean. > > 2008/10/5 James Mansion > > > Andreas F?rber wrote: > > package. And most importantly many workarounds for Solaris 10 > are not > > necessary on OpenSolaris. > > > For any practical production use though, its necessary to support real > Solaris 10, even if its > only the latest version. > > Is there a list anywhere of the problematic bits of the system? > > > Lots of Solaris users are still in production on Solaris 8, too. I'd > dearly like to be able to > consider Mono for real projects but that can't happen until it works > properly on Sol8 > sparc and Sol10 (sparc and AMD). > > James > > _______________________________________________ > 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 miguel at novell.com Sun Oct 5 15:50:49 2008 From: miguel at novell.com (Miguel de Icaza) Date: Sun, 05 Oct 2008 15:50:49 -0400 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> Message-ID: <1223236249.5523.6.camel@erandi.site> Hello, > Unfortunately, sparc is hard to test without access to the hardware. > The only sparc emulator appeared to be QEMU, whose qemu-system-sparc > is 32-bit only (sun4m), whereas Solaris 10 and Mono seem to expect > sparcv9. I have a local branch where I once tried to make it work on a > sparcv8 QEMU VM running Debian Etch, but the emulated compilation took > much too long to get far. The above is actually a really good reason why we do not spend more cycles on Solaris/SPARC. The machines are overpriced, and underperforming. It is like buying an iPhone, just not as useful. Miguel. From pablosantosluac at terra.es Sun Oct 5 16:13:26 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sun, 05 Oct 2008 22:13:26 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <1223236249.5523.6.camel@erandi.site> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> Message-ID: <48E91FE6.9050705@terra.es> Miguel, I'm trying to run on Solaris/SPARC since we've a spare machine here (although you're right is slow and overpriced). We can plug it to the internet for the mono team if anyone is interested. pablo Miguel de Icaza escribi?: > Hello, > > >> Unfortunately, sparc is hard to test without access to the hardware. >> The only sparc emulator appeared to be QEMU, whose qemu-system-sparc >> is 32-bit only (sun4m), whereas Solaris 10 and Mono seem to expect >> sparcv9. I have a local branch where I once tried to make it work on a >> sparcv8 QEMU VM running Debian Etch, but the emulated compilation took >> much too long to get far. >> > > The above is actually a really good reason why we do not spend more > cycles on Solaris/SPARC. > > The machines are overpriced, and underperforming. It is like buying an > iPhone, just not as useful. > > Miguel. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From pablosantosluac at terra.es Sun Oct 5 16:16:31 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Sun, 05 Oct 2008 22:16:31 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48E8A1BD.20600@web.de> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E7F889.7030603@terra.es> <48E8A1BD.20600@web.de> Message-ID: <48E9209F.7080406@terra.es> Andreas, I just followed your instructions, step by step. First downloaded and installed gc-7.1 (worked perfectly), then configure and make mono. But I'm afraid I think I'm reaching the same point. Here's the ouput. At some point (it seems it happens after compiling some c# code) it starts complaining about mscorlib location... gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/build' gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/build' gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/jay' gmake all-local gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/jay' gmake[7]: Nothing to be done for `all-local'. gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/jay' gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/jay' gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/mcs' gmake all-local gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/mcs' mcs /codepage:65001 -optimize -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug -target:exe -out:mcs.exe cs-parser.cs @mcs.exe.sources GC Warning: Large stack limit(133464064): only scanning 8 MB cs-parser.cs(6665,7): warning CS0162: Unreachable code detected cs-parser.cs(6667,5): warning CS0162: Unreachable code detected expression.cs(991,14): warning CS0618: `Mono.CSharp.UserOperatorCall.MakeSimpleCall(Mono.CSharp.EmitContext, Mono.CSharp.MethodGroupExpr, Mono.CSharp.Expression, Mono.CSharp.Location)' is obsolete: `It may not be compatible with expression trees' Compilation succeeded - 3 warning(s) cp mcs.exe ../class/lib/basic/mcs.exe test ! -f mcs.exe.mdb || cp mcs.exe.mdb ../class/lib/basic/mcs.exe.mdb gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/mcs' gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/mcs' gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class' gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' gmake all-local gmake[8]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' mcs /codepage:65001 -nowarn:169,612,618,649 -d:INSIDE_CORLIB -optimize -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -unsafe -nostdlib -resource:resources/collation.core.bin -resource:resources/collation.tailoring.bin -resource:resources/collation.cjkCHS.bin -resource:resources/collation.cjkCHT.bin -resource:resources/collation.cjkJA.bin -resource:resources/collation.cjkKO.bin -resource:resources/collation.cjkKOlv2.bin -target:library -out:mscorlib.dll @corlib.dll.sources GC Warning: Large stack limit(133464064): only scanning 8 MB System/WindowsConsoleDriver.cs(29,1): warning CS1635: Cannot restore warning `CS0169' because it was disabled globally System.Security.Cryptography/PasswordDeriveBytes.cs(231,1): warning CS1691: `809' is not a valid warning number System.Security.Cryptography/PasswordDeriveBytes.cs(237,1): warning CS1691: `809' is not a valid warning number System/Int16.cs(178,3): warning CS0162: Unreachable code detected System/Int32.cs(200,3): warning CS0162: Unreachable code detected System/Int64.cs(181,3): warning CS0162: Unreachable code detected System/String.cs(946,6): warning CS0162: Unreachable code detected System/String.cs(1049,6): warning CS0162: Unreachable code detected Mono.Globalization.Unicode/Normalization.cs(76,36): warning CS0162: Unreachable code detected Compilation succeeded - 9 warning(s) : mscorlib.dll ../../class/mono.snk mv mscorlib.dll ../../class/lib/basic/mscorlib.dll test ! -f mscorlib.dll.mdb || mv mscorlib.dll.mdb ../../class/lib/basic/mscorlib.dll.mdb test ! -f mscorlib.pdb || mv mscorlib.pdb ../../class/lib/basic/mscorlib.pdb gmake[8]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/System' gmake all-local gmake[8]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/System' ** Warning: System.dll built without parts that depend on: System.Xml.dll MONO_PATH="../../class/lib/basic:$MONO_PATH" /home/pablo/mono/mono-2.0/runtime/mono-wrapper ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -target:library -out:System.dll @System.dll.sources The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `/opt/mono/lib/mono/1.0/mscorlib.dll' directory. gmake[8]: *** [../../class/lib/basic/System.dll] Error 1 gmake[8]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/System' gmake[7]: *** [do-all] Error 2 gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/System' gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class' gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' gmake[4]: *** [profile-do--basic--all] Error 2 gmake[4]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' gmake[3]: *** [profiles-do--all] Error 2 gmake[3]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' gmake[2]: *** [all-local] Error 2 gmake[2]: Leaving directory `/home/pablo/mono/mono-2.0/runtime' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/pablo/mono/mono-2.0' gmake: *** [all] Error 2 -bash-3.00$ uname -a SunOS unknown 5.10 Generic_127128-11 i86pc i386 i86pc Thanks again for your help pablo Andreas F?rber escribi?: > pablosantosluac at terra.es schrieb: >> Well, it seems building the "core" is not hard if you make sure (on >> Solaris 10) that you use GNU packages and not the SUN ones (gmake, >> libtool, and everything else). I can build "mono" from trunk or 2-0. >> but the problems start with mcs... I'm now following the instructions >> sent by Geoff (basically using >> http://mono.ximian.com/monobuild/preview/sources/mono/mono-2.0.tar.bz2). > > Having the runtime compile does not imply it'll work at runtime... > Whether you use a tarball or monolite usually doesn't matter, but if > you can, a tarball is "safer". > > Fwiw, I've just finished compiling mono at r114845+mcs@r114882 from > mono at r109531+mcs@r109587 (all trunk) on OpenSolaris build 95 for i86 > using exactly this: > > ../mono/configure --prefix=/opt/mono --with-gc=boehm \ > --with-sigaltstack=no \ > CPPFLAGS="-I/opt/mono-gc/include" \ > LDFLAGS="-L/opt/mono-gc/lib -R/opt/mono/lib" > > where /opt/mono-gc is the prefix of Boehm GC 7.1, compiled with: > > ../gc-7.1/configure --prefix=/opt/mono-gc > > Works nicely there. Don't have access to S10 from here though to fetch > my scripts or to try the latest revs there. > > On OpenSolaris/amd64, I use these on top: > > PREFIX=/opt/mono-gc > > ../gc-7.1/configure --prefix=$PREFIX --libdir=$PREFIX/lib/amd64 \ > CPPFLAGS=-m64 CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 > > and: > > PREFIX=/opt/mono > > ../mono/configure --prefix=$PREFIX --bindir=$PREFIX/bin/amd64 > --libdir=$PREFIX/lib/amd64 \ > --with-gc=boehm --with-sigaltstack=no --enable-big-arrays > --enable-dtrace --disable-mcs-build \ > CPPFLAGS="-m64 -I/opt/mono-gc/include" CFLAGS="-m64" \ > LDFLAGS="-m64 -L/opt/mono-gc/lib/amd64 -R/opt/mono/lib/amd64" \ > PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig:$PKG_CONFIG_PATH" > > (Obviously I'm skipping mcs build in this script, but I've done full > amd64 bootstraps before with post-2.0 revisions.) > > Note that I use dedicated /opt subdirs because that's where 3rdparty > packages are often installed on Solarises, making it easy to rename or > remove. $prefix/{bin,lib}/amd64 is where Sun places their amd64 files. > > Using a monolite from 12:05 GMT+02:00 today (with Sun's `mcs` renamed), > there are no problems on OSol/i86 either. > So it's definitely not mcs's or monolite's fault!!! > > >>> Cetin actually mentioned OpenSolaris as opposed to Solaris 10. When >>> OpenSolaris 2008.05 was released I posted the following mini-guide: >>> http://lists.ximian.com/pipermail/mono-list/2008-May/038584.html >>> >>> It was actually supposed to avoid questions later on. ;) >>> >> Following this guide the only thing I realize I missed is the LDFLAGS >> stuff? Is it the reason why mcs.exe can't be run? > > In case you mean LDFLAGS=-R/path then no, it has no influence on mcs. It > helps with MD (libPosixHelper.so et al.). > >>> The often-referenced http://www.mono-project.com/Mono:Solaris page >>> contains a link to another post of mine, for Solaris 10: >>> http://lists.ximian.com/pipermail/mono-list/2007-January/034101.html >>> >> Yes, this guide was helpful building 1.1.13 (almost two years ago >> already), but now all those tricks are not needed anymore... You can >> get the whole c code build easily... > > If you build using Blastwave tools you don't need some of the > environment variables; otherwise you still do on Solaris 10. > > The only thing outdated in that post to my knowledge is > CFLAGS=-D_POSIX_PTHREAD_SEMANTICS and possibly the mono-service issue. > Jonel's blog on the -mt pkg-config issue is almost three years old and > mostly still applies due to the long lifetime of S10. :) > AS=gas for instance was only needed for running `make check` so you > won't notice during plain `make`. > > Andreas > > > From kumpera at gmail.com Sun Oct 5 21:33:17 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Sun, 5 Oct 2008 22:33:17 -0300 Subject: [Mono-dev] [PATCH] bug 431001: Exception using XmlTextReader In-Reply-To: References: Message-ID: <8cca42d80810051833j1bab9c92w59038ba0cc04f85d@mail.gmail.com> Hi Brian, The usual way to post patches for existing bugs in to use bugzilla. But posting to the mailing list is ok. But since your have already posted it to bugzilla, there is no need to re do it on the mailing list as maintainers monitor its activity and would have seen it. Anyway, about your patch, catching ObjectDisposedException is not the way to fix it as this is just a hack around the root of the issue. This has severe performance implication as well, as exception handling is one of the slowest parts of the VM. Rodrigo 2008/10/2 Brian Browning > This is my first time contributing to mono, so let me know if this looks > ok, or if I did something wrong please. > > This patch handles the exception, passes the test case given in the bug > report, and it passes all current tests. > My only fear is that there is some detail of XmlSchema and XmlTextReader > that I am overlooking that needs to be handled. > > Thanks, > Brian > > > _______________________________________________ > 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/20081005/2c31903c/attachment.html From mike at middlesoft.co.uk Mon Oct 6 04:08:35 2008 From: mike at middlesoft.co.uk (Michael Barker) Date: Mon, 6 Oct 2008 21:08:35 +1300 Subject: [Mono-dev] [PATCH] System.Messaging using AMQP (RabbitMQ) Message-ID: <80d1dfde0810060108j62b1198egd0a61a3e29fcb12a@mail.gmail.com> Hi, Patch attached bugzilla report. https://bugzilla.novell.com/show_bug.cgi?id=432471 Regards, Michael Barker. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081006/c1ca3924/attachment-0001.html From pablosantosluac at terra.es Mon Oct 6 09:08:11 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Mon, 06 Oct 2008 15:08:11 +0200 Subject: [Mono-dev] Using using System.Threading namespace Message-ID: <48EA0DBB.5010502@terra.es> Hi, I'd like to try System.Threading and System.Threading.Collections on Linux to work a little bit with "ParallelFX". Is it going to be included together with the mono sources or should I just go to the Mono GSoc repository? Thanks, pablo From pablosantosluac at terra.es Mon Oct 6 16:17:27 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Mon, 06 Oct 2008 22:17:27 +0200 Subject: [Mono-dev] Mono 2.0 download Message-ID: <48EA7257.3050004@terra.es> Hi, Provided I'm right, the downloads page is still pointing to the old yast repositories for OpenSUSE... http://ftp.novell.com/pub/mono/download-stable/suse-103-i586 Is that ok? It will have an impact on new users trying to download the latest version. From ajorgensen at novell.com Mon Oct 6 16:41:45 2008 From: ajorgensen at novell.com (Andrew Jorgensen) Date: Mon, 06 Oct 2008 14:41:45 -0600 Subject: [Mono-dev] Mono 2.0 download Message-ID: <48EA23A90200004000040233@lucius.provo.novell.com> As we announced before we are only producing binaries for openSUSE 11.0 SUSE Linux Enterprise 10 Windows Mac OS X We have left up the old repositories for now. We may remove them around the 2.2 release cycle. >>> "pablosantosluac at terra.es" 10/06/08 2:18 PM >>> Hi, Provided I'm right, the downloads page is still pointing to the old yast repositories for OpenSUSE... http://ftp.novell.com/pub/mono/download-stable/suse-103-i586 Is that ok? It will have an impact on new users trying to download the latest version. _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From kev.clark7 at googlemail.com Mon Oct 6 19:16:12 2008 From: kev.clark7 at googlemail.com (Kevin Clark) Date: Tue, 7 Oct 2008 00:16:12 +0100 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: <48EA23A90200004000040233@lucius.provo.novell.com> References: <48EA23A90200004000040233@lucius.provo.novell.com> Message-ID: 2008/10/6 Andrew Jorgensen > As we announced before we are only producing binaries for > > openSUSE 11.0 > SUSE Linux Enterprise 10 > Windows > Mac OS X > > We have left up the old repositories for now. We may remove them around > the 2.2 release cycle. > Jezz.... way to alienate the user base. Ive been using Mono for a number of years, and one of my main reasons for using SuSe/openSuse was due to the fact that Novell always made sure that the mono releases were availble for the last couple of suse releases. Now Im faced with either upgrading to 11.0 or setting a day aside to build mono from source, and loose the system maintained updates. Thanks for that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081007/a0e42916/attachment.html From pablosantosluac at terra.es Mon Oct 6 19:26:23 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Tue, 07 Oct 2008 01:26:23 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48E9209F.7080406@terra.es> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E7F889.7030603@terra.es> <48E8A1BD.20600@web.de> <48E9209F.7080406@terra.es> Message-ID: <48EA9E9F.4060801@terra.es> Hi Andreas, all, I gave up trying to build on Solaris 10, since it seems it has some sort of problem. I switched to OpenSolaris. I've just downloaded the latest OpenSolaris release, installed it and add some required packages like gcc, libtool, gmake, bison and glib2 from blastwave. Removed mcs executable. Then I also had to install SUNWhea to have includes since the default 2008.05 opensolaris CD doesn't include them. I also installed: SUNWarc, SUNWscp and SUNWxinc. Then I donwloaded a tar.gz mono-2.0 source code release. ./configure worked "gmake" worked until hitting the mcs stuff... Installed mono 1.1.13.8 from blastwave. Run make again and got the following error. If you look carefully you'll see there's (again) a problem locating mscorlib.dll, this time after being able to build a bunch of c-sharp code... ../../jay/jay: 3 rules never reduced ../../jay/jay: 1 shift/reduce conflict, 46 reduce/reduce conflicts. echo "#define XSLT_PATTERN" > Mono.Xml.Xsl/PatternTokenizer.cs cat System.Xml.XPath/Tokenizer.cs >>Mono.Xml.Xsl/PatternTokenizer.cs MONO_PATH="../../class/lib/basic:$MONO_PATH" /export/home/pablo/mono-2.0/runtime/mono-wrapper ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -r:mscorlib.dll -r:System.dll -nowarn:0162,0618,0612,0642,1595 -target:library -out:System.Xml.dll System.Xml.XPath/Parser.cs Mono.Xml.Xsl/PatternParser.cs Mono.Xml.Xsl/PatternTokenizer.cs @System.Xml.dll.sources GC Warning: Large stack limit(133464064): only scanning 8 MB The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `/opt/mono/lib/mono/1.0/mscorlib.dll' directory. gmake[8]: *** [../../class/lib/basic/System.Xml.dll] Error 1 gmake[8]: Leaving directory `/export/home/pablo/mono-2.0/mcs/class/System.XML' gmake[7]: *** [do-all] Error 2 gmake[7]: Leaving directory `/export/home/pablo/mono-2.0/mcs/class/System.XML' gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory `/export/home/pablo/mono-2.0/mcs/class' gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory `/export/home/pablo/mono-2.0/mcs' gmake[4]: *** [profile-do--basic--all] Error 2 gmake[4]: Leaving directory `/export/home/pablo/mono-2.0/mcs' gmake[3]: *** [profiles-do--all] Error 2 gmake[3]: Leaving directory `/export/home/pablo/mono-2.0/mcs' gmake[2]: *** [all-local] Error 2 gmake[2]: Leaving directory `/export/home/pablo/mono-2.0/runtime' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/export/home/pablo/mono-2.0' gmake: *** [all] Error 2 Any help would be really (really) welcomed... pablo pablosantosluac at terra.es escribi?: > Andreas, > > I just followed your instructions, step by step. First downloaded and > installed gc-7.1 (worked perfectly), then configure and make mono. But > I'm afraid I think I'm reaching the same point. > > > Here's the ouput. At some point (it seems it happens after compiling > some c# code) it starts complaining about mscorlib location... > > > gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/build' > gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/build' > gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/jay' > gmake all-local > gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/jay' > gmake[7]: Nothing to be done for `all-local'. > gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/jay' > gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/jay' > gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/mcs' > gmake all-local > gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/mcs' > mcs /codepage:65001 -optimize -d:NET_1_1 -d:ONLY_1_1 > -d:BOOTSTRAP_WITH_OLDLIB -debug -target:exe -out:mcs.exe cs-parser.cs > @mcs.exe.sources > GC Warning: Large stack limit(133464064): only scanning 8 MB > cs-parser.cs(6665,7): warning CS0162: Unreachable code detected > cs-parser.cs(6667,5): warning CS0162: Unreachable code detected > expression.cs(991,14): warning CS0618: > `Mono.CSharp.UserOperatorCall.MakeSimpleCall(Mono.CSharp.EmitContext, > Mono.CSharp.MethodGroupExpr, Mono.CSharp.Expression, > Mono.CSharp.Location)' is obsolete: `It may not be compatible with > expression trees' > Compilation succeeded - 3 warning(s) > cp mcs.exe ../class/lib/basic/mcs.exe > test ! -f mcs.exe.mdb || cp mcs.exe.mdb ../class/lib/basic/mcs.exe.mdb > gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/mcs' > gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/mcs' > gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class' > gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' > gmake all-local > gmake[8]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' > mcs /codepage:65001 -nowarn:169,612,618,649 -d:INSIDE_CORLIB -optimize > -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -unsafe > -nostdlib -resource:resources/collation.core.bin > -resource:resources/collation.tailoring.bin > -resource:resources/collation.cjkCHS.bin > -resource:resources/collation.cjkCHT.bin > -resource:resources/collation.cjkJA.bin > -resource:resources/collation.cjkKO.bin > -resource:resources/collation.cjkKOlv2.bin -target:library > -out:mscorlib.dll @corlib.dll.sources > GC Warning: Large stack limit(133464064): only scanning 8 MB > System/WindowsConsoleDriver.cs(29,1): warning CS1635: Cannot restore > warning `CS0169' because it was disabled globally > System.Security.Cryptography/PasswordDeriveBytes.cs(231,1): warning > CS1691: `809' is not a valid warning number > System.Security.Cryptography/PasswordDeriveBytes.cs(237,1): warning > CS1691: `809' is not a valid warning number > System/Int16.cs(178,3): warning CS0162: Unreachable code detected > System/Int32.cs(200,3): warning CS0162: Unreachable code detected > System/Int64.cs(181,3): warning CS0162: Unreachable code detected > System/String.cs(946,6): warning CS0162: Unreachable code detected > System/String.cs(1049,6): warning CS0162: Unreachable code detected > Mono.Globalization.Unicode/Normalization.cs(76,36): warning CS0162: > Unreachable code detected > Compilation succeeded - 9 warning(s) > : mscorlib.dll ../../class/mono.snk > mv mscorlib.dll ../../class/lib/basic/mscorlib.dll > test ! -f mscorlib.dll.mdb || mv mscorlib.dll.mdb > ../../class/lib/basic/mscorlib.dll.mdb > test ! -f mscorlib.pdb || mv mscorlib.pdb ../../class/lib/basic/mscorlib.pdb > gmake[8]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' > gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' > gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/System' > gmake all-local > gmake[8]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/System' > ** Warning: System.dll built without parts that depend on: System.Xml.dll > MONO_PATH="../../class/lib/basic:$MONO_PATH" > /home/pablo/mono/mono-2.0/runtime/mono-wrapper > ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 > -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -target:library > -out:System.dll @System.dll.sources > The assembly mscorlib.dll was not found or could not be loaded. > It should have been installed in the > `/opt/mono/lib/mono/1.0/mscorlib.dll' directory. > gmake[8]: *** [../../class/lib/basic/System.dll] Error 1 > gmake[8]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/System' > gmake[7]: *** [do-all] Error 2 > gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/System' > gmake[6]: *** [all-recursive] Error 1 > gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class' > gmake[5]: *** [all-recursive] Error 1 > gmake[5]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' > gmake[4]: *** [profile-do--basic--all] Error 2 > gmake[4]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' > gmake[3]: *** [profiles-do--all] Error 2 > gmake[3]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' > gmake[2]: *** [all-local] Error 2 > gmake[2]: Leaving directory `/home/pablo/mono/mono-2.0/runtime' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/home/pablo/mono/mono-2.0' > gmake: *** [all] Error 2 > > > -bash-3.00$ uname -a > SunOS unknown 5.10 Generic_127128-11 i86pc i386 i86pc > > > Thanks again for your help > > pablo > > > > > Andreas F?rber escribi?: > >> pablosantosluac at terra.es schrieb: >> >>> Well, it seems building the "core" is not hard if you make sure (on >>> Solaris 10) that you use GNU packages and not the SUN ones (gmake, >>> libtool, and everything else). I can build "mono" from trunk or 2-0. >>> but the problems start with mcs... I'm now following the instructions >>> sent by Geoff (basically using >>> http://mono.ximian.com/monobuild/preview/sources/mono/mono-2.0.tar.bz2). >>> >> Having the runtime compile does not imply it'll work at runtime... >> Whether you use a tarball or monolite usually doesn't matter, but if >> you can, a tarball is "safer". >> >> Fwiw, I've just finished compiling mono at r114845+mcs@r114882 from >> mono at r109531+mcs@r109587 (all trunk) on OpenSolaris build 95 for i86 >> using exactly this: >> >> ../mono/configure --prefix=/opt/mono --with-gc=boehm \ >> --with-sigaltstack=no \ >> CPPFLAGS="-I/opt/mono-gc/include" \ >> LDFLAGS="-L/opt/mono-gc/lib -R/opt/mono/lib" >> >> where /opt/mono-gc is the prefix of Boehm GC 7.1, compiled with: >> >> ../gc-7.1/configure --prefix=/opt/mono-gc >> >> Works nicely there. Don't have access to S10 from here though to fetch >> my scripts or to try the latest revs there. >> >> On OpenSolaris/amd64, I use these on top: >> >> PREFIX=/opt/mono-gc >> >> ../gc-7.1/configure --prefix=$PREFIX --libdir=$PREFIX/lib/amd64 \ >> CPPFLAGS=-m64 CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 >> >> and: >> >> PREFIX=/opt/mono >> >> ../mono/configure --prefix=$PREFIX --bindir=$PREFIX/bin/amd64 >> --libdir=$PREFIX/lib/amd64 \ >> --with-gc=boehm --with-sigaltstack=no --enable-big-arrays >> --enable-dtrace --disable-mcs-build \ >> CPPFLAGS="-m64 -I/opt/mono-gc/include" CFLAGS="-m64" \ >> LDFLAGS="-m64 -L/opt/mono-gc/lib/amd64 -R/opt/mono/lib/amd64" \ >> PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig:$PKG_CONFIG_PATH" >> >> (Obviously I'm skipping mcs build in this script, but I've done full >> amd64 bootstraps before with post-2.0 revisions.) >> >> Note that I use dedicated /opt subdirs because that's where 3rdparty >> packages are often installed on Solarises, making it easy to rename or >> remove. $prefix/{bin,lib}/amd64 is where Sun places their amd64 files. >> >> Using a monolite from 12:05 GMT+02:00 today (with Sun's `mcs` renamed), >> there are no problems on OSol/i86 either. >> So it's definitely not mcs's or monolite's fault!!! >> >> >> >>>> Cetin actually mentioned OpenSolaris as opposed to Solaris 10. When >>>> OpenSolaris 2008.05 was released I posted the following mini-guide: >>>> http://lists.ximian.com/pipermail/mono-list/2008-May/038584.html >>>> >>>> It was actually supposed to avoid questions later on. ;) >>>> >>>> >>> Following this guide the only thing I realize I missed is the LDFLAGS >>> stuff? Is it the reason why mcs.exe can't be run? >>> >> In case you mean LDFLAGS=-R/path then no, it has no influence on mcs. It >> helps with MD (libPosixHelper.so et al.). >> >> >>>> The often-referenced http://www.mono-project.com/Mono:Solaris page >>>> contains a link to another post of mine, for Solaris 10: >>>> http://lists.ximian.com/pipermail/mono-list/2007-January/034101.html >>>> >>>> >>> Yes, this guide was helpful building 1.1.13 (almost two years ago >>> already), but now all those tricks are not needed anymore... You can >>> get the whole c code build easily... >>> >> If you build using Blastwave tools you don't need some of the >> environment variables; otherwise you still do on Solaris 10. >> >> The only thing outdated in that post to my knowledge is >> CFLAGS=-D_POSIX_PTHREAD_SEMANTICS and possibly the mono-service issue. >> Jonel's blog on the -mt pkg-config issue is almost three years old and >> mostly still applies due to the long lifetime of S10. :) >> AS=gas for instance was only needed for running `make check` so you >> won't notice during plain `make`. >> >> Andreas >> >> >> >> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From pablosantosluac at terra.es Mon Oct 6 20:12:33 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Tue, 07 Oct 2008 02:12:33 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48EA9E9F.4060801@terra.es> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E7F889.7030603@terra.es> <48E8A1BD.20600@web.de> <48E9209F.7080406@terra.es> <48EA9E9F.4060801@terra.es> Message-ID: <48EAA971.4000101@terra.es> Hi, Do you think the problem can be related to the "profiles"? I mean, it seems I can't try to use a 2.0 profile, only a 1.1, and as soon as it tries 2.0 it fails... Is that possible? pablosantosluac at terra.es escribi?: > Hi Andreas, all, > > I gave up trying to build on Solaris 10, since it seems it has some sort > of problem. > > I switched to OpenSolaris. > > I've just downloaded the latest OpenSolaris release, installed it and > add some required packages like gcc, libtool, gmake, bison and glib2 > from blastwave. > > Removed mcs executable. > > Then I also had to install SUNWhea to have includes since the default > 2008.05 opensolaris CD doesn't include them. > > I also installed: SUNWarc, SUNWscp and SUNWxinc. > > Then I donwloaded a tar.gz mono-2.0 source code release. > > ./configure worked > > "gmake" worked until hitting the mcs stuff... > > Installed mono 1.1.13.8 from blastwave. > > Run make again and got the following error. If you look carefully you'll > see there's (again) a problem locating mscorlib.dll, this time after > being able to build a bunch of c-sharp code... > > ../../jay/jay: 3 rules never reduced > ../../jay/jay: 1 shift/reduce conflict, 46 reduce/reduce conflicts. > echo "#define XSLT_PATTERN" > Mono.Xml.Xsl/PatternTokenizer.cs > cat System.Xml.XPath/Tokenizer.cs >>Mono.Xml.Xsl/PatternTokenizer.cs > MONO_PATH="../../class/lib/basic:$MONO_PATH" > /export/home/pablo/mono-2.0/runtime/mono-wrapper > ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 > -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -r:mscorlib.dll > -r:System.dll -nowarn:0162,0618,0612,0642,1595 -target:library > -out:System.Xml.dll System.Xml.XPath/Parser.cs > Mono.Xml.Xsl/PatternParser.cs Mono.Xml.Xsl/PatternTokenizer.cs > @System.Xml.dll.sources > GC Warning: Large stack limit(133464064): only scanning 8 MB > The assembly mscorlib.dll was not found or could not be loaded. > It should have been installed in the > `/opt/mono/lib/mono/1.0/mscorlib.dll' directory. > gmake[8]: *** [../../class/lib/basic/System.Xml.dll] Error 1 > gmake[8]: Leaving directory > `/export/home/pablo/mono-2.0/mcs/class/System.XML' > gmake[7]: *** [do-all] Error 2 > gmake[7]: Leaving directory > `/export/home/pablo/mono-2.0/mcs/class/System.XML' > gmake[6]: *** [all-recursive] Error 1 > gmake[6]: Leaving directory `/export/home/pablo/mono-2.0/mcs/class' > gmake[5]: *** [all-recursive] Error 1 > gmake[5]: Leaving directory `/export/home/pablo/mono-2.0/mcs' > gmake[4]: *** [profile-do--basic--all] Error 2 > gmake[4]: Leaving directory `/export/home/pablo/mono-2.0/mcs' > gmake[3]: *** [profiles-do--all] Error 2 > gmake[3]: Leaving directory `/export/home/pablo/mono-2.0/mcs' > gmake[2]: *** [all-local] Error 2 > gmake[2]: Leaving directory `/export/home/pablo/mono-2.0/runtime' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/export/home/pablo/mono-2.0' > gmake: *** [all] Error 2 > > Any help would be really (really) welcomed... > > pablo > > > pablosantosluac at terra.es escribi?: > >> Andreas, >> >> I just followed your instructions, step by step. First downloaded and >> installed gc-7.1 (worked perfectly), then configure and make mono. But >> I'm afraid I think I'm reaching the same point. >> >> >> Here's the ouput. At some point (it seems it happens after compiling >> some c# code) it starts complaining about mscorlib location... >> >> >> gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/build' >> gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/build' >> gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/jay' >> gmake all-local >> gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/jay' >> gmake[7]: Nothing to be done for `all-local'. >> gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/jay' >> gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/jay' >> gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/mcs' >> gmake all-local >> gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/mcs' >> mcs /codepage:65001 -optimize -d:NET_1_1 -d:ONLY_1_1 >> -d:BOOTSTRAP_WITH_OLDLIB -debug -target:exe -out:mcs.exe cs-parser.cs >> @mcs.exe.sources >> GC Warning: Large stack limit(133464064): only scanning 8 MB >> cs-parser.cs(6665,7): warning CS0162: Unreachable code detected >> cs-parser.cs(6667,5): warning CS0162: Unreachable code detected >> expression.cs(991,14): warning CS0618: >> `Mono.CSharp.UserOperatorCall.MakeSimpleCall(Mono.CSharp.EmitContext, >> Mono.CSharp.MethodGroupExpr, Mono.CSharp.Expression, >> Mono.CSharp.Location)' is obsolete: `It may not be compatible with >> expression trees' >> Compilation succeeded - 3 warning(s) >> cp mcs.exe ../class/lib/basic/mcs.exe >> test ! -f mcs.exe.mdb || cp mcs.exe.mdb ../class/lib/basic/mcs.exe.mdb >> gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/mcs' >> gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/mcs' >> gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class' >> gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' >> gmake all-local >> gmake[8]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' >> mcs /codepage:65001 -nowarn:169,612,618,649 -d:INSIDE_CORLIB -optimize >> -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -unsafe >> -nostdlib -resource:resources/collation.core.bin >> -resource:resources/collation.tailoring.bin >> -resource:resources/collation.cjkCHS.bin >> -resource:resources/collation.cjkCHT.bin >> -resource:resources/collation.cjkJA.bin >> -resource:resources/collation.cjkKO.bin >> -resource:resources/collation.cjkKOlv2.bin -target:library >> -out:mscorlib.dll @corlib.dll.sources >> GC Warning: Large stack limit(133464064): only scanning 8 MB >> System/WindowsConsoleDriver.cs(29,1): warning CS1635: Cannot restore >> warning `CS0169' because it was disabled globally >> System.Security.Cryptography/PasswordDeriveBytes.cs(231,1): warning >> CS1691: `809' is not a valid warning number >> System.Security.Cryptography/PasswordDeriveBytes.cs(237,1): warning >> CS1691: `809' is not a valid warning number >> System/Int16.cs(178,3): warning CS0162: Unreachable code detected >> System/Int32.cs(200,3): warning CS0162: Unreachable code detected >> System/Int64.cs(181,3): warning CS0162: Unreachable code detected >> System/String.cs(946,6): warning CS0162: Unreachable code detected >> System/String.cs(1049,6): warning CS0162: Unreachable code detected >> Mono.Globalization.Unicode/Normalization.cs(76,36): warning CS0162: >> Unreachable code detected >> Compilation succeeded - 9 warning(s) >> : mscorlib.dll ../../class/mono.snk >> mv mscorlib.dll ../../class/lib/basic/mscorlib.dll >> test ! -f mscorlib.dll.mdb || mv mscorlib.dll.mdb >> ../../class/lib/basic/mscorlib.dll.mdb >> test ! -f mscorlib.pdb || mv mscorlib.pdb ../../class/lib/basic/mscorlib.pdb >> gmake[8]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' >> gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/corlib' >> gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/System' >> gmake all-local >> gmake[8]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class/System' >> ** Warning: System.dll built without parts that depend on: System.Xml.dll >> MONO_PATH="../../class/lib/basic:$MONO_PATH" >> /home/pablo/mono/mono-2.0/runtime/mono-wrapper >> ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 >> -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -target:library >> -out:System.dll @System.dll.sources >> The assembly mscorlib.dll was not found or could not be loaded. >> It should have been installed in the >> `/opt/mono/lib/mono/1.0/mscorlib.dll' directory. >> gmake[8]: *** [../../class/lib/basic/System.dll] Error 1 >> gmake[8]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/System' >> gmake[7]: *** [do-all] Error 2 >> gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class/System' >> gmake[6]: *** [all-recursive] Error 1 >> gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class' >> gmake[5]: *** [all-recursive] Error 1 >> gmake[5]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' >> gmake[4]: *** [profile-do--basic--all] Error 2 >> gmake[4]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' >> gmake[3]: *** [profiles-do--all] Error 2 >> gmake[3]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' >> gmake[2]: *** [all-local] Error 2 >> gmake[2]: Leaving directory `/home/pablo/mono/mono-2.0/runtime' >> gmake[1]: *** [all-recursive] Error 1 >> gmake[1]: Leaving directory `/home/pablo/mono/mono-2.0' >> gmake: *** [all] Error 2 >> >> >> -bash-3.00$ uname -a >> SunOS unknown 5.10 Generic_127128-11 i86pc i386 i86pc >> >> >> Thanks again for your help >> >> pablo >> >> >> >> >> Andreas F?rber escribi?: >> >> >>> pablosantosluac at terra.es schrieb: >>> >>> >>>> Well, it seems building the "core" is not hard if you make sure (on >>>> Solaris 10) that you use GNU packages and not the SUN ones (gmake, >>>> libtool, and everything else). I can build "mono" from trunk or 2-0. >>>> but the problems start with mcs... I'm now following the instructions >>>> sent by Geoff (basically using >>>> http://mono.ximian.com/monobuild/preview/sources/mono/mono-2.0.tar.bz2). >>>> >>>> >>> Having the runtime compile does not imply it'll work at runtime... >>> Whether you use a tarball or monolite usually doesn't matter, but if >>> you can, a tarball is "safer". >>> >>> Fwiw, I've just finished compiling mono at r114845+mcs@r114882 from >>> mono at r109531+mcs@r109587 (all trunk) on OpenSolaris build 95 for i86 >>> using exactly this: >>> >>> ../mono/configure --prefix=/opt/mono --with-gc=boehm \ >>> --with-sigaltstack=no \ >>> CPPFLAGS="-I/opt/mono-gc/include" \ >>> LDFLAGS="-L/opt/mono-gc/lib -R/opt/mono/lib" >>> >>> where /opt/mono-gc is the prefix of Boehm GC 7.1, compiled with: >>> >>> ../gc-7.1/configure --prefix=/opt/mono-gc >>> >>> Works nicely there. Don't have access to S10 from here though to fetch >>> my scripts or to try the latest revs there. >>> >>> On OpenSolaris/amd64, I use these on top: >>> >>> PREFIX=/opt/mono-gc >>> >>> ../gc-7.1/configure --prefix=$PREFIX --libdir=$PREFIX/lib/amd64 \ >>> CPPFLAGS=-m64 CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 >>> >>> and: >>> >>> PREFIX=/opt/mono >>> >>> ../mono/configure --prefix=$PREFIX --bindir=$PREFIX/bin/amd64 >>> --libdir=$PREFIX/lib/amd64 \ >>> --with-gc=boehm --with-sigaltstack=no --enable-big-arrays >>> --enable-dtrace --disable-mcs-build \ >>> CPPFLAGS="-m64 -I/opt/mono-gc/include" CFLAGS="-m64" \ >>> LDFLAGS="-m64 -L/opt/mono-gc/lib/amd64 -R/opt/mono/lib/amd64" \ >>> PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig:$PKG_CONFIG_PATH" >>> >>> (Obviously I'm skipping mcs build in this script, but I've done full >>> amd64 bootstraps before with post-2.0 revisions.) >>> >>> Note that I use dedicated /opt subdirs because that's where 3rdparty >>> packages are often installed on Solarises, making it easy to rename or >>> remove. $prefix/{bin,lib}/amd64 is where Sun places their amd64 files. >>> >>> Using a monolite from 12:05 GMT+02:00 today (with Sun's `mcs` renamed), >>> there are no problems on OSol/i86 either. >>> So it's definitely not mcs's or monolite's fault!!! >>> >>> >>> >>> >>>>> Cetin actually mentioned OpenSolaris as opposed to Solaris 10. When >>>>> OpenSolaris 2008.05 was released I posted the following mini-guide: >>>>> http://lists.ximian.com/pipermail/mono-list/2008-May/038584.html >>>>> >>>>> It was actually supposed to avoid questions later on. ;) >>>>> >>>>> >>>>> >>>> Following this guide the only thing I realize I missed is the LDFLAGS >>>> stuff? Is it the reason why mcs.exe can't be run? >>>> >>>> >>> In case you mean LDFLAGS=-R/path then no, it has no influence on mcs. It >>> helps with MD (libPosixHelper.so et al.). >>> >>> >>> >>>>> The often-referenced http://www.mono-project.com/Mono:Solaris page >>>>> contains a link to another post of mine, for Solaris 10: >>>>> http://lists.ximian.com/pipermail/mono-list/2007-January/034101.html >>>>> >>>>> >>>>> >>>> Yes, this guide was helpful building 1.1.13 (almost two years ago >>>> already), but now all those tricks are not needed anymore... You can >>>> get the whole c code build easily... >>>> >>>> >>> If you build using Blastwave tools you don't need some of the >>> environment variables; otherwise you still do on Solaris 10. >>> >>> The only thing outdated in that post to my knowledge is >>> CFLAGS=-D_POSIX_PTHREAD_SEMANTICS and possibly the mono-service issue. >>> Jonel's blog on the -mt pkg-config issue is almost three years old and >>> mostly still applies due to the long lifetime of S10. :) >>> AS=gas for instance was only needed for running `make check` so you >>> won't notice during plain `make`. >>> >>> Andreas >>> >>> >>> >>> >>> >> _______________________________________________ >> 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 ajorgensen at novell.com Tue Oct 7 00:56:52 2008 From: ajorgensen at novell.com (Andrew Jorgensen) Date: Mon, 06 Oct 2008 22:56:52 -0600 Subject: [Mono-dev] Mono 2.0 download Message-ID: <48EA97B402000040000402F2@lucius.provo.novell.com> The original announcement about that is here: http://lists.ximian.com/pipermail/mono-devel-list/2008-September/029144.html It would not be terribly difficult to make 2.0 available for 10.3 but we must be clear on the point that it is not tested and therefore not supported. We don't want to alienate you but we also won't be held resposible if a 10.3 build of Mono 2.0 causes minor skin irritation. :-) Because you asked so politely I'm enabling the openSUSE_10.3 builds in the Mono OBS project. It will be a while before they are built and published. UNSUPPORTED: http://download.opensuse.org/repositories/Mono/openSUSE_10.3/ Please do consider upgrading to 11.0. It's a solid release with vastly improved package management among other things. Best Regards, Andrew Jorgensen PS: Any 10.3 builds are unofficial and unsupported, got it? Good. PPS: There's a good chance they'll work just fine. PPPS: Don't tell anyone I said so though. >>> "Kevin Clark" 10/06/08 5:16 PM >>> Jezz.... way to alienate the user base. Ive been using Mono for a number of years, and one of my main reasons for using SuSe/openSuse was due to the fact that Novell always made sure that the mono releases were availble for the last couple of suse releases. Now Im faced with either upgrading to 11.0 or setting a day aside to build mono from source, and loose the system maintained updates. Thanks for that. From kev.clark7 at googlemail.com Tue Oct 7 01:48:23 2008 From: kev.clark7 at googlemail.com (Kevin Clark) Date: Tue, 7 Oct 2008 06:48:23 +0100 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: <48EA97B402000040000402F2@lucius.provo.novell.com> References: <48EA97B402000040000402F2@lucius.provo.novell.com> Message-ID: 2008/10/7 Andrew Jorgensen > The original announcement about that is here: > > http://lists.ximian.com/pipermail/mono-devel-list/2008-September/029144.html > > It would not be terribly difficult to make 2.0 available for 10.3 but we > must be clear on the point that it is not tested and therefore not > supported. We don't want to alienate you but we also won't be held > resposible if a 10.3 build of Mono 2.0 causes minor skin irritation. :-) > > Because you asked so politely I'm enabling the openSUSE_10.3 builds in the > Mono OBS project. It will be a while before they are built and published. > > UNSUPPORTED: http://download.opensuse.org/repositories/Mono/openSUSE_10.3/ > > Please do consider upgrading to 11.0. It's a solid release with vastly > improved package management among other things. > > Best Regards, > Andrew Jorgensen > > PS: Any 10.3 builds are unofficial and unsupported, got it? Good. > PPS: There's a good chance they'll work just fine. > PPPS: Don't tell anyone I said so though. > > Wow, I didn't actually believe you would just put 10.3 back in there, but thats excellent news, it's very much appreciated, and I'm sure others will feel so too. Sorry about the abruptness, it had been a very long day, and its easy to just bash out what you're thinking. I would upgrade to 11.0, but I generally wait for the ##.1 releases after the whole problems that where experienced with the 10.0 release; and also I have to make sure all apps still work the same way in the new OS release, otherwise I alienate the wife from Linux adoption. I take your point with the lack of testing for 10.3, and I will test with mono 2.0 on that basis. But thanks again for enabling this! Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081007/561f8bc2/attachment.html From atsushi at ximian.com Tue Oct 7 06:28:55 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Tue, 07 Oct 2008 19:28:55 +0900 Subject: [Mono-dev] [PATCH] System.Messaging using AMQP (RabbitMQ) In-Reply-To: <80d1dfde0810060108j62b1198egd0a61a3e29fcb12a@mail.gmail.com> References: <80d1dfde0810060108j62b1198egd0a61a3e29fcb12a@mail.gmail.com> Message-ID: <48EB39E7.7080803@ximian.com> Hi, Thanks a lot for the updated implementation since April :) I had a look at the patch, and noticed that some essential stuff such as MessageQueue.GetEnumerator() and MessageEnumerator are left unimplemented. I'm still not sure we want to go this patch way, especiall on your Mono.Messaging API (this does not mean, I don't like it; I'm just unsure). Probably we need more stuff there, as we will also have to implement those not-yet-implemented things there. Probably, someone can join the effort to verify the API by adding Win32API-based implementation? (Like Gert's Win32Registory API) BTW do you know if AMQP/Rabbit is going to support message peek and receive-by-id functionality (in some milestones), as you mentioned in the early discussion ? http://www.mail-archive.com/mono-devel-list at lists.ximian.com/msg16731.html Atsushi Eno Michael Barker wrote: > Hi, > > Patch attached bugzilla report. > > https://bugzilla.novell.com/show_bug.cgi?id=432471 > > Regards, > Michael Barker. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From robertj at gmx.net Tue Oct 7 07:09:08 2008 From: robertj at gmx.net (Robert Jordan) Date: Tue, 07 Oct 2008 13:09:08 +0200 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: <48EA97B402000040000402F2@lucius.provo.novell.com> References: <48EA97B402000040000402F2@lucius.provo.novell.com> Message-ID: Hi Andrew, Andrew Jorgensen wrote: > The original announcement about that is here: > http://lists.ximian.com/pipermail/mono-devel-list/2008-September/029144.html > > It would not be terribly difficult to make 2.0 available for 10.3 but we must be clear on the point that it is not tested and therefore not supported. We don't want to alienate you but we also won't be held resposible if a 10.3 build of Mono 2.0 causes minor skin irritation. :-) > > Because you asked so politely I'm enabling the openSUSE_10.3 builds in the Mono OBS project. It will be a while before they are built and published. > > UNSUPPORTED: http://download.opensuse.org/repositories/Mono/openSUSE_10.3/ There seems to be a problem with this repo: # cat /etc/SuSE-release openSUSE 10.3 (i586) VERSION = 10.3 # zypper sa --repo http://download.opensuse.org/repositories/Mono/openSUSE_10.3/Mono.repo * Adding repository 'Mono Project (openSUSE_10.3)' Repository 'Mono Project (openSUSE_10.3)' successfully added: Enabled: Yes Autorefresh: No URL: http://download.opensuse.org/repositories/Mono/openSUSE_10.3/ # zypper refresh Repository 'Mono Project (openSUSE_10.3)' is up to date. * Building repository 'Mono Project (openSUSE_10.3)' cache Error building the cache database: Parse error Skipping repository 'Mono Project (openSUSE_10.3)' because of the above error. Robert From mousse_man at hotmail.com Tue Oct 7 09:45:44 2008 From: mousse_man at hotmail.com (FirstName LastName) Date: Tue, 7 Oct 2008 13:45:44 +0000 Subject: [Mono-dev] Mono crashes when using callbacks from unmanaged to managed world Message-ID: Hi, I have been doing some tests with Mono quite a while. I'm working with Mono on a ARM. When I try to call a managed callback from the unmanaged world in a unmanaged thread, I get the following: ** ERROR **: file mini.c: line 10315 (mono_get_lmf_addr): should not be reached When I try to call a managed callback from the unmanaged world in a managed thread (actually, in the caller's thread which is managed), it is ok. When I run this on Ubuntu on a X86, I don't get this. Any ideas why? _________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081007/061c6666/attachment.html From listasdavid at codicesoftware.com Tue Oct 7 10:01:50 2008 From: listasdavid at codicesoftware.com (David Suarez) Date: Tue, 7 Oct 2008 16:01:50 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48EAA971.4000101@terra.es> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E7F889.7030603@terra.es> <48E8A1BD.20600@web.de> <48E9209F.7080406@terra.es> <48EA9E9F.4060801@terra.es> <48EAA971.4000101@terra.es> Message-ID: <00a701c92885$3ff6a560$bfe3f020$@com> Hi, I tried too, and using monolite (or the latest mono binaries available on solaris, it's the same for both) I get this recurrent error: -bash-3.00$ /home/pablo/mono/mono/mono/mini/mono ../../class/lib/monolite/mcs.exe dave: /home/pablo/monobin/lib/mono/1.0/mscorlib.dll The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `/home/pablo/monobin/lib/mono/1.0/mscorlib.dll' directory. -bash-3.00$ export MONO_PATH=/home/pablo/mono/mcs/class/lib/monolite -bash-3.00$ /home/pablo/mono/mono/mono/mini/mono ../../class/lib/monolite/mcs.exe dave: /home/pablo/mono/mcs/class/lib/monolite/mscorlib.dll dave: /home/pablo/mono/mcs/class/lib/monolite/mono/1.0/mscorlib.dll dave: /home/pablo/monobin/lib/mono/1.0/mscorlib.dll The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `/home/pablo/monobin/lib/mono/1.0/mscorlib.dll' directory. -bash-3.00$ ll ../../class/lib/monolite/ total 10592 -rwxr-xr-x 1 pablo staff 288256 Oct 7 10:17 Mono.Security.dll -rwxr-xr-x 1 pablo staff 1111040 Oct 7 10:17 System.Xml.dll -rwxr-xr-x 1 pablo staff 850432 Oct 7 10:17 System.dll -rwxr-xr-x 1 pablo staff 1036800 Oct 7 10:17 mcs.exe -rwxr-xr-x 1 pablo staff 2078720 Oct 7 10:17 mscorlib.dll (I added some debug output to the mono load_in_path function in assembly.c in order to print the search paths, lines starting with "dave:") It seems that it's not able to load the mscorlib provided with monolite (at /home/pablo/mono/mcs/class/lib/monolite/mscorlib.dll) although it's trying to load that path. Is there any environment variable or argument that can be set anywhere to get the compiled mono to find corlib? > -----Original Message----- > From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list- > bounces at lists.ximian.com] On Behalf Of pablosantosluac at terra.es > Sent: Tuesday, October 07, 2008 2:13 AM > To: Andreas F?rber > Cc: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] mono 2.0, solaris x86, bootstrap > > Hi, > > Do you think the problem can be related to the "profiles"? I mean, it > seems I can't try to use a 2.0 profile, only a 1.1, and as soon as it > tries 2.0 it fails... Is that possible? > > pablosantosluac at terra.es escribi?: > > Hi Andreas, all, > > > > I gave up trying to build on Solaris 10, since it seems it has some > sort > > of problem. > > > > I switched to OpenSolaris. > > > > I've just downloaded the latest OpenSolaris release, installed it and > > add some required packages like gcc, libtool, gmake, bison and glib2 > > from blastwave. > > > > Removed mcs executable. > > > > Then I also had to install SUNWhea to have includes since the default > > 2008.05 opensolaris CD doesn't include them. > > > > I also installed: SUNWarc, SUNWscp and SUNWxinc. > > > > Then I donwloaded a tar.gz mono-2.0 source code release. > > > > ./configure worked > > > > "gmake" worked until hitting the mcs stuff... > > > > Installed mono 1.1.13.8 from blastwave. > > > > Run make again and got the following error. If you look carefully > you'll > > see there's (again) a problem locating mscorlib.dll, this time after > > being able to build a bunch of c-sharp code... > > > > ../../jay/jay: 3 rules never reduced > > ../../jay/jay: 1 shift/reduce conflict, 46 reduce/reduce conflicts. > > echo "#define XSLT_PATTERN" > Mono.Xml.Xsl/PatternTokenizer.cs > > cat System.Xml.XPath/Tokenizer.cs >>Mono.Xml.Xsl/PatternTokenizer.cs > > MONO_PATH="../../class/lib/basic:$MONO_PATH" > > /export/home/pablo/mono-2.0/runtime/mono-wrapper > > ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 > > -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig -r:mscorlib.dll > > -r:System.dll -nowarn:0162,0618,0612,0642,1595 -target:library > > -out:System.Xml.dll System.Xml.XPath/Parser.cs > > Mono.Xml.Xsl/PatternParser.cs Mono.Xml.Xsl/PatternTokenizer.cs > > @System.Xml.dll.sources > > GC Warning: Large stack limit(133464064): only scanning 8 MB > > The assembly mscorlib.dll was not found or could not be loaded. > > It should have been installed in the > > `/opt/mono/lib/mono/1.0/mscorlib.dll' directory. > > gmake[8]: *** [../../class/lib/basic/System.Xml.dll] Error 1 > > gmake[8]: Leaving directory > > `/export/home/pablo/mono-2.0/mcs/class/System.XML' > > gmake[7]: *** [do-all] Error 2 > > gmake[7]: Leaving directory > > `/export/home/pablo/mono-2.0/mcs/class/System.XML' > > gmake[6]: *** [all-recursive] Error 1 > > gmake[6]: Leaving directory `/export/home/pablo/mono-2.0/mcs/class' > > gmake[5]: *** [all-recursive] Error 1 > > gmake[5]: Leaving directory `/export/home/pablo/mono-2.0/mcs' > > gmake[4]: *** [profile-do--basic--all] Error 2 > > gmake[4]: Leaving directory `/export/home/pablo/mono-2.0/mcs' > > gmake[3]: *** [profiles-do--all] Error 2 > > gmake[3]: Leaving directory `/export/home/pablo/mono-2.0/mcs' > > gmake[2]: *** [all-local] Error 2 > > gmake[2]: Leaving directory `/export/home/pablo/mono-2.0/runtime' > > gmake[1]: *** [all-recursive] Error 1 > > gmake[1]: Leaving directory `/export/home/pablo/mono-2.0' > > gmake: *** [all] Error 2 > > > > Any help would be really (really) welcomed... > > > > pablo > > > > > > pablosantosluac at terra.es escribi?: > > > >> Andreas, > >> > >> I just followed your instructions, step by step. First downloaded > and > >> installed gc-7.1 (worked perfectly), then configure and make mono. > But > >> I'm afraid I think I'm reaching the same point. > >> > >> > >> Here's the ouput. At some point (it seems it happens after compiling > >> some c# code) it starts complaining about mscorlib location... > >> > >> > >> gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/build' > >> gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/build' > >> gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/jay' > >> gmake all-local > >> gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/jay' > >> gmake[7]: Nothing to be done for `all-local'. > >> gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/jay' > >> gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/jay' > >> gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/mcs' > >> gmake all-local > >> gmake[7]: Entering directory `/home/pablo/mono/mono-2.0/mcs/mcs' > >> mcs /codepage:65001 -optimize -d:NET_1_1 -d:ONLY_1_1 > >> -d:BOOTSTRAP_WITH_OLDLIB -debug -target:exe -out:mcs.exe cs- > parser.cs > >> @mcs.exe.sources > >> GC Warning: Large stack limit(133464064): only scanning 8 MB > >> cs-parser.cs(6665,7): warning CS0162: Unreachable code detected > >> cs-parser.cs(6667,5): warning CS0162: Unreachable code detected > >> expression.cs(991,14): warning CS0618: > >> > `Mono.CSharp.UserOperatorCall.MakeSimpleCall(Mono.CSharp.EmitContext, > >> Mono.CSharp.MethodGroupExpr, Mono.CSharp.Expression, > >> Mono.CSharp.Location)' is obsolete: `It may not be compatible with > >> expression trees' > >> Compilation succeeded - 3 warning(s) > >> cp mcs.exe ../class/lib/basic/mcs.exe > >> test ! -f mcs.exe.mdb || cp mcs.exe.mdb > ../class/lib/basic/mcs.exe.mdb > >> gmake[7]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/mcs' > >> gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/mcs' > >> gmake[6]: Entering directory `/home/pablo/mono/mono-2.0/mcs/class' > >> gmake[7]: Entering directory `/home/pablo/mono/mono- > 2.0/mcs/class/corlib' > >> gmake all-local > >> gmake[8]: Entering directory `/home/pablo/mono/mono- > 2.0/mcs/class/corlib' > >> mcs /codepage:65001 -nowarn:169,612,618,649 -d:INSIDE_CORLIB - > optimize > >> -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig - > unsafe > >> -nostdlib -resource:resources/collation.core.bin > >> -resource:resources/collation.tailoring.bin > >> -resource:resources/collation.cjkCHS.bin > >> -resource:resources/collation.cjkCHT.bin > >> -resource:resources/collation.cjkJA.bin > >> -resource:resources/collation.cjkKO.bin > >> -resource:resources/collation.cjkKOlv2.bin -target:library > >> -out:mscorlib.dll @corlib.dll.sources > >> GC Warning: Large stack limit(133464064): only scanning 8 MB > >> System/WindowsConsoleDriver.cs(29,1): warning CS1635: Cannot restore > >> warning `CS0169' because it was disabled globally > >> System.Security.Cryptography/PasswordDeriveBytes.cs(231,1): warning > >> CS1691: `809' is not a valid warning number > >> System.Security.Cryptography/PasswordDeriveBytes.cs(237,1): warning > >> CS1691: `809' is not a valid warning number > >> System/Int16.cs(178,3): warning CS0162: Unreachable code detected > >> System/Int32.cs(200,3): warning CS0162: Unreachable code detected > >> System/Int64.cs(181,3): warning CS0162: Unreachable code detected > >> System/String.cs(946,6): warning CS0162: Unreachable code detected > >> System/String.cs(1049,6): warning CS0162: Unreachable code detected > >> Mono.Globalization.Unicode/Normalization.cs(76,36): warning CS0162: > >> Unreachable code detected > >> Compilation succeeded - 9 warning(s) > >> : mscorlib.dll ../../class/mono.snk > >> mv mscorlib.dll ../../class/lib/basic/mscorlib.dll > >> test ! -f mscorlib.dll.mdb || mv mscorlib.dll.mdb > >> ../../class/lib/basic/mscorlib.dll.mdb > >> test ! -f mscorlib.pdb || mv mscorlib.pdb > ../../class/lib/basic/mscorlib.pdb > >> gmake[8]: Leaving directory `/home/pablo/mono/mono- > 2.0/mcs/class/corlib' > >> gmake[7]: Leaving directory `/home/pablo/mono/mono- > 2.0/mcs/class/corlib' > >> gmake[7]: Entering directory `/home/pablo/mono/mono- > 2.0/mcs/class/System' > >> gmake all-local > >> gmake[8]: Entering directory `/home/pablo/mono/mono- > 2.0/mcs/class/System' > >> ** Warning: System.dll built without parts that depend on: > System.Xml.dll > >> MONO_PATH="../../class/lib/basic:$MONO_PATH" > >> /home/pablo/mono/mono-2.0/runtime/mono-wrapper > >> ../../class/lib/basic/mcs.exe /codepage:65001 -optimize -d:NET_1_1 > >> -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB -debug /noconfig - > target:library > >> -out:System.dll @System.dll.sources > >> The assembly mscorlib.dll was not found or could not be loaded. > >> It should have been installed in the > >> `/opt/mono/lib/mono/1.0/mscorlib.dll' directory. > >> gmake[8]: *** [../../class/lib/basic/System.dll] Error 1 > >> gmake[8]: Leaving directory `/home/pablo/mono/mono- > 2.0/mcs/class/System' > >> gmake[7]: *** [do-all] Error 2 > >> gmake[7]: Leaving directory `/home/pablo/mono/mono- > 2.0/mcs/class/System' > >> gmake[6]: *** [all-recursive] Error 1 > >> gmake[6]: Leaving directory `/home/pablo/mono/mono-2.0/mcs/class' > >> gmake[5]: *** [all-recursive] Error 1 > >> gmake[5]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' > >> gmake[4]: *** [profile-do--basic--all] Error 2 > >> gmake[4]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' > >> gmake[3]: *** [profiles-do--all] Error 2 > >> gmake[3]: Leaving directory `/home/pablo/mono/mono-2.0/mcs' > >> gmake[2]: *** [all-local] Error 2 > >> gmake[2]: Leaving directory `/home/pablo/mono/mono-2.0/runtime' > >> gmake[1]: *** [all-recursive] Error 1 > >> gmake[1]: Leaving directory `/home/pablo/mono/mono-2.0' > >> gmake: *** [all] Error 2 > >> > >> > >> -bash-3.00$ uname -a > >> SunOS unknown 5.10 Generic_127128-11 i86pc i386 i86pc > >> > >> > >> Thanks again for your help > >> > >> pablo > >> > >> > >> > >> > >> Andreas F?rber escribi?: > >> > >> > >>> pablosantosluac at terra.es schrieb: > >>> > >>> > >>>> Well, it seems building the "core" is not hard if you make sure > (on > >>>> Solaris 10) that you use GNU packages and not the SUN ones (gmake, > >>>> libtool, and everything else). I can build "mono" from trunk or 2- > 0. > >>>> but the problems start with mcs... I'm now following the > instructions > >>>> sent by Geoff (basically using > >>>> http://mono.ximian.com/monobuild/preview/sources/mono/mono- > 2.0.tar.bz2). > >>>> > >>>> > >>> Having the runtime compile does not imply it'll work at runtime... > >>> Whether you use a tarball or monolite usually doesn't matter, but > if > >>> you can, a tarball is "safer". > >>> > >>> Fwiw, I've just finished compiling mono at r114845+mcs@r114882 from > >>> mono at r109531+mcs@r109587 (all trunk) on OpenSolaris build 95 for > i86 > >>> using exactly this: > >>> > >>> ../mono/configure --prefix=/opt/mono --with-gc=boehm \ > >>> --with-sigaltstack=no \ > >>> CPPFLAGS="-I/opt/mono-gc/include" \ > >>> LDFLAGS="-L/opt/mono-gc/lib -R/opt/mono/lib" > >>> > >>> where /opt/mono-gc is the prefix of Boehm GC 7.1, compiled with: > >>> > >>> ../gc-7.1/configure --prefix=/opt/mono-gc > >>> > >>> Works nicely there. Don't have access to S10 from here though to > fetch > >>> my scripts or to try the latest revs there. > >>> > >>> On OpenSolaris/amd64, I use these on top: > >>> > >>> PREFIX=/opt/mono-gc > >>> > >>> ../gc-7.1/configure --prefix=$PREFIX --libdir=$PREFIX/lib/amd64 \ > >>> CPPFLAGS=-m64 CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 > >>> > >>> and: > >>> > >>> PREFIX=/opt/mono > >>> > >>> ../mono/configure --prefix=$PREFIX --bindir=$PREFIX/bin/amd64 > >>> --libdir=$PREFIX/lib/amd64 \ > >>> --with-gc=boehm --with-sigaltstack=no --enable-big-arrays > >>> --enable-dtrace --disable-mcs-build \ > >>> CPPFLAGS="-m64 -I/opt/mono-gc/include" CFLAGS="-m64" \ > >>> LDFLAGS="-m64 -L/opt/mono-gc/lib/amd64 -R/opt/mono/lib/amd64" \ > >>> PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig:$PKG_CONFIG_PATH" > >>> > >>> (Obviously I'm skipping mcs build in this script, but I've done > full > >>> amd64 bootstraps before with post-2.0 revisions.) > >>> > >>> Note that I use dedicated /opt subdirs because that's where > 3rdparty > >>> packages are often installed on Solarises, making it easy to rename > or > >>> remove. $prefix/{bin,lib}/amd64 is where Sun places their amd64 > files. > >>> > >>> Using a monolite from 12:05 GMT+02:00 today (with Sun's `mcs` > renamed), > >>> there are no problems on OSol/i86 either. > >>> So it's definitely not mcs's or monolite's fault!!! > >>> > >>> > >>> > >>> > >>>>> Cetin actually mentioned OpenSolaris as opposed to Solaris 10. > When > >>>>> OpenSolaris 2008.05 was released I posted the following mini- > guide: > >>>>> http://lists.ximian.com/pipermail/mono-list/2008-May/038584.html > >>>>> > >>>>> It was actually supposed to avoid questions later on. ;) > >>>>> > >>>>> > >>>>> > >>>> Following this guide the only thing I realize I missed is the > LDFLAGS > >>>> stuff? Is it the reason why mcs.exe can't be run? > >>>> > >>>> > >>> In case you mean LDFLAGS=-R/path then no, it has no influence on > mcs. It > >>> helps with MD (libPosixHelper.so et al.). > >>> > >>> > >>> > >>>>> The often-referenced http://www.mono-project.com/Mono:Solaris > page > >>>>> contains a link to another post of mine, for Solaris 10: > >>>>> http://lists.ximian.com/pipermail/mono-list/2007- > January/034101.html > >>>>> > >>>>> > >>>>> > >>>> Yes, this guide was helpful building 1.1.13 (almost two years ago > >>>> already), but now all those tricks are not needed anymore... You > can > >>>> get the whole c code build easily... > >>>> > >>>> > >>> If you build using Blastwave tools you don't need some of the > >>> environment variables; otherwise you still do on Solaris 10. > >>> > >>> The only thing outdated in that post to my knowledge is > >>> CFLAGS=-D_POSIX_PTHREAD_SEMANTICS and possibly the mono-service > issue. > >>> Jonel's blog on the -mt pkg-config issue is almost three years old > and > >>> mostly still applies due to the long lifetime of S10. :) > >>> AS=gas for instance was only needed for running `make check` so you > >>> won't notice during plain `make`. > >>> > >>> Andreas > >>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> Mono-devel-list mailing list > >> Mono-devel-list at lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >> > >> > >> > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From tachyon at pobox.com Tue Oct 7 10:56:38 2008 From: tachyon at pobox.com (Charles Terrell) Date: Tue, 7 Oct 2008 09:56:38 -0500 Subject: [Mono-dev] need contact person for patent risk info Message-ID: <2EAA4C97-3FDD-4FA3-B79B-3EC333D12C90@pobox.com> Someone (I'm not at liberty to say exactly who at the moment) needs information about Microsoft patent risks involved in using Mono for development of commercial software. Specific concerns include the System.* classes. I'm not saying that Mono is bad, or that the risks are real or dire. I don't want to start a big discussion on the list. We just need to make contact with someone who can tell us what the patent risks really are from the Mono project's perspective. What is known, what is unknown, and what has been worked around. We need someone who can speak with reasonable authority about the matter. Not just random opinions. Who would be the best person at Novell or the Mono project to ask about this? Thanks! From lupus at ximian.com Tue Oct 7 10:28:39 2008 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 7 Oct 2008 16:28:39 +0200 Subject: [Mono-dev] Using using System.Threading namespace In-Reply-To: <48EA0DBB.5010502@terra.es> References: <48EA0DBB.5010502@terra.es> Message-ID: <20081007142839.GJ27246@debian.org> On 10/06/08 pablosantosluac at terra.es wrote: > I'd like to try System.Threading and System.Threading.Collections on > Linux to work a little bit with "ParallelFX". > > Is it going to be included together with the mono sources or should I > just go to the Mono GSoc repository? We'll include them in mono when the corresponding libraries will switch from unsupported previews to beta. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From gnorton at novell.com Tue Oct 7 11:08:05 2008 From: gnorton at novell.com (Geoff Norton) Date: Tue, 07 Oct 2008 11:08:05 -0400 Subject: [Mono-dev] Mono crashes when using callbacks from unmanaged to managed world In-Reply-To: References: Message-ID: <1223392085.11319.158.camel@limestone> Are you calling back into the runtime from a native thread that you have created yourself (ie; not in managed code) Zoltan, It appears at a quick glance we aren't calling mono_jit_thread_attach for unregistered threads in the jit on arm, is there a reason for this (aside from we just havn't done the work yet?) -g On Tue, 2008-10-07 at 13:45 +0000, FirstName LastName wrote: > Hi, > > I have been doing some tests with Mono quite a while. I'm working > with Mono on a ARM. > > When I try to call a managed callback from the unmanaged world in a > unmanaged thread, I get the following: > > ** ERROR **: file mini.c: line 10315 (mono_get_lmf_addr): should not > be reached > > When I try to call a managed callback from the unmanaged world in > a managed thread (actually, in the caller's thread which is managed), > it is ok. > > When I run this on Ubuntu on a X86, I don't get this. > > Any ideas why? > > > > ______________________________________________________________________ > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From pablosantosluac at terra.es Tue Oct 7 11:32:22 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Tue, 07 Oct 2008 17:32:22 +0200 Subject: [Mono-dev] Using using System.Threading namespace In-Reply-To: <20081007142839.GJ27246@debian.org> References: <48EA0DBB.5010502@terra.es> <20081007142839.GJ27246@debian.org> Message-ID: <48EB8106.2070908@terra.es> So, in the meantime, the gsoc svn is the right source, ok? Paolo Molaro escribi?: > On 10/06/08 pablosantosluac at terra.es wrote: > >> I'd like to try System.Threading and System.Threading.Collections on >> Linux to work a little bit with "ParallelFX". >> >> Is it going to be included together with the mono sources or should I >> just go to the Mono GSoc repository? >> > > We'll include them in mono when the corresponding libraries will switch > from unsupported previews to beta. > > lupus > > From lupus at ximian.com Tue Oct 7 11:58:54 2008 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 7 Oct 2008 17:58:54 +0200 Subject: [Mono-dev] Mono crashes when using callbacks from unmanaged to managed world In-Reply-To: References: Message-ID: <20081007155854.GK27246@debian.org> On 10/07/08 FirstName LastName wrote: > I have been doing some tests with Mono quite a while. I'm working with Mono on a ARM. > > When I try to call a managed callback from the unmanaged world in a unmanaged thread, I get the following: > > ** ERROR **: file mini.c: line 10315 (mono_get_lmf_addr): should not be reached Currently only x86, amd64 and ppc have support for that. Feel free to file a bug report. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From ajorgensen at novell.com Tue Oct 7 12:04:41 2008 From: ajorgensen at novell.com (Andrew Jorgensen) Date: Tue, 07 Oct 2008 10:04:41 -0600 Subject: [Mono-dev] Mono 2.0 download Message-ID: <48EB343B0200004000040444@lucius.provo.novell.com> Sounds to me like it's a problem with the .repo file, not with the repository itself. Please file a bug against the Build Service. Also try adding using just the URL. - Andrew >>> Robert Jordan 10/07/08 5:09 AM >>> Hi Andrew, Andrew Jorgensen wrote: > The original announcement about that is here: > http://lists.ximian.com/pipermail/mono-devel-list/2008-September/029144.html > > It would not be terribly difficult to make 2.0 available for 10.3 but we must be clear on the point that it is not tested and therefore not supported. We don't want to alienate you but we also won't be held resposible if a 10.3 build of Mono 2.0 causes minor skin irritation. :-) > > Because you asked so politely I'm enabling the openSUSE_10.3 builds in the Mono OBS project. It will be a while before they are built and published. > > UNSUPPORTED: http://download.opensuse.org/repositories/Mono/openSUSE_10.3/ There seems to be a problem with this repo: # cat /etc/SuSE-release openSUSE 10.3 (i586) VERSION = 10.3 # zypper sa --repo http://download.opensuse.org/repositories/Mono/openSUSE_10.3/Mono.repo * Adding repository 'Mono Project (openSUSE_10.3)' Repository 'Mono Project (openSUSE_10.3)' successfully added: Enabled: Yes Autorefresh: No URL: http://download.opensuse.org/repositories/Mono/openSUSE_10.3/ # zypper refresh Repository 'Mono Project (openSUSE_10.3)' is up to date. * Building repository 'Mono Project (openSUSE_10.3)' cache Error building the cache database: Parse error Skipping repository 'Mono Project (openSUSE_10.3)' because of the above error. Robert _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From robertj at gmx.net Tue Oct 7 12:42:48 2008 From: robertj at gmx.net (Robert Jordan) Date: Tue, 07 Oct 2008 18:42:48 +0200 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: <48EB343B0200004000040444@lucius.provo.novell.com> References: <48EB343B0200004000040444@lucius.provo.novell.com> Message-ID: Hey Andrew, Andrew Jorgensen wrote: > Sounds to me like it's a problem with the .repo file, not with the > repository itself. Please file a bug against the Build Service. > Also try adding using just the URL. Adding by URL doesn't work either. I'll file a bug. Thanks Robert From mousse_man at hotmail.com Tue Oct 7 13:19:08 2008 From: mousse_man at hotmail.com (FirstName LastName) Date: Tue, 7 Oct 2008 17:19:08 +0000 Subject: [Mono-dev] Mono crashes when using callbacks from unmanaged to managed world In-Reply-To: <20081007155854.GK27246@debian.org> References: <20081007155854.GK27246@debian.org> Message-ID: OK. I've opened a bug report. Bug 433148Thanks. > Date: Tue, 7 Oct 2008 17:58:54 +0200> From: lupus at ximian.com> To: mono-devel-list at lists.ximian.com> Subject: Re: [Mono-dev] Mono crashes when using callbacks from unmanaged to managed world> > On 10/07/08 FirstName LastName wrote:> > I have been doing some tests with Mono quite a while. I'm working with Mono on a ARM.> > > > When I try to call a managed callback from the unmanaged world in a unmanaged thread, I get the following:> > > > ** ERROR **: file mini.c: line 10315 (mono_get_lmf_addr): should not be reached> > Currently only x86, amd64 and ppc have support for that.> Feel free to file a bug report.> > 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 _________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081007/9e7b17b5/attachment.html From vargaz at gmail.com Tue Oct 7 13:48:39 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Tue, 7 Oct 2008 19:48:39 +0200 Subject: [Mono-dev] Mono crashes when using callbacks from unmanaged to managed world In-Reply-To: <1223392085.11319.158.camel@limestone> References: <1223392085.11319.158.camel@limestone> Message-ID: <295e750a0810071048u5057567n7534afeaa6a8ec6a@mail.gmail.com> Hi, Yeah, arm doesn't have fast TLS support yet, so the cost of determining whenever to attach is very high. Zoltan On Tue, Oct 7, 2008 at 5:08 PM, Geoff Norton wrote: > Are you calling back into the runtime from a native thread that you have > created yourself (ie; not in managed code) > > Zoltan, > > It appears at a quick glance we aren't calling mono_jit_thread_attach > for unregistered threads in the jit on arm, is there a reason for this > (aside from we just havn't done the work yet?) > > -g > > On Tue, 2008-10-07 at 13:45 +0000, FirstName LastName wrote: >> Hi, >> >> I have been doing some tests with Mono quite a while. I'm working >> with Mono on a ARM. >> >> When I try to call a managed callback from the unmanaged world in a >> unmanaged thread, I get the following: >> >> ** ERROR **: file mini.c: line 10315 (mono_get_lmf_addr): should not >> be reached >> >> When I try to call a managed callback from the unmanaged world in >> a managed thread (actually, in the caller's thread which is managed), >> it is ok. >> >> When I run this on Ubuntu on a X86, I don't get this. >> >> Any ideas why? >> >> >> >> ______________________________________________________________________ >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From charlie at nunit.com Tue Oct 7 15:10:55 2008 From: charlie at nunit.com (Charlie Poole) Date: Tue, 7 Oct 2008 12:10:55 -0700 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: <48EA97B402000040000402F2@lucius.provo.novell.com> Message-ID: <00c101c928b0$6ce10090$6401a8c0@ferrari> Hi Andrew, > Please do consider upgrading to 11.0. It's a solid release > with vastly improved package management among other things. Bear in mind that some of us develop and support tools. We don't have the ability to simply upgrade. Instead, we have to add each new release to those we try to support. Charlie From james at mansionfamily.plus.com Tue Oct 7 17:00:00 2008 From: james at mansionfamily.plus.com (James Mansion) Date: Tue, 07 Oct 2008 22:00:00 +0100 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <1223236249.5523.6.camel@erandi.site> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> Message-ID: <48EBCDD0.4080004@mansionfamily.plus.com> Miguel de Icaza wrote: > The above is actually a really good reason why we do not spend more > cycles on Solaris/SPARC. > > The machines are overpriced, and underperforming. It is like buying an > iPhone, just not as useful. > This is the most stupid thing I've seen in a while. Go to a bank and take a look in the datacentre. Hurry, before they go out of business. :-( Please, try to consider what real users do, and what sort of heterogeneous systems they actually have. I'd wager that there are a lot more SPARC/Solaris systems deployed to live than there are AMD/Solaris, and where new SPARC systems are being deployed they are generally rather important. That'll change, and we'll get to the point where the SPARC systems are database engines rather than application engines first. But the reality is that Solaris shops tend to be conservative. And no, I'm not disagreeing that x86 doesn't give more bang for the buck for CPU grunt. That's not the point at all. SPARC might be slow(ish) but its not broke. This is a question of user need vs developer convenience. I think your attitude is inappropriate if you want to push Mono as a realistic alternative to Java. Which does work rather well on Solaris. James From pablosantosluac at terra.es Tue Oct 7 18:18:55 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 00:18:55 +0200 Subject: [Mono-dev] Mono 2.0 LiveCD Message-ID: <48EBE04F.5020106@terra.es> Hi folks, I've just downloaded and played around a little bit with Mono 2.0 LiveCD. Some comments/suggestions: - The included MonoDevelop doesn't come with the debugger - The mdb command is not available Since it's the first thing a lot of newcomers are going to see about Mono, I'd strongly recommend to include the debugger, now that it's available and announced at Miguel's post. Regards, pablo From miguel at novell.com Tue Oct 7 18:20:58 2008 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 07 Oct 2008 18:20:58 -0400 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48EBCDD0.4080004@mansionfamily.plus.com> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> <48EBCDD0.4080004@mansionfamily.plus.com> Message-ID: <1223418058.4547.155.camel@erandi.site> Hello, > > The above is actually a really good reason why we do not spend more > > cycles on Solaris/SPARC. > > > > The machines are overpriced, and underperforming. It is like buying an > > iPhone, just not as useful. > > > This is the most stupid thing I've seen in a while. Go to a bank and > take a look in the > datacentre. Hurry, before they go out of business. :-( Well, maybe banks should not have been buying overpriced stuff, like debt, or SPARC computers. We do support it, and I wish we could do more, because I do like the SPARC architecture, but with its current pricing I have zero desire on buying more overpriced slow hardware. But if people want to donate expensive SPARC computers to the project, we could certainly use them. > This is a question of user need vs developer convenience. I think your > attitude is > inappropriate if you want to push Mono as a realistic alternative to > Java. Which > does work rather well on Solaris. You are under the mistaken impression that our goal is to replace other technologies. We are not trying to compete with Java, if you are happy with Java, keep using Java. And if you are happy with Ruby, or Python, or C++, more power to you. We are offering a platform that might suit some people, and we are trying to maximize developer pleasure and enjoyment when they write and maintain software. From knocte at gmail.com Tue Oct 7 18:27:23 2008 From: knocte at gmail.com (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses=22?=) Date: Tue, 07 Oct 2008 18:27:23 -0400 Subject: [Mono-dev] Mono 2.0 LiveCD In-Reply-To: <48EBE04F.5020106@terra.es> References: <48EBE04F.5020106@terra.es> Message-ID: pablosantosluac at terra.es wrote: > Hi folks, > > I've just downloaded and played around a little bit with Mono 2.0 LiveCD. > > Some comments/suggestions: > > - The included MonoDevelop doesn't come with the debugger > - The mdb command is not available > > Since it's the first thing a lot of newcomers are going to see about > Mono, I'd strongly recommend to include the debugger, now that it's > available and announced at Miguel's post. > > Regards, > > > pablo The debugger Addin for MD is going to be included in the upcoming MD new release (currently lives in trunk). I guess the LiveCD has the stable MD. Regards, Andr?s -- From pablosantosluac at terra.es Tue Oct 7 18:35:28 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 00:35:28 +0200 Subject: [Mono-dev] Mono 2.0 LiveCD In-Reply-To: References: <48EBE04F.5020106@terra.es> Message-ID: <48EBE430.2030602@terra.es> Ok, but I guess the mdb is stable already, right? Andr?s G. Aragoneses escribi?: > pablosantosluac at terra.es wrote: > >> Hi folks, >> >> I've just downloaded and played around a little bit with Mono 2.0 LiveCD. >> >> Some comments/suggestions: >> >> - The included MonoDevelop doesn't come with the debugger >> - The mdb command is not available >> >> Since it's the first thing a lot of newcomers are going to see about >> Mono, I'd strongly recommend to include the debugger, now that it's >> available and announced at Miguel's post. >> >> Regards, >> >> >> pablo >> > > > The debugger Addin for MD is going to be included in the upcoming MD new > release (currently lives in trunk). I guess the LiveCD has the stable MD. > > Regards, > > Andr?s > > From pablosantosluac at terra.es Tue Oct 7 18:38:50 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 00:38:50 +0200 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: References: <48EB343B0200004000040444@lucius.provo.novell.com> Message-ID: <48EBE4FA.4030807@terra.es> So, *right now* the only way to use mono 2.0 on OpenSuse < 11 is building the source? If there's other way, a howto would be greatly appreciated Robert Jordan escribi?: > Hey Andrew, > > Andrew Jorgensen wrote: > >> Sounds to me like it's a problem with the .repo file, not with the >> repository itself. Please file a bug against the Build Service. >> Also try adding using just the URL. >> > > Adding by URL doesn't work either. I'll file a bug. > > Thanks > Robert > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From matthias_weiser at yahoo.com Tue Oct 7 22:48:08 2008 From: matthias_weiser at yahoo.com (weismat) Date: Tue, 7 Oct 2008 19:48:08 -0700 (PDT) Subject: [Mono-dev] Mono 2.0 - Problems building on Solaris Sparc Message-ID: <19871367.post@talk.nabble.com> I am trying to build Mono 2.0 on Solaris 10 with Sparc architecture, but there is a problem with the makefiles. The machine is running the regular Solaris. There is make 3.8.1 and gcc 3.4.3 from sunfreeware.com installed , which I have used for building other software without a problem. The output on the console: [xxx at ARDSU002:~/test/mono-2.0] make make all-recursive Making all in libgc Making all in include Making all in private Making all in doc Making all in mono Making all in utils make all-am source='mono-hash.c' object='mono-hash.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --quiet --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono -I../../libgc/include -mt -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DGC_SOLARIS_THREADS -DGC_SOLARIS_PTHREADS -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_MMAP -DUSE_MUNMAP -DPLATFORM_SOLARIS -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -D_XOPEN_SOURCE_EXTENDED=1 -DNO_UNALIGNED_ACCESS -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -Wno-char-subscripts -Wno-cast-align -mcpu=v9 -c -o mono-hash.lo mono-hash.c cc1: error: invalid option `t' *** Error code 1 I am attaching the config.log so that you can check for other issues. Thanks in advance Matthias http://www.nabble.com/file/p19871367/config.log config.log -- View this message in context: http://www.nabble.com/Mono-2.0---Problems-building-on-Solaris-Sparc-tp19871367p19871367.html Sent from the Mono - Dev mailing list archive at Nabble.com. From ajorgensen at novell.com Wed Oct 8 00:25:29 2008 From: ajorgensen at novell.com (Andrew Jorgensen) Date: Tue, 07 Oct 2008 22:25:29 -0600 Subject: [Mono-dev] Mono 2.0 LiveCD Message-ID: <48EBE1D902000040000405EB@lucius.provo.novell.com> This is nothing more than an unfortunate (and preplexing!) oversight on my part. We will probably re-spin the LiveCD and VMware image to include this. I think what happened is that my cached repositories didn't have the debuginfo packages (because rsync.opensuse.org filters those) so I removed all the packages that included the word "debug". I am very sorry for the inconvenience. In the mean time you can get a root terminal by running 'sudo -i' and then do 'zypper ref' and 'zypper install mono-debugger'. This will work in the LiveCD also but will eat up some memory. Again, I'm really really sorry about that. The debugger should definitely be included in the LiveCD and VMware appliance. Andrew Jorgensen >>> "pablosantosluac at terra.es" 10/07/08 4:35 PM >>> Ok, but I guess the mdb is stable already, right? Andr?s G. Aragoneses escribi?: > pablosantosluac at terra.es wrote: > >> Hi folks, >> >> I've just downloaded and played around a little bit with Mono 2.0 LiveCD. >> >> Some comments/suggestions: >> >> - The included MonoDevelop doesn't come with the debugger >> - The mdb command is not available >> >> Since it's the first thing a lot of newcomers are going to see about >> Mono, I'd strongly recommend to include the debugger, now that it's >> available and announced at Miguel's post. >> >> Regards, >> >> >> pablo >> > > > The debugger Addin for MD is going to be included in the upcoming MD new > release (currently lives in trunk). I guess the LiveCD has the stable MD. > > Regards, > > Andr?s > > _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From ajorgensen at novell.com Wed Oct 8 00:39:55 2008 From: ajorgensen at novell.com (Andrew Jorgensen) Date: Tue, 07 Oct 2008 22:39:55 -0600 Subject: [Mono-dev] Mono 2.0 download Message-ID: <48EBE53B020000400004060A@lucius.provo.novell.com> It looks like the 32-bit openSUSE 10.3 builds have not finished yet. This may or may not explain repository problems. I have also enabled 10.2 and SLE 9 but, again, we are not supporting these (and I'm not reallly sure if SLE 9 will build). I cannot be sure but it is very likely that we will not build on 10.2 and SLE 9 at all for the 2.2 release as these distros will have been end-of-life'd and you use them at your own peril (EOL means no security updates). 10.3 will probably still be built as an unsupported, untested platform. >>> "pablosantosluac at terra.es" 10/07/08 4:39 PM >>> So, *right now* the only way to use mono 2.0 on OpenSuse < 11 is building the source? If there's other way, a howto would be greatly appreciated Robert Jordan escribi?: > Hey Andrew, > > Andrew Jorgensen wrote: > >> Sounds to me like it's a problem with the .repo file, not with the >> repository itself. Please file a bug against the Build Service. >> Also try adding using just the URL. >> > > Adding by URL doesn't work either. I'll file a bug. > > Thanks > 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 From vargaz at gmail.com Wed Oct 8 00:56:01 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Wed, 8 Oct 2008 06:56:01 +0200 Subject: [Mono-dev] Mono 2.0 - Problems building on Solaris Sparc In-Reply-To: <19871367.post@talk.nabble.com> References: <19871367.post@talk.nabble.com> Message-ID: <295e750a0810072156k7ebb1985r1bc3b873d550c6f2@mail.gmail.com> Hi, Read this: http://www.mono-project.com/Mono:Solaris Zoltan On Wed, Oct 8, 2008 at 4:48 AM, weismat wrote: > > I am trying to build Mono 2.0 on Solaris 10 with Sparc architecture, but > there is a problem with the makefiles. > The machine is running the regular Solaris. > There is make 3.8.1 and gcc 3.4.3 from sunfreeware.com installed , which I > have used for building other software without a problem. > The output on the console: > [xxx at ARDSU002:~/test/mono-2.0] make > make all-recursive > Making all in libgc > Making all in include > Making all in private > Making all in doc > Making all in mono > Making all in utils > make all-am > source='mono-hash.c' object='mono-hash.lo' libtool=yes \ > DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ > /bin/bash ../../libtool --quiet --tag=CC --mode=compile gcc > -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono -I../../libgc/include -mt > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DGC_SOLARIS_THREADS > -DGC_SOLARIS_PTHREADS -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_MMAP > -DUSE_MUNMAP -DPLATFORM_SOLARIS -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=500 > -D__EXTENSIONS__ -D_XOPEN_SOURCE_EXTENDED=1 -DNO_UNALIGNED_ACCESS -g -O2 > -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused > -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes > -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual > -Wcast-align -Wwrite-strings -Wno-char-subscripts -Wno-cast-align -mcpu=v9 > -c -o mono-hash.lo mono-hash.c > cc1: error: invalid option `t' > *** Error code 1 > I am attaching the config.log so that you can check for other issues. > Thanks in advance > > Matthias > http://www.nabble.com/file/p19871367/config.log config.log > > -- > View this message in context: http://www.nabble.com/Mono-2.0---Problems-building-on-Solaris-Sparc-tp19871367p19871367.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From pablosantosluac at terra.es Wed Oct 8 02:39:43 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 08:39:43 +0200 Subject: [Mono-dev] Mono 2.0 - Problems building on Solaris Sparc In-Reply-To: <19871367.post@talk.nabble.com> References: <19871367.post@talk.nabble.com> Message-ID: <48EC55AF.6000606@terra.es> Get rid of the sun packages and install GNU tools: gtar gsed gcc gmake autoconf automake libtool alias make=gmake alias cc=gcc You can obtain them all from blastwave.org Once you're there... cross your fingers!!! I'm still trying to build on Solaris 10 x86. It seems there's a problem with big/little endian or something like that. I'm working on it with Geoff and Miguel. pablo weismat escribi?: > I am trying to build Mono 2.0 on Solaris 10 with Sparc architecture, but > there is a problem with the makefiles. > The machine is running the regular Solaris. > There is make 3.8.1 and gcc 3.4.3 from sunfreeware.com installed , which I > have used for building other software without a problem. > The output on the console: > [xxx at ARDSU002:~/test/mono-2.0] make > make all-recursive > Making all in libgc > Making all in include > Making all in private > Making all in doc > Making all in mono > Making all in utils > make all-am > source='mono-hash.c' object='mono-hash.lo' libtool=yes \ > DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ > /bin/bash ../../libtool --quiet --tag=CC --mode=compile gcc > -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono -I../../libgc/include -mt > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DGC_SOLARIS_THREADS > -DGC_SOLARIS_PTHREADS -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_MMAP > -DUSE_MUNMAP -DPLATFORM_SOLARIS -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=500 > -D__EXTENSIONS__ -D_XOPEN_SOURCE_EXTENDED=1 -DNO_UNALIGNED_ACCESS -g -O2 > -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused > -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes > -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual > -Wcast-align -Wwrite-strings -Wno-char-subscripts -Wno-cast-align -mcpu=v9 > -c -o mono-hash.lo mono-hash.c > cc1: error: invalid option `t' > *** Error code 1 > I am attaching the config.log so that you can check for other issues. > Thanks in advance > > Matthias > http://www.nabble.com/file/p19871367/config.log config.log > > From pablosantosluac at terra.es Wed Oct 8 02:47:48 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 08:47:48 +0200 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: <48EBE53B020000400004060A@lucius.provo.novell.com> References: <48EBE53B020000400004060A@lucius.provo.novell.com> Message-ID: <48EC5794.3060603@terra.es> Any plans for the BitRock based installer? This one supports all distros and is good enough, easy enough, and will make most of the people happy. Again, I'm thinking about Mono adoption. You've done an excellent job guys, we've probably one of the best software development platforms around, but then there're small details making it close to impossible to use for newcomers unless they're really (really) eager to use mono. The good part is I think these details are really easy to fix, much easier than all the incredible work you do on a daily basis, but they need to be addressed. We (I mean, Codice Sotftware) are trying to get in charge of the Solaris x86 (and hopefully SPARC) releases, building everything and so on, but as you've probably noticed we weren't able to finish it yet. But even more important than the Solaris, BSDs and everything else, IMHO it is making 2.0 *easy to install* on any Linux distro. I'll post about Solaris once we (hopefully) make it work, and I think *now* is the time for all of you to blog about how to set up Mono 2.0. I'm not only talking about the mono team but the rest of the people reading this list regularly. Let's talk about the new 2.0! And let's start by telling everyone how to put their hands on it! pablo Andrew Jorgensen escribi?: > It looks like the 32-bit openSUSE 10.3 builds have not finished yet. This may or may not explain repository problems. > I have also enabled 10.2 and SLE 9 but, again, we are not supporting these (and I'm not reallly sure if SLE 9 will build). > > I cannot be sure but it is very likely that we will not build on 10.2 and SLE 9 at all for the 2.2 release as these distros will have been end-of-life'd and you use them at your own peril (EOL means no security updates). 10.3 will probably still be built as an unsupported, untested platform. > > >>>> "pablosantosluac at terra.es" 10/07/08 4:39 PM >>> >>>> > So, *right now* the only way to use mono 2.0 on OpenSuse < 11 is > building the source? > > If there's other way, a howto would be greatly appreciated > > > > Robert Jordan escribi?: > >> Hey Andrew, >> >> Andrew Jorgensen wrote: >> >> >>> Sounds to me like it's a problem with the .repo file, not with the >>> repository itself. Please file a bug against the Build Service. >>> Also try adding using just the URL. >>> >>> >> Adding by URL doesn't work either. I'll file a bug. >> >> Thanks >> 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 > > > > From mike at middlesoft.co.uk Wed Oct 8 03:04:49 2008 From: mike at middlesoft.co.uk (Michael Barker) Date: Wed, 8 Oct 2008 20:04:49 +1300 Subject: [Mono-dev] [PATCH] System.Messaging using AMQP (RabbitMQ) In-Reply-To: <80d1dfde0810060108j62b1198egd0a61a3e29fcb12a@mail.gmail.com> References: <80d1dfde0810060108j62b1198egd0a61a3e29fcb12a@mail.gmail.com> Message-ID: <80d1dfde0810080004k3d651576o70cd2baf51dbbad5@mail.gmail.com> > > Thanks a lot for the updated implementation since April :) I had > a look at the patch, and noticed that some essential stuff such as > MessageQueue.GetEnumerator() and MessageEnumerator are left > unimplemented. > > I've just had a look at the MessageEnumerator API and I'm not sure if it can be implemented using AMQP as I don't think that its possible to selectively remove messages from a queue (except with selectors, but I'll get to that). I'll try prototype it, but if it can't be implemented do you think that an AMQP solution would be a no go? BTW do you know if AMQP/Rabbit is going to support message peek > and receive-by-id functionality (in some milestones), as you > mentioned in the early discussion ? > http://www.mail-archive.com/mono-devel-list lists.ximian.com/msg16731.htm > > I had a chat with one of the standards committee members at a conference around the end of April. Selectors (to support ReceiveById) are unlikely to be part of the standard, although there was a message on the RabbitMQ list indicating that they'll probably add a server extension (that's compatible with Apache QPid) to support it. Queue browsers are being considered, but peek functionality can be fudged by not acknowleding messages. The other area where there is a mismatch is queue discovery, AMQP uses a declare model, i.e. all queues exist, but its not possible to find what they're called. Queue discovery is being considered for a future revision too. Mike. On Mon, Oct 6, 2008 at 9:08 PM, Michael Barker wrote: > Hi, > > Patch attached bugzilla report. > > https://bugzilla.novell.com/show_bug.cgi?id=432471 > > Regards, > Michael Barker. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081008/2588920c/attachment.html From pablosantosluac at terra.es Wed Oct 8 04:01:49 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 10:01:49 +0200 Subject: [Mono-dev] Mono 2.0 LiveCD In-Reply-To: <48EBE1D902000040000405EB@lucius.provo.novell.com> References: <48EBE1D902000040000405EB@lucius.provo.novell.com> Message-ID: <48EC68ED.6080508@terra.es> Andrew, Don't worry, but it will be great for new people. BTW, now the image is not available from the FTP site. pablo Andrew Jorgensen escribi?: > This is nothing more than an unfortunate (and preplexing!) oversight on > my part. We will probably re-spin the LiveCD and VMware image to > include this. > > I think what happened is that my cached repositories didn't have the > debuginfo packages (because rsync.opensuse.org filters those) so I > removed all the packages that included the word "debug". I am very > sorry for the inconvenience. > > In the mean time you can get a root terminal by running 'sudo -i' and > then do 'zypper ref' and 'zypper install mono-debugger'. This will work > in the LiveCD also but will eat up some memory. > > Again, I'm really really sorry about that. The debugger should > definitely be included in the LiveCD and VMware appliance. > > Andrew Jorgensen > > >>>> "pablosantosluac at terra.es" 10/07/08 4:35 >>>> > PM >>> > Ok, but I guess the mdb is stable already, right? > > Andr?s G. Aragoneses escribi?: > >> pablosantosluac at terra.es wrote: >> >> >>> Hi folks, >>> >>> I've just downloaded and played around a little bit with Mono 2.0 >>> > LiveCD. > >>> Some comments/suggestions: >>> >>> - The included MonoDevelop doesn't come with the debugger >>> - The mdb command is not available >>> >>> Since it's the first thing a lot of newcomers are going to see about >>> Mono, I'd strongly recommend to include the debugger, now that it's >>> available and announced at Miguel's post. >>> >>> Regards, >>> >>> >>> pablo >>> >>> >> The debugger Addin for MD is going to be included in the upcoming MD >> > new > >> release (currently lives in trunk). I guess the LiveCD has the stable >> > MD. > >> Regards, >> >> Andr?s >> >> >> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > From pablosantosluac at terra.es Wed Oct 8 04:10:55 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 10:10:55 +0200 Subject: [Mono-dev] VStudio mono debugger status update? Message-ID: <48EC6B0F.2080005@terra.es> Hi guys, About one month ago we read about the VStudio debugger on Miguel's blog: http://tirania.org/blog/archive/2008/Sep-04.html How is it going on? pablo From mousse_man at hotmail.com Wed Oct 8 09:50:01 2008 From: mousse_man at hotmail.com (FirstName LastName) Date: Wed, 8 Oct 2008 13:50:01 +0000 Subject: [Mono-dev] Mono crashes when using callbacks from unmanaged to managed world In-Reply-To: <295e750a0810071048u5057567n7534afeaa6a8ec6a@mail.gmail.com> References: <1223392085.11319.158.camel@limestone> <295e750a0810071048u5057567n7534afeaa6a8ec6a@mail.gmail.com> Message-ID: I tried out Paolo's fix and it works. That was really quick support. Now, I can continue my tests with Mono 2.0. Thanks. You guys rock! > Date: Tue, 7 Oct 2008 19:48:39 +0200> From: vargaz at gmail.com> To: gnorton at novell.com> Subject: Re: [Mono-dev] Mono crashes when using callbacks from unmanaged to managed world> CC: mousse_man at hotmail.com; mono-devel-list at lists.ximian.com> > Hi,> > Yeah, arm doesn't have fast TLS support yet, so the cost of> determining whenever to> attach is very high.> > Zoltan> > On Tue, Oct 7, 2008 at 5:08 PM, Geoff Norton wrote:> > Are you calling back into the runtime from a native thread that you have> > created yourself (ie; not in managed code)> >> > Zoltan,> >> > It appears at a quick glance we aren't calling mono_jit_thread_attach> > for unregistered threads in the jit on arm, is there a reason for this> > (aside from we just havn't done the work yet?)> >> > -g> >> > On Tue, 2008-10-07 at 13:45 +0000, FirstName LastName wrote:> >> Hi,> >>> >> I have been doing some tests with Mono quite a while. I'm working> >> with Mono on a ARM.> >>> >> When I try to call a managed callback from the unmanaged world in a> >> unmanaged thread, I get the following:> >>> >> ** ERROR **: file mini.c: line 10315 (mono_get_lmf_addr): should not> >> be reached> >>> >> When I try to call a managed callback from the unmanaged world in> >> a managed thread (actually, in the caller's thread which is managed),> >> it is ok.> >>> >> When I run this on Ubuntu on a X86, I don't get this.> >>> >> Any ideas why?> >>> >>> >>> >> ______________________________________________________________________> >> _______________________________________________> >> 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/20081008/783dd53a/attachment.html From abatishchev at gmail.com Wed Oct 8 10:30:07 2008 From: abatishchev at gmail.com (Alexander M. Batishchev) Date: Wed, 8 Oct 2008 18:30:07 +0400 Subject: [Mono-dev] Compile monodevelop-debugger from SVN on Debian Message-ID: <000301c92952$5d9e6ad0$18db4070$@com> Hello! I'm windows developer and new for Linux, that's why I cannot resolve next problem. Help me a bit, please. Debian's repository contains only Monodevelop 1.0. I want to try Monodevelop 2.0 and going to compile it from the source. $ svn co svn://anonsvn.mono-project.com/source/trunk/monodevelop $ cd monodevelop $ ./configure --prefix=/usr Checking for package 'mono-debugger'.. ERROR: Package named 'mono-debugger' >= 0.80 not found. Ok, I understand. Need to download, compile and install monodevelop-debugger $ svn co svn://anonsvn.mono-project.com/source/trunk/debugger $ cd debugger $ ./autogen.sh --prefix=/usr configure: error: Cannot find termcap library Debian's FAQ said: Debian uses the terminfo database and the ncurses library of terminal interface routes, rather than the termcap database and the termcap library. Users who are compiling programs that require some knowledge of the terminal interface should replace references to libtermcap with references to libncurses. To support binaries that have already been linked with the termcap library, and for which you do not have the source, Debian provides a package called termcap-compat. This provides both libtermcap.so.2 and /etc/termcap. Install this package if the program fails to run with the error message "can't load library 'libtermcap.so.2'", or complains about a missing /etc/termcap file. I have installed libtermcap-compat and its dependencies manually, but autogen script has the same error: Cannot find termcap library What I have to do? === Best regards, Alexander M. Batishchev From pablosantosluac at terra.es Wed Oct 8 11:33:23 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 17:33:23 +0200 Subject: [Mono-dev] Oracle and Mono Message-ID: <48ECD2C3.1010909@terra.es> Hi there, I've read that Oracle is not supported on SPARC nor PPC here http://www.mono-project.com/Oracle. Is that correct? Thanks pablo From pablosantosluac at terra.es Wed Oct 8 11:47:45 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 17:47:45 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <1223418058.4547.155.camel@erandi.site> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> <48EBCDD0.4080004@mansionfamily.plus.com> <1223418058.4547.155.camel@erandi.site> Message-ID: <48ECD621.2080002@terra.es> Hi all, After one week going crazy with the Solaris x86 build, Geoff Norton has found what was going wrong. It wasn't monolite. It seems I have a wrong define in glibconfig.h -bash-3.00$ grep G_BYTE_ORDER * glibconfig.h:#define G_BYTE_ORDER G_BIG_ENDIAN -bash-3.00$ pwd /opt/csw/include/glib-2.0 I'll replace it by G_LITTLE_ENDIAN! So, I'm using the packages from blastwave.org (someone told me to use these ones instead of the "sunfreeware" ones), but it seems they're broken. Now my question is: where should I be getting the packages from? Which ones are you (guys able to build on Solaris x86 or OpenSolaris) using????? If I get to the point to compile it I'll try to write all the steps... :-P pablo Miguel de Icaza escribi?: > Hello, > > >>> The above is actually a really good reason why we do not spend more >>> cycles on Solaris/SPARC. >>> >>> The machines are overpriced, and underperforming. It is like buying an >>> iPhone, just not as useful. >>> >>> >> This is the most stupid thing I've seen in a while. Go to a bank and >> take a look in the >> datacentre. Hurry, before they go out of business. :-( >> > > Well, maybe banks should not have been buying overpriced stuff, like > debt, or SPARC computers. > > We do support it, and I wish we could do more, because I do like the > SPARC architecture, but with its current pricing I have zero desire on > buying more overpriced slow hardware. > > But if people want to donate expensive SPARC computers to the project, > we could certainly use them. > > >> This is a question of user need vs developer convenience. I think your >> attitude is >> inappropriate if you want to push Mono as a realistic alternative to >> Java. Which >> does work rather well on Solaris. >> > > You are under the mistaken impression that our goal is to replace other > technologies. We are not trying to compete with Java, if you are happy > with Java, keep using Java. And if you are happy with Ruby, or Python, > or C++, more power to you. > > We are offering a platform that might suit some people, and we are > trying to maximize developer pleasure and enjoyment when they write and > maintain software. > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From pablosantosluac at terra.es Wed Oct 8 11:50:58 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 17:50:58 +0200 Subject: [Mono-dev] Mono 2.0 LiveCD In-Reply-To: <48EBE1D902000040000405EB@lucius.provo.novell.com> References: <48EBE1D902000040000405EB@lucius.provo.novell.com> Message-ID: <48ECD6E2.9040907@terra.es> Hi Andrew, This is what I get with the zypper method... (and yes, I do have internet connection on that box) linux:~ # zypper install mono-debugger Timeout exceed Abort, retry, ignore? autoselect retry after 21 autoselect retry after 20 autoselect retry after 19 autoselect retry after 1 Timeout exceed Abort, retry, ignore? autoselect retry after 1 Timeout exceed Abort, retry, ignore? autoselect retry after 1 Download (curl) error for 'http://www.go-mono.com/download-stable/openSUSE_11.0/repodata/repomd.xml': Error code: Error message: Empty reply from server Andrew Jorgensen escribi?: > This is nothing more than an unfortunate (and preplexing!) oversight on > my part. We will probably re-spin the LiveCD and VMware image to > include this. > > I think what happened is that my cached repositories didn't have the > debuginfo packages (because rsync.opensuse.org filters those) so I > removed all the packages that included the word "debug". I am very > sorry for the inconvenience. > > In the mean time you can get a root terminal by running 'sudo -i' and > then do 'zypper ref' and 'zypper install mono-debugger'. This will work > in the LiveCD also but will eat up some memory. > > Again, I'm really really sorry about that. The debugger should > definitely be included in the LiveCD and VMware appliance. > > Andrew Jorgensen > > >>>> "pablosantosluac at terra.es" 10/07/08 4:35 >>>> > PM >>> > Ok, but I guess the mdb is stable already, right? > > Andr?s G. Aragoneses escribi?: > >> pablosantosluac at terra.es wrote: >> >> >>> Hi folks, >>> >>> I've just downloaded and played around a little bit with Mono 2.0 >>> > LiveCD. > >>> Some comments/suggestions: >>> >>> - The included MonoDevelop doesn't come with the debugger >>> - The mdb command is not available >>> >>> Since it's the first thing a lot of newcomers are going to see about >>> Mono, I'd strongly recommend to include the debugger, now that it's >>> available and announced at Miguel's post. >>> >>> Regards, >>> >>> >>> pablo >>> >>> >> The debugger Addin for MD is going to be included in the upcoming MD >> > new > >> release (currently lives in trunk). I guess the LiveCD has the stable >> > MD. > >> Regards, >> >> Andr?s >> >> >> > _______________________________________________ > 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 Wed Oct 8 11:53:55 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Wed, 8 Oct 2008 17:53:55 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48ECD621.2080002@terra.es> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> <48EBCDD0.4080004@mansionfamily.plus.com> <1223418058.4547.155.camel@erandi.site> <48ECD621.2080002@terra.es> Message-ID: <295e750a0810080853w67aab3feh4e92bbffcdeb7fe2@mail.gmail.com> Hi, On opensolaris, I'm using the official sun packages from the opersolaris repository. Zoltan On Wed, Oct 8, 2008 at 5:47 PM, pablosantosluac at terra.es wrote: > Hi all, > > After one week going crazy with the Solaris x86 build, Geoff Norton has > found what was going wrong. > > It wasn't monolite. > > It seems I have a wrong define in glibconfig.h > > -bash-3.00$ grep G_BYTE_ORDER * > glibconfig.h:#define G_BYTE_ORDER G_BIG_ENDIAN > -bash-3.00$ pwd > /opt/csw/include/glib-2.0 > > I'll replace it by G_LITTLE_ENDIAN! > > So, I'm using the packages from blastwave.org (someone told me to use these ones instead of the "sunfreeware" ones), but it seems they're broken. > > Now my question is: where should I be getting the packages from? Which ones are you (guys able to build on Solaris x86 or OpenSolaris) using????? > > > If I get to the point to compile it I'll try to write all the steps... :-P > > > pablo > > > > > > > > Miguel de Icaza escribi?: >> Hello, >> >> >>>> The above is actually a really good reason why we do not spend more >>>> cycles on Solaris/SPARC. >>>> >>>> The machines are overpriced, and underperforming. It is like buying an >>>> iPhone, just not as useful. >>>> >>>> >>> This is the most stupid thing I've seen in a while. Go to a bank and >>> take a look in the >>> datacentre. Hurry, before they go out of business. :-( >>> >> >> Well, maybe banks should not have been buying overpriced stuff, like >> debt, or SPARC computers. >> >> We do support it, and I wish we could do more, because I do like the >> SPARC architecture, but with its current pricing I have zero desire on >> buying more overpriced slow hardware. >> >> But if people want to donate expensive SPARC computers to the project, >> we could certainly use them. >> >> >>> This is a question of user need vs developer convenience. I think your >>> attitude is >>> inappropriate if you want to push Mono as a realistic alternative to >>> Java. Which >>> does work rather well on Solaris. >>> >> >> You are under the mistaken impression that our goal is to replace other >> technologies. We are not trying to compete with Java, if you are happy >> with Java, keep using Java. And if you are happy with Ruby, or Python, >> or C++, more power to you. >> >> We are offering a platform that might suit some people, and we are >> trying to maximize developer pleasure and enjoyment when they write and >> maintain software. >> >> >> >> _______________________________________________ >> 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 pablosantosluac at terra.es Wed Oct 8 11:56:10 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 17:56:10 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <295e750a0810080853w67aab3feh4e92bbffcdeb7fe2@mail.gmail.com> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> <48EBCDD0.4080004@mansionfamily.plus.com> <1223418058.4547.155.camel@erandi.site> <48ECD621.2080002@terra.es> <295e750a0810080853w67aab3feh4e92bbffcdeb7fe2@mail.gmail.com> Message-ID: <48ECD81A.2080706@terra.es> Ok, I'll try then Zoltan Varga escribi?: > Hi, > > On opensolaris, I'm using the official sun packages from the > opersolaris repository. > > Zoltan > > On Wed, Oct 8, 2008 at 5:47 PM, pablosantosluac at terra.es > wrote: > >> Hi all, >> >> After one week going crazy with the Solaris x86 build, Geoff Norton has >> found what was going wrong. >> >> It wasn't monolite. >> >> It seems I have a wrong define in glibconfig.h >> >> -bash-3.00$ grep G_BYTE_ORDER * >> glibconfig.h:#define G_BYTE_ORDER G_BIG_ENDIAN >> -bash-3.00$ pwd >> /opt/csw/include/glib-2.0 >> >> I'll replace it by G_LITTLE_ENDIAN! >> >> So, I'm using the packages from blastwave.org (someone told me to use these ones instead of the "sunfreeware" ones), but it seems they're broken. >> >> Now my question is: where should I be getting the packages from? Which ones are you (guys able to build on Solaris x86 or OpenSolaris) using????? >> >> >> If I get to the point to compile it I'll try to write all the steps... :-P >> >> >> pablo >> >> >> >> >> >> >> >> Miguel de Icaza escribi?: >> >>> Hello, >>> >>> >>> >>>>> The above is actually a really good reason why we do not spend more >>>>> cycles on Solaris/SPARC. >>>>> >>>>> The machines are overpriced, and underperforming. It is like buying an >>>>> iPhone, just not as useful. >>>>> >>>>> >>>>> >>>> This is the most stupid thing I've seen in a while. Go to a bank and >>>> take a look in the >>>> datacentre. Hurry, before they go out of business. :-( >>>> >>>> >>> Well, maybe banks should not have been buying overpriced stuff, like >>> debt, or SPARC computers. >>> >>> We do support it, and I wish we could do more, because I do like the >>> SPARC architecture, but with its current pricing I have zero desire on >>> buying more overpriced slow hardware. >>> >>> But if people want to donate expensive SPARC computers to the project, >>> we could certainly use them. >>> >>> >>> >>>> This is a question of user need vs developer convenience. I think your >>>> attitude is >>>> inappropriate if you want to push Mono as a realistic alternative to >>>> Java. Which >>>> does work rather well on Solaris. >>>> >>>> >>> You are under the mistaken impression that our goal is to replace other >>> technologies. We are not trying to compete with Java, if you are happy >>> with Java, keep using Java. And if you are happy with Ruby, or Python, >>> or C++, more power to you. >>> >>> We are offering a platform that might suit some people, and we are >>> trying to maximize developer pleasure and enjoyment when they write and >>> maintain software. >>> >>> >>> >>> _______________________________________________ >>> 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 ajorgensen at novell.com Wed Oct 8 11:56:37 2008 From: ajorgensen at novell.com (Andrew Jorgensen) Date: Wed, 08 Oct 2008 09:56:37 -0600 Subject: [Mono-dev] Mono 2.0 LiveCD Message-ID: <48EC83D5020000400004071D@lucius.provo.novell.com> I think that ftp.novell.com has been straining under the load of the Mono 2.0 release. Our IT people should be working on it. Please be patient. Thanks, Andrew >>> "pablosantosluac at terra.es" 10/08/08 9:51 AM >>> Hi Andrew, This is what I get with the zypper method... (and yes, I do have internet connection on that box) linux:~ # zypper install mono-debugger Timeout exceed Abort, retry, ignore? autoselect retry after 21 autoselect retry after 20 autoselect retry after 19 autoselect retry after 1 Timeout exceed Abort, retry, ignore? autoselect retry after 1 Timeout exceed Abort, retry, ignore? autoselect retry after 1 Download (curl) error for 'http://www.go-mono.com/download-stable/openSUSE_11.0/repodata/repomd.xml': Error code: Error message: Empty reply from server Andrew Jorgensen escribi?: > This is nothing more than an unfortunate (and preplexing!) oversight on > my part. We will probably re-spin the LiveCD and VMware image to > include this. > > I think what happened is that my cached repositories didn't have the > debuginfo packages (because rsync.opensuse.org filters those) so I > removed all the packages that included the word "debug". I am very > sorry for the inconvenience. > > In the mean time you can get a root terminal by running 'sudo -i' and > then do 'zypper ref' and 'zypper install mono-debugger'. This will work > in the LiveCD also but will eat up some memory. > > Again, I'm really really sorry about that. The debugger should > definitely be included in the LiveCD and VMware appliance. > > Andrew Jorgensen > > >>>> "pablosantosluac at terra.es" 10/07/08 4:35 >>>> > PM >>> > Ok, but I guess the mdb is stable already, right? > > Andr?s G. Aragoneses escribi?: > >> pablosantosluac at terra.es wrote: >> >> >>> Hi folks, >>> >>> I've just downloaded and played around a little bit with Mono 2.0 >>> > LiveCD. > >>> Some comments/suggestions: >>> >>> - The included MonoDevelop doesn't come with the debugger >>> - The mdb command is not available >>> >>> Since it's the first thing a lot of newcomers are going to see about >>> Mono, I'd strongly recommend to include the debugger, now that it's >>> available and announced at Miguel's post. >>> >>> Regards, >>> >>> >>> pablo >>> >>> >> The debugger Addin for MD is going to be included in the upcoming MD >> > new > >> release (currently lives in trunk). I guess the LiveCD has the stable >> > MD. > >> Regards, >> >> Andr?s >> >> >> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > From pablosantosluac at terra.es Wed Oct 8 12:03:49 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 18:03:49 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <295e750a0810080853w67aab3feh4e92bbffcdeb7fe2@mail.gmail.com> References: <48E793CF.4070204@terra.es> <1ff5dedc0810040924r21f2e02cnd613e354d10d5e9e@mail.gmail.com> <48E7A670.1050001@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> <48EBCDD0.4080004@mansionfamily.plus.com> <1223418058.4547.155.camel@erandi.site> <48ECD621.2080002@terra.es> <295e750a0810080853w67aab3feh4e92bbffcdeb7fe2@mail.gmail.com> Message-ID: <48ECD9E5.4040302@terra.es> Zoltan, Did you take everything from there? Including gsed, gtar and all the GNU tools? Because I remember someone telling me about the blastwave instead... Zoltan Varga escribi?: > Hi, > > On opensolaris, I'm using the official sun packages from the > opersolaris repository. > > Zoltan > > On Wed, Oct 8, 2008 at 5:47 PM, pablosantosluac at terra.es > wrote: > >> Hi all, >> >> After one week going crazy with the Solaris x86 build, Geoff Norton has >> found what was going wrong. >> >> It wasn't monolite. >> >> It seems I have a wrong define in glibconfig.h >> >> -bash-3.00$ grep G_BYTE_ORDER * >> glibconfig.h:#define G_BYTE_ORDER G_BIG_ENDIAN >> -bash-3.00$ pwd >> /opt/csw/include/glib-2.0 >> >> I'll replace it by G_LITTLE_ENDIAN! >> >> So, I'm using the packages from blastwave.org (someone told me to use these ones instead of the "sunfreeware" ones), but it seems they're broken. >> >> Now my question is: where should I be getting the packages from? Which ones are you (guys able to build on Solaris x86 or OpenSolaris) using????? >> >> >> If I get to the point to compile it I'll try to write all the steps... :-P >> >> >> pablo >> >> >> >> >> >> >> >> Miguel de Icaza escribi?: >> >>> Hello, >>> >>> >>> >>>>> The above is actually a really good reason why we do not spend more >>>>> cycles on Solaris/SPARC. >>>>> >>>>> The machines are overpriced, and underperforming. It is like buying an >>>>> iPhone, just not as useful. >>>>> >>>>> >>>>> >>>> This is the most stupid thing I've seen in a while. Go to a bank and >>>> take a look in the >>>> datacentre. Hurry, before they go out of business. :-( >>>> >>>> >>> Well, maybe banks should not have been buying overpriced stuff, like >>> debt, or SPARC computers. >>> >>> We do support it, and I wish we could do more, because I do like the >>> SPARC architecture, but with its current pricing I have zero desire on >>> buying more overpriced slow hardware. >>> >>> But if people want to donate expensive SPARC computers to the project, >>> we could certainly use them. >>> >>> >>> >>>> This is a question of user need vs developer convenience. I think your >>>> attitude is >>>> inappropriate if you want to push Mono as a realistic alternative to >>>> Java. Which >>>> does work rather well on Solaris. >>>> >>>> >>> You are under the mistaken impression that our goal is to replace other >>> technologies. We are not trying to compete with Java, if you are happy >>> with Java, keep using Java. And if you are happy with Ruby, or Python, >>> or C++, more power to you. >>> >>> We are offering a platform that might suit some people, and we are >>> trying to maximize developer pleasure and enjoyment when they write and >>> maintain software. >>> >>> >>> >>> _______________________________________________ >>> 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 Wed Oct 8 12:21:41 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Wed, 8 Oct 2008 18:21:41 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48ECD9E5.4040302@terra.es> References: <48E793CF.4070204@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> <48EBCDD0.4080004@mansionfamily.plus.com> <1223418058.4547.155.camel@erandi.site> <48ECD621.2080002@terra.es> <295e750a0810080853w67aab3feh4e92bbffcdeb7fe2@mail.gmail.com> <48ECD9E5.4040302@terra.es> Message-ID: <295e750a0810080921h2365e62t80978699ce52b904@mail.gmail.com> Hi, That person probably referred to solaris, opensolaris has these packages built in. Zoltan On Wed, Oct 8, 2008 at 6:03 PM, pablosantosluac at terra.es wrote: > Zoltan, > > > Did you take everything from there? Including gsed, gtar and all the GNU > tools? Because I remember someone telling me about the blastwave instead... > > Zoltan Varga escribi?: >> Hi, >> >> On opensolaris, I'm using the official sun packages from the >> opersolaris repository. >> >> Zoltan >> >> On Wed, Oct 8, 2008 at 5:47 PM, pablosantosluac at terra.es >> wrote: >> >>> Hi all, >>> >>> After one week going crazy with the Solaris x86 build, Geoff Norton has >>> found what was going wrong. >>> >>> It wasn't monolite. >>> >>> It seems I have a wrong define in glibconfig.h >>> >>> -bash-3.00$ grep G_BYTE_ORDER * >>> glibconfig.h:#define G_BYTE_ORDER G_BIG_ENDIAN >>> -bash-3.00$ pwd >>> /opt/csw/include/glib-2.0 >>> >>> I'll replace it by G_LITTLE_ENDIAN! >>> >>> So, I'm using the packages from blastwave.org (someone told me to use these ones instead of the "sunfreeware" ones), but it seems they're broken. >>> >>> Now my question is: where should I be getting the packages from? Which ones are you (guys able to build on Solaris x86 or OpenSolaris) using????? >>> >>> >>> If I get to the point to compile it I'll try to write all the steps... :-P >>> >>> >>> pablo >>> >>> >>> >>> >>> >>> >>> >>> Miguel de Icaza escribi?: >>> >>>> Hello, >>>> >>>> >>>> >>>>>> The above is actually a really good reason why we do not spend more >>>>>> cycles on Solaris/SPARC. >>>>>> >>>>>> The machines are overpriced, and underperforming. It is like buying an >>>>>> iPhone, just not as useful. >>>>>> >>>>>> >>>>>> >>>>> This is the most stupid thing I've seen in a while. Go to a bank and >>>>> take a look in the >>>>> datacentre. Hurry, before they go out of business. :-( >>>>> >>>>> >>>> Well, maybe banks should not have been buying overpriced stuff, like >>>> debt, or SPARC computers. >>>> >>>> We do support it, and I wish we could do more, because I do like the >>>> SPARC architecture, but with its current pricing I have zero desire on >>>> buying more overpriced slow hardware. >>>> >>>> But if people want to donate expensive SPARC computers to the project, >>>> we could certainly use them. >>>> >>>> >>>> >>>>> This is a question of user need vs developer convenience. I think your >>>>> attitude is >>>>> inappropriate if you want to push Mono as a realistic alternative to >>>>> Java. Which >>>>> does work rather well on Solaris. >>>>> >>>>> >>>> You are under the mistaken impression that our goal is to replace other >>>> technologies. We are not trying to compete with Java, if you are happy >>>> with Java, keep using Java. And if you are happy with Ruby, or Python, >>>> or C++, more power to you. >>>> >>>> We are offering a platform that might suit some people, and we are >>>> trying to maximize developer pleasure and enjoyment when they write and >>>> maintain software. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mono-devel-list mailing list >>>> Mono-devel-list at lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> >>>> >>>> >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >>> >> >> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From kumpera at gmail.com Wed Oct 8 12:40:58 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Wed, 8 Oct 2008 13:40:58 -0300 Subject: [Mono-dev] [Mono-patches] r115240 - in trunk/mcs/class/System.Web.Extensions: . System.Web.UI.WebControls In-Reply-To: <20081008161706.282149472C@mono-cvs.ximian.com> References: <20081008161706.282149472C@mono-cvs.ximian.com> Message-ID: <8cca42d80810080940o48623e87ped586b278ea6ed86@mail.gmail.com> Hi Atsushi, I got a few questions about your commit r115240. Any reason to use "...GetSetMethod ().Invoke (entity, new object [] {p.Value});" instead of just "..SetValue (entity, p.Value, null);"? They produce the same result. The ExecuteInsert method does a lot of reflection searches for what looks like a finite and small set of types. If this method end been called frequently enough it will be a performance bottleneck as such calls are synchronized under a single lock. It is a good a idea to cache the results of GetProperty() and GetSetMethod(). Thanks, Rodrigo Modified: > trunk/mcs/class/System.Web.Extensions/System.Web.UI.WebControls/LinqDataSourceView.cs > =================================================================== > --- > trunk/mcs/class/System.Web.Extensions/System.Web.UI.WebControls/LinqDataSourceView.cs > 2008-10-08 16:13:20 UTC (rev 115239) > +++ > trunk/mcs/class/System.Web.Extensions/System.Web.UI.WebControls/LinqDataSourceView.cs > 2008-10-08 16:17:05 UTC (rev 115240) > @@ -221,10 +235,24 @@ > throw new NotImplementedException (); > } > > - [MonoTODO] > protected override int ExecuteInsert (IDictionary values) > { > - throw new NotImplementedException (); > + var dc = (DataContext) GetDataContext (); > + foreach (var mt in dc.Mapping.GetTables ()) { > + if (mt.TableName != TableName) > + continue; > + > + var t = mt.RowType.Type; > + ITable table = dc.GetTable (t); > + object entity = Activator.CreateInstance > (t); > + // FIXME: merge InsertParameters > + foreach (DictionaryEntry p in values) > + t.GetProperty ((string) > p.Key).GetSetMethod ().Invoke (entity, new object [] {p.Value}); > + > + InsertDataObject (dc, table, entity); > + return 1; > + } > + throw new InvalidOperationException (String.Format > ("Table '{0}' was not found on the data context '{1}'", TableName, > ContextType)); > } > > [MonoTODO] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081008/17c773fa/attachment-0001.html From monodanmorg at yahoo.com Wed Oct 8 13:05:47 2008 From: monodanmorg at yahoo.com (Daniel Morgan) Date: Wed, 8 Oct 2008 10:05:47 -0700 (PDT) Subject: [Mono-dev] Oracle and Mono In-Reply-To: <48ECD2C3.1010909@terra.es> Message-ID: <756157.70476.qm@web30802.mail.mud.yahoo.com> When I say "supported", it means it has not been tested nor developed for the platform. Thus, it probably does not work on these platforms. However, if you need access to Oracle via Mono on these platforms, there are some things you can do to get it "supported". 1. contribute patches which fixes any bugs to allow it to work on those platofrms -- or -- 2. provide some hacker remote access to a sparc machine with a recent version of mono/mcs working on the machine, and access to an oracle database. ssh? -- or -- 3. donate or lend a developer a sparc machine with a recent mono which runs a recent version of mono -- or -- 4. Your best bet - pay Novell for the support. There is some wiki page where you can get paid support to add a feature of fix a bug for mono. http://www.mono-project.com/Kickstart Note, I do not work for Novell nor am I getting anything for this message - just a public message. Most people running oracle is on linux/x86, windows, or hp these days. --- On Wed, 10/8/08, pablosantosluac at terra.es wrote: > From: pablosantosluac at terra.es > Subject: [Mono-dev] Oracle and Mono > To: "mono-devel-list at lists.ximian.com" > Date: Wednesday, October 8, 2008, 11:33 AM > Hi there, > > I've read that Oracle is not supported on SPARC nor PPC > here > http://www.mono-project.com/Oracle. Is that correct? > > > Thanks > > > pablo > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From pablosantosluac at terra.es Wed Oct 8 13:15:21 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 19:15:21 +0200 Subject: [Mono-dev] Oracle and Mono In-Reply-To: <756157.70476.qm@web30802.mail.mud.yahoo.com> References: <756157.70476.qm@web30802.mail.mud.yahoo.com> Message-ID: <48ECEAA9.2000007@terra.es> Hi Daniel, I can give hacker access to a Solaris 10 SPARC box. Putting the latest mono there is what I'm really trying to do these days. About 4: it's not normally an option, talk to Miguel. pablo Daniel Morgan escribi?: > When I say "supported", it means it has not been tested nor developed for the platform. Thus, it probably does not work on these platforms. > > However, if you need access to Oracle via Mono on these platforms, there are some things you can do to get it "supported". > > 1. contribute patches which fixes any bugs to allow it to work on those platofrms > > -- or -- > > 2. provide some hacker remote access to a sparc machine with a recent version of mono/mcs working on the machine, and access to an oracle database. ssh? > > -- or -- > > 3. donate or lend a developer a sparc machine with a recent mono which runs a recent version of mono > > -- or -- > > 4. Your best bet - pay Novell for the support. There is some wiki page where you can get paid support to add a feature of fix a bug for mono. > > http://www.mono-project.com/Kickstart > > Note, I do not work for Novell nor am I getting anything for this message - just a public message. > > Most people running oracle is on linux/x86, windows, or hp these days. > > --- On Wed, 10/8/08, pablosantosluac at terra.es wrote: > > >> From: pablosantosluac at terra.es >> Subject: [Mono-dev] Oracle and Mono >> To: "mono-devel-list at lists.ximian.com" >> Date: Wednesday, October 8, 2008, 11:33 AM >> Hi there, >> >> I've read that Oracle is not supported on SPARC nor PPC >> here >> http://www.mono-project.com/Oracle. Is that correct? >> >> >> Thanks >> >> >> pablo >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > > > > > From casper.bang at gmail.com Mon Oct 6 16:53:29 2008 From: casper.bang at gmail.com (Casper Bang) Date: Mon, 06 Oct 2008 22:53:29 +0200 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: <48EA23A90200004000040233@lucius.provo.novell.com> References: <48EA23A90200004000040233@lucius.provo.novell.com> Message-ID: <48EA7AC9.2070001@gmail.com> I know SUSE sponsors the project, but is there a good reason for not producing .deb packages for Debian/*buntu, the most popular line of distro? Anyway congrats with the release, looking forward to taking it for a spin! /Casper Andrew Jorgensen wrote: > As we announced before we are only producing binaries for > > openSUSE 11.0 > SUSE Linux Enterprise 10 > Windows > Mac OS X > > We have left up the old repositories for now. We may remove them around the 2.2 release cycle. > > >>>> "pablosantosluac at terra.es" 10/06/08 2:18 PM >>> >>>> > Hi, > > > Provided I'm right, the downloads page is still pointing to the old yast > repositories for OpenSUSE... > > http://ftp.novell.com/pub/mono/download-stable/suse-103-i586 > > Is that ok? > > > It will have an impact on new users trying to download the latest version. > _______________________________________________ > 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 matthias_weiser at yahoo.com Tue Oct 7 12:20:13 2008 From: matthias_weiser at yahoo.com (weismat) Date: Tue, 7 Oct 2008 09:20:13 -0700 (PDT) Subject: [Mono-dev] Mono invoke the C++ method In-Reply-To: <1221857414.31050.52.camel@tazmanian-devil.novell.com> References: <000d01c919fd$979c8f50$1701a8c0@YETAOMPC013> <1221857414.31050.52.camel@tazmanian-devil.novell.com> Message-ID: <19861855.post@talk.nabble.com> I am not an expert on Mono under Windows. P/Invoke works only with C -thus you need C Wrappers for your functions and then you need to map the datatypes according to this article. http://msdn.microsoft.com/de-de/library/ac7ay120.aspx Platformtypes It is in German, but it should be pretty much self-explaining in English as well. Be careful also with the calling convention... -- View this message in context: http://www.nabble.com/Mono-invoke-the-C%2B%2B-method-tp19579273p19861855.html Sent from the Mono - Dev mailing list archive at Nabble.com. From konstantink at epsystems.lt Wed Oct 8 03:09:03 2008 From: konstantink at epsystems.lt (Mrak) Date: Wed, 8 Oct 2008 00:09:03 -0700 (PDT) Subject: [Mono-dev] NullReferenceException when trying to use socket with embedded mono2 Message-ID: <19873451.post@talk.nabble.com> Hello, I'm using mono in embedded mode, and currently trying to upgrade runtime to version 2.0. However have a strange problem. When trying to use TCP sockets i'm getting the following exception: System.Configuration.ConfigurationErrorsException: Error Initializing the configuration system. ---> System.NullReferenceException: Object reference not set to an instance of an object at System.Configuration.ConfigurationManager.OpenExeConfigurationInternal (ConfigurationUserLevel userLevel, System.Reflection.Assembly calling_assembly, System.String exePath) [0x00000] at System.Configuration.ClientConfigurationSystem.get_Configuration () [0x00000] --- End of inner exception stack trace --- at System.Configuration.ClientConfigurationSystem.get_Configuration () [0x00000] at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection (System.String configKey) [0x00000] at System.Configuration.ConfigurationManager.GetSection (System.String sectionName) [0x00000] at System.Net.Sockets.Socket.CheckProtocolSupport () [0x00000] at System.Net.Sockets.Socket..cctor () [0x00000] I've explored some source code and figured out that in this code (ConfigurationManager.cs starting from line 96): if (exePath == null || exePath.Length == 0) { if (!systemWebInUse && calling_assembly != null) exePath = calling_assembly.Location; else exePath = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile; map.ExeConfigFilename = exePath.EndsWith (".config") ? exePath : exePath + ".config"; Both calling_assembly and AppDomain.CurrentDomain.SetupInformation.ConfigurationFile are null so exePath.EndsWith(".config") fails with NullReferenceException I've checked, in embedded mode Assembly.GetEntryAssembly() returns null, so naturally calling_assembly here is null. Is it a bug or "feature" and how can I overcome it? Thank you very much in advance, -- Konstantin Koryashev -- View this message in context: http://www.nabble.com/NullReferenceException-when-trying-to-use-socket-with-embedded-mono2-tp19873451p19873451.html Sent from the Mono - Dev mailing list archive at Nabble.com. From mloichate at gmail.com Wed Oct 8 07:58:33 2008 From: mloichate at gmail.com (lonifasiko) Date: Wed, 8 Oct 2008 04:58:33 -0700 (PDT) Subject: [Mono-dev] Where to start with Mono 2.0? Message-ID: <19877273.post@talk.nabble.com> Hi, I've got quite a big background developing with .NET Framework, and now we're bound to start testing Mono platform. I only would like to know which the best start point is: Start developing inside a Linux environment (we'd use VMWare OpenSuse image) or install Mono 2.0 for Windows and "play" with the samples under Windows? By the way, is there a way to develop applications for Mono in a Windows environment? Or the idea would be to develop under Visual Studio, then run Moma and then run the application from command-line? What about trying to solve "problems" of an assembly in which Moma has found "problems"? How would I need to proceed? I would really be grateful if somebody could help me getting started with Mono, pointing me at a basic document for newbies and so on, I'm a bit lost. Thanks very much in advance. ----- Miguel Blog: http://lonifasiko.blogspot.com/ http://lonifasiko.blogspot.com/ -- View this message in context: http://www.nabble.com/Where-to-start-with-Mono-2.0--tp19877273p19877273.html Sent from the Mono - Dev mailing list archive at Nabble.com. From billholmes54 at gmail.com Wed Oct 8 14:13:58 2008 From: billholmes54 at gmail.com (Bill Holmes) Date: Wed, 8 Oct 2008 14:13:58 -0400 Subject: [Mono-dev] NullReferenceException when trying to use socket with embedded mono2 In-Reply-To: <19873451.post@talk.nabble.com> References: <19873451.post@talk.nabble.com> Message-ID: <37c5788d0810081113ld7f3e47x4bd1848b2d49dfae@mail.gmail.com> Hi, We had the same problem. To work around this problem call mono_jit_exec on a Main in an exe. Then proceed with calling your methods as usual. Specifically what we had to do was change the type of the assembly being called to an executable and add a Main that does nothing. Then we obtained and called the Main method (with mono_jit_exec) before calling the real methods. -bill On Wed, Oct 8, 2008 at 3:09 AM, Mrak wrote: > > Hello, > > I'm using mono in embedded mode, and currently trying to upgrade runtime to > version 2.0. However have a strange problem. When trying to use TCP sockets > i'm getting the following exception: > > System.Configuration.ConfigurationErrorsException: Error Initializing the > configuration system. ---> System.NullReferenceException: Object reference > not set to an instance of an object > at System.Configuration.ConfigurationManager.OpenExeConfigurationInternal > (ConfigurationUserLevel userLevel, System.Reflection.Assembly > calling_assembly, System.String exePath) [0x00000] > at System.Configuration.ClientConfigurationSystem.get_Configuration () > [0x00000] > --- End of inner exception stack trace --- > at System.Configuration.ClientConfigurationSystem.get_Configuration () > [0x00000] > at > System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection > (System.String configKey) [0x00000] > at System.Configuration.ConfigurationManager.GetSection (System.String > sectionName) [0x00000] > at System.Net.Sockets.Socket.CheckProtocolSupport () [0x00000] > at System.Net.Sockets.Socket..cctor () [0x00000] > > I've explored some source code and figured out that in this code > (ConfigurationManager.cs starting from line 96): > > if (exePath == null || exePath.Length == 0) { > if (!systemWebInUse && calling_assembly != null) > exePath = calling_assembly.Location; > else > exePath = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile; > map.ExeConfigFilename = exePath.EndsWith (".config") ? exePath : > exePath + ".config"; > > Both calling_assembly and > AppDomain.CurrentDomain.SetupInformation.ConfigurationFile are null so > exePath.EndsWith(".config") fails with NullReferenceException > > I've checked, in embedded mode Assembly.GetEntryAssembly() returns null, so > naturally calling_assembly here is null. > > Is it a bug or "feature" and how can I overcome it? > > Thank you very much in advance, > > -- > Konstantin Koryashev > -- > View this message in context: http://www.nabble.com/NullReferenceException-when-trying-to-use-socket-with-embedded-mono2-tp19873451p19873451.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From monkey at jpobst.com Wed Oct 8 14:24:38 2008 From: monkey at jpobst.com (Jonathan Pobst) Date: Wed, 08 Oct 2008 13:24:38 -0500 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: <48EA7AC9.2070001@gmail.com> References: <48EA23A90200004000040233@lucius.provo.novell.com> <48EA7AC9.2070001@gmail.com> Message-ID: <48ECFAE6.6090904@jpobst.com> The biggest reason is that Debian/Ubuntu ships Mono with their system, and chops it up differently than Suse does. This means there is a good chance that our packages would cause problems on your machine when we overwrite those packages with the new ones. IE: things like Banshee, F-Spot, and Tomboy might no longer work. Therefore, we believe it is better to let Debian/Ubuntu make packages that are compatible with their systems. Hopefully, 2.0 packages for Debian/Ubuntu will soon start appearing in the places listed on http://www.mono-project.com/Other_Downloads. Jonathan Casper Bang wrote: > I know SUSE sponsors the project, but is there a good reason for not > producing .deb packages for Debian/*buntu, the most popular line of distro? > > Anyway congrats with the release, looking forward to taking it for a spin! > > /Casper From monoman at gmail.com Wed Oct 8 14:35:26 2008 From: monoman at gmail.com (Rafael Teixeira) Date: Wed, 8 Oct 2008 15:35:26 -0300 Subject: [Mono-dev] Where to start with Mono 2.0? In-Reply-To: <19877273.post@talk.nabble.com> References: <19877273.post@talk.nabble.com> Message-ID: If your intent is to develop that will run on Mono in Linux, it is better to use the VM approach and have the Linux image, to test deployment and operation issues. You can develop in VS.NET in Windows and "deploy" it in the Linux image, and even debug it running in the VM from VS.NET. Moma already tells the type of problem, and if it is a portability issue (which should be normally solved in the application side) or a Mono issue (like an unimplemented feature) which should be directed to the mono team on the bug reporting page. Also Gendarme can be used to have your application checked for bad practices, in general, and specifically about portability. Hope it helps, On Wed, Oct 8, 2008 at 8:58 AM, lonifasiko wrote: > > Hi, I've got quite a big background developing with .NET Framework, and now > we're bound to start testing Mono platform. > > I only would like to know which the best start point is: Start developing > inside a Linux environment (we'd use VMWare OpenSuse image) or install Mono > 2.0 for Windows and "play" with the samples under Windows? > > By the way, is there a way to develop applications for Mono in a Windows > environment? Or the idea would be to develop under Visual Studio, then run > Moma and then run the application from command-line? > > What about trying to solve "problems" of an assembly in which Moma has > found > "problems"? How would I need to proceed? > > I would really be grateful if somebody could help me getting started with > Mono, pointing me at a basic document for newbies and so on, I'm a bit > lost. > > Thanks very much in advance. > > ----- > Miguel > Blog: http://lonifasiko.blogspot.com/ http://lonifasiko.blogspot.com/ > -- > View this message in context: > http://www.nabble.com/Where-to-start-with-Mono-2.0--tp19877273p19877273.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Rafael "Monoman" Teixeira --------------------------------------- "I myself am made entirely of flaws, stitched together with good intentions." Augusten Burroughs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081008/31ac9a5a/attachment.html From pablosantosluac at terra.es Wed Oct 8 15:15:13 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Wed, 08 Oct 2008 21:15:13 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <295e750a0810080921h2365e62t80978699ce52b904@mail.gmail.com> References: <48E793CF.4070204@terra.es> <2637C2A5-80FA-415B-839E-61948FE759BB@web.de> <48E8ABBB.6010005@mansionfamily.plus.com> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> <48EBCDD0.4080004@mansionfamily.plus.com> <1223418058.4547.155.camel@erandi.site> <48ECD621.2080002@terra.es> <295e750a0810080853w67aab3feh4e92bbffcdeb7fe2@mail.gmail.com> <48ECD9E5.4040302@terra.es> <295e750a0810080921h2365e62t80978699ce52b904@mail.gmail.com> Message-ID: <48ED06C1.2060403@terra.es> Zoltan, Could you tell me where is your pkg-config coming from? I can't find it on the opensolaris repo... pablo >>> Hi, >>> >>> On opensolaris, I'm using the official sun packages from the >>> opersolaris repository. >>> >>> Zoltan >>> >>> From atsushi at ximian.com Wed Oct 8 16:46:52 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Thu, 09 Oct 2008 05:46:52 +0900 Subject: [Mono-dev] [Mono-patches] r115240 - in trunk/mcs/class/System.Web.Extensions: . System.Web.UI.WebControls In-Reply-To: <8cca42d80810080940o48623e87ped586b278ea6ed86@mail.gmail.com> References: <20081008161706.282149472C@mono-cvs.ximian.com> <8cca42d80810080940o48623e87ped586b278ea6ed86@mail.gmail.com> Message-ID: <48ED1C3C.8020308@ximian.com> Hi Rodrigo, Rodrigo Kumpera wrote: > Hi Atsushi, > > I got a few questions about your commit r115240. > > Any reason to use "...GetSetMethod ().Invoke (entity, new object [] > {p.Value});" instead of just "..SetValue (entity, p.Value, null);"? > They produce the same result. Sure, no reason - I'll replace it later (it was for sort of debugging). > The ExecuteInsert method does a lot of reflection searches for what > looks like a finite and small set of types. If this method > end been called frequently enough it will be a performance bottleneck as > such calls are synchronized under a single lock. > > It is a good a idea to cache the results of GetProperty() and > GetSetMethod(). Sure, will improve them. Thanks for the suggestion. Atsushi Eno From paul at all-the-johnsons.co.uk Wed Oct 8 16:56:00 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 08 Oct 2008 21:56:00 +0100 Subject: [Mono-dev] A call for programmers... Message-ID: <1223499360.15158.41.camel@PB3.Linux> Hi, Firstly, please excuse this massive cross post. Those who aren't familiar with each other... Association of C and C++ Users, this is Fedora Fedora, Association of C and C++ Users Association of C and C++ USers, this is Mono Mono, Association of C and C++ Users. I'm sure Fedora and Mono know each other ;-) Every 2 years in the UK we have a fund raising event called Comic Relief[1]. Comedians, singers and generally everyone gets together to raise money which is used for grass roots programmes (in other words, they build the infrastructure, teach people to be self-sufficient etc) in the developing nations around the world as well as at home (home being the UK). Next year is one such year and in a moment of insanity, thought it would be kind of cool to not only raise money for Comic Relief but also have a world record attempt for the most number of programmed hours in a day[2]. The idea is this. Everyone codes for an hour on a project and gets sponsored for this hour. I'm sure any coder worth their salt can spare an hour in a day for this and even if the sponsorship is in pennies, if enough people do it, then pennies mount up to pounds. Put it this way, if 744 do this then that will be the equivalent of a months programming in a day. If they each raise 10UKP, that becomes 7440 UKP raised - all for just working for an hour!!! I'm not sure yet of the full details (all work on one project, submit to svn etc), but would certainly welcome ideas. I will now return you to your scheduled things. TTFN Paul [1] http://www.comicrelief.com [2] The day being the 13th March -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081008/2d5bd567/attachment.bin From mark.probst at gmail.com Wed Oct 8 17:30:13 2008 From: mark.probst at gmail.com (Mark Probst) Date: Wed, 08 Oct 2008 23:30:13 +0200 Subject: [Mono-dev] Patch: Fix fast generic virtual method calls with remoting Message-ID: <1223501413.5557.4.camel@newton> Hi, The attached patch fixes the Remoting regressions that were caused by the fast generic virtual method invoking code. The problem is that remoting methods need a remoting wrapper, but invoking a generic method via the vtable cannot provide that wrapper, so I added a new trampoline type which does that. Paolo: Please review. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: generic_virtual_remoting.diff Type: text/x-patch Size: 7293 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081008/e9ccd276/attachment.bin From kumpera at gmail.com Wed Oct 8 18:17:23 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Wed, 8 Oct 2008 19:17:23 -0300 Subject: [Mono-dev] Patch: Fix fast generic virtual method calls with remoting In-Reply-To: <1223501413.5557.4.camel@newton> References: <1223501413.5557.4.camel@newton> Message-ID: <8cca42d80810081517u49aa5d59wc13c2c924de48cf1@mail.gmail.com> Hi Mark, @@ -1991,7 +1990,7 @@ iter = NULL; j = 0; while ((cm = mono_class_get_methods (interf, &iter))) - pvt->vtable [slot + j++] = mono_method_signature (cm)->generic_param_count ? cm : arch_create_remoting_trampoline (cm, target_type); + pvt->vtable [slot + j++] = mono_method_signature (cm)->generic_param_count ? cm : arch_create_remoting_trampoline (domain, cm, target_type); slot += mono_class_num_methods (interf); } Why this part of the vtable doesn't receive a remoting wrapper? These checks were added by Robert Jordan in r85526 to fix https://bugzilla.novell.com/show_bug.cgi?id=MONO78882 Looks like your patch reverts Robert's changes and use a new trampoline instead, thou there are other changes in object.c that haven't been changed back and seen related to virtual generic methods. Cheers, Rodrigo 2008/10/8 Mark Probst > Hi, > > The attached patch fixes the Remoting regressions that were caused by > the fast generic virtual method invoking code. The problem is that > remoting methods need a remoting wrapper, but invoking a generic method > via the vtable cannot provide that wrapper, so I added a new trampoline > type which does that. > > Paolo: Please review. > > Mark > > > _______________________________________________ > 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/20081008/9d3af858/attachment-0001.html From miguel at novell.com Wed Oct 8 18:17:55 2008 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 08 Oct 2008 18:17:55 -0400 Subject: [Mono-dev] Using using System.Threading namespace In-Reply-To: <48EA0DBB.5010502@terra.es> References: <48EA0DBB.5010502@terra.es> Message-ID: <1223504275.4547.270.camel@erandi.site> Hello, > I'd like to try System.Threading and System.Threading.Collections on > Linux to work a little bit with "ParallelFX". > > Is it going to be included together with the mono sources or should I > just go to the Mono GSoc repository? Until the API stabilizes it will remain separate. We could move it into the Mono repository, but we just have not had time. From miguel at novell.com Wed Oct 8 18:19:48 2008 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 08 Oct 2008 18:19:48 -0400 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: <48EA7AC9.2070001@gmail.com> References: <48EA23A90200004000040233@lucius.provo.novell.com> <48EA7AC9.2070001@gmail.com> Message-ID: <1223504388.4547.274.camel@erandi.site> Hello, > I know SUSE sponsors the project, but is there a good reason for not > producing .deb packages for Debian/*buntu, the most popular line of distro? > > Anyway congrats with the release, looking forward to taking it for a spin! Debian ships their own package, and we do not want to end up in a position where our packages conflict with Debian ones. So we are switching to a new process, where we are engaging with downstream packagers, they will get early access to our tarballs, we will get their patches and track distro-specific patches into Mono directly. That way everyone wins: you get high-quality packages by the maintainers of each group. The links to the Debian packages are on the "Other Downloads" section. From miguel at novell.com Wed Oct 8 18:20:23 2008 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 08 Oct 2008 18:20:23 -0400 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: References: <48EA23A90200004000040233@lucius.provo.novell.com> Message-ID: <1223504423.4547.276.camel@erandi.site> > Jezz.... way to alienate the user base. Ive been using Mono for a > number of years, and one of my main reasons for using SuSe/openSuse > was due to the fact that Novell always made sure that the mono > releases were availble for the last couple of suse releases. Now Im > faced with either upgrading to 11.0 or setting a day aside to build > mono from source, and loose the system maintained updates. > > Thanks for that. We are fixing that; We just were short on time, as we did many test releases that ended up consuming a lot of our time. > From pablosantosluac at terra.es Wed Oct 8 18:22:12 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Thu, 09 Oct 2008 00:22:12 +0200 Subject: [Mono-dev] Using using System.Threading namespace In-Reply-To: <1223504275.4547.270.camel@erandi.site> References: <48EA0DBB.5010502@terra.es> <1223504275.4547.270.camel@erandi.site> Message-ID: <48ED3294.5010204@terra.es> no problem, I'll give it a try Miguel de Icaza escribi?: > Hello, > > >> I'd like to try System.Threading and System.Threading.Collections on >> Linux to work a little bit with "ParallelFX". >> >> Is it going to be included together with the mono sources or should I >> just go to the Mono GSoc repository? >> > > Until the API stabilizes it will remain separate. > > We could move it into the Mono repository, but we just have not had > time. > > > From miguel at novell.com Wed Oct 8 18:21:35 2008 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 08 Oct 2008 18:21:35 -0400 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: References: <48EA97B402000040000402F2@lucius.provo.novell.com> Message-ID: <1223504495.4547.278.camel@erandi.site> > I would upgrade to 11.0, but I generally wait for the ##.1 releases > after the whole problems that where experienced with the 10.0 release; > and also I have to make sure all apps still work the same way in the > new OS release, otherwise I alienate the wife from Linux adoption. I understand the feeling, but 11.0 is so much better in every regard, and I have only had one problem (PulseAudio, but that is easy to fix: remove it). Miguel > I take your point with the lack of testing for 10.3, and I will test > with mono 2.0 on that basis. > > But thanks again for enabling this! > > Kevin > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From miguel at novell.com Wed Oct 8 18:23:03 2008 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 08 Oct 2008 18:23:03 -0400 Subject: [Mono-dev] need contact person for patent risk info In-Reply-To: <2EAA4C97-3FDD-4FA3-B79B-3EC333D12C90@pobox.com> References: <2EAA4C97-3FDD-4FA3-B79B-3EC333D12C90@pobox.com> Message-ID: <1223504583.4547.280.camel@erandi.site> > We need someone who can speak with reasonable authority about the > matter. Not just random opinions. Who would be the best person at > Novell or the Mono project to ask about this? www.go-mono.com/contact From miguel at novell.com Wed Oct 8 18:27:33 2008 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 08 Oct 2008 18:27:33 -0400 Subject: [Mono-dev] Mono 2.0 download In-Reply-To: <48EC5794.3060603@terra.es> References: <48EBE53B020000400004060A@lucius.provo.novell.com> <48EC5794.3060603@terra.es> Message-ID: <1223504853.4547.284.camel@erandi.site> Hello, > Any plans for the BitRock based installer? This one supports all distros > and is good enough, easy enough, and will make most of the people happy. We are abandoning the BitRock installer because Mono installations ended up broken many times. This had two unfortunate side effects, we spent a lot of our time tracking down bugs, just to find out that they were users using the installer and had broken systems, or Mono was not properly configured for their system. We basically do not have the resources to support every possible configuration, and would rather have users get packages properly packaged by their distributions (See the Mono Packagers List for details on how we are working now with Downstream to make sure Mono reaches you). The other issue was just that people had poor experiences with Mono. And yes, the installer worked on a handful of systems, and worked most of the time. The problem is the *other* times, the corner cases and the corner operating systems. Miguel. From miguel at novell.com Wed Oct 8 18:28:30 2008 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 08 Oct 2008 18:28:30 -0400 Subject: [Mono-dev] VStudio mono debugger status update? In-Reply-To: <48EC6B0F.2080005@terra.es> References: <48EC6B0F.2080005@terra.es> Message-ID: <1223504910.4547.286.camel@erandi.site> > About one month ago we read about the VStudio debugger on Miguel's blog: > > http://tirania.org/blog/archive/2008/Sep-04.html > > > How is it going on? If you sign up for the Alpha, you will be notified when we are ready to show something to the public. From mark.probst at gmail.com Wed Oct 8 19:09:43 2008 From: mark.probst at gmail.com (Mark Probst) Date: Thu, 9 Oct 2008 01:09:43 +0200 Subject: [Mono-dev] Patch: Fix fast generic virtual method calls with remoting In-Reply-To: <8cca42d80810081517u49aa5d59wc13c2c924de48cf1@mail.gmail.com> References: <1223501413.5557.4.camel@newton> <8cca42d80810081517u49aa5d59wc13c2c924de48cf1@mail.gmail.com> Message-ID: Hi Rodrigo, > @@ -1991,7 +1990,7 @@ > iter = NULL; > j = 0; > while ((cm = mono_class_get_methods (interf, &iter))) > - pvt->vtable [slot + j++] = mono_method_signature > (cm)->generic_param_count ? cm : arch_create_remoting_trampoline (cm, > target_type); > + pvt->vtable [slot + j++] = mono_method_signature > (cm)->generic_param_count ? cm : arch_create_remoting_trampoline (domain, > cm, target_type); > > slot += mono_class_num_methods (interf); > } > > Why this part of the vtable doesn't receive a remoting wrapper? It probably needs one, too :-) > Looks like your patch reverts Robert's changes and use a new trampoline > instead, thou there are other changes in object.c that haven't been changed > back and seen related to virtual generic methods. My guess is that the changes regarding the vtable were just there to save memory, i.e. to not create trampolines for the generic virtual slots which are never jumped to. Since fast virtual generic method calls do jump to those slots, we need something there. We don't have a particular test case for bug #78882, but we have several tests for generic remoting invokes in the System.Runtime.Remoting testsuite (those were the one that were broken), which are fixed by this patch, and the test case attached with the bug report runs as well. Anyway, updated patch attached. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: generic_virtual_remoting.diff Type: text/x-diff Size: 7238 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081009/ded41fe7/attachment-0001.bin From vargaz at gmail.com Thu Oct 9 02:12:16 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Thu, 9 Oct 2008 08:12:16 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <48ED06C1.2060403@terra.es> References: <48E793CF.4070204@terra.es> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> <48EBCDD0.4080004@mansionfamily.plus.com> <1223418058.4547.155.camel@erandi.site> <48ECD621.2080002@terra.es> <295e750a0810080853w67aab3feh4e92bbffcdeb7fe2@mail.gmail.com> <48ECD9E5.4040302@terra.es> <295e750a0810080921h2365e62t80978699ce52b904@mail.gmail.com> <48ED06C1.2060403@terra.es> Message-ID: <295e750a0810082312m6ddd565fgc1c7eafe3bab0724@mail.gmail.com> Hi, http://swik.net/MySQL/Planet+MySQL/OpenSolaris+EPIC+FAIL/cbotd Zoltan On Wed, Oct 8, 2008 at 9:15 PM, pablosantosluac at terra.es wrote: > Zoltan, > > Could you tell me where is your pkg-config coming from? I can't find it on > the opensolaris repo... > > > pablo > > >>>> Hi, >>>> >>>> On opensolaris, I'm using the official sun packages from the >>>> opersolaris repository. >>>> >>>> Zoltan >>>> >>>> > > From pablosantosluac at terra.es Thu Oct 9 02:42:17 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Thu, 09 Oct 2008 08:42:17 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: <295e750a0810082312m6ddd565fgc1c7eafe3bab0724@mail.gmail.com> References: <48E793CF.4070204@terra.es> <3BE75C66-B989-4AB6-84CB-B1A35ED1ED00@web.de> <1223236249.5523.6.camel@erandi.site> <48EBCDD0.4080004@mansionfamily.plus.com> <1223418058.4547.155.camel@erandi.site> <48ECD621.2080002@terra.es> <295e750a0810080853w67aab3feh4e92bbffcdeb7fe2@mail.gmail.com> <48ECD9E5.4040302@terra.es> <295e750a0810080921h2365e62t80978699ce52b904@mail.gmail.com> <48ED06C1.2060403@terra.es> <295e750a0810082312m6ddd565fgc1c7eafe3bab0724@mail.gmail.com> Message-ID: <48EDA7C9.6020900@terra.es> :-DD ok, doesn't look very good but I'll give it a try! Zoltan Varga escribi?: > Hi, > > http://swik.net/MySQL/Planet+MySQL/OpenSolaris+EPIC+FAIL/cbotd > > Zoltan > > On Wed, Oct 8, 2008 at 9:15 PM, pablosantosluac at terra.es > wrote: > >> Zoltan, >> >> Could you tell me where is your pkg-config coming from? I can't find it on >> the opensolaris repo... >> >> >> pablo >> >> >> >>>>> Hi, >>>>> >>>>> On opensolaris, I'm using the official sun packages from the >>>>> opersolaris repository. >>>>> >>>>> Zoltan >>>>> >>>>> >>>>> >> > > From emperon at gmail.com Thu Oct 9 03:07:55 2008 From: emperon at gmail.com (Onur Gumus) Date: Thu, 9 Oct 2008 10:07:55 +0300 Subject: [Mono-dev] why does gtk# installer requires .net 1.1 ? Message-ID: <8a7a2d050810090007o13771519g543d6b8086386b80@mail.gmail.com> It seems gtk# requires .net 1.1 explicitly for windows. Though this seems to be an unrealistic requirement if people want GTK# usage increase on windows as well. As you would guess, vast majority of windows boxes has .net 2.0+. Any improvements possible ? From lnc19 at hotmail.com Thu Oct 9 08:20:45 2008 From: lnc19 at hotmail.com (Luciano _) Date: Thu, 9 Oct 2008 12:20:45 +0000 Subject: [Mono-dev] Compile monodevelop-debugger from SVN on Debian In-Reply-To: <000301c92952$5d9e6ad0$18db4070$@com> References: <000301c92952$5d9e6ad0$18db4070$@com> Message-ID: Hi: To run mono-debugger you need Mono from svn or mono 2.0 and Mono-debugger 2.0. (Which i think it is not present on Debian/Ubuntu Repository) An alternative could be to run: ./configure --prefix=/usr --select this let you select which package you will build, and you can disable the debugger Addin. My recomendation: Setup a parallel mono environment [*], if you have any version of mono installed, maybe some applications could depend on that installation, and if you break it you will have problem with other installed applications. (I've got this problem some times ago on Ubuntu) Bye [*] http://www.mono-project.com/Parallel_Mono_Environments > From: abatishchev at gmail.com> To: mono-devel-list at lists.ximian.com> Date: Wed, 8 Oct 2008 18:30:07 +0400> Subject: [Mono-dev] Compile monodevelop-debugger from SVN on Debian> > Hello!> I'm windows developer and new for Linux, that's why I cannot resolve next> problem. Help me a bit, please.> > Debian's repository contains only Monodevelop 1.0. I want to try Monodevelop> 2.0 and going to compile it from the source.> > $ svn co svn://anonsvn.mono-project.com/source/trunk/monodevelop> $ cd monodevelop> $ ./configure --prefix=/usr> Checking for package 'mono-debugger'.. ERROR: Package named 'mono-debugger'> >= 0.80 not found.> > Ok, I understand. Need to download, compile and install monodevelop-debugger> > $ svn co svn://anonsvn.mono-project.com/source/trunk/debugger> $ cd debugger> $ ./autogen.sh --prefix=/usr> configure: error: Cannot find termcap library> > Debian's FAQ said:> Debian uses the terminfo database and the ncurses library of terminal> interface routes, rather than the termcap database and the termcap library.> Users who are compiling programs that require some knowledge of the terminal> interface should replace references to libtermcap with references to> libncurses.> > To support binaries that have already been linked with the termcap library,> and for which you do not have the source, Debian provides a package called> termcap-compat. This provides both libtermcap.so.2 and /etc/termcap. Install> this package if the program fails to run with the error message "can't load> library 'libtermcap.so.2'", or complains about a missing /etc/termcap file.> > I have installed libtermcap-compat and its dependencies manually, but> autogen script has the same error: Cannot find termcap library> > What I have to do?> > ===> Best regards,> Alexander M. Batishchev> > > _______________________________________________> Mono-devel-list mailing list> Mono-devel-list at lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-devel-list _________________________________________________________________ Your PC, mobile phone, and online services work together like never before. http://clk.atdmt.com/MRT/go/108587394/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081009/cc074779/attachment.html From niksisavailable at gmail.com Thu Oct 9 11:49:50 2008 From: niksisavailable at gmail.com (Bas Smit) Date: Thu, 9 Oct 2008 08:49:50 -0700 (PDT) Subject: [Mono-dev] Compiling mono from the repository Message-ID: <19901757.post@talk.nabble.com> Hi guys, First off, im new to mono and ubuntu so I might be missing something obvious. Im trying to compile mono from the repository, on ubuntu. I've followed the instructions on http://www.mono-project.com/Compiling_Mono but when I autogen I get the following error: ... ... checking for ieeefp.h... no checking for isinf... yes checking for void *... yes checking size of void *... 4 checking for -Wdeclaration-after-statement option to gcc... yes checking integrity of package... configure: error: Your mono distribution is incomplete; if unpacking from a tar file, make sure you use GNU tar; see http://www.mono-project.com/IncompletePackage for more details Ive tried creating a new checkout, but the package really seems incomplete. Im 99% sure I've got mono, mcs, glib and pkg-config installed correctly. Could someone point out what I could be doing wrong? Many thanks, Bas -- View this message in context: http://www.nabble.com/Compiling-mono-from-the-repository-tp19901757p19901757.html Sent from the Mono - Dev mailing list archive at Nabble.com. From bojanr at brandeis.edu Thu Oct 9 17:14:18 2008 From: bojanr at brandeis.edu (Bojan Rajkovic) Date: Thu, 9 Oct 2008 17:14:18 -0400 Subject: [Mono-dev] Compiling mono from the repository In-Reply-To: <19901757.post@talk.nabble.com> References: <19901757.post@talk.nabble.com> Message-ID: <4E8AF960-694D-464D-8A86-BC237C2B4B5D@brandeis.edu> Did you make sure to checkout mcs too? On Oct 9, 2008, at 11:49 AM, Bas Smit wrote: > > Hi guys, > > First off, im new to mono and ubuntu so I might be missing something > obvious. Im trying to compile mono from the repository, on ubuntu. > I've > followed the instructions on http://www.mono-project.com/Compiling_Mono > but > when I autogen I get the following error: > > ... > ... > checking for ieeefp.h... no > checking for isinf... yes > checking for void *... yes > checking size of void *... 4 > checking for -Wdeclaration-after-statement option to gcc... yes > checking integrity of package... configure: error: Your mono > distribution is > incomplete; if unpacking from a tar file, make sure you use GNU > tar; see > http://www.mono-project.com/IncompletePackage for more details > > Ive tried creating a new checkout, but the package really seems > incomplete. > Im 99% sure I've got mono, mcs, glib and pkg-config installed > correctly. > Could someone point out what I could be doing wrong? > > Many thanks, Bas > -- > View this message in context: http://www.nabble.com/Compiling-mono-from-the-repository-tp19901757p19901757.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From federico_ballan at yahoo.it Thu Oct 9 04:35:56 2008 From: federico_ballan at yahoo.it (Federico Ballan) Date: Thu, 9 Oct 2008 10:35:56 +0200 Subject: [Mono-dev] [WF] who is involved in Workflow develop? Message-ID: <004c01c929ea$0d17cf00$1700a8c0@sintelvdh.com> Sorry in advance for my english: I hope this is the correct mailing list for my question on Workflow. I'm a developer for vending machine and automation control on Windows Workflow Foundation: now our products are Ms Windows based but we are thinking about porting proects on Linux so on Mono. I wish to known some details on next Mono Workflow implementation and I wish to notify some actual limitation (i think the name is BUG) on original Microsoft Workflow Visual Studio Designer (if those bugs are relevant for Mono Develop) I already notify these bugs on Microsoft Connect so you may see them directly on those site. - StateMachineWorkflow designer is too slow https://connect.microsoft.com/wf/feedback/ViewFeedback.aspx?FeedbackID=323904 - StateMachineWorkflow designer autoredraw move nested states outside container https://connect.microsoft.com/wf/feedback/ViewFeedback.aspx?FeedbackID=323899 In general you may search for bugs in Workflow signed by 'fedeballan', my nickname in Microsoft Connect. Thank You. Federico Ballan From carsten.harnisch at intradesys.com Fri Oct 10 04:30:15 2008 From: carsten.harnisch at intradesys.com (Carsten Harnisch) Date: Fri, 10 Oct 2008 01:30:15 -0700 (PDT) Subject: [Mono-dev] Please advise. Threading in unmanaged code Message-ID: <19914089.post@talk.nabble.com> This is my first post, but I already need some experts advise :) We are evaluating to port an existing app (written in c/c++, for LINUX/Windows/Mac) to mono. The basic pattern is a daemon-based system (using pthreads, epoll) that will dispatch data to various embedded scripting engines (PHP, Tcl, Perl, etc.). Currently the engines will have one-time startup and shutdown methods and the system will pre-create numerous threads. The daemon will then notify the workers to do their work. In the planed scenario the daemon should be written in mono whereas the scripting-engines needs to have unmanaged wrappers. As I understood mono is using phreads and epoll, so having created a "mono"-thread and using this thread to call an unmanged piece of code, will this unmanaged code be run in the context of the underlaying pthread? Or does the mono i/o layer call the unmanaged code with its own thread pool? thx for you help Carsten Harnisch -- View this message in context: http://www.nabble.com/Please-advise.-Threading-in-unmanaged-code-tp19914089p19914089.html Sent from the Mono - Dev mailing list archive at Nabble.com. From konstantink at epsystems.lt Fri Oct 10 06:01:37 2008 From: konstantink at epsystems.lt (Mrak) Date: Fri, 10 Oct 2008 03:01:37 -0700 (PDT) Subject: [Mono-dev] NullReferenceException when trying to use socket with embedded mono2 In-Reply-To: <37c5788d0810081113ld7f3e47x4bd1848b2d49dfae@mail.gmail.com> References: <19873451.post@talk.nabble.com> <37c5788d0810081113ld7f3e47x4bd1848b2d49dfae@mail.gmail.com> Message-ID: <19915412.post@talk.nabble.com> Hello, Thanks alot Bill!!! That really solved the problem! Bill Holmes wrote: > > Hi, > > We had the same problem. To work around this problem call > mono_jit_exec on a Main in an exe. Then proceed with calling your > methods as usual. > > Specifically what we had to do was change the type of the assembly > being called to an executable and add a Main that does nothing. Then > we obtained and called the Main method (with mono_jit_exec) before > calling the real methods. > > -bill > > -- View this message in context: http://www.nabble.com/NullReferenceException-when-trying-to-use-socket-with-embedded-mono2-tp19873451p19915412.html Sent from the Mono - Dev mailing list archive at Nabble.com. From lnc19 at hotmail.com Fri Oct 10 08:10:24 2008 From: lnc19 at hotmail.com (Luciano _) Date: Fri, 10 Oct 2008 12:10:24 +0000 Subject: [Mono-dev] Compiling mono from the repository In-Reply-To: <4E8AF960-694D-464D-8A86-BC237C2B4B5D@brandeis.edu> References: <19901757.post@talk.nabble.com> <4E8AF960-694D-464D-8A86-BC237C2B4B5D@brandeis.edu> Message-ID: I have mono from source (svn) on ubuntu, you need to checkout this 3 items: svn co svn://anonsvn.mono-project.com/source/trunk/mono svn co svn://anonsvn.mono-project.com/source/trunk/mcs svn co svn://anonsvn.mono-project.com/source/trunk/libgdiplusSome days ago, i add reference to Compiling [1] on IncompletePackage [2] wiki page beacause i was having the same issue. [1] http://www.mono-project.com/Compiling_Mono [2] http://www.mono-project.com/IncompletePackage > From: bojanr at brandeis.edu> To: niksisavailable at gmail.com> Date: Thu, 9 Oct 2008 17:14:18 -0400> CC: mono-devel-list at lists.ximian.com> Subject: Re: [Mono-dev] Compiling mono from the repository> > Did you make sure to checkout mcs too?> > On Oct 9, 2008, at 11:49 AM, Bas Smit wrote:> > >> > Hi guys,> >> > First off, im new to mono and ubuntu so I might be missing something> > obvious. Im trying to compile mono from the repository, on ubuntu. > > I've> > followed the instructions on http://www.mono-project.com/Compiling_Mono > > but> > when I autogen I get the following error:> >> > ...> > ...> > checking for ieeefp.h... no> > checking for isinf... yes> > checking for void *... yes> > checking size of void *... 4> > checking for -Wdeclaration-after-statement option to gcc... yes> > checking integrity of package... configure: error: Your mono > > distribution is> > incomplete; if unpacking from a tar file, make sure you use GNU > > tar; see> > http://www.mono-project.com/IncompletePackage for more details> >> > Ive tried creating a new checkout, but the package really seems > > incomplete.> > Im 99% sure I've got mono, mcs, glib and pkg-config installed > > correctly.> > Could someone point out what I could be doing wrong?> >> > Many thanks, Bas> > -- > > View this message in context: http://www.nabble.com/Compiling-mono-from-the-repository-tp19901757p19901757.html> > Sent from the Mono - Dev mailing list archive at Nabble.com.> >> > _______________________________________________> > Mono-devel-list mailing list> > Mono-devel-list at lists.ximian.com> > http://lists.ximian.com/mailman/listinfo/mono-devel-list> >> _______________________________________________> Mono-devel-list mailing list> Mono-devel-list at lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-devel-list _________________________________________________________________ Reveal your inner athlete and share it with friends on Windows Live. http://revealyourinnerathlete.windowslive.com?locale=en-us&ocid=TXT_TAGLM_WLYIA_whichathlete_us -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081010/9746cd47/attachment.html From rhowell at novell.com Fri Oct 10 13:47:02 2008 From: rhowell at novell.com (Rusty Howell) Date: Fri, 10 Oct 2008 11:47:02 -0600 Subject: [Mono-dev] Missing mscorlib Message-ID: <48EF9516.1020509@novell.com> I'm getting this error when building moonlight on opensuse 10.3 x86_64 http://mono.ximian.com/monobuild/builds/HEAD/suse-103-x86_64/moon/115461/logs/build.log Making all in test-runner make[4]: Entering directory `/tmp/monobuild/build/BUILD/moon-115461/test/harness/test-runner' gmcs -debug+ -unsafe -r:System.Drawing.dll -r:Mono.Posix.dll -r:System.Data.dll -r:Npgsql.dll -pkg:ndesk-dbus-1.0 /resource:./html_template.html /resource:./comparison_report.html /resource:./regression_report.txt /out:test-runner.exe Agviewer.cs DbusServices.cs IDbusService.cs Driver.cs ExternalProcess.cs Test.cs TestBeginEventHandler.cs TestCompleteEventHandler.cs TestCompleteReason.cs TestResult.cs TestRun.cs TestRunner.cs HtmlTest.cs XamlTest.cs LoggingServer.cs Screensaver.cs ImageCompare.cs EdgeCompare.cs IReport.cs VerboseLevel.cs ComparisonReport.cs ConsoleReport.cs HtmlReport.cs XmlReport.cs DbReport.cs ../../../tools/Options.cs ExocortexDSP/src/AssemblyInfo.cs ExocortexDSP/src/Complex.cs ExocortexDSP/src/ComplexMath.cs ExocortexDSP/src/FourierDirection.cs ExocortexDSP/src/ComplexArray.cs ExocortexDSP/src/ComplexF.cs ExocortexDSP/src/ComplexStats.cs ExocortexDSP/src/Fourier.cs The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `/usr/lib64/mono/2.0/mscorlib.dll' directory. make[4]: *** [test-runner.exe] Error 1 I noticed that the mono def file changed 'default' to 'net_1_1'. What do i need to change in the build to get this to work? Thanks for the help. Rusty From mousse_man at hotmail.com Fri Oct 10 15:28:09 2008 From: mousse_man at hotmail.com (FirstName LastName) Date: Fri, 10 Oct 2008 19:28:09 +0000 Subject: [Mono-dev] Mono 2.0 (arm): Reverse PInvoke can cause memory corruption? Message-ID: Hi, Recently, I asked about doing reverse pinvoke from a native thread that caused an assert in mini-arm.c. A fix was done and I'm able to do it. But know, I have a feeling that I have memory corruption. My application is crashing at different times and display different stack traces. I have a general question regarding GC. When the GC runs, does it stop all threads in the process, even those created in unmanaged. I asking the following because I'm wondering what would happen if the GC collects and at the same time, a reverse pinvoke is done from a native thread (back to managed code)? Can this be an issue? _________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081010/bdd0b41b/attachment.html From vargaz at gmail.com Fri Oct 10 15:41:22 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Fri, 10 Oct 2008 21:41:22 +0200 Subject: [Mono-dev] Mono 2.0 (arm): Reverse PInvoke can cause memory corruption? In-Reply-To: References: Message-ID: <295e750a0810101241q126b92b0u3fde65c29c80c072@mail.gmail.com> Hi, The GC only stops threads registered with it. This can be done multiple ways: - all threads started by the runtime are automatically registered. - an embedding app can register its threads by calling the mono_thread_attach () API function. - a non-registered thread is automatically registered the first time it calls into managed code. The third way is the easiest for applications, but it might have race condition: if a GC happens inside the call, I'm not sure what happens. Zoltan 2008/10/10 FirstName LastName : > Hi, > > Recently, I asked about doing reverse pinvoke from a native thread that > caused an assert in mini-arm.c. > > A fix was done and I'm able to do it. But know, I have a feeling that I > have memory corruption. My application is crashing at different times > > and display different stack traces. > > I have a general question regarding GC. When the GC runs, does it stop all > threads in the process, even those created in unmanaged. > > I asking the following because I'm wondering what would happen if the GC > collects and at the same time, a reverse pinvoke is done from a native > thread (back to managed code)? > > Can this be an issue? > > > > ________________________________ > _______________________________________________ > 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 Fri Oct 10 16:43:47 2008 From: lupus at ximian.com (Paolo Molaro) Date: Fri, 10 Oct 2008 22:43:47 +0200 Subject: [Mono-dev] Patch: Fix fast generic virtual method calls with remoting In-Reply-To: References: <1223501413.5557.4.camel@newton> <8cca42d80810081517u49aa5d59wc13c2c924de48cf1@mail.gmail.com> Message-ID: <20081010204347.GU27246@debian.org> On 10/09/08 Mark Probst wrote: > Anyway, updated patch attached. The changes look fine to me. Maybe it's a good idea to have a remoting test that triggers this also in the runtime tests. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Fri Oct 10 16:49:26 2008 From: lupus at ximian.com (Paolo Molaro) Date: Fri, 10 Oct 2008 22:49:26 +0200 Subject: [Mono-dev] Mono 2.0 (arm): Reverse PInvoke can cause memory corruption? In-Reply-To: References: Message-ID: <20081010204926.GV27246@debian.org> On 10/10/08 FirstName LastName wrote: > I have a general question regarding GC. When the GC runs, does it > stop all threads in the process, even those created in unmanaged. Only the ones it knows about, but see below. > I asking the following because I'm wondering what would happen if the > GC collects and at the same time, a reverse pinvoke is done from a native > thread (back to managed code)? The fix I committed will register the thread with the GC before the delegate is executed on that thread. Note that you must not manipulate managed objects in threads that were not known to the runtime (they are known when they where created by mono, the main thread, the ones where reverse p/invoke delegates are called and the ones registered explicitly). Try setting GC_DONT_GC=1 and running the app to see the crashes are due to the GC. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Fri Oct 10 16:51:16 2008 From: lupus at ximian.com (Paolo Molaro) Date: Fri, 10 Oct 2008 22:51:16 +0200 Subject: [Mono-dev] Please advise. Threading in unmanaged code In-Reply-To: <19914089.post@talk.nabble.com> References: <19914089.post@talk.nabble.com> Message-ID: <20081010205116.GW27246@debian.org> On 10/10/08 Carsten Harnisch wrote: > As I understood mono is using phreads and epoll, so having created a > "mono"-thread and using this thread to call an unmanged piece of code, will > this unmanaged code be run in the context of the underlaying pthread? Or > does the mono i/o layer call the unmanaged code with its own thread pool? The call will happen in the same thread. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From kornelpal at gmail.com Fri Oct 10 16:52:51 2008 From: kornelpal at gmail.com (=?ISO-8859-2?Q?Korn=E9l_P=E1l?=) Date: Fri, 10 Oct 2008 22:52:51 +0200 Subject: [Mono-dev] How to create a JIT trampoline? Message-ID: <48EFC0A3.8050603@gmail.com> Hi, Currently mono_image_fixup_vtable actually compiles methods that causes type loads as well and requires the assembly to be loaded. Please help with letting me know how could I avoiding this by using JIT trampolines. I have no idea how to create them and late fixup their address. Thanks. Korn?l From bojanr at brandeis.edu Fri Oct 10 19:00:16 2008 From: bojanr at brandeis.edu (Bojan Rajkovic) Date: Fri, 10 Oct 2008 19:00:16 -0400 Subject: [Mono-dev] Mono's JIT and SSE instructions Message-ID: <20081010230016.GA30915@bojanr.brandeis.edu> Hi all, How does Mono deal with SSE-capable processors (or Altivec capable processors)? That is, does the JIT emit any SSE calls when there's a chance to use them, or are they totally unused in Mono? Thanks, Bojan Rajkovic -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2263 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081010/ddaf8163/attachment.bin From lupus at ximian.com Fri Oct 10 19:41:18 2008 From: lupus at ximian.com (Paolo Molaro) Date: Sat, 11 Oct 2008 01:41:18 +0200 Subject: [Mono-dev] How to create a JIT trampoline? In-Reply-To: <48EFC0A3.8050603@gmail.com> References: <48EFC0A3.8050603@gmail.com> Message-ID: <20081010234118.GX27246@debian.org> On 10/10/08 Korn?l P?l wrote: > Currently mono_image_fixup_vtable actually compiles methods that causes > type loads as well and requires the assembly to be loaded. > > Please help with letting me know how could I avoiding this by using JIT > trampolines. I have no idea how to create them and late fixup their address. You can use mono_runtime_create_jump_trampoline (), though it's not really clear what domain you should use, I guess the root domain would work in most cases. If this is to work for other domains as well, you will need more work, I don't know the details of how the methods exported this way are supposed to behave. To optimize the calls after the first something like the current jump_target_got_slot_hash hash may be used so the function address is replaced with the compiled method's code instead of going through the trampoline every time. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Fri Oct 10 19:45:58 2008 From: lupus at ximian.com (Paolo Molaro) Date: Sat, 11 Oct 2008 01:45:58 +0200 Subject: [Mono-dev] Mono's JIT and SSE instructions In-Reply-To: <20081010230016.GA30915@bojanr.brandeis.edu> References: <20081010230016.GA30915@bojanr.brandeis.edu> Message-ID: <20081010234558.GY27246@debian.org> On 10/10/08 Bojan Rajkovic wrote: > How does Mono deal with SSE-capable processors (or Altivec capable > processors)? That is, does the JIT emit any SSE calls when there's a > chance to use them, or are they totally unused in Mono? We use some of the SSE instructios if available on x86. On amd64 they are obviously used to implement the fp support. We don't use any altivec instruction as that is pretty much pointless. We don't auto vectorize from IL code, but we're developing an extension that allows people to take advantage of sse instructions with intrinsics (people watching the changes list can see it already). lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From Dax at daxxfiles.net Fri Oct 10 20:01:50 2008 From: Dax at daxxfiles.net (Dax) Date: Sat, 11 Oct 2008 02:01:50 +0200 Subject: [Mono-dev] Mono's JIT and SSE instructions In-Reply-To: <20081010234558.GY27246@debian.org> References: <20081010230016.GA30915@bojanr.brandeis.edu> <20081010234558.GY27246@debian.org> Message-ID: <48EFECEE.9000402@daxxfiles.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paolo Molaro wrote: > We don't auto vectorize from IL code, but we're developing an extension > that allows people to take advantage of sse instructions with > intrinsics (people watching the changes list can see it already). That said, what versions of SSE will be supported? Original SSE only, since it's probably available on every mono-compatible machine, everything up to SSSE3/SSE4..? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjv7O4ACgkQU1h3wAxL79ithwCfWawHcmn3qd4XB/WfcDZVWXLL qtoAn0ayqtxqMofMsHB9QXFzsk02xD8Q =DtZP -----END PGP SIGNATURE----- From lupus at ximian.com Fri Oct 10 20:06:00 2008 From: lupus at ximian.com (Paolo Molaro) Date: Sat, 11 Oct 2008 02:06:00 +0200 Subject: [Mono-dev] Mono's JIT and SSE instructions In-Reply-To: <48EFECEE.9000402@daxxfiles.net> References: <20081010230016.GA30915@bojanr.brandeis.edu> <20081010234558.GY27246@debian.org> <48EFECEE.9000402@daxxfiles.net> Message-ID: <20081011000600.GZ27246@debian.org> On 10/11/08 Dax wrote: > Paolo Molaro wrote: > > We don't auto vectorize from IL code, but we're developing an extension > > that allows people to take advantage of sse instructions with > > intrinsics (people watching the changes list can see it already). > > That said, what versions of SSE will be supported? Original SSE only, > since it's probably available on every mono-compatible machine, > everything up to SSSE3/SSE4..? We'll use what is needed and available on the cpu that's running the mono process. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From jacobgladish at yahoo.com Fri Oct 10 21:03:03 2008 From: jacobgladish at yahoo.com (Jacob Gladish) Date: Fri, 10 Oct 2008 18:03:03 -0700 (PDT) Subject: [Mono-dev] svn trunk broken? Message-ID: <398632.28024.qm@web39503.mail.mud.yahoo.com> I just sync'd up to the trunk and my build is failing. Any ideas? make[4]: Leaving directory `/home/jake/mono/mono' LD pedump ./.libs/libmonoruntime.a(gc.o): In function `finalizer_thread': /home/jake/mono/mono/mono/metadata/gc.c:914: undefined reference to `mono_attach_maybe_start' ./.libs/libmonoruntime.a(appdomain.o): In function `mono_runtime_cleanup': /home/jake/mono/mono/mono/metadata/appdomain.c:282: undefined reference to `mono_attach_cleanup ' ./.libs/libmonoruntime.a(appdomain.o): In function `mono_runtime_init': /home/jake/mono/mono/mono/metadata/appdomain.c:219: undefined reference to `mono_attach_init' collect2: ld returned 1 exit status From Dax at daxxfiles.net Fri Oct 10 22:01:23 2008 From: Dax at daxxfiles.net (Dax) Date: Sat, 11 Oct 2008 04:01:23 +0200 Subject: [Mono-dev] svn trunk broken? In-Reply-To: <398632.28024.qm@web39503.mail.mud.yahoo.com> References: <398632.28024.qm@web39503.mail.mud.yahoo.com> Message-ID: <48F008F3.5060609@daxxfiles.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jacob Gladish wrote: > I just sync'd up to the trunk and my build is failing. Any ideas? You might want to run a full clean (svn clean, make clean, reconfigure) and retry - that fixed that for me a few days ago. If not, deleting your local copy (saving all diffs, if applicable) and checking out again should do. bedah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjwCPMACgkQU1h3wAxL79gucQCgxlEimKF0V/WuyKfupBb4BILd 0QEAoKTCAZUc+AG9rE/U0uUfYWNEWyvb =yzOi -----END PGP SIGNATURE----- From kumpera at gmail.com Fri Oct 10 22:16:39 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Fri, 10 Oct 2008 23:16:39 -0300 Subject: [Mono-dev] Mono's JIT and SSE instructions In-Reply-To: <48EFECEE.9000402@daxxfiles.net> References: <20081010230016.GA30915@bojanr.brandeis.edu> <20081010234558.GY27246@debian.org> <48EFECEE.9000402@daxxfiles.net> Message-ID: <8cca42d80810101916g63ac7db3h6cc18922ab9ef292@mail.gmail.com> On Fri, Oct 10, 2008 at 9:01 PM, Dax wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paolo Molaro wrote: > > We don't auto vectorize from IL code, but we're developing an extension > > that allows people to take advantage of sse instructions with > > intrinsics (people watching the changes list can see it already). > > That said, what versions of SSE will be supported? Original SSE only, > since it's probably available on every mono-compatible machine, > everything up to SSSE3/SSE4..? > Everything up to SSE4.2 as this is what is available on the current generation of CPUs. Thing that won't be supported includes MMX and 3DNow. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081010/7bd01ca1/attachment-0001.html From kornelpal at gmail.com Sat Oct 11 05:04:42 2008 From: kornelpal at gmail.com (=?ISO-8859-2?Q?Korn=E9l_P=E1l?=) Date: Sat, 11 Oct 2008 11:04:42 +0200 Subject: [Mono-dev] Build broken on Windows Message-ID: <48F06C2A.6020509@gmail.com> Hi, I get: $ make make all-recursive make[1]: Entering directory `/mono/mono' Making all in po make[2]: Entering directory `/mono/mono/po' Making all in mcs make[3]: Entering directory `/mono/mono/po/mcs' test ! -f ./mcs.pot || \ test -z "es.gmo ja.gmo de.gmo" || make es.gmo ja.gmo de.gmo make[4]: Entering directory `/mono/mono/po/mcs' rm -f es.gmo && : -c --statistics -o es.gmo es.po mv: cannot stat `t-es.gmo': No such file or directory make[4]: *** [es.gmo] Error 1 make[4]: Leaving directory `/mono/mono/po/mcs' make[3]: *** [stamp-po] Error 2 make[3]: Leaving directory `/mono/mono/po/mcs' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/mono/mono/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/mono/mono' make: *** [all] Error 2 Do I miss some packages or how am I supposed to avoid this? Thanks. Korn?l From andyhume32 at yahoo.co.uk Sat Oct 11 06:12:58 2008 From: andyhume32 at yahoo.co.uk (Andy Hume) Date: Sat, 11 Oct 2008 03:12:58 -0700 (PDT) Subject: [Mono-dev] Build broken on Windows In-Reply-To: <48F06C2A.6020509@gmail.com> References: <48F06C2A.6020509@gmail.com> Message-ID: <19931284.post@talk.nabble.com> Install cygwin's gettext-devel package and it'll then work. :-) See Robert's answer at http://lists.ximian.com/pipermail/mono-list/2008-September/039671.html Andy Korn?l P?l wrote: > > Hi, > > I get: > $ make > make all-recursive > make[1]: Entering directory `/mono/mono' > Making all in po > make[2]: Entering directory `/mono/mono/po' > Making all in mcs > make[3]: Entering directory `/mono/mono/po/mcs' > test ! -f ./mcs.pot || \ > test -z "es.gmo ja.gmo de.gmo" || make es.gmo ja.gmo de.gmo > make[4]: Entering directory `/mono/mono/po/mcs' > rm -f es.gmo && : -c --statistics -o es.gmo es.po > mv: cannot stat `t-es.gmo': No such file or directory > make[4]: *** [es.gmo] Error 1 > make[4]: Leaving directory `/mono/mono/po/mcs' > make[3]: *** [stamp-po] Error 2 > make[3]: Leaving directory `/mono/mono/po/mcs' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/mono/mono/po' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/mono/mono' > make: *** [all] Error 2 > > Do I miss some packages or how am I supposed to avoid this? > > Thanks. > > Korn?l > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- View this message in context: http://www.nabble.com/Build-broken-on-Windows-tp19930871p19931284.html Sent from the Mono - Dev mailing list archive at Nabble.com. From atsushi at ximian.com Sat Oct 11 07:44:14 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Sat, 11 Oct 2008 20:44:14 +0900 Subject: [Mono-dev] [PATCH] System.Messaging using AMQP (RabbitMQ) In-Reply-To: <80d1dfde0810080004k3d651576o70cd2baf51dbbad5@mail.gmail.com> References: <80d1dfde0810060108j62b1198egd0a61a3e29fcb12a@mail.gmail.com> <80d1dfde0810080004k3d651576o70cd2baf51dbbad5@mail.gmail.com> Message-ID: <48F0918E.5020602@ximian.com> Hello, Michael Barker wrote: > Thanks a lot for the updated implementation since April :) I had > > a look at the patch, and noticed that some essential stuff such as > MessageQueue.GetEnumerator() and MessageEnumerator are left > unimplemented. > > I've just had a look at the MessageEnumerator API and I'm not sure if it > can be implemented using AMQP as I don't think that its possible to > selectively remove messages from a queue (except with selectors, but > I'll get to that). I'll try prototype it, but if it can't be > implemented do you think that an AMQP solution would be a no go? Well, I'm rather afraid of having Mono.Messaging base API dependent on Rabbit (by "dependent" I don't mean that Mono.Messaging.dll has reference to Mono.Messaging.RabbitMQ.dll). AMQP solution might not be chosen if it lacks significant functionality, but that does not mean it is no-go. If Rabbit based implementation does not work here, I rather assume nothing would work fine here ;) > BTW do you know if AMQP/Rabbit is going to support message peek > > and receive-by-id functionality (in some milestones), as you > mentioned in the early discussion ? > http://www.mail-archive.com/mono-devel-list lists.ximian.com/msg16731.htm > > I had a chat with one of the standards committee members at a conference > around the end of April. Selectors (to support ReceiveById) are > unlikely to be part of the standard, although there was a message on the > RabbitMQ list indicating that they'll probably add a server extension > (that's compatible with Apache QPid) to support it. Queue browsers are > being considered, but peek functionality can be fudged by not > acknowleding messages. The other area where there is a mismatch is > queue discovery, AMQP uses a declare model, i.e. all queues exist, but > its not possible to find what they're called. Queue discovery is being > considered for a future revision too. OK. If Rabbit .NET binding supports such extensions, you could simply use them. The binding does not have to be limited to AMQP (still might be better to have Rabbit/Qpid bindings based on AMQP binding based on Mono.Messaging though). Atsushi Eno From atsushi at ximian.com Sat Oct 11 07:46:47 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Sat, 11 Oct 2008 20:46:47 +0900 Subject: [Mono-dev] [WF] who is involved in Workflow develop? In-Reply-To: <004c01c929ea$0d17cf00$1700a8c0@sintelvdh.com> References: <004c01c929ea$0d17cf00$1700a8c0@sintelvdh.com> Message-ID: <48F09227.2000209@ximian.com> Hello, Currently there is no one hacking workflow implementation. There was early work by Jordi in olive module couple of years ago, and then it has been in deep hibernation. See http://anonsvn.mono-project.com/viewvc/trunk/olive/class/System.Workflow.Runtime/ (and its family components). Atsushi Eno Federico Ballan wrote: > Sorry in advance for my english: I hope this is the correct mailing list for > my question on Workflow. > > I'm a developer for vending machine and automation control on Windows > Workflow Foundation: now our products are Ms Windows based but we are > thinking about porting proects on Linux so on Mono. > > I wish to known some details on next Mono Workflow implementation and I wish > to notify some actual limitation (i think the name is BUG) on original > Microsoft Workflow Visual Studio Designer (if those bugs are relevant for > Mono Develop) > > I already notify these bugs on Microsoft Connect so you may see them > directly on those site. > > - StateMachineWorkflow designer is too slow > https://connect.microsoft.com/wf/feedback/ViewFeedback.aspx?FeedbackID=323904 > > - StateMachineWorkflow designer autoredraw move nested states outside > container > https://connect.microsoft.com/wf/feedback/ViewFeedback.aspx?FeedbackID=323899 > > In general you may search for bugs in Workflow signed by 'fedeballan', my > nickname in Microsoft Connect. > > Thank You. > > Federico Ballan > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From gnorton at novell.com Fri Oct 10 22:27:33 2008 From: gnorton at novell.com (Geoff Norton) Date: Fri, 10 Oct 2008 22:27:33 -0400 Subject: [Mono-dev] Mono's JIT and SSE instructions In-Reply-To: <8cca42d80810101916g63ac7db3h6cc18922ab9ef292@mail.gmail.com> References: <20081010230016.GA30915@bojanr.brandeis.edu> <20081010234558.GY27246@debian.org> <48EFECEE.9000402@daxxfiles.net> <8cca42d80810101916g63ac7db3h6cc18922ab9ef292@mail.gmail.com> Message-ID: <1223692054.11319.280.camel@limestone> On Fri, 2008-10-10 at 23:16 -0300, Rodrigo Kumpera wrote: > > > On Fri, Oct 10, 2008 at 9:01 PM, Dax wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paolo Molaro wrote: > > We don't auto vectorize from IL code, but we're developing > an extension > > that allows people to take advantage of sse instructions > with > > intrinsics (people watching the changes list can see it > already). > > > That said, what versions of SSE will be supported? Original > SSE only, > since it's probably available on every mono-compatible > machine, > everything up to SSSE3/SSE4..? > > Everything up to SSE4.2 as this is what is available on the current > generation of CPUs. > > Thing that won't be supported includes MMX and 3DNow. Its also worth noting that SSE5 is (yet another) weird naming scheme in the superset scheme of things. AMD has announced it, but its not a superset of (all) of SSE4 but a competitor for (some) of it. Just to muddy the water a little more. I imagine when SSE5 is finalized and shipped we'll add support for it to Mono.Simd as well. -g From niksisavailable at gmail.com Sat Oct 11 10:56:44 2008 From: niksisavailable at gmail.com (Bas Smit) Date: Sat, 11 Oct 2008 07:56:44 -0700 (PDT) Subject: [Mono-dev] Compiling mono from the repository In-Reply-To: <4E8AF960-694D-464D-8A86-BC237C2B4B5D@brandeis.edu> References: <4E8AF960-694D-464D-8A86-BC237C2B4B5D@brandeis.edu> Message-ID: <19933265.post@talk.nabble.com> Hi guys, thanks for the replies. Im sorry to say I just forgot to checkout mcs, I was under the impression it had to be installed and could be gotten from the same location just for convenience. Bas Bojan Rajkovic wrote: > > Did you make sure to checkout mcs too? > > On Oct 9, 2008, at 11:49 AM, Bas Smit wrote: > >> >> Hi guys, >> >> First off, im new to mono and ubuntu so I might be missing something >> obvious. Im trying to compile mono from the repository, on ubuntu. >> I've >> followed the instructions on http://www.mono-project.com/Compiling_Mono >> but >> when I autogen I get the following error: >> >> ... >> ... >> checking for ieeefp.h... no >> checking for isinf... yes >> checking for void *... yes >> checking size of void *... 4 >> checking for -Wdeclaration-after-statement option to gcc... yes >> checking integrity of package... configure: error: Your mono >> distribution is >> incomplete; if unpacking from a tar file, make sure you use GNU >> tar; see >> http://www.mono-project.com/IncompletePackage for more details >> >> Ive tried creating a new checkout, but the package really seems >> incomplete. >> Im 99% sure I've got mono, mcs, glib and pkg-config installed >> correctly. >> Could someone point out what I could be doing wrong? >> >> Many thanks, Bas >> -- >> View this message in context: >> http://www.nabble.com/Compiling-mono-from-the-repository-tp19901757p19901757.html >> Sent from the Mono - Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- View this message in context: http://www.nabble.com/Re%3A-Compiling-mono-from-the-repository-tp19907513p19933265.html Sent from the Mono - Dev mailing list archive at Nabble.com. From mkestner at gmail.com Sat Oct 11 14:53:48 2008 From: mkestner at gmail.com (Mike Kestner) Date: Sat, 11 Oct 2008 13:53:48 -0500 Subject: [Mono-dev] why does gtk# installer requires .net 1.1 ? In-Reply-To: <8a7a2d050810090007o13771519g543d6b8086386b80@mail.gmail.com> References: <8a7a2d050810090007o13771519g543d6b8086386b80@mail.gmail.com> Message-ID: <1223751228.4287.3.camel@linux-wpou.site> On Thu, 2008-10-09 at 10:07 +0300, Onur Gumus wrote: > It seems gtk# requires .net 1.1 explicitly for windows. Though this > seems to be an unrealistic requirement if people want GTK# usage > increase on windows as well. As you would guess, vast majority of > windows boxes has .net 2.0+. Any improvements possible ? Right now, gtk-sharp requires the 1.1 SDK to build. Starting with the 2.10 installers though, I'm told that the installer doesn't require 1.1. There is no technical reason I am aware of that the gtk-sharp assemblies should require 1.1 at runtime. Can you confirm which installer you are referring to? -- Mike Kestner From emperon at gmail.com Sat Oct 11 15:02:20 2008 From: emperon at gmail.com (Onur Gumus) Date: Sat, 11 Oct 2008 22:02:20 +0300 Subject: [Mono-dev] why does gtk# installer requires .net 1.1 ? In-Reply-To: <1223751228.4287.3.camel@linux-wpou.site> References: <8a7a2d050810090007o13771519g543d6b8086386b80@mail.gmail.com> <1223751228.4287.3.camel@linux-wpou.site> Message-ID: <8a7a2d050810111202l1e014f80udf8f925fd046da9a@mail.gmail.com> Both 2.10 and 2.8 asked me .net 1.1 sdk On Sat, Oct 11, 2008 at 9:53 PM, Mike Kestner wrote: > On Thu, 2008-10-09 at 10:07 +0300, Onur Gumus wrote: >> It seems gtk# requires .net 1.1 explicitly for windows. Though this >> seems to be an unrealistic requirement if people want GTK# usage >> increase on windows as well. As you would guess, vast majority of >> windows boxes has .net 2.0+. Any improvements possible ? > > Right now, gtk-sharp requires the 1.1 SDK to build. Starting with the > 2.10 installers though, I'm told that the installer doesn't require 1.1. > There is no technical reason I am aware of that the gtk-sharp assemblies > should require 1.1 at runtime. > > Can you confirm which installer you are referring to? > > > -- > Mike Kestner > > From carsten.harnisch at intradesys.com Sun Oct 12 08:08:33 2008 From: carsten.harnisch at intradesys.com (Carsten Harnisch) Date: Sun, 12 Oct 2008 05:08:33 -0700 (PDT) Subject: [Mono-dev] genmdesc (c-version) seems to be broken Message-ID: <19941055.post@talk.nabble.com> I tried to build mono from source on a debian box (running under amd64). I got a problem with the genmdesc-submake. The c-version reports continously errors while processing the cpu-amd64.md file. The perl-version seems to work; so switching the genmdesc-pkg to the perl-version works fine. Anyway manually configure for linux-i386 also produce a running system. best wishes Carsten -- View this message in context: http://www.nabble.com/genmdesc-%28c-version%29-seems-to-be-broken-tp19941055p19941055.html Sent from the Mono - Dev mailing list archive at Nabble.com. From andreas.faerber at web.de Sun Oct 12 15:03:28 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 12 Oct 2008 21:03:28 +0200 Subject: [Mono-dev] Fwd: mono 2.0, solaris x86, bootstrap References: <80002D9E-A8A0-4FE4-8D0D-98FD519FA113@web.de> Message-ID: > Here's my Solaris 10 build environment: > > PATH=/usr/local/bin:/opt/gdb/bin:/opt/mono/bin:/opt/sfw/bin:/opt/sfw/ > sbin:/usr/sfw/bin:/usr/bin:/usr/dt/bin:/usr/openwin/bin > export PATH > export MAKE=gmake > export AR=gar > export STRIP=gstrip > export RANLIB=granlib > export AS=gas Note: /opt/gdb is a self-compiled amd64 GDB - not needed for bootstrapping. Some GNU packages from the Companion CD are used here, Subversion comes from sunfreeware.com. > x86: > > GC_PREFIX=/opt/mono-gc7.0 > ../gc-7.0/configure --prefix=$GC_PREFIX CC=gcc MAKE=gmake AR=gar > RANLIB=granlib STRIP=gstrip AS=gas INSTALL=/usr/ucb/install > > ../mono/configure --prefix=/opt/mono --with-tls=pthread --with- > sigaltstack=no --with-gc=boehm --enable-dtrace \ > CC=gcc MAKE=gmake AR=gar RANLIB=granlib STRIP=gstrip AS=gas INSTALL=/ > usr/ucb/install \ > CPPFLAGS=-I/opt/mono-gc7.0/include LDFLAGS=-L/opt/mono-gc7.0/lib > > amd64: > > export LD_LIBRARY_PATH=/usr/sfw/lib/amd64:$LD_LIBRARY_PATH > GC_PREFIX=/opt/mono-gc7.0 > ../gc-7.0/configure --prefix=$GC_PREFIX --libdir=$GC_PREFIX/lib/ > amd64 CC=gcc CFLAGS=-m64 MAKE=gmake AR=gar RANLIB=granlib > STRIP=gstrip CCAS=gas CCASFLAGS=-64 INSTALL=/usr/ucb/install > > export LD_LIBRARY_PATH=/usr/sfw/lib/amd64:$LD_LIBRARY_PATH > MONO_PREFIX=/opt/mono > ../mono/configure --prefix=$MONO_PREFIX --bindir=$MONO_PREFIX/bin/ > amd64 --libdir=$MONO_PREFIX/lib/amd64 --with-tls=pthread --with- > sigaltstack=no --with-gc=boehm --disable-mcs-build CC="gcc -m64" > MAKE=gmake AR=gar RANLIB=granlib STRIP=gstrip AS="gas -64" INSTALL=/ > usr/ucb/install CPPFLAGS=-I/opt/mono-gc7.0/include LDFLAGS=-L/opt/ > mono-gc7.0/lib/amd64 PKG_CONFIG_PATH=/usr/lib/amd64/pkgconfig:/opt/ > mono-gc7.0/lib/amd64/pkgconfig > > Just quickly grabbed my scripts, didn't try HEAD, but it was likely > something in the 1.9 range. ... more precisely, it was what my DTrace patch was tested on. HTH, Andreas From mike at middlesoft.co.uk Sun Oct 12 21:36:21 2008 From: mike at middlesoft.co.uk (Michael Barker) Date: Mon, 13 Oct 2008 14:36:21 +1300 Subject: [Mono-dev] Fwd: [PATCH] System.Messaging using AMQP (RabbitMQ) In-Reply-To: <80d1dfde0810112146n70f33f7ftefcf756438819c88@mail.gmail.com> References: <80d1dfde0810060108j62b1198egd0a61a3e29fcb12a@mail.gmail.com> <80d1dfde0810080004k3d651576o70cd2baf51dbbad5@mail.gmail.com> <48F0918E.5020602@ximian.com> <80d1dfde0810112146n70f33f7ftefcf756438819c88@mail.gmail.com> Message-ID: <80d1dfde0810121836w1b9f36b0i6c1a9879f20312ce@mail.gmail.com> Forgot to CC the list. ---------- Forwarded message ---------- From: Michael Barker Date: Sun, Oct 12, 2008 at 5:46 PM Subject: Re: [Mono-dev] [PATCH] System.Messaging using AMQP (RabbitMQ) To: Atsushi Eno Hi, I have updated the bug report (https://bugzilla.novell.com/show_bug.cgi?id=432471) to include a first cut of MessageEnumerators. It does seem to work, originally I though that an AMQP Ack would acknowledge all messages up to that point, but that does not seem to be the case, so I can implement the System.Messaging behaviour reasonably well. > Well, I'm rather afraid of having Mono.Messaging base API dependent > on Rabbit (by "dependent" I don't mean that Mono.Messaging.dll has > reference to Mono.Messaging.RabbitMQ.dll). AMQP solution might not > be chosen if it lacks significant functionality, but that does not > mean it is no-go. If Rabbit based implementation does not work here, > I rather assume nothing would work fine here ;) I would be useful if you could describe what you mean by dependent? I'm assuming that you're referring to the design of the API. I've tried hard to avoid designing Mono.Messaging based on the RabbitMQ bindings. The majority of it is direct delegation from the System.Messaging library (expect for the parts that don't need to happen in Messaging implementation, e.g. formatting), so the Mono.Messaging is more dependent on that library. Also I think that Mono.Messaging should be considered only as an SPI, not an API. Anyone writing an application requiring a brand new application should either use System.Messaging or the messaging API for the bus that are interested in using. That way we will only have a single client of Mono.Messaging (i.e. System.Messaging) making it reasonably easy to change as required, assuming that most of the implementations of Mono.Messaging are included in the mono build. RE: AMQP, If its of any use here are a list of the main features and how they can be supported: Supported easily through the standard: - Basic Messaging Send/Receive - Message Listeners - Transactions Supported with a couple jumps through hoops: - Peek() (may be better supported through queue browsers later on) - Message Enumerators Supported only with custom extensions to the server: - {Receive,Peek}By{Id,CorrelationId,..} Supported only with later potential protocol updates: - Queue discovery If you have some good ideas about how System.Messaging should be implemented, send them through. Regards, Michael Barker. From shane.isbell at gmail.com Sun Oct 12 23:32:25 2008 From: shane.isbell at gmail.com (Shane Isbell) Date: Sun, 12 Oct 2008 20:32:25 -0700 Subject: [Mono-dev] How to: Run tar command from c# app In-Reply-To: <19675227.post@talk.nabble.com> References: <19675227.post@talk.nabble.com> Message-ID: There is a tar utility written in C# that I wrote last year: http://www.codeplex.com/Archivist. You can use it from the command line or from within an application. Shane On Thu, Sep 25, 2008 at 11:05 AM, ebonnett wrote: > > Hi all, > > How would I run a tar command from a c# app on mono (1.9.1) on Debian? > Would I use the Process and ProcessStartInfo object? > > My time is short so any help would be greatly appreciated. > > Thanks, > > Ebonnett > -- > View this message in context: > http://www.nabble.com/How-to%3A-Run-tar-command-from-c--app-tp19675227p19675227.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081012/98b1e363/attachment.html From lupus at ximian.com Mon Oct 13 04:06:23 2008 From: lupus at ximian.com (Paolo Molaro) Date: Mon, 13 Oct 2008 10:06:23 +0200 Subject: [Mono-dev] svn trunk broken? In-Reply-To: <398632.28024.qm@web39503.mail.mud.yahoo.com> References: <398632.28024.qm@web39503.mail.mud.yahoo.com> Message-ID: <20081013080622.GA28194@debian.org> On 10/10/08 Jacob Gladish wrote: > I just sync'd up to the trunk and my build is failing. Any ideas? > > make[4]: Leaving directory `/home/jake/mono/mono' > LD pedump > ./.libs/libmonoruntime.a(gc.o): In function `finalizer_thread': > /home/jake/mono/mono/mono/metadata/gc.c:914: undefined reference to `mono_attach_maybe_start' You didn't run autogen.sh as the build instructions document it is needed when building from a svn snapshot. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From informatique.internet at fiducial.fr Mon Oct 13 11:18:10 2008 From: informatique.internet at fiducial.fr (Hubert FONGARNAND) Date: Mon, 13 Oct 2008 17:18:10 +0200 Subject: [Mono-dev] Mono 2.0 defeat story... Message-ID: <1223911090.18346.28.camel@hublinux.fidudev.fr> Hi, A week ago, i tried to upgrade my mono server from 1.2.6 to the new 2.0 mono version. Bad idea... We use a custom CMS written in C#, it use to work well with 1.2.6 version. We had test mono 2.0 on our beta platform since a month and we had no big problems... But on production servers, the environnment is often different (multi-processor systems, much more users...). I was confident with mono 2.0 as it was supposed to be well tested by novell... The upgrade was really a pain, because we have found at least two bugs in mono : https://bugzilla.novell.com/show_bug.cgi?id=433908 https://bugzilla.novell.com/show_bug.cgi?id=434305 These bugs prevent our CMS app to run correctly on mono... In addition to these bugs we experienced a big memory leak with our mod-mono-server (it use to take ~60Mb (RSS) with mono 1.2.6, with mono 2.0 it was growing up to 3Go). So this week end we had some "out of memory" crash... In addition to this memory leak, the website was slowing down... When i start the mod-mono-server process, the web site speed is good (~900ms/req) and it was getting worse and worse as time... (15s/req) This morning i downgrade to 1.9.1 in hope that it would solve my problems... it solves the two first bugs problems (#433908, #434305); but not my memory leak problem So the last thing to do was to revert to the good one 1.2.6... and my speed and memory problems went away!!! I hope we could upgrade to mono 2.0 when it becomes more stable! I'm ready to help mono guys to trac these problems. best wishes Hubert FONGARNAND FIDUCIAL PS: we already run 1.9.1 on our intranet without any memory leaks problems, but we don't use our CMS PS : we run in a load balancing environnement, i've downgraded on only one server... and keep the other one offline in mono 2.0 to do some tests... _________________________________________________ Ce message et les ?ventuels documents joints peuvent contenir des informations confidentielles. Au cas o? il ne vous serait pas destin?, nous vous remercions de bien vouloir le supprimer et en aviser imm?diatement l'exp?diteur. Toute utilisation de ce message non conforme ? sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'?tant pas s?curis?es, l'int?grit? de ce message n'est pas assur?e et la soci?t? ?mettrice ne peut ?tre tenue pour responsable de son contenu. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081013/58352ea2/attachment.html From Tao.ye at micropatternusa.com Sun Oct 12 04:11:35 2008 From: Tao.ye at micropatternusa.com (Taoye) Date: Sun, 12 Oct 2008 16:11:35 +0800 Subject: [Mono-dev] About DllNotFountExeption Message-ID: <001501c92c42$27904600$1701a8c0@YETAOMPC013> Hello ,Jeffrey. When i run a WinForm App in MonoDevelop , it occurs the following exceptions.See the picture. I have searched in google many times but not find how to resolve.Can you tell me what the problem is? Thanks a lot ! Peter.Ye -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081012/4f5c325f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 89940 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081012/4f5c325f/attachment-0001.jpe From ecanuto at gmail.com Mon Oct 13 12:29:36 2008 From: ecanuto at gmail.com (Everaldo Canuto) Date: Mon, 13 Oct 2008 14:29:36 -0200 Subject: [Mono-dev] About DllNotFountExeption In-Reply-To: <001501c92c42$27904600$1701a8c0@YETAOMPC013> References: <001501c92c42$27904600$1701a8c0@YETAOMPC013> Message-ID: Hey, Do you have libgdiplus package installed ? Everaldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081013/87090bdc/attachment.html From ecanuto at gmail.com Mon Oct 13 12:58:15 2008 From: ecanuto at gmail.com (Everaldo Canuto) Date: Mon, 13 Oct 2008 14:58:15 -0200 Subject: [Mono-dev] About DllNotFountExeption In-Reply-To: <84776a970810130948g15c12cb4icbdf540771ae576@mail.gmail.com> References: <001501c92c42$27904600$1701a8c0@YETAOMPC013> <84776a970810130948g15c12cb4icbdf540771ae576@mail.gmail.com> Message-ID: Hey, Problem still remain after install lidgdiplus and run ldconfig ? Everaldo. On Mon, Oct 13, 2008 at 2:48 PM, Petit Eric wrote: > Le 13 octobre 2008 18:29, Everaldo Canuto a ?crit : > > Hey, > > > > Do you have libgdiplus package installed ? > I think so, too > urpmi -a libgdiplus > apt-get libgdiplus > wget http://anonsvn.mono-project.com/viewvc/trunk/libgdiplus.tar.gz > tar -xf ./libgdiplus.tar.gz > cd libgdiplus > ./configure --prefix=/usr && make > su > make install > lol ;-) > > > > > Everaldo. > > > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > > -- > > Cordially. > > Small Eric Quotations of the days: > --------------------------------------------------------------------------- > If one day one reproaches you that your work is not a work of > professional, say you that: > Amateurs built the arch of Noah, and professionals the Titanic. > --------------------------------------------------------------------------- > > Few people are done for independence, it is the privilege of the powerful > ones. > --------------------------------------------------------------------------- > > No key was wounded during the drafting of this message. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081013/693c030f/attachment.html From surfzoid at gmail.com Mon Oct 13 13:10:41 2008 From: surfzoid at gmail.com (Petit Eric) Date: Mon, 13 Oct 2008 19:10:41 +0200 Subject: [Mono-dev] About DllNotFountExeption In-Reply-To: References: <001501c92c42$27904600$1701a8c0@YETAOMPC013> Message-ID: <84776a970810131010u6d05fe3ap58f7a16bfe28bcc5@mail.gmail.com> Le 13 octobre 2008 18:29, Everaldo Canuto a ?crit : > Hey, > > Do you have libgdiplus package installed ? Damed Gmail, the answer button alway take the last sender and then i forget the list, sorry for that Everaldo So i sayed : I think so, too urpmi -a libgdiplus apt-get libgdiplus wget http://anonsvn.mono-project.com/viewvc/trunk/libgdiplus.tar.gz tar -xf ./libgdiplus.tar.gz cd libgdiplus ./configure --prefix=/usr && make su make install lol ;-) > > Everaldo. > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Cordially. Small Eric Quotations of the days: --------------------------------------------------------------------------- If one day one reproaches you that your work is not a work of professional, say you that: Amateurs built the arch of Noah, and professionals the Titanic. --------------------------------------------------------------------------- Few people are done for independence, it is the privilege of the powerful ones. --------------------------------------------------------------------------- No key was wounded during the drafting of this message. From ylatuya at gmail.com Mon Oct 13 15:50:34 2008 From: ylatuya at gmail.com (Andoni Morales) Date: Mon, 13 Oct 2008 21:50:34 +0200 Subject: [Mono-dev] Dll not found when deploying a mono app into a different machine Message-ID: <772db3280810131250p4cece2e9n9ea14440e52ac783@mail.gmail.com> Hi, I'm having a very strange problem on Windows.... I've created a multimedia player based on GStreamer an Gtk that runs both on Windows and Linux. The GStreamer backend is written in C and wrapped to C# using the GAPI tools, importing my own dll called libcesarplayer.dll. I compile and link libcesaplayer.dll on windows (I've tried both Mingw and MSVC) and all works well. But.... If I try to run my app in my laptop, for example, I got a DllNotFoundException. So, it just works in the computer I used to compile libcesarplayer.dll. Do I have to compile it in a special way? Any suggestion? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081013/4c4a8831/attachment.html From Tao.ye at micropatternusa.com Tue Oct 14 03:19:20 2008 From: Tao.ye at micropatternusa.com (Taoye) Date: Tue, 14 Oct 2008 15:19:20 +0800 Subject: [Mono-dev] About DllNotFountExeption References: <001501c92c42$27904600$1701a8c0@YETAOMPC013> Message-ID: <003901c92dcd$2fd6ed50$1701a8c0@YETAOMPC013> Hi , Everaldo Canuto :? I am sorry , i reply you now. Yes, i installerd the libgdiplus package.Here is the path of the libgdiplus in my system ( Red Hat Enterprise 5 ). See the following: libgdiplus.so.0 (libc6) => /usr/lib/libgdiplus.so.0 libgdiplus.so (libc6) => /usr/lib/libgdiplus.so Thanks a lot! Yetao. ----- Original Message ----- From: Everaldo Canuto To: Taoye Cc: Jeffrey Stedfast ; mono-devel-list at lists.ximian.com Sent: Tuesday, October 14, 2008 12:29 AM Subject: Re: [Mono-dev] About DllNotFountExeption Hey, Do you have libgdiplus package installed ? Everaldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081014/df30e0ab/attachment.html From surfzoid at gmail.com Tue Oct 14 03:55:35 2008 From: surfzoid at gmail.com (Petit Eric) Date: Tue, 14 Oct 2008 09:55:35 +0200 Subject: [Mono-dev] About DllNotFountExeption In-Reply-To: <003901c92dcd$2fd6ed50$1701a8c0@YETAOMPC013> References: <001501c92c42$27904600$1701a8c0@YETAOMPC013> <003901c92dcd$2fd6ed50$1701a8c0@YETAOMPC013> Message-ID: <84776a970810140055v182abc9fu9328d01234349bde@mail.gmail.com> Le 14 octobre 2008 09:19, Taoye a ?crit : > Hi , Everaldo Canuto : > > I am sorry , i reply you now. Yes, i installerd the libgdiplus > package.Here is the path of the libgdiplus in my system ( Red Hat Enterprise > 5 ). See the following: > > libgdiplus.so.0 (libc6) => /usr/lib/libgdiplus.so.0 > libgdiplus.so (libc6) => > /usr/lib/libgdiplus.so I don't remember exactly depandancy, i think there is pango and cairo ? > > Thanks a lot! > > Yetao. > > > > > > ----- Original Message ----- > From: Everaldo Canuto > To: Taoye > Cc: Jeffrey Stedfast ; mono-devel-list at lists.ximian.com > Sent: Tuesday, October 14, 2008 12:29 AM > Subject: Re: [Mono-dev] About DllNotFountExeption > Hey, > > Do you have libgdiplus package installed ? > > Everaldo. > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Cordially. Small Eric Quotations of the days: --------------------------------------------------------------------------- If one day one reproaches you that your work is not a work of professional, say you that: Amateurs built the arch of Noah, and professionals the Titanic. --------------------------------------------------------------------------- Few people are done for independence, it is the privilege of the powerful ones. --------------------------------------------------------------------------- No key was wounded during the drafting of this message. From paul at all-the-johnsons.co.uk Tue Oct 14 04:56:42 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 14 Oct 2008 09:56:42 +0100 Subject: [Mono-dev] About DllNotFountExeption In-Reply-To: <003901c92dcd$2fd6ed50$1701a8c0@YETAOMPC013> References: <001501c92c42$27904600$1701a8c0@YETAOMPC013> <003901c92dcd$2fd6ed50$1701a8c0@YETAOMPC013> Message-ID: <1223974602.18629.38.camel@PB3.Linux> Hi, > I am sorry , i reply you now. Yes, i installerd the libgdiplus > package.Here is the path of the libgdiplus in my system ( Red Hat > Enterprise 5 ). See the following: > > libgdiplus.so.0 (libc6) => /usr/lib/libgdiplus.so.0 > libgdiplus.so (libc6) > => /usr/lib/libgdiplus.so Assuming you're using the RedHat supplied RPMs over any others, you also need to install the libgdiplus-devel subpackage. It's a known bug that we're trying to fix in a way which doesn't break everything else! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081014/9e89273e/attachment-0001.bin From sebastien.pouliot at gmail.com Tue Oct 14 08:30:39 2008 From: sebastien.pouliot at gmail.com (Sebastien Pouliot) Date: Tue, 14 Oct 2008 08:30:39 -0400 Subject: [Mono-dev] About DllNotFountExeption In-Reply-To: <84776a970810140055v182abc9fu9328d01234349bde@mail.gmail.com> References: <001501c92c42$27904600$1701a8c0@YETAOMPC013> <003901c92dcd$2fd6ed50$1701a8c0@YETAOMPC013> <84776a970810140055v182abc9fu9328d01234349bde@mail.gmail.com> Message-ID: <1223987439.3951.526.camel@mizar.home> On Tue, 2008-10-14 at 09:55 +0200, Petit Eric wrote: > Le 14 octobre 2008 09:19, Taoye a ?crit : > > Hi , Everaldo Canuto : > > > > I am sorry , i reply you now. Yes, i installerd the libgdiplus > > package.Here is the path of the libgdiplus in my system ( Red Hat Enterprise > > 5 ). See the following: > > > > libgdiplus.so.0 (libc6) => /usr/lib/libgdiplus.so.0 > > libgdiplus.so (libc6) => > > /usr/lib/libgdiplus.so > I don't remember exactly depandancy, i think there is pango and cairo > ? No in both case. Libgdiplus use it's embedded copy of cairo and does not depend on pango. Anyway his package management software should have tracked anything else he requires. > > > > Thanks a lot! > > > > Yetao. > > > > > > > > > > > > ----- Original Message ----- > > From: Everaldo Canuto > > To: Taoye > > Cc: Jeffrey Stedfast ; mono-devel-list at lists.ximian.com > > Sent: Tuesday, October 14, 2008 12:29 AM > > Subject: Re: [Mono-dev] About DllNotFountExeption > > Hey, > > > > Do you have libgdiplus package installed ? > > > > Everaldo. > > > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > From surfzoid at gmail.com Tue Oct 14 08:43:35 2008 From: surfzoid at gmail.com (Petit Eric) Date: Tue, 14 Oct 2008 14:43:35 +0200 Subject: [Mono-dev] About DllNotFountExeption In-Reply-To: <1223987439.3951.526.camel@mizar.home> References: <001501c92c42$27904600$1701a8c0@YETAOMPC013> <003901c92dcd$2fd6ed50$1701a8c0@YETAOMPC013> <84776a970810140055v182abc9fu9328d01234349bde@mail.gmail.com> <1223987439.3951.526.camel@mizar.home> Message-ID: <84776a970810140543u1184c81ao741d5765634d09ac@mail.gmail.com> 2008/10/14 Sebastien Pouliot : > On Tue, 2008-10-14 at 09:55 +0200, Petit Eric wrote: >> Le 14 octobre 2008 09:19, Taoye a ?crit : >> > Hi , Everaldo Canuto : >> > >> > I am sorry , i reply you now. Yes, i installerd the libgdiplus >> > package.Here is the path of the libgdiplus in my system ( Red Hat Enterprise >> > 5 ). See the following: >> > >> > libgdiplus.so.0 (libc6) => /usr/lib/libgdiplus.so.0 >> > libgdiplus.so (libc6) => >> > /usr/lib/libgdiplus.so >> I don't remember exactly depandancy, i think there is pango and cairo >> ? > > No in both case. Libgdiplus use it's embedded copy of cairo and does not > depend on pango. > > Anyway his package management software should have tracked anything else > he requires. Well, i say that because i already see Pkg manager, or Rpm built, whit depandancy problem. Also Paul i answered, he 's need to install the devel pkg of libgdiplus, this is a bug and paul trying to fix it. > >> > >> > Thanks a lot! >> > >> > Yetao. >> > >> > >> > >> > >> > >> > ----- Original Message ----- >> > From: Everaldo Canuto >> > To: Taoye >> > Cc: Jeffrey Stedfast ; mono-devel-list at lists.ximian.com >> > Sent: Tuesday, October 14, 2008 12:29 AM >> > Subject: Re: [Mono-dev] About DllNotFountExeption >> > Hey, >> > >> > Do you have libgdiplus package installed ? >> > >> > Everaldo. >> > >> > >> > _______________________________________________ >> > Mono-devel-list mailing list >> > Mono-devel-list at lists.ximian.com >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > >> > >> >> >> > > -- Cordially. Small Eric Quotations of the days: --------------------------------------------------------------------------- If one day one reproaches you that your work is not a work of professional, say you that: Amateurs built the arch of Noah, and professionals the Titanic. --------------------------------------------------------------------------- Few people are done for independence, it is the privilege of the powerful ones. --------------------------------------------------------------------------- No key was wounded during the drafting of this message. From mhorsley at vqlive.com Tue Oct 14 10:22:27 2008 From: mhorsley at vqlive.com (mike horsley) Date: Tue, 14 Oct 2008 15:22:27 +0100 Subject: [Mono-dev] problems compiling using System.Configuration using Mono 2.0 Message-ID: <006801c92e08$496ac580$9c01a8c0@VQsteve> I can use the following on MS: System.Configuration.ConfigurationManager.AppSettings(....) This requires a reference to System.Configuration. I'm trying to do the same on mono 2.0 (using the VMWARE image) but cant figure out what reference I need to give mcs to get it to compile. I've tried "-r:System.Configuration.dll" and get the mcs error "cannot find metadata file 'System.Configuration.dll" whereas if I use "-r:System.Configuration.Install.dll" (having found the dlls in /user/lib/mono/2.0/) I get the mcs error "Error CS0234 the type or namespace 'ConfigurationManager' does not exist in the namespace 'System.Configuration' are you missing an assembly reference? I can use the legacy mode ConfigurationSettings.AppSettings but this then means I have 2 variants of code (one for Windows, one for Linux) Any help appreciated! Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081014/1cc2208d/attachment.html From billholmes54 at gmail.com Tue Oct 14 11:56:25 2008 From: billholmes54 at gmail.com (Bill Holmes) Date: Tue, 14 Oct 2008 11:56:25 -0400 Subject: [Mono-dev] problems compiling using System.Configuration using Mono 2.0 In-Reply-To: <006801c92e08$496ac580$9c01a8c0@VQsteve> References: <006801c92e08$496ac580$9c01a8c0@VQsteve> Message-ID: <37c5788d0810140856j4b4fd694r1a04ad16d200120b@mail.gmail.com> Hi, Try gmcs instead of mcs. -bill 2008/10/14 mike horsley : > I can use the following on MS: > > System.Configuration.ConfigurationManager.AppSettings(??..) > > > > This requires a reference to System.Configuration. > > > > I'm trying to do the same on mono 2.0 (using the VMWARE image) but cant > figure out what reference I need to give mcs to get it to compile. > > > > I've tried "-r:System.Configuration.dll" and get the mcs error "cannot find > metadata file 'System.Configuration.dll" whereas if I use > "-r:System.Configuration.Install.dll" (having found the dlls in > /user/lib/mono/2.0/) I get the mcs error "Error CS0234 the type or namespace > 'ConfigurationManager' does not exist in the namespace > 'System.Configuration' are you missing an assembly reference? > > > > I can use the legacy mode ConfigurationSettings.AppSettings but this then > means I have 2 variants of code (one for Windows, one for Linux) > > > > Any help appreciated! > > Mike > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From gonzalo.mono at gmail.com Tue Oct 14 16:29:37 2008 From: gonzalo.mono at gmail.com (Gonzalo Paniagua Javier) Date: Tue, 14 Oct 2008 13:29:37 -0700 Subject: [Mono-dev] Mono 2.0 defeat story... In-Reply-To: <1223911090.18346.28.camel@hublinux.fidudev.fr> References: <1223911090.18346.28.camel@hublinux.fidudev.fr> Message-ID: <1224016177.4759.6.camel@lalo.home> Hi Hubert! On Mon, 2008-10-13 at 17:18 +0200, Hubert FONGARNAND wrote: [...] > The upgrade was really a pain, because we have found at least two bugs > in mono : > > https://bugzilla.novell.com/show_bug.cgi?id=433908 > https://bugzilla.novell.com/show_bug.cgi?id=434305 > > These bugs prevent our CMS app to run correctly on mono... In addition > to these bugs we experienced a big memory leak with our > mod-mono-server (it use to take ~60Mb (RSS) with mono 1.2.6, with > mono 2.0 it was growing up to 3Go). So this week end we had some "out > of memory" crash... > In addition to this memory leak, the website was slowing down... When > i start the mod-mono-server process, the web site speed is good > (~900ms/req) and it was getting worse and worse as time... (15s/req) [...] Those bugs and the leak (https://bugzilla.novell.com/show_bug.cgi?id=435263) have already been addressed. Let us know if you find any other problem and sorry for the inconvenience. -Gonzalo From cedricv at neonux.com Wed Oct 15 02:48:28 2008 From: cedricv at neonux.com (Cedric Vivier) Date: Wed, 15 Oct 2008 14:48:28 +0800 Subject: [Mono-dev] [PATCH] Get back methods in the symbol files generated by SRE-using compilers Message-ID: Hey all, I've recently discovered that code generated by booc (or other compilers using SRE [1]) cannot be conveniently debugged with the mono debugger anymore because there is no methods information in the generated symbol file. It was working pre-kahalo, but when symbol writing code from SRE came back in r105607 (Jun 11 2008) the necessary SymbolWriter.SetMethodSourceRange method has not been implemented but just stubbed with a "#if FIXME" englobing all body. This patch implements SetMethodSourceRange using the new underlying MonoSymbolWriter's API so that the symbol files generated by SRE-using compiler are useful again. Please review. Regards, [1] System.Reflection.Emit -------------- next part -------------- A non-text attachment was scrubbed... Name: SymbolWriterImpl.patch Type: text/x-diff Size: 2533 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081015/7a815c6e/attachment.bin From mousse_man at hotmail.com Wed Oct 15 07:46:01 2008 From: mousse_man at hotmail.com (FirstName LastName) Date: Wed, 15 Oct 2008 11:46:01 +0000 Subject: [Mono-dev] Marshaling DateTime type Message-ID: What would be the best equivalent unmanaged type (linux and windows) to use if I want to marshal a DateTime in the managed world (.NET, mono)? Thanks. _________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081015/54aea824/attachment-0001.html From robertj at gmx.net Wed Oct 15 08:20:11 2008 From: robertj at gmx.net (Robert Jordan) Date: Wed, 15 Oct 2008 14:20:11 +0200 Subject: [Mono-dev] Marshaling DateTime type In-Reply-To: References: Message-ID: FirstName LastName wrote: > What would be the best equivalent unmanaged type (linux and windows) > to use if I want to marshal a DateTime in the managed world (.NET, > mono)? You can't marshal DateTime directly because its internal representation is different between runtimes *and* profiles. Use DateTime.Tick (an int64) or a similar era-based representation. Robert From harinath at hurrynot.org Wed Oct 15 09:46:20 2008 From: harinath at hurrynot.org (Raja R Harinath) Date: Wed, 15 Oct 2008 19:16:20 +0530 Subject: [Mono-dev] Marshaling DateTime type References: Message-ID: <87ej2i9djn.fsf@hariville.hurrynot.org> Hi, Robert Jordan writes: > FirstName LastName wrote: >> What would be the best equivalent unmanaged type (linux and windows) >> to use if I want to marshal a DateTime in the managed world (.NET, >> mono)? > > You can't marshal DateTime directly because its internal representation > is different between runtimes *and* profiles. Use DateTime.Tick (an > int64) or a similar era-based representation. But, IIRC, strangely enough, arrays of DateTimes should serialize fine. So, you might be better of using a one-element DateTime array. - Hari From kumpera at gmail.com Wed Oct 15 10:13:48 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Wed, 15 Oct 2008 12:13:48 -0200 Subject: [Mono-dev] [PATCH] Get back methods in the symbol files generated by SRE-using compilers In-Reply-To: References: Message-ID: <8cca42d80810150713p6d570a65hd83af9abdac522cf@mail.gmail.com> Martin, Do you think that this fix can be backported to 2.0? Thanks, Rodrigo 2008/10/15 Cedric Vivier > Hey all, > > I've recently discovered that code generated by booc (or other > compilers using SRE [1]) cannot be conveniently debugged with the mono > debugger anymore because there is no methods information in the > generated symbol file. > It was working pre-kahalo, but when symbol writing code from SRE came > back in r105607 (Jun 11 2008) the necessary > SymbolWriter.SetMethodSourceRange method has not been implemented but > just stubbed with a "#if FIXME" englobing all body. > > This patch implements SetMethodSourceRange using the new underlying > MonoSymbolWriter's API so that the symbol files generated by SRE-using > compiler are useful again. > > Please review. > > Regards, > > [1] System.Reflection.Emit > > _______________________________________________ > 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/20081015/7aa877c2/attachment.html From jb at nurv.fr Wed Oct 15 10:15:16 2008 From: jb at nurv.fr (Jb Evain) Date: Wed, 15 Oct 2008 16:15:16 +0200 Subject: [Mono-dev] [PATCH] Get back methods in the symbol files generated by SRE-using compilers In-Reply-To: References: Message-ID: <69f7d8470810150715n1ff702eeya404cef9d9b7fee5@mail.gmail.com> Hey, On 10/15/08, Cedric Vivier wrote: > Please review. Following up an IRC discussion, this patch has been reviewed and commited. -- Jb Evain From robertj at gmx.net Wed Oct 15 10:23:10 2008 From: robertj at gmx.net (Robert Jordan) Date: Wed, 15 Oct 2008 16:23:10 +0200 Subject: [Mono-dev] Marshaling DateTime type In-Reply-To: <87ej2i9djn.fsf@hariville.hurrynot.org> References: <87ej2i9djn.fsf@hariville.hurrynot.org> Message-ID: Raja R Harinath wrote: > Hi, > > Robert Jordan writes: > >> FirstName LastName wrote: >>> What would be the best equivalent unmanaged type (linux and windows) >>> to use if I want to marshal a DateTime in the managed world (.NET, >>> mono)? >> You can't marshal DateTime directly because its internal representation >> is different between runtimes *and* profiles. Use DateTime.Tick (an >> int64) or a similar era-based representation. > > But, IIRC, strangely enough, arrays of DateTimes should serialize fine. > So, you might be better of using a one-element DateTime array. Look at DateTime's layout: public struct DateTime { private TimeSpan ticks; #if NET_2_0 DateTimeKind kind; #endif } Nasty things would happen if the unmanaged code is profile agnostic. Robert From lupus at ximian.com Wed Oct 15 10:51:06 2008 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 15 Oct 2008 16:51:06 +0200 Subject: [Mono-dev] Dll not found when deploying a mono app into a different machine In-Reply-To: <772db3280810131250p4cece2e9n9ea14440e52ac783@mail.gmail.com> References: <772db3280810131250p4cece2e9n9ea14440e52ac783@mail.gmail.com> Message-ID: <20081015145106.GI28194@debian.org> On 10/13/08 Andoni Morales wrote: > I'm having a very strange problem on Windows.... > I've created a multimedia player based on GStreamer an Gtk that runs both on > Windows and Linux. The GStreamer backend is written in C and wrapped to C# > using the GAPI tools, importing my own dll called libcesarplayer.dll. > I compile and link libcesaplayer.dll on windows (I've tried both Mingw and > MSVC) and all works well. > But.... If I try to run my app in my laptop, for example, I got a > DllNotFoundException. So, it just works in the computer I used to compile > libcesarplayer.dll. > Do I have to compile it in a special way? It's likely that the library depends on another library that you have installed and that you didn't copy (or you use a windows binary on a linux system, who knows, you provide too few details). You can run with: MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono yourprogram.exe as detailed in the man page to see what error might happen when loading your library. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From harinath at hurrynot.org Wed Oct 15 11:41:09 2008 From: harinath at hurrynot.org (Raja R Harinath) Date: Wed, 15 Oct 2008 21:11:09 +0530 Subject: [Mono-dev] Marshaling DateTime type References: <87ej2i9djn.fsf@hariville.hurrynot.org> Message-ID: <878wspamsq.fsf@hariville.hurrynot.org> Hi, Robert Jordan writes: > Raja R Harinath wrote: >> Robert Jordan writes: >>> FirstName LastName wrote: >>>> What would be the best equivalent unmanaged type (linux and windows) >>>> to use if I want to marshal a DateTime in the managed world (.NET, >>>> mono)? >>> You can't marshal DateTime directly because its internal representation >>> is different between runtimes *and* profiles. Use DateTime.Tick (an >>> int64) or a similar era-based representation. >> >> But, IIRC, strangely enough, arrays of DateTimes should serialize fine. >> So, you might be better of using a one-element DateTime array. > > Look at DateTime's layout: > > public struct DateTime > { > private TimeSpan ticks; > #if NET_2_0 > DateTimeKind kind; > #endif > } > > Nasty things would happen if the unmanaged code is profile agnostic. >From a quick examination of the source code in SVN trunk, my understanding is that both the Binary and Soap serializers have special cases for DateTime, which aren't dependent on the exact layout -- and the serialization is profile-dependent. (Of course, since I haven't actually tried it out, I can't guarantee that it's fully interoperable with .NET.) - Hari From monodanmorg at yahoo.com Wed Oct 15 11:41:58 2008 From: monodanmorg at yahoo.com (Daniel Morgan) Date: Wed, 15 Oct 2008 08:41:58 -0700 (PDT) Subject: [Mono-dev] Interactive C# - running a script Message-ID: <636467.8650.qm@web30801.mail.mud.yahoo.com> I would like to use the csharp interactive shell to run a script file. Is this possible? Here is an example (not tested): linux$ cat script-file > csharp Connecting... Copying... Done. linux$ Example script (not tested): LoadLibrary("System.Data.dll"); LoadLibrary("System.Data.OracleClient"); using System.Data; using System.Data.SqlClient; using System.Data.OracleClient; Console.WriteLine("Connecting..."); SqlConnection sourcedb = SqlConnection("..."); sourcedb.Open(); SqlCommand sourceCmd = sourcedb.CreateCommand(); sourceCmd.CommandText = "SELECT somecolumn FROM sometable WHERE C = 'A'"; string value = (string) sourceCmd.ExecuteScalar(); OracleConnection targetdb = OracleConnection("..."); targetdb.Open(); Console.WriteLine("Copying..."); OracleCommand targetCmd = targetdb.CreateCommand(); targetCmd.CommandText = "INSERT INTO sometable (column1) VALUES ('" + value + "')"; targetCmd.ExecuteNonQuery(); targetCmd.CommandText = "COMMIT"; targetCmd.ExecuteNonQuery(); sourcedb.Close(); targetdb.Close(); Console.WriteLine("Done."); From jb at nurv.fr Wed Oct 15 11:43:02 2008 From: jb at nurv.fr (Jb Evain) Date: Wed, 15 Oct 2008 17:43:02 +0200 Subject: [Mono-dev] [PATCH] Get back methods in the symbol files generated by SRE-using compilers In-Reply-To: <69f7d8470810150715n1ff702eeya404cef9d9b7fee5@mail.gmail.com> References: <69f7d8470810150715n1ff702eeya404cef9d9b7fee5@mail.gmail.com> Message-ID: <69f7d8470810150843o27f848cbq8fe4fd36ad913a4e@mail.gmail.com> On 10/15/08, Jb Evain wrote: > Following up an IRC discussion, this patch has been reviewed and commited. And has been backported to the 2.0 branch as well. -- Jb Evain From robertj at gmx.net Wed Oct 15 12:14:48 2008 From: robertj at gmx.net (Robert Jordan) Date: Wed, 15 Oct 2008 18:14:48 +0200 Subject: [Mono-dev] Marshaling DateTime type In-Reply-To: <878wspamsq.fsf@hariville.hurrynot.org> References: <87ej2i9djn.fsf@hariville.hurrynot.org> <878wspamsq.fsf@hariville.hurrynot.org> Message-ID: Hi, Raja R Harinath wrote: > Hi, > > Robert Jordan writes: >> Raja R Harinath wrote: >>> Robert Jordan writes: >>>> FirstName LastName wrote: >>>>> What would be the best equivalent unmanaged type (linux and windows) >>>>> to use if I want to marshal a DateTime in the managed world (.NET, >>>>> mono)? >>>> You can't marshal DateTime directly because its internal representation >>>> is different between runtimes *and* profiles. Use DateTime.Tick (an >>>> int64) or a similar era-based representation. >>> But, IIRC, strangely enough, arrays of DateTimes should serialize fine. >>> So, you might be better of using a one-element DateTime array. >> Look at DateTime's layout: >> >> public struct DateTime >> { >> private TimeSpan ticks; >> #if NET_2_0 >> DateTimeKind kind; >> #endif >> } >> >> Nasty things would happen if the unmanaged code is profile agnostic. > >>From a quick examination of the source code in SVN trunk, my > understanding is that both the Binary and Soap serializers have special > cases for DateTime, which aren't dependent on the exact layout -- and > the serialization is profile-dependent. Yes. Unfortunately, the special DateTime serialization is not used in all cases (see the bug below). Anyway, serialization doesn't apply to p/invoke. If I understood correctly, the original poster was asking about managed/unmanaged marshaling. > > (Of course, since I haven't actually tried it out, I can't guarantee > that it's fully interoperable with .NET.) Here is the full story of DateTime serialization issues: https://bugzilla.novell.com/show_bug.cgi?id=325067 Robert From apenwarr at gmail.com Wed Oct 15 16:48:52 2008 From: apenwarr at gmail.com (Avery Pennarun) Date: Wed, 15 Oct 2008 16:48:52 -0400 Subject: [Mono-dev] Using Mono.Options in MS.NET Message-ID: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> Hi, I just read Miguel's posting about Mono.Options being included in Mono 2.2. I agree that Mono.Options is great; in fact, I include a copy of it in several of the problems we've built at work. It doesn't particularly require mono, so it works fine under MS.NET. There are a few other libraries in a similar vein, such as Miguel's Mono.Terminal. Now that Mono.Options is included in Mono 2.2, will it still be available separately? If not, it will be hard to build Windows-compatible programs that use it, unless people go digging throug the mono sources and extracting the libraries they like. I think it might be helpful to separate "mono libraries that add functionality to any .Net application" and "mono libraries that implement the MS class library" into two different projects. Am I missing something? Thanks, Avery From atsushi at ximian.com Thu Oct 16 04:24:13 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Thu, 16 Oct 2008 17:24:13 +0900 Subject: [Mono-dev] Fwd: [PATCH] System.Messaging using AMQP (RabbitMQ) In-Reply-To: <80d1dfde0810121836w1b9f36b0i6c1a9879f20312ce@mail.gmail.com> References: <80d1dfde0810060108j62b1198egd0a61a3e29fcb12a@mail.gmail.com> <80d1dfde0810080004k3d651576o70cd2baf51dbbad5@mail.gmail.com> <48F0918E.5020602@ximian.com> <80d1dfde0810112146n70f33f7ftefcf756438819c88@mail.gmail.com> <80d1dfde0810121836w1b9f36b0i6c1a9879f20312ce@mail.gmail.com> Message-ID: <48F6FA2D.4080903@ximian.com> Hi Michael, Michael Barker wrote: > Hi, > > I have updated the bug report > (https://bugzilla.novell.com/show_bug.cgi?id=432471) to include a > first cut of MessageEnumerators. It does seem to work, originally I > though that an AMQP Ack would acknowledge all messages up to that > point, but that does not seem to be the case, so I can implement the > System.Messaging behaviour reasonably well. Looks like (at least) Mono.Messaging.RabbitMQ/MessageFactory.cs is missing. Can you please check missing stuff in the patch (probably new files) ? >> Well, I'm rather afraid of having Mono.Messaging base API dependent >> on Rabbit (by "dependent" I don't mean that Mono.Messaging.dll has >> reference to Mono.Messaging.RabbitMQ.dll). AMQP solution might not >> be chosen if it lacks significant functionality, but that does not >> mean it is no-go. If Rabbit based implementation does not work here, >> I rather assume nothing would work fine here ;) > > I would be useful if you could describe what you mean by dependent? > I'm assuming that you're referring to the design of the API. I've > tried hard to avoid designing Mono.Messaging based on the RabbitMQ > bindings. The majority of it is direct delegation from the > System.Messaging library (expect for the parts that don't need to > happen in Messaging implementation, e.g. formatting), so the > Mono.Messaging is more dependent on that library. Sometimes we see System.Messaging bridge API, well, SPI, as to be actually dependent (or premised) on the message queue implementation. For example, if we return an array of Message (in bridge) to be used in MessageEnumerator (sys.messaging), it may not be very efficient for some queue systems that return IEnumerator of Message (it does not have to iterate all messages just to create an array). As long as the common SPI is direct delegation, it should be fine. > Also I think that Mono.Messaging should be considered only as an SPI, > not an API. Anyone writing an application requiring a brand new OK (I didn't bother to differentiate API from SPI ;) > RE: AMQP, If its of any use here are a list of the main features and > how they can be supported: > > Supported easily through the standard: > - Basic Messaging Send/Receive > - Message Listeners > - Transactions > > Supported with a couple jumps through hoops: > - Peek() (may be better supported through queue browsers later on) > - Message Enumerators > > Supported only with custom extensions to the server: > - {Receive,Peek}By{Id,CorrelationId,..} > > Supported only with later potential protocol updates: > - Queue discovery Thanks, that's a nice list of the features to be (or not to be) supported :) For the time being, Peek and retrieval by IDs can be left unimplemented. There would be a couple of ways to provide queue discovery emulation through configuration, dummy management queue or something else (apart from the queue system itself). I think it'd be good way to create a branch for your implementation in svn and let other people help hacking other implementations (such as Win32API one, as I suggested earlier). Atsushi Eno From paul at all-the-johnsons.co.uk Thu Oct 16 02:30:08 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 16 Oct 2008 07:30:08 +0100 Subject: [Mono-dev] Using Mono.Options in MS.NET In-Reply-To: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> References: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> Message-ID: <1224138608.18629.85.camel@PB3.Linux> Hi, > Now that Mono.Options is included in Mono 2.2 2.2? We've only just had the official release of 2.0! I've not seen anything on this list over a 2.2 release with tarballs or are you talking about svn? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081016/a36d4510/attachment.bin From mhorsley at vqlive.com Thu Oct 16 05:04:44 2008 From: mhorsley at vqlive.com (mike horsley) Date: Thu, 16 Oct 2008 10:04:44 +0100 Subject: [Mono-dev] problems compiling using System.Configuration using Message-ID: <002d01c92f6e$3bd1c100$9c01a8c0@VQsteve> Bill Using gmcs was the answer. Many thanks Mike Mike Horsley VQ Communications Ltd mhorsley at vqlive.com T: 01249-460002 M:07920-151804 W:www.vqlive.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081016/a0d3b1f2/attachment.html From mousse_man at hotmail.com Thu Oct 16 08:12:24 2008 From: mousse_man at hotmail.com (FirstName LastName) Date: Thu, 16 Oct 2008 12:12:24 +0000 Subject: [Mono-dev] Marshaling DateTime type In-Reply-To: <878wspamsq.fsf@hariville.hurrynot.org> References: <87ej2i9djn.fsf@hariville.hurrynot.org> <878wspamsq.fsf@hariville.hurrynot.org> Message-ID: Thanks everyone. I think my best bet will be to use the Tick property. > To: mono-devel-list at lists.ximian.com> From: harinath at hurrynot.org> Date: Wed, 15 Oct 2008 21:11:09 +0530> Subject: Re: [Mono-dev] Marshaling DateTime type> > Hi,> > Robert Jordan writes:> > Raja R Harinath wrote:> >> Robert Jordan writes:> >>> FirstName LastName wrote:> >>>> What would be the best equivalent unmanaged type (linux and windows)> >>>> to use if I want to marshal a DateTime in the managed world (.NET,> >>>> mono)?> >>> You can't marshal DateTime directly because its internal representation> >>> is different between runtimes *and* profiles. Use DateTime.Tick (an> >>> int64) or a similar era-based representation.> >> > >> But, IIRC, strangely enough, arrays of DateTimes should serialize fine.> >> So, you might be better of using a one-element DateTime array.> >> > Look at DateTime's layout:> >> > public struct DateTime> > {> > private TimeSpan ticks;> > #if NET_2_0> > DateTimeKind kind;> > #endif> > }> >> > Nasty things would happen if the unmanaged code is profile agnostic.> > >From a quick examination of the source code in SVN trunk, my> understanding is that both the Binary and Soap serializers have special> cases for DateTime, which aren't dependent on the exact layout -- and> the serialization is profile-dependent.> > (Of course, since I haven't actually tried it out, I can't guarantee> that it's fully interoperable with .NET.)> > - Hari> > _______________________________________________> 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/20081016/6f9c1751/attachment.html From pablosantosluac at terra.es Thu Oct 16 08:25:26 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Thu, 16 Oct 2008 14:25:26 +0200 Subject: [Mono-dev] Using Mono.Options in MS.NET In-Reply-To: <1224138608.18629.85.camel@PB3.Linux> References: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> <1224138608.18629.85.camel@PB3.Linux> Message-ID: <48F732B6.5080007@terra.es> Yes, SVN Paul escribi?: > Hi, > > >> Now that Mono.Options is included in Mono 2.2 >> > > 2.2? We've only just had the official release of 2.0! I've not seen > anything on this list over a 2.2 release with tarballs or are you > talking about svn? > > TTFN > > Paul > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From mhorsley at vqlive.com Thu Oct 16 10:13:00 2008 From: mhorsley at vqlive.com (mike horsley) Date: Thu, 16 Oct 2008 15:13:00 +0100 Subject: [Mono-dev] help needed please for ASP.NET migration to mono 2.0 Message-ID: <005b01c92f99$4bd0d9d0$9c01a8c0@VQsteve> Hi We use mono already for our server based software and its working well. With 2.0, we're starting migrating our ASP.NET application over as well. I'm using the VMWARE image for 2.0 Initially, I read the "welcome to mono" page on the VM and followed the "copy you asp.net code to a folder under '/srv/www/htdocs'" instructions and went to the local host URL and got a variety of errors (including one which was the giveway that firefox didn't know what to do with an aspx file) I then dug around and found the mojoportal site; backtracked into the /etc/apache2/conf.d folder, found the conf file and the 'webapp' config file under /etc/xsp/2.0/applications_available and copied them and modified to suite my application. If I access my default.aspx page now, I no longer get the errors and see the status bar at the bottom which says "transferring data from local host" which then changes to "waiting for local host". Nothing furher happens. I've managed to set up the mono-control tool and that works but doesn't give me much additional information. The ASP.NET application is straight off VS 2005; it works fine under MS. It contains AJAX.NET. I've renamed Bin to bin. Given that nothing really happens, could it be something basic like its not compiling under mono on the first reference to the site? Help would be greatly appreciated. Regards Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081016/f3763e1d/attachment.html From emperon at gmail.com Thu Oct 16 10:46:37 2008 From: emperon at gmail.com (Onur Gumus) Date: Thu, 16 Oct 2008 17:46:37 +0300 Subject: [Mono-dev] help needed please for ASP.NET migration to mono 2.0 In-Reply-To: <005b01c92f99$4bd0d9d0$9c01a8c0@VQsteve> References: <005b01c92f99$4bd0d9d0$9c01a8c0@VQsteve> Message-ID: <8a7a2d050810160746q62ffd899ne0b5d684dd67f9c0@mail.gmail.com> disregarding the minor incompabilities, your application should run out of box on mono/linux. The only exceptions would be third party dlls using P/Invoke. Also you need to use Mono's System.Web.Extensions. Not microsofts. Other than that everything should work including ajax 2008/10/16 mike horsley : > Hi > > > > We use mono already for our server based software and its working well. With > 2.0, we're starting migrating our ASP.NET application over as well. > > > > I'm using the VMWARE image for 2.0 > > > > Initially, I read the "welcome to mono" page on the VM and followed the > "copy you asp.net code to a folder under '/srv/www/htdocs'" instructions and > went to the local host URL and got a variety of errors (including one which > was the giveway that firefox didn't know what to do with an aspx file) > > > > I then dug around and found the mojoportal site; backtracked into the > /etc/apache2/conf.d folder, found the conf file and the 'webapp' config file > under /etc/xsp/2.0/applications_available and copied them and modified to > suite my application. > > > > If I access my default.aspx page now, I no longer get the errors and see the > status bar at the bottom which says "transferring data from local host" > which then changes to "waiting for local host". Nothing furher happens. > > > > I've managed to set up the mono-control tool and that works but doesn't give > me much additional information. > > > > The ASP.NET application is straight off VS 2005; it works fine under MS. It > contains AJAX.NET. I've renamed Bin to bin. Given that nothing really > happens, could it be something basic like its not compiling under mono on > the first reference to the site? > > > > Help would be greatly appreciated. > > Regards > > Mike > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From joe_audette at yahoo.com Thu Oct 16 10:58:29 2008 From: joe_audette at yahoo.com (Joe Audette) Date: Thu, 16 Oct 2008 10:58:29 -0400 Subject: [Mono-dev] help needed please for ASP.NET migration to mono 2.0 In-Reply-To: <005b01c92f99$4bd0d9d0$9c01a8c0@VQsteve> References: <005b01c92f99$4bd0d9d0$9c01a8c0@VQsteve> Message-ID: <27d75530810160758p191f5654nd2ad7a478f3919e0@mail.gmail.com> 2008/10/16 mike horsley : > If I access my default.aspx page now, I no longer get the errors and see the > status bar at the bottom which says "transferring data from local host" > which then changes to "waiting for local host". Nothing furher happens. > > I've managed to set up the mono-control tool and that works but doesn't give > me much additional information. > The ASP.NET application is straight off VS 2005; it works fine under MS. It > contains AJAX.NET. I've renamed Bin to bin. Given that nothing really > happens, could it be something basic like its not compiling under mono on > the first reference to the site? > If your app includes the MS System.Web.Extensions.dll in your bin folder, you should delete it because it can't run on Mono and will throw an error if you try to include it in the bin. Mono has its own copy in the GAC so deleting the one in the bin may help. If your app also depends on Microsoft.Web.Preview.dll, I'm not sure whether its supported, but again if its included in your bin folder it will prevent the app from running. probably there are errors you can review in the apache error log. You can get more info about what is happening with your app if you run it from the command line using xsp. Open a terminal cd into your web root folder and enter the command: MONO_OPTIONS="--debug " xsp2 Now you can open a browser http://localhost:8080 to see run app and errors and or debug info will be shown in the terminal Hope it helps, Joe -- Joe Audette Software Solutions Architect Source Tree Solutions, LLC PO Box 621861 Charlotte, NC 28262 704.323.8225 joe.audette at gmail.com http://www.sourcetreesolutions.com http://www.mojoportal.com From apenwarr at gmail.com Thu Oct 16 13:16:49 2008 From: apenwarr at gmail.com (Avery Pennarun) Date: Thu, 16 Oct 2008 13:16:49 -0400 Subject: [Mono-dev] Using Mono.Options in MS.NET In-Reply-To: <1224138608.18629.85.camel@PB3.Linux> References: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> <1224138608.18629.85.camel@PB3.Linux> Message-ID: <32541b130810161016t527d1d3ale5cbce09ba6ecda0@mail.gmail.com> 2008/10/16 Paul : >> Now that Mono.Options is included in Mono 2.2 > > 2.2? We've only just had the official release of 2.0! I've not seen > anything on this list over a 2.2 release with tarballs or are you > talking about svn? Sorry, I was referring to this: http://tirania.org/blog/archive/2008/Oct-14.html Obviously there is no Mono 2.2 yet, but I was assuming from Miguel's post that it's "as good as included" in 2.2. Thanks, Avery From ylatuya at gmail.com Thu Oct 16 18:38:47 2008 From: ylatuya at gmail.com (Andoni Morales) Date: Fri, 17 Oct 2008 00:38:47 +0200 Subject: [Mono-dev] Deploying on windows using mkbundle Message-ID: <772db3280810161538r66dc1f5bi6e92630fcf729b10@mail.gmail.com> Hi, I've ported my application to windows and now I'm trying to deploy it on this platfrom using mkbundle. My app runs with the executable generated by mkbundle but I need to set/hardcode an environmental variable (GST_PLUGIN_PATH=../lib/gstreamer-0.10), this way I don't have to call the executable from a .bat file. I think the best way is hardcoding it in the "host.c" file generated by mkbundle. I'm not used to program on windows and I don't witch is the default behaviour for this kind of problem. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081017/14b6a8d8/attachment.html From joncham at gmail.com Thu Oct 16 18:47:04 2008 From: joncham at gmail.com (Jonathan Chambers) Date: Thu, 16 Oct 2008 18:47:04 -0400 Subject: [Mono-dev] Deploying on windows using mkbundle In-Reply-To: <772db3280810161538r66dc1f5bi6e92630fcf729b10@mail.gmail.com> References: <772db3280810161538r66dc1f5bi6e92630fcf729b10@mail.gmail.com> Message-ID: <17c2d80b0810161547y86e17cek4084c50ccee4988a@mail.gmail.com> Hello, If you need that environment variable set for you process, you can set it at startup of you application. So, make one of the first things you do in your app: Environment.SetEnvironmentVariable("GST_PLUGIN_PATH", "../lib/gstreamer-0.10") This will be picked up by the current process, if I understand what you are trying to do. Thanks, Jonathan 2008/10/16 Andoni Morales > Hi, > > I've ported my application to windows and now I'm trying to deploy it on > this platfrom using mkbundle. My app runs with the executable generated by > mkbundle but I need to set/hardcode an environmental variable > (GST_PLUGIN_PATH=../lib/gstreamer-0.10), this way I don't have to call the > executable from a .bat file. > I think the best way is hardcoding it in the "host.c" file generated by > mkbundle. > I'm not used to program on windows and I don't witch is the default > behaviour for this kind of problem. > Thanks > > _______________________________________________ > 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/20081016/27552f06/attachment.html From miguel at novell.com Thu Oct 16 20:33:37 2008 From: miguel at novell.com (Miguel de Icaza) Date: Thu, 16 Oct 2008 20:33:37 -0400 Subject: [Mono-dev] Using Mono.Options in MS.NET In-Reply-To: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> References: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> Message-ID: <1224203617.960.159.camel@erandi.site> > Now that Mono.Options is included in Mono 2.2, will it still be > available separately? If not, it will be hard to build > Windows-compatible programs that use it, unless people go digging > throug the mono sources and extracting the libraries they like. I > think it might be helpful to separate "mono libraries that add > functionality to any .Net application" and "mono libraries that > implement the MS class library" into two different projects. > > Am I missing something? You can always pull the code using the AnonSVN user interface from the web, it can produce tarballs of just the things that you need. Our todo list includes "Make it easier to release components independently", would love to do it, we just need the spare cycles to make it happen in a general way for everything that we need. I think the tarball solution is pretty good, and we could just bundle solutions or files for the more complicated modules (Mono.Options is really easy to use). From apenwarr at gmail.com Thu Oct 16 21:17:16 2008 From: apenwarr at gmail.com (Avery Pennarun) Date: Thu, 16 Oct 2008 21:17:16 -0400 Subject: [Mono-dev] Using Mono.Options in MS.NET In-Reply-To: <1224203617.960.159.camel@erandi.site> References: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> <1224203617.960.159.camel@erandi.site> Message-ID: <32541b130810161817x179bf135hdff48963f0bc03de@mail.gmail.com> On Thu, Oct 16, 2008 at 8:33 PM, Miguel de Icaza wrote: >> Now that Mono.Options is included in Mono 2.2, will it still be >> available separately? If not, it will be hard to build >> Windows-compatible programs that use it, unless people go digging >> throug the mono sources and extracting the libraries they like. I >> think it might be helpful to separate "mono libraries that add >> functionality to any .Net application" and "mono libraries that >> implement the MS class library" into two different projects. >> >> Am I missing something? > > You can always pull the code using the AnonSVN user interface from the > web, it can produce tarballs of just the things that you need. > > Our todo list includes "Make it easier to release components > independently", would love to do it, we just need the spare cycles to > make it happen in a general way for everything that we need. > > I think the tarball solution is pretty good, and we could just bundle > solutions or files for the more complicated modules (Mono.Options is > really easy to use). Thanks, that answers my question. Avery From surfzoid at gmail.com Fri Oct 17 03:03:54 2008 From: surfzoid at gmail.com (Petit Eric) Date: Fri, 17 Oct 2008 09:03:54 +0200 Subject: [Mono-dev] Using Mono.Options in MS.NET In-Reply-To: <32541b130810161817x179bf135hdff48963f0bc03de@mail.gmail.com> References: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> <1224203617.960.159.camel@erandi.site> <32541b130810161817x179bf135hdff48963f0bc03de@mail.gmail.com> Message-ID: <84776a970810170003i4d3010b6va49c1af98321c2a@mail.gmail.com> 2008/10/17 Avery Pennarun : > On Thu, Oct 16, 2008 at 8:33 PM, Miguel de Icaza wrote: >>> Now that Mono.Options is included in Mono 2.2, will it still be >>> available separately? If not, it will be hard to build >>> Windows-compatible programs that use it, unless people go digging >>> throug the mono sources and extracting the libraries they like. I >>> think it might be helpful to separate "mono libraries that add >>> functionality to any .Net application" and "mono libraries that >>> implement the MS class library" into two different projects. >>> >>> Am I missing something? >> >> You can always pull the code using the AnonSVN user interface from the >> web, it can produce tarballs of just the things that you need. >> >> Our todo list includes "Make it easier to release components >> independently", would love to do it, we just need the spare cycles to >> make it happen in a general way for everything that we need. >> >> I think the tarball solution is pretty good, and we could just bundle >> solutions or files for the more complicated modules (Mono.Options is >> really easy to use). I don't know if Mono.Option made P/Invoke, but if not you can simply set , assembly property to "Locale copy" as it, the dll will folow the .exe and so ... > > Thanks, that answers my question. > > Avery > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Cordially. Small Eric Quotations of the days: --------------------------------------------------------------------------- If one day one reproaches you that your work is not a work of professional, say you that: Amateurs built the arch of Noah, and professionals the Titanic. --------------------------------------------------------------------------- Few people are done for independence, it is the privilege of the powerful ones. --------------------------------------------------------------------------- No key was wounded during the drafting of this message. From vladhociota at yahoo.com Fri Oct 17 03:23:58 2008 From: vladhociota at yahoo.com (Vlad Hociota) Date: Fri, 17 Oct 2008 00:23:58 -0700 (PDT) Subject: [Mono-dev] [PATCH] Implement .NET 2.0 API for UnixListener and UnixClient Message-ID: <339142.12908.qm@web50106.mail.re2.yahoo.com> Hi Jonathan. This is a stab at doing the updates we've discussed: implement new properties and methods for UnixListener and UnixClient similar to those exposed by TcpListener and TcpClient in .NET 2.0 . Please review. Thanks, Vlad -------------- next part -------------- A non-text attachment was scrubbed... Name: UnixListener_new.diff Type: text/x-patch Size: 1911 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081017/eb47e49c/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: UnixClient_new.diff Type: text/x-patch Size: 3103 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081017/eb47e49c/attachment-0001.bin From alan.mcgovern at gmail.com Fri Oct 17 04:54:34 2008 From: alan.mcgovern at gmail.com (Alan McGovern) Date: Fri, 17 Oct 2008 09:54:34 +0100 Subject: [Mono-dev] Using Mono.Options in MS.NET In-Reply-To: <84776a970810170003i4d3010b6va49c1af98321c2a@mail.gmail.com> References: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> <1224203617.960.159.camel@erandi.site> <32541b130810161817x179bf135hdff48963f0bc03de@mail.gmail.com> <84776a970810170003i4d3010b6va49c1af98321c2a@mail.gmail.com> Message-ID: <117799f00810170154x3889d959x4734e031dc2c77d8@mail.gmail.com> It's 100% pure managed code, and also a single .cs file. That makes it trivial to just include as part of your build. You can reference it using an svn:external (or equivalent) so you always have the latest from svn aswell, which minimises the need to keep in sync with the working copy. There's no need to lug around an extra assembly when it's so easy to compile it right in :) Alan. On Fri, Oct 17, 2008 at 8:03 AM, Petit Eric wrote: > 2008/10/17 Avery Pennarun : > > On Thu, Oct 16, 2008 at 8:33 PM, Miguel de Icaza > wrote: > >>> Now that Mono.Options is included in Mono 2.2, will it still be > >>> available separately? If not, it will be hard to build > >>> Windows-compatible programs that use it, unless people go digging > >>> throug the mono sources and extracting the libraries they like. I > >>> think it might be helpful to separate "mono libraries that add > >>> functionality to any .Net application" and "mono libraries that > >>> implement the MS class library" into two different projects. > >>> > >>> Am I missing something? > >> > >> You can always pull the code using the AnonSVN user interface from the > >> web, it can produce tarballs of just the things that you need. > >> > >> Our todo list includes "Make it easier to release components > >> independently", would love to do it, we just need the spare cycles to > >> make it happen in a general way for everything that we need. > >> > >> I think the tarball solution is pretty good, and we could just bundle > >> solutions or files for the more complicated modules (Mono.Options is > >> really easy to use). > I don't know if Mono.Option made P/Invoke, but if not you can simply > set , assembly property to "Locale copy" as it, the dll will folow the > .exe and so ... > > > > Thanks, that answers my question. > > > > Avery > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > -- > > Cordially. > > Small Eric Quotations of the days: > --------------------------------------------------------------------------- > If one day one reproaches you that your work is not a work of > professional, say you that: > Amateurs built the arch of Noah, and professionals the Titanic. > --------------------------------------------------------------------------- > > Few people are done for independence, it is the privilege of the powerful > ones. > --------------------------------------------------------------------------- > > No key was wounded during the drafting of this message. > _______________________________________________ > 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/20081017/86f8e00f/attachment.html From alan.mcgovern at gmail.com Fri Oct 17 05:02:08 2008 From: alan.mcgovern at gmail.com (Alan McGovern) Date: Fri, 17 Oct 2008 10:02:08 +0100 Subject: [Mono-dev] [PATCH] Implement .NET 2.0 API for UnixListener and UnixClient In-Reply-To: <339142.12908.qm@web50106.mail.re2.yahoo.com> References: <339142.12908.qm@web50106.mail.re2.yahoo.com> Message-ID: <117799f00810170202t6473476csa0b088a20797748d@mail.gmail.com> Hey, This isn't a full review, it's just me point out some stuff I notice. Here it goes: + public IAsyncResult BeginAcceptSocket (AsyncCallback callback, object state) + { + if (server == null) + throw new ObjectDisposedException (GetType ().FullName); + + return(server.BeginAccept (callback, state)); Why not just call CheckDisposed () as is done in BeginAccept ()? +#if NET_2_0 + public Socket Server +#else + protected Socket Server +#endif I think the usual way to write this is: +#if NET_2_0 + public +#else + protected +#endif Socket Server 2008/10/17 Vlad Hociota > Hi Jonathan. > > This is a stab at doing the updates we've discussed: implement new > properties and methods for UnixListener and UnixClient similar to those > exposed by TcpListener and TcpClient in .NET 2.0 . Please review. > > Thanks, > Vlad > > > > > _______________________________________________ > 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/20081017/771dad3c/attachment-0001.html From vgiszpenc at dsci.com Fri Oct 17 08:45:01 2008 From: vgiszpenc at dsci.com (Vladimir Giszpenc) Date: Fri, 17 Oct 2008 08:45:01 -0400 Subject: [Mono-dev] FIPS 140 cryptography References: <1192105032.26264.126.camel@poupou.home> <1192118639.26264.187.camel@poupou.home> Message-ID: > > The Java community has JSS. Would asking for a MonoSS be asking too > > much? > > It depends from who you're asking ;-) Think of me as an ISV that wants to produce applications for the US government. The entire federal government including DoD is mandated to use FIPS compliant crypto libraries. > > Network Security Services for Java (JSS) is provided by Mozilla. So yes > Mozilla *could* do something like this (not Mono-specific but for > all .NET users) just like they provide the API for Java. OK. Today the picture is a little different. Red Hat produced Python bindings https://fedoraproject.org/wiki/Features/PythonNSS . These will be in fedora 10. And someone is producing Perl bindings http://search.cpan.org/~claesjac/Crypt-NSS-0.03/lib/Crypt/NSS.pm Making Mono and SuSE second class citizens in this realm. > However I don't think this (NSS) should ever become a direct(*) Mono > goal(**). Mono itself has already too many things to complete to afford > a duplicate effort (since we already offer the same features). I am going to show my inexperience so please don't get upset when you tell me it is not so simple. Is there not a way to automatically generate a bunch of C# stubs based on the C headers? > Besides NSS there are other FIPS140 certified libraries that could be > wrapped to give the same end result. However I don't know any available > on Linux that have .NET binding. If you are thinking of OpenSSL it is not as attractive (neither as current nor Level 2 certified) as NSS. If you are thinking of CryptoAPI it is a Windows only technology. I like NSS because it is cross platform (on top of NSPR) and certified to the teeth. Btw, will Crimson come out of hibernation? Thanks, Vlad From sebastien.pouliot at gmail.com Fri Oct 17 09:56:21 2008 From: sebastien.pouliot at gmail.com (Sebastien Pouliot) Date: Fri, 17 Oct 2008 09:56:21 -0400 Subject: [Mono-dev] FIPS 140 cryptography In-Reply-To: References: <1192105032.26264.126.camel@poupou.home> <1192118639.26264.187.camel@poupou.home> Message-ID: <1224251781.4020.51.camel@mizar.home> Hello Vladimir, On Fri, 2008-10-17 at 08:45 -0400, Vladimir Giszpenc wrote: > > > The Java community has JSS. Would asking for a MonoSS be asking too > > > much? > > > > It depends from who you're asking ;-) > > Think of me as an ISV that wants to produce applications for the US > government. The entire federal government including DoD is mandated to > use FIPS compliant crypto libraries. > > > > Network Security Services for Java (JSS) is provided by Mozilla. So > yes > > Mozilla *could* do something like this (not Mono-specific but for > > all .NET users) just like they provide the API for Java. > > OK. Today the picture is a little different. Red Hat produced Python > bindings https://fedoraproject.org/wiki/Features/PythonNSS . These will > be in fedora 10. And someone is producing Perl bindings > http://search.cpan.org/~claesjac/Crypt-NSS-0.03/lib/Crypt/NSS.pm I think it's great news. Note that both previous examples shows where the *community*, not the core project, came up with extra libraries to enhance their beloved language. > Making Mono and SuSE second class citizens in this realm. I can understand your point (on that very precise realm) about Mono but why SuSE ? Are they not providing PythonNSS or Perl's NSS like other distros ? because I'm pretty sure no other distro offers NSS bindings for mono ;-) > > However I don't think this (NSS) should ever become a direct(*) Mono > > goal(**). Mono itself has already too many things to complete to > afford > > a duplicate effort (since we already offer the same features). I still did not change my mind from above. This is still a "one request per year" issue where most of the stuff in Mono roadmap is being anticipated but much larger crowd. > I am going to show my inexperience so please don't get upset when you > tell me it is not so simple. Is there not a way to automatically > generate a bunch of C# stubs based on the C headers? I'm not a big fan of bindings as I like my world managed as much as possible ;-). Other people should be able to answer this more precisely. My *guess* is that, like everything Mozilla-related (e.g. moonlight plugin, reusable web browser component), it's not as easy as it looks. Then you must go on to make this play happily with the .NET crypto (since to be FIPS140 you need to ensure no other crypto is being used internally), packaging (across all different distro, versions of NSS...). So it's nothing impossible and it's not harder (nor easier) than it was last time the question was raised. > > Besides NSS there are other FIPS140 certified libraries that could be > > wrapped to give the same end result. However I don't know any > available > > on Linux that have .NET binding. > > If you are thinking of OpenSSL it is not as attractive (neither as > current nor Level 2 certified) as NSS. If you are thinking of CryptoAPI > it is a Windows only technology. I like NSS because it is cross > platform (on top of NSPR) and certified to the teeth. I did not list them on purpose because there are several certified products - a bunch of them I have never seen personally. It's not clear if you're looking for an open source product or not since you listed CryptoAPI which is supported by Mono (Mono.Security.Win32) but, as you said, limited to win32 operating systems. If you want something open source there are not so many choice. Beside the one mentioned above there is (at least) another one: Crypto++ [1], but its C++ based, so it would be a bit harder (but not impossible) to create .net bindings. [1] http://www.cryptopp.com/ > Btw, will Crimson come out of hibernation? Good question :) Long answer: Crimson was created because a few people wanted to make changes in Mono's crypto code that caused a lot of problems (export paperwork not the least of them). Since many of those people wanted/needed my help I offered Crimson as a way to express their imagination without the limits of what mono/mcs requires. This is made somewhat easy because of the built-in extensibility model used by .NET cryptography. The Crimson inactivity since then shows that (many) people talk a bit more than they code ;-) but don't worry I don't take any offense in that :-) Short answer: whenever people are interested in experimenting crypto stuff. I will be happy to help/guide them! Finally if you want to use Crimson as a test bed for NSS bindings I would be happy to help you (and anyone else) work around any major issue you face (in my free time). Sebastien From SpamMonkey01+Mono at gmail.com Fri Oct 17 11:09:48 2008 From: SpamMonkey01+Mono at gmail.com (Thracx) Date: Fri, 17 Oct 2008 08:09:48 -0700 (PDT) Subject: [Mono-dev] Compiling Mono on SPARC Message-ID: <20014354.post@talk.nabble.com> Glad to hear that you managed to get Mono v1.9 compiled on a Solaris 10 SPARC. I've been fighting with getting v2.0 compiled for the same for quite some time now. Have you tried compiling v2.0? Did you ever encounter any errors regarding delay signing while installing? Would you be willing to provide me with your 1.9 or other binaries? Thanks in advance! -Thracx PCM Reddy wrote: > > ...Finally with latest 1.9 sources I am able to > compile it on Solaris 10 SPARC. > ... > -- View this message in context: http://www.nabble.com/Compiling-Mono-on-SPARC-tp16758361p20014354.html Sent from the Mono - Dev mailing list archive at Nabble.com. From mark.probst at gmail.com Fri Oct 17 11:42:16 2008 From: mark.probst at gmail.com (Mark Probst) Date: Fri, 17 Oct 2008 17:42:16 +0200 Subject: [Mono-dev] Patch: Stack alignment on x86 Message-ID: <1224258136.23602.7.camel@newton> Hi, This patch aligns the stack in managed code on x86 to 16 bytes on all platforms, not only on Darwin, as done (incompletely) previously. In addition the alignment can now be specified by a #define. The reason for this patch is that floating point code that uses doubles performs poorly if the stack (and thus the local variables) is not aligned to at least 8 bytes. Paolo: Please review. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: x86_stack_align.diff Type: text/x-patch Size: 7044 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081017/243c19bf/attachment.bin From SpamMonkey01+Mono at gmail.com Fri Oct 17 11:46:35 2008 From: SpamMonkey01+Mono at gmail.com (Thracx) Date: Fri, 17 Oct 2008 08:46:35 -0700 (PDT) Subject: [Mono-dev] Mono 2.0 on SPARC Solaris 10 Message-ID: <20014556.post@talk.nabble.com> I would also be willing to help contribute towards getting Mono 2.0 working on Solaris 10 SPARC, including Oracle support. The https://bugzilla.novell.com/show_bug.cgi?id=426264 link to the bug above doesn't seem to work for me. What issues remain to be worked? -Thomas ( http://www.nabble.com/Mono-Support-for-Sparc-Solaris-and-Oracle-td13151607ef1367.html#a20014432 Related Post ) PABLOSANTOSLUAC at terra.es wrote: > > ...We're trying to publish the Mono 2.0 build on Solaris x86, so having > SPARC will be great too... > -- View this message in context: http://www.nabble.com/Mono-2.0-on-SPARC-Solaris-10-tp19713193p20014556.html Sent from the Mono - Dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081017/a6b61967/attachment.html From cedricv at neonux.com Fri Oct 17 12:50:23 2008 From: cedricv at neonux.com (Cedric Vivier) Date: Sat, 18 Oct 2008 00:50:23 +0800 Subject: [Mono-dev] [PATCH] Enable stepping into remotinginvoke-wrapped methods Message-ID: Hi, Currently it is not possible to step into a method of an object deriving MarshalByRefObject, as in the example below debugger cannot step into Bar() from Main(). >> using System; public class Foo : MarshalByRefObject { public void Bar() { Console.WriteLine("foo!"); } private static void Main() { var foo = new Foo(); foo.Bar(); } } << Please review the attached patch that enables StepInto for remotinginvoke-wrapped methods. Regards, -------------- next part -------------- A non-text attachment was scrubbed... Name: remoting-wrapper.patch Type: text/x-diff Size: 2674 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081018/ebf89b93/attachment-0001.bin From vargaz at gmail.com Fri Oct 17 12:54:07 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Fri, 17 Oct 2008 18:54:07 +0200 Subject: [Mono-dev] Patch: Stack alignment on x86 In-Reply-To: <1224258136.23602.7.camel@newton> References: <1224258136.23602.7.camel@newton> Message-ID: <295e750a0810170954o33f40e5et27c2eef8e98d9c39@mail.gmail.com> Hi, Looks good. Why is this part needed: + if (cfg->method->wrapper_type == MONO_WRAPPER_NATIVE_TO_MANAGED || + cfg->method->wrapper_type == MONO_WRAPPER_RUNTIME_INVOKE) { + x86_pop_reg (code, X86_ESP); + } Those wrappers are never called from managed code. Zoltan 2008/10/17 Mark Probst : > Hi, > > This patch aligns the stack in managed code on x86 to 16 bytes on all > platforms, not only on Darwin, as done (incompletely) previously. In > addition the alignment can now be specified by a #define. > > The reason for this patch is that floating point code that uses doubles > performs poorly if the stack (and thus the local variables) is not > aligned to at least 8 bytes. > > Paolo: Please review. > > Mark > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From mark.probst at gmail.com Fri Oct 17 13:06:33 2008 From: mark.probst at gmail.com (Mark Probst) Date: Fri, 17 Oct 2008 19:06:33 +0200 Subject: [Mono-dev] Patch: Stack alignment on x86 In-Reply-To: <295e750a0810170954o33f40e5et27c2eef8e98d9c39@mail.gmail.com> References: <1224258136.23602.7.camel@newton> <295e750a0810170954o33f40e5et27c2eef8e98d9c39@mail.gmail.com> Message-ID: Hi Zoltan, > Looks good. Why is this part needed: > > + if (cfg->method->wrapper_type == > MONO_WRAPPER_NATIVE_TO_MANAGED || > + cfg->method->wrapper_type == > MONO_WRAPPER_RUNTIME_INVOKE) { > + x86_pop_reg (code, X86_ESP); > + } > > Those wrappers are never called from managed code. They are entry points from unmanaged code to managed code, and since we can't rely on stack alignment in unmanaged code we have to align the stack in those entry points. What I do in those two wrappers is to put stack alignment instructions around each call. This is the part after the call which restores the stack pointer. The part that goes before the call is in mono_arch_emit_call(). Mark From mark.probst at gmail.com Fri Oct 17 13:43:30 2008 From: mark.probst at gmail.com (Mark Probst) Date: Fri, 17 Oct 2008 19:43:30 +0200 Subject: [Mono-dev] Patch: Stack alignment on x86 In-Reply-To: <295e750a0810170954o33f40e5et27c2eef8e98d9c39@mail.gmail.com> References: <1224258136.23602.7.camel@newton> <295e750a0810170954o33f40e5et27c2eef8e98d9c39@mail.gmail.com> Message-ID: <1224265410.23602.10.camel@newton> Here's a new version of the patch which does the stack alignment upon entry of the wrappers. The nice thing about this is that it only needs one instruction and no counterpart in the epilog. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: x86_stack_align.diff Type: text/x-patch Size: 6421 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081017/8827317d/attachment.bin From twiest at novell.com Fri Oct 17 17:54:02 2008 From: twiest at novell.com (Thomas Wiest) Date: Fri, 17 Oct 2008 15:54:02 -0600 Subject: [Mono-dev] Mono 2.0 for OS X Released! Message-ID: <48F9097A.1080601@novell.com> Today we are pleased to announce the immediate availability of Mono 2.0 for OSX. You can download it from the Mono download page: http://www.go-mono.com/mono-downloads/download.html We apologize for any inconvenience the delay has caused. Thomas From kyuhwan at gmail.com Fri Oct 17 18:52:47 2008 From: kyuhwan at gmail.com (KyuHwan Kim) Date: Fri, 17 Oct 2008 15:52:47 -0700 Subject: [Mono-dev] Class loading related problem with mono xsp and ikvm Message-ID: Hi, everyone. I am doing some project with mono xsp and ikvm. But there is a class loading related problem. Here is my situation. I have the following dlls - dll compiled with IKVMC: JAVA.dll - C# dll: CS.dll --> call JAVA api above When one of the method in CS.dll which call JAVA.dll's method is called from web server, it throws System.NullReferenceException. It seems to be class loading related problem. And when I built test.exe file which calls the CS.dll's method without web server. It also had same problem. I resolved the problem with the test.exe.config which specify the class loader for IKVM The following is the config file. But, with web server (mono xsp) I don't know how to give the configuration to mono xsp or whatever. I expected that simply providing xsp.exe.config with above would resolve it. But it doesn't work. How to resolve this problem? Regards, Kyuhwan From jonpryor at vt.edu Fri Oct 17 21:10:38 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Fri, 17 Oct 2008 21:10:38 -0400 Subject: [Mono-dev] monodoc & mcs/mono module merging Message-ID: <1224292239.6192.56.camel@lina.magi.jprl.com> This is a heads-up that the monodoc & mcs modules are merging for the Mono 2.2 release. Why? The largest reason is so that documentation is closer to the source, in the hopes that someone other than me will actually update the documentation stubs and write documentation for the class libraries. (This may be in vain, but I can hope, can't I?) Another reason is that some class library source I've seen makes use of C#'s XML documentation features, and having the documentation in the same module as the source code should simplify importing this documentation. (I would enable XML documentation importing now, but for mscorlib.dll it drops a fair bit of the existing docs...) How? Files and directories from the monodoc svn module were `svn copy`d into the mcs and mono modules, so full file history should be preserved. This includes: * monodoc/class/ASSEMBLY -> mcs/class/ASSEMBLY/Documentation. * ??monodoc/ecma334 -> mcs/docs/ecma334 * monodoc/engine -> mcs/tools/monodoc * monodoc/man ? -> mono/man * monodoc/scripts ? -> mono/scripts * monodoc/tools/* ? -> mcs/tools/mdoc. The monodoc module hasn't gone (though we may remove it; no ETA), so it can still be referred to. The mcs Makefiles have gained a new `doc-update` target, which when run will update the documentation stubs within the Documentation/en directory using mdoc. Running `doc-update` at the mcs toplevel will update the documentation stubs for all libraries within mcs (where "library" is defined as "anything including library.make" in Makefile). The doc-update target is NOT currently run automatically by the build system. It is up to those wishing to update the documentation to run this target. (This decision may be revisited in the future; I just didn't think it a good idea to have several files changed whenever a library was built, increasing the amount of "noise" developers need to sort through before committing...) The mcs/docs directory assembles the Documentation directories into .tree and .zip files for use by monodoc, and installs them into the same location these files have always been: $prefix/lib/monodoc/sources. mcs now contains and will build and install the documentation-related tools that were in the monodoc module, such as mdoc, monodoc.dll, mod, etc. In terms of packaging, I *hope* that very little will change, big-picture wise. For example, mono-core.spec already creates 18 packages, so it should be possible to create a new %package which contains the same files as the previous monodoc package...[0] Related issues: Many of the monodoc/tools and monodoc/engine programs, which used to be separate, have been bundled together into the mdoc program. (mdoc was introduced in Mono 2.0, but it was just a wrapper for the other apps.) To maintain compatibility, I'll be writing shell scripts which convert the previous command-lines to mdoc command lines. This will impact the commands: mdassembler, mdvalidater, monodocer, monodocs2html, monodocs2slashdoc. I would like to remove the commands mdcs2ecma and mdnormalizer, as mdcs2ecma hasn't been maintained in eons (and monodocer/mdoc already has Microsoft XML documentation import support), and mdnormalizer seems ~pointless (xmllint, anyone?). Unanswered Questions: What should be done about monodoc/engine/web, the ASP.NET frontend to monodoc documentation? I don't believe that it's actually packaged, nor do I know of anyone using it except for http://go-mono.com/docs, but if we want to remove the monodoc module we'll need to move it _somewhere_ (standalone svn module?). - Jon [0] Famous Last Words (TM) From cedricv at neonux.com Sat Oct 18 00:28:08 2008 From: cedricv at neonux.com (Cedric Vivier) Date: Sat, 18 Oct 2008 12:28:08 +0800 Subject: [Mono-dev] [PATCH] Implement Diagnostics.Debugger.IsAttached Message-ID: Hey, Please review attached patch implementing Diagnostics.Debugger.IsAttached. Cheers, -------------- next part -------------- A non-text attachment was scrubbed... Name: debugger_isattached.patch Type: text/x-diff Size: 3827 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081018/756c4ba2/attachment-0001.bin From paul at all-the-johnsons.co.uk Sat Oct 18 19:19:51 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 19 Oct 2008 00:19:51 +0100 Subject: [Mono-dev] libgdiplus shared lib problem Message-ID: <1224371991.5015.19.camel@PB3.Linux> Hi, I'm not sure if this is a problem at my end or with libgdiplus. AIUI, the .so file should not be a symlink to the .so.0 file, but it currently is. Am I correct in thinking this is the case? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081019/5484b488/attachment.bin From mike at middlesoft.co.uk Sat Oct 18 19:45:31 2008 From: mike at middlesoft.co.uk (Michael Barker) Date: Sun, 19 Oct 2008 12:45:31 +1300 Subject: [Mono-dev] Re: [PATCH] System.Messaging using AMQP (RabbitMQ) In-Reply-To: <80d1dfde0810160158h243777f4xf143efd14a2ab28b@mail.gmail.com> References: <80d1dfde0810060108j62b1198egd0a61a3e29fcb12a@mail.gmail.com> <80d1dfde0810080004k3d651576o70cd2baf51dbbad5@mail.gmail.com> <48F0918E.5020602@ximian.com> <80d1dfde0810112146n70f33f7ftefcf756438819c88@mail.gmail.com> <80d1dfde0810121836w1b9f36b0i6c1a9879f20312ce@mail.gmail.com> <48F6FA2D.4080903@ximian.com> <80d1dfde0810160158h243777f4xf143efd14a2ab28b@mail.gmail.com> Message-ID: <80d1dfde0810181645s75493f92s654413d51b97f39@mail.gmail.com> On Thu, Oct 16, 2008 at 9:24 PM, Atsushi Eno wrote: > Looks like (at least) Mono.Messaging.RabbitMQ/MessageFactory.cs is > missing. Can you please check missing stuff in the patch (probably > new files) ? Sorry, my bad. I attached an updated patch to the bug report. > I think it'd be good way to create a branch for your implementation > in svn and let other people help hacking other implementations > (such as Win32API one, as I suggested earlier). Sounds like a good idea to me. If someone wants to create the branch and commit the patches to it I'll be happy to work from there. Regards, Michael Barker. From davidiw at ufl.edu Sat Oct 18 23:01:16 2008 From: davidiw at ufl.edu (David Isaac Wolinsky) Date: Sat, 18 Oct 2008 23:01:16 -0400 Subject: [Mono-dev] .Net remoting and xml-rpc.net on mono 2.0+ In-Reply-To: References: Message-ID: <48FAA2FC.6010809@ufl.edu> Has anyone tried this out yet? It seems to work fine in 1.9.1 but all versions of 2.0 and later (including latest svn from about 1 hour ago) seem not to work. I can file a formal bug report, but I wanted to be optimistic and ask on this list first. If this isn't the preferred solution, then please point me in the right direction. Best, David From m.j.hutchinson at gmail.com Sat Oct 18 23:48:09 2008 From: m.j.hutchinson at gmail.com (Michael Hutchinson) Date: Sat, 18 Oct 2008 23:48:09 -0400 Subject: [Mono-dev] .Net remoting and xml-rpc.net on mono 2.0+ In-Reply-To: <48FAA2FC.6010809@ufl.edu> References: <48FAA2FC.6010809@ufl.edu> Message-ID: On Sat, Oct 18, 2008 at 11:01 PM, David Isaac Wolinsky wrote: > Has anyone tried this out yet? It seems to work fine in 1.9.1 but all > versions of 2.0 and later (including latest svn from about 1 hour ago) > seem not to work. I can file a formal bug report, but I wanted to be > optimistic and ask on this list first. If this isn't the preferred > solution, then please point me in the right direction. Could you file a bug with problem details and a reproducible test case, ideally in a minimal/automatable form we could integrate into the test suite so it doesn't happen again? Thanks! -- Michael Hutchinson http://mjhutchinson.com From adar.wesley at gmail.com Sun Oct 19 03:08:29 2008 From: adar.wesley at gmail.com (Adar Wesley) Date: Sun, 19 Oct 2008 09:08:29 +0200 Subject: [Mono-dev] Class loading related problem with mono xsp and ikvm In-Reply-To: References: Message-ID: Hi, Try naming the configuration file web.config and putting it in the root directory of your web application. --- Adar Wesley On Sat, Oct 18, 2008 at 12:52 AM, KyuHwan Kim wrote: > Hi, everyone. > > I am doing some project with mono xsp and ikvm. > But there is a class loading related problem. > > Here is my situation. > I have the following dlls > - dll compiled with IKVMC: JAVA.dll > - C# dll: CS.dll --> call JAVA api above > > When one of the method in CS.dll which call JAVA.dll's method is > called from web server, it throws System.NullReferenceException. > It seems to be class loading related problem. > And when I built test.exe file which calls the CS.dll's method without > web server. > It also had same problem. I resolved the problem with the > test.exe.config which specify the class loader for IKVM > The following is the config file. > > > > > value="ikvm.runtime.AppDomainAssemblyClassLoader, > IKVM.OpenJDK.ClassLibrary, Version=0.36.0.5, Culture=neutral, > PublicKeyToken=null" /> > > > > But, with web server (mono xsp) I don't know how to give the > configuration to mono xsp or whatever. > I expected that simply providing xsp.exe.config with > above would resolve it. But it doesn't work. > How to resolve this problem? > > > Regards, > Kyuhwan > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- --- Adar Wesley -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081019/174a9362/attachment.html From graham.newton at peavey-eu.com Sun Oct 19 03:05:29 2008 From: graham.newton at peavey-eu.com (Graham Newton) Date: Sun, 19 Oct 2008 08:05:29 +0100 Subject: [Mono-dev] libgdiplus shared lib problem In-Reply-To: <1224371991.5015.19.camel@PB3.Linux> References: <1224371991.5015.19.camel@PB3.Linux> Message-ID: <48FADC39.6080506@peavey-eu.com> It should be a symlink so that if .so.0 is replaced with .so.x the library name doesn't change just the symlink. What is the problem you are having? Graham Paul wrote: > Hi, > > I'm not sure if this is a problem at my end or with libgdiplus. AIUI, > the .so file should not be a symlink to the .so.0 file, but it currently > is. > > Am I correct in thinking this is the case? > > TTFN > > Paul > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From andreas.faerber at web.de Sun Oct 19 04:32:45 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 19 Oct 2008 10:32:45 +0200 Subject: [Mono-dev] mono 2.0, solaris x86, bootstrap In-Reply-To: References: <80002D9E-A8A0-4FE4-8D0D-98FD519FA113@web.de> Message-ID: <5EA225BD-C9A3-45AC-A7A4-70FDCFBA927F@web.de> Hi Pablo et al., I've compiled the latest Mono trunk on S10 5/08, and faced some issues but two different ones: ;) * GNU gettext or something was probably not installed, so gmake failed early when trying to process mcs' .po files. As a workaround I added -- disable-nls to the configure switches. * I had r104591 (post-1.9) installed, and compilation of the net_2_0 assemblies failed due to some class missing in the old mscorlib.dll apparently. Removing the installed Mono and using the latest monolite instead worked fine however. I remember having such an issue before - is this expected? -bash-3.00$ uname -a SunOS sonnengoettin 5.10 Generic_137112-08 i86pc i386 i86pc -bash-3.00$ mono -V Mono JIT compiler version 2.1 (/trunk/mono r116391) Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com TLS: normal GC: System Boehm (with typed GC) SIGSEGV: normal Notification: Thread + polling Architecture: x86 Disabled: none Btw I noticed that lacking git-svn (didn't find the SVN Perl files on S10 on quick search...), Mono from my Git repo wrongly said "Mono JIT compiler version 1.9 (tarball)". I'll see if I can piece together a patch. Andreas Am 12.10.2008 um 21:03 schrieb Andreas F?rber: > >> Here's my Solaris 10 build environment: >> >> PATH=/usr/local/bin:/opt/gdb/bin:/opt/mono/bin:/opt/sfw/bin:/opt/sfw/ >> sbin:/usr/sfw/bin:/usr/bin:/usr/dt/bin:/usr/openwin/bin >> export PATH >> export MAKE=gmake >> export AR=gar >> export STRIP=gstrip >> export RANLIB=granlib >> export AS=gas > > Note: /opt/gdb is a self-compiled amd64 GDB - not needed for > bootstrapping. > Some GNU packages from the Companion CD are used here, Subversion > comes from sunfreeware.com. > >> x86: >> >> GC_PREFIX=/opt/mono-gc7.0 >> ../gc-7.0/configure --prefix=$GC_PREFIX CC=gcc MAKE=gmake AR=gar >> RANLIB=granlib STRIP=gstrip AS=gas INSTALL=/usr/ucb/install >> >> ../mono/configure --prefix=/opt/mono --with-tls=pthread --with- >> sigaltstack=no --with-gc=boehm --enable-dtrace \ >> CC=gcc MAKE=gmake AR=gar RANLIB=granlib STRIP=gstrip AS=gas INSTALL=/ >> usr/ucb/install \ >> CPPFLAGS=-I/opt/mono-gc7.0/include LDFLAGS=-L/opt/mono-gc7.0/lib >> >> amd64: >> >> export LD_LIBRARY_PATH=/usr/sfw/lib/amd64:$LD_LIBRARY_PATH >> GC_PREFIX=/opt/mono-gc7.0 >> ../gc-7.0/configure --prefix=$GC_PREFIX --libdir=$GC_PREFIX/lib/ >> amd64 CC=gcc CFLAGS=-m64 MAKE=gmake AR=gar RANLIB=granlib >> STRIP=gstrip CCAS=gas CCASFLAGS=-64 INSTALL=/usr/ucb/install >> >> export LD_LIBRARY_PATH=/usr/sfw/lib/amd64:$LD_LIBRARY_PATH >> MONO_PREFIX=/opt/mono >> ../mono/configure --prefix=$MONO_PREFIX --bindir=$MONO_PREFIX/bin/ >> amd64 --libdir=$MONO_PREFIX/lib/amd64 --with-tls=pthread --with- >> sigaltstack=no --with-gc=boehm --disable-mcs-build CC="gcc -m64" >> MAKE=gmake AR=gar RANLIB=granlib STRIP=gstrip AS="gas -64" INSTALL=/ >> usr/ucb/install CPPFLAGS=-I/opt/mono-gc7.0/include LDFLAGS=-L/opt/ >> mono-gc7.0/lib/amd64 PKG_CONFIG_PATH=/usr/lib/amd64/pkgconfig:/opt/ >> mono-gc7.0/lib/amd64/pkgconfig From paul at all-the-johnsons.co.uk Sun Oct 19 06:06:14 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 19 Oct 2008 11:06:14 +0100 Subject: [Mono-dev] libgdiplus shared lib problem In-Reply-To: <48FADC39.6080506@peavey-eu.com> References: <1224371991.5015.19.camel@PB3.Linux> <48FADC39.6080506@peavey-eu.com> Message-ID: <1224410774.5015.24.camel@PB3.Linux> Hi, > It should be a symlink so that if .so.0 is replaced with .so.x the > library name doesn't change just the symlink. > What is the problem you are having? It's for part of the packaging for fedora. Currently, to get mono-winforms to work, libgdiplus-devel (which contains the .so file) is needed. I'm trying to fix it so that the -devel file isn't needed (and it's not a case of the .so file being placed in the main package, that isn't allowed), but that means the .so file is not a symlink. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081019/f390807c/attachment-0001.bin From meebey at meebey.net Sun Oct 19 06:50:39 2008 From: meebey at meebey.net (Mirco Bauer) Date: Sun, 19 Oct 2008 12:50:39 +0200 Subject: [Mono-dev] libgdiplus shared lib problem In-Reply-To: <1224410774.5015.24.camel@PB3.Linux> References: <1224371991.5015.19.camel@PB3.Linux> <48FADC39.6080506@peavey-eu.com> <1224410774.5015.24.camel@PB3.Linux> Message-ID: <20081019125039.48d73ff5@redbull.qnetp.net> On Sun, 19 Oct 2008 11:06:14 +0100 Paul wrote: > Hi, > > > It should be a symlink so that if .so.0 is replaced with .so.x the > > library name doesn't change just the symlink. > > What is the problem you are having? > > It's for part of the packaging for fedora. Currently, to get > mono-winforms to work, libgdiplus-devel (which contains the .so file) > is needed. I'm trying to fix it so that the -devel file isn't needed > (and it's not a case of the .so file being placed in the main > package, that isn't allowed), but that means the .so file is not a > symlink. That's a common downstream packaging issue for distributions that split runtime library files from development files. For a solution see: http://pkg-mono.alioth.debian.org/cli-policy/ch-mono.html#s4.2 This specific issue with libgdiplus doesn't apply to Debian though as we are packaging libgdiplus not as a versioned library, thus all files are in one package. (AFAIK upstream is not maintaining ABI/API compat) > > TTFN > > Paul -- Regards, Mirco 'meebey' Bauer PGP-Key ID: 0xEEF946C8 FOSS Developer meebey at meebey.net http://www.meebey.net/ PEAR Developer meebey at php.net http://pear.php.net/ Debian Developer meebey at debian.org http://www.debian.org/ From miguel at novell.com Sun Oct 19 14:23:07 2008 From: miguel at novell.com (Miguel de Icaza) Date: Sun, 19 Oct 2008 14:23:07 -0400 Subject: [Mono-dev] Mono on OSX and iPhone Survey. Message-ID: <1224440587.4608.31.camel@erandi.site> Hello folks, To better understand where we should take Mono in the future for OSX, I have put together a quick survey. Your feedback will help us shape the future of Mono on OSX: http://spreadsheets.google.com/viewform?key=pvPgcz_0Kij3soDnggioyfw&hl=en Miguel. From martin at ximian.com Sun Oct 19 18:14:10 2008 From: martin at ximian.com (Martin Baulig) Date: Mon, 20 Oct 2008 00:14:10 +0200 Subject: [Mono-dev] [PATCH] Implement Diagnostics.Debugger.IsAttached In-Reply-To: References: Message-ID: <1224454450.26167.37.camel@rivendell.trier.ximian.com> On Sat, 2008-10-18 at 12:28 +0800, Cedric Vivier wrote: > Please review attached patch implementing Diagnostics.Debugger.IsAttached. Hi, patch looks good. Can you please add ChangeLog entries and commit ? Martin > > Cheers, -- Martin Baulig - martin at novell.com Novell GmbH, D?sseldorf GF: Volker Smid, Djamel Souici; HRB 21108 (AG D?sseldorf) From martin at ximian.com Sun Oct 19 18:32:47 2008 From: martin at ximian.com (Martin Baulig) Date: Mon, 20 Oct 2008 00:32:47 +0200 Subject: [Mono-dev] [PATCH] Enable stepping into remotinginvoke-wrapped methods In-Reply-To: References: Message-ID: <1224455567.26167.41.camel@rivendell.trier.ximian.com> Hi, thanks a lot for your patch ! I committed it to SVN and also added a testcase for it :-) Martin On Sat, 2008-10-18 at 00:50 +0800, Cedric Vivier wrote: > Hi, > > Currently it is not possible to step into a method of an object > deriving MarshalByRefObject, as in the example below > debugger cannot step into Bar() from Main(). > > >> > using System; > > public class Foo : MarshalByRefObject { > > public void Bar() { > Console.WriteLine("foo!"); > } > > private static void Main() { > var foo = new Foo(); > foo.Bar(); > } > } > << > > Please review the attached patch that enables StepInto for > remotinginvoke-wrapped methods. > > Regards, -- Martin Baulig - martin at novell.com Novell GmbH, D?sseldorf GF: Volker Smid, Djamel Souici; HRB 21108 (AG D?sseldorf) From cedricv at neonux.com Sun Oct 19 20:05:16 2008 From: cedricv at neonux.com (Cedric Vivier) Date: Mon, 20 Oct 2008 08:05:16 +0800 Subject: [Mono-dev] [PATCH] Implement Diagnostics.Debugger.IsAttached In-Reply-To: <1224454450.26167.37.camel@rivendell.trier.ximian.com> References: <1224454450.26167.37.camel@rivendell.trier.ximian.com> Message-ID: On Mon, Oct 20, 2008 at 6:14 AM, Martin Baulig wrote: > patch looks good. > Can you please add ChangeLog entries and commit ? Hey, Commited in as r116486 and r116487. Regards, From atsushi at ximian.com Mon Oct 20 04:06:23 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Mon, 20 Oct 2008 17:06:23 +0900 Subject: [Mono-dev] [PATCH] System.Messaging using AMQP (RabbitMQ) In-Reply-To: <80d1dfde0810181645s75493f92s654413d51b97f39@mail.gmail.com> References: <80d1dfde0810060108j62b1198egd0a61a3e29fcb12a@mail.gmail.com> <80d1dfde0810080004k3d651576o70cd2baf51dbbad5@mail.gmail.com> <48F0918E.5020602@ximian.com> <80d1dfde0810112146n70f33f7ftefcf756438819c88@mail.gmail.com> <80d1dfde0810121836w1b9f36b0i6c1a9879f20312ce@mail.gmail.com> <48F6FA2D.4080903@ximian.com> <80d1dfde0810160158h243777f4xf143efd14a2ab28b@mail.gmail.com> <80d1dfde0810181645s75493f92s654413d51b97f39@mail.gmail.com> Message-ID: <48FC3BFF.5050700@ximian.com> OK, I have committed the patch to "messaging-2008" branch. http://anonsvn.mono-project.com/viewvc/branches/messaging-2008/mcs/class/ Atsushi Eno Michael Barker wrote: > On Thu, Oct 16, 2008 at 9:24 PM, Atsushi Eno wrote: >> Looks like (at least) Mono.Messaging.RabbitMQ/MessageFactory.cs is >> missing. Can you please check missing stuff in the patch (probably >> new files) ? > > Sorry, my bad. I attached an updated patch to the bug report. > >> I think it'd be good way to create a branch for your implementation >> in svn and let other people help hacking other implementations >> (such as Win32API one, as I suggested earlier). > > Sounds like a good idea to me. If someone wants to create the branch > and commit the patches to it I'll be happy to work from there. > > Regards, > Michael Barker. > _______________________________________________ > 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 Mon Oct 20 05:23:11 2008 From: lupus at ximian.com (Paolo Molaro) Date: Mon, 20 Oct 2008 11:23:11 +0200 Subject: [Mono-dev] [PATCH] Implement Diagnostics.Debugger.IsAttached In-Reply-To: References: Message-ID: <20081020092311.GN28194@debian.org> On 10/18/08 Cedric Vivier wrote: > Please review attached patch implementing Diagnostics.Debugger.IsAttached. Please be careful with your patches and don't include whitespace changes mixed with functionality changes. Thanks. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From jonpryor at vt.edu Mon Oct 20 10:53:26 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Mon, 20 Oct 2008 10:53:26 -0400 Subject: [Mono-dev] Using Mono.Options in MS.NET In-Reply-To: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> References: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> Message-ID: <1224514406.6192.153.camel@lina.magi.jprl.com> On Wed, 2008-10-15 at 16:48 -0400, Avery Pennarun wrote: > Now that Mono.Options is included in Mono 2.2, will it still be > available separately? Good question. The answer is that the Mono.Options currently in svn is ~identical to NDesk.Options 0.2.1 (which I'll be announcing soon, it's only been sitting around for the last few months with ~no changes...). The only major difference is the namespace. Which of course means they're not source compatible -- you'll need to change a `using` declaration... That said, for the time being I plan on keeping NDesk.Options & Mono.Options in sync with each other (and will likely use a #if block in the future to control the namespace so that they'll be identical files), but I don't know for how long I'd want to do this... - Jon From apenwarr at gmail.com Mon Oct 20 13:32:35 2008 From: apenwarr at gmail.com (Avery Pennarun) Date: Mon, 20 Oct 2008 13:32:35 -0400 Subject: [Mono-dev] Using Mono.Options in MS.NET In-Reply-To: <1224514406.6192.153.camel@lina.magi.jprl.com> References: <32541b130810151348y728dcabbp3754b59a6e13ae2e@mail.gmail.com> <1224514406.6192.153.camel@lina.magi.jprl.com> Message-ID: <32541b130810201032q1902e2c6g456fb6d7bd9c2a7d@mail.gmail.com> On Mon, Oct 20, 2008 at 10:53 AM, Jonathan Pryor wrote: > On Wed, 2008-10-15 at 16:48 -0400, Avery Pennarun wrote: >> Now that Mono.Options is included in Mono 2.2, will it still be >> available separately? > > Good question. The answer is that the Mono.Options currently in svn is > ~identical to NDesk.Options 0.2.1 (which I'll be announcing soon, it's > only been sitting around for the last few months with ~no changes...). > The only major difference is the namespace. > > Which of course means they're not source compatible -- you'll need to > change a `using` declaration... > > That said, for the time being I plan on keeping NDesk.Options & > Mono.Options in sync with each other (and will likely use a #if block in > the future to control the namespace so that they'll be identical files), > but I don't know for how long I'd want to do this... In the end, as others have pointed out, it's pretty easy to extract the file from the mono svn repository, and it's not something that has to happen often. It just seems like an odd thing to ask non-mono-using C# programmers to do :) Harmless, though, particularly if you provide a direct hyperlink to the SVN tarball-making URL. Thanks again for your work on this library. It's awesome. Have fun, Avery From albertoavila at gmail.com Mon Oct 20 14:12:48 2008 From: albertoavila at gmail.com (albertoavila at gmail.com) Date: Mon, 20 Oct 2008 14:12:48 -0400 (EDT) Subject: [Mono-dev] Te invito a ver mi metroFLOG Message-ID: <20081020181248.5FEAD7001F@herald.ximian.com> Hola!!! Te invito a que visites mi metroFlog para que puedas ver y firmar mis ?ltimas fotograf?as.. Para visitar mi espacio, deber?s ir a: http://www.metroflog.com/albertein metroFLOG es un espacio personal completamente personalizable para que compartas con quien deseas. Diaramente podr?s subir una foto con una descripci?n, y que tus amigos firmen el libro de visitas. Para crear tu propio espacio, deber?s ir a: http://www.metroflog.com Saludos! Si no deseas continuar recibiendo invitaciones de parte de tus amigos para ver sus espacios, accede en la siguiente direcci?n: http://www.metroflog.com/unsubscribe?Email=mono-devel-list at lists.ximian.com Este mensaje ha sido enviado autom?ticamente mediante los servicios de metroFLOG.com a pedido del remitente. Garantizamos que su direcci?n de correo no ha sido agregada a ninguna lista de envios ni ser? compartida con terceros en ning?n momento. From mashcaster at googlemail.com Mon Oct 20 03:49:13 2008 From: mashcaster at googlemail.com (mashcaster) Date: Mon, 20 Oct 2008 00:49:13 -0700 (PDT) Subject: [Mono-dev] System tray Message-ID: <20064781.post@talk.nabble.com> How do I make my program minimise to a linux system tray? -- View this message in context: http://www.nabble.com/System-tray-tp20064781p20064781.html Sent from the Mono - Dev mailing list archive at Nabble.com. From alisdair_little at yahoo.com Mon Oct 20 12:00:45 2008 From: alisdair_little at yahoo.com (Alisdair Little) Date: Mon, 20 Oct 2008 09:00:45 -0700 (PDT) Subject: [Mono-dev] RichTextBox Scroll Position Message-ID: <20073031.post@talk.nabble.com> Hi Guys, Any idea how to get the vertical scroll position for a RichTextBox? I have tried; [DllImport("user32")] public static extern bool GetScrollInfo(IntPtr hwnd, int fnBar, ref SCROLLINFO lpsi); [DllImport("user32")] public static extern int GetScrollPos(IntPtr hwnd, int nBar); [DllImport("user32")] public static extern int SendMessage(HWND hwnd, int wMsg, int wParam, IntPtr lParam); All these calls work under Visual Studio/windows but not under mono. My Environment: Windows XP, Visual Studio 2005 and Mono 2.0. Thanks, Al -- View this message in context: http://www.nabble.com/RichTextBox-Scroll-Position-tp20073031p20073031.html Sent from the Mono - Dev mailing list archive at Nabble.com. From steve.gentile at yahoo.com Mon Oct 20 15:18:00 2008 From: steve.gentile at yahoo.com (Recon) Date: Mon, 20 Oct 2008 12:18:00 -0700 (PDT) Subject: [Mono-dev] ASP.NET MVC and Mono problems In-Reply-To: <489F0B68.2050704@terminaldischarge.net> References: <489F0B68.2050704@terminaldischarge.net> Message-ID: <20076543.post@talk.nabble.com> Did you add: to your web.config ? -- View this message in context: http://www.nabble.com/ASP.NET-MVC-and-Mono-problems-tp18914187p20076543.html Sent from the Mono - Dev mailing list archive at Nabble.com. From contact at i-nz.net Tue Oct 21 11:09:51 2008 From: contact at i-nz.net (Ivan N. Zlatev) Date: Tue, 21 Oct 2008 16:09:51 +0100 Subject: [Mono-dev] RichTextBox Scroll Position In-Reply-To: <20073031.post@talk.nabble.com> References: <20073031.post@talk.nabble.com> Message-ID: <3db1ec7f0810210809p668415c8n23c48e2abc80304@mail.gmail.com> On Mon, Oct 20, 2008 at 5:00 PM, Alisdair Little wrote: > > Hi Guys, > > Any idea how to get the vertical scroll position for a RichTextBox? > > I have tried; > [DllImport("user32")] > public static extern bool GetScrollInfo(IntPtr hwnd, int fnBar, ref > SCROLLINFO lpsi); > [DllImport("user32")] > public static extern int GetScrollPos(IntPtr hwnd, int nBar); > [DllImport("user32")] > public static extern int SendMessage(HWND hwnd, int wMsg, int > wParam, IntPtr lParam); > > All these calls work under Visual Studio/windows but not under mono. > My Environment: Windows XP, Visual Studio 2005 and Mono 2.0. > What about richTextBox.GetPositionFromCharIndex (richTextBox.GetFirstCharIndexFromLine (0)).Y ? -- Kind Regards, Ivan N. Zlatev From billholmes54 at gmail.com Tue Oct 21 11:18:34 2008 From: billholmes54 at gmail.com (Bill Holmes) Date: Tue, 21 Oct 2008 11:18:34 -0400 Subject: [Mono-dev] [PATCH] VS changes needed for MonoPosixHelper.dll in mono/support. Message-ID: <37c5788d0810210818p4e82be9di2abeda6dd9fc8067@mail.gmail.com> The attached patch is to add some additional preprocessor to support/map.c. I am starting to add MonoPosixHelper.dll to the VS build for Winx64. I do have some questions about changing configure.in. Where is the right place to add AC_CHECK_HEADERS(dirent.h)? There are AC_CHECK_HEADERS checks for sys/time.h and utime.h already. There does not appear to be a check for unistd.h but #define HAVE_UNISTD_H does appear in config.h. Does a check need to be added? Is it obvious that I know nothing about autogen, autoconf and make? ;) -bill 2008-10-21 Bill Holmes * configure.in : Adding a auto configure check for dirent.h. * support/Makefile.am : For generation of map.c adding preprocessor checks for sys/time.h, unistd.h, dirent.h and utime.h. * support/map.c : Re-run 'make refresh' to add preprocessor checks for sys/time.h, unistd.h, dirent.h and utime.h. Code is contributed under MIT/X11 license. -------------- next part -------------- A non-text attachment was scrubbed... Name: support_map.c.diff Type: application/octet-stream Size: 4081 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081021/cee0e8c2/attachment.obj From contact at i-nz.net Tue Oct 21 14:02:53 2008 From: contact at i-nz.net (Ivan N. Zlatev) Date: Tue, 21 Oct 2008 19:02:53 +0100 Subject: [Mono-dev] Fwd: RichTextBox Scroll Position In-Reply-To: <15685505.1501691224602933812.JavaMail.nabble@isper.nabble.com> References: <15685505.1501691224602933812.JavaMail.nabble@isper.nabble.com> Message-ID: <3db1ec7f0810211102n4dacd390p9f3524afc44c4319@mail.gmail.com> ---------- Forwarded message ---------- From: Date: Tue, Oct 21, 2008 at 4:28 PM Subject: Re: RichTextBox Scroll Position To: contact at i-nz.net Hi Ivan, Thanks so much for the hint. It works like a charm! Kind Regards, Al Ivan N. Zlatev wrote: > > On Mon, Oct 20, 2008 at 5:00 PM, Alisdair Little > wrote: >> >> Hi Guys, >> >> Any idea how to get the vertical scroll position for a RichTextBox? >> >> I have tried; >> [DllImport("user32")] >> public static extern bool GetScrollInfo(IntPtr hwnd, int fnBar, >> ref >> SCROLLINFO lpsi); >> [DllImport("user32")] >> public static extern int GetScrollPos(IntPtr hwnd, int nBar); >> [DllImport("user32")] >> public static extern int SendMessage(HWND hwnd, int wMsg, int >> wParam, IntPtr lParam); >> >> All these calls work under Visual Studio/windows but not under mono. >> My Environment: Windows XP, Visual Studio 2005 and Mono 2.0. >> > > What about richTextBox.GetPositionFromCharIndex > (richTextBox.GetFirstCharIndexFromLine (0)).Y ? > > -- > Kind Regards, > Ivan N. Zlatev > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > Quoted from: http://www.nabble.com/RichTextBox-Scroll-Position-tp20073031p20092389.html -- Kind Regards, Ivan N. Zlatev From SpamMonkey01+Mono at gmail.com Tue Oct 21 15:24:57 2008 From: SpamMonkey01+Mono at gmail.com (Thracx) Date: Tue, 21 Oct 2008 12:24:57 -0700 (PDT) Subject: [Mono-dev] Oracle and Mono In-Reply-To: <48ECEAA9.2000007@terra.es> References: <48ECD2C3.1010909@terra.es> <756157.70476.qm@web30802.mail.mud.yahoo.com> <48ECEAA9.2000007@terra.es> Message-ID: <20097391.post@talk.nabble.com> Hello All, I'm interested in helping to get Oracle working on a Solaris 10 Sparc machines. Has any work been started recently that I can help with, or is there someone familiar with this section of the code which could help me get started? Thanks, -Thracx PABLOSANTOSLUAC at terra.es wrote: > > Hi Daniel, > > > I can give hacker access to a Solaris 10 SPARC box. Putting the latest > mono there is what I'm really trying to do these days. > > About 4: it's not normally an option, talk to Miguel. > > > pablo > > Daniel Morgan escribi?: >> When I say "supported", it means it has not been tested nor developed for >> the platform. Thus, it probably does not work on these platforms. >> >> However, if you need access to Oracle via Mono on these platforms, there >> are some things you can do to get it "supported". >> >> 1. contribute patches which fixes any bugs to allow it to work on those >> platofrms >> >> -- or -- >> >> 2. provide some hacker remote access to a sparc machine with a recent >> version of mono/mcs working on the machine, and access to an oracle >> database. ssh? >> >> -- or -- >> >> 3. donate or lend a developer a sparc machine with a recent mono which >> runs a recent version of mono >> >> -- or -- >> >> 4. Your best bet - pay Novell for the support. There is some wiki page >> where you can get paid support to add a feature of fix a bug for mono. >> >> http://www.mono-project.com/Kickstart >> >> Note, I do not work for Novell nor am I getting anything for this message >> - just a public message. >> >> Most people running oracle is on linux/x86, windows, or hp these days. >> >> --- On Wed, 10/8/08, pablosantosluac at terra.es >> wrote: >> >> >>> From: pablosantosluac at terra.es >>> Subject: [Mono-dev] Oracle and Mono >>> To: "mono-devel-list at lists.ximian.com" >>> >>> Date: Wednesday, October 8, 2008, 11:33 AM >>> Hi there, >>> >>> I've read that Oracle is not supported on SPARC nor PPC >>> here >>> http://www.mono-project.com/Oracle. Is that correct? >>> >>> >>> Thanks >>> >>> >>> pablo >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >> >> >> >> >> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- View this message in context: http://www.nabble.com/Oracle-and-Mono-tp19881320p20097391.html Sent from the Mono - Dev mailing list archive at Nabble.com. From SpamMonkey01+Mono at gmail.com Tue Oct 21 15:26:26 2008 From: SpamMonkey01+Mono at gmail.com (Thracx) Date: Tue, 21 Oct 2008 12:26:26 -0700 (PDT) Subject: [Mono-dev] Oracle and Mono Message-ID: <20097391.post@talk.nabble.com> Hello All, I'm interested in helping to get Oracle working on a Solaris 10 Sparc machines. Has any work been started recently that I can help with, or is there someone familiar with this section of the code which could help me get started? Thanks, -Thracx >> When I say "supported", it means it has not been tested nor developed for >> the platform. Thus, it probably does not work on these platforms. >> >> However, if you need access to Oracle via Mono on these platforms, there >> are some things you can do to get it "supported". >> >> 1. contribute patches which fixes any bugs to allow it to work on those >> platofrms > .... > .... >>> I've read that Oracle is not supported on SPARC nor PPC >>> here >>> http://www.mono-project.com/Oracle. Is that correct? > -- View this message in context: http://www.nabble.com/Oracle-and-Mono-tp19881320p20097391.html Sent from the Mono - Dev mailing list archive at Nabble.com. From Scott.Fluto at cmgl.ca Tue Oct 21 16:06:24 2008 From: Scott.Fluto at cmgl.ca (srf) Date: Tue, 21 Oct 2008 13:06:24 -0700 (PDT) Subject: [Mono-dev] PPC64 - is it any closer In-Reply-To: <250D8FA2-912D-4FC5-B34A-AAAA774B9577@web.de> References: <1222994013.6325.8.camel@PB3.Linux> <48E52BA1020000400003FAC6@lucius.provo.novell.com> <250D8FA2-912D-4FC5-B34A-AAAA774B9577@web.de> Message-ID: <20098328.post@talk.nabble.com> We have IBM PowerPC boxes and would like to get mono running on it so if you have something semi stable that we could test, that would be greae and we could help it the testing to find any problems. Let me know anyhow . thanks scott Andreas F?rber wrote: > > Hi Paul et al., > > I have been offline for some weeks. Some smaller patches were posted > before that time, but there has still been no review yet to my > knowledge. This includes my long-standing enhancements to ppc(64) code > generation [2], some signedness changes for OSX, some guint32 -> > gulong changes (e.g., [1]), and Olaf posted a ppc64-related patch to > use GCC 4.1's new built-in atomic ops when available [3]. > > There is a ticket tracking ppc64 progress: > https://bugzilla.novell.com/show_bug.cgi?id=324134 > > I have multiple Git branches on repo.or.cz: > http://repo.or.cz/w/mono/afaerber.git > - ppc64-cleanup includes cosmetic changes that help with our changes > and their review > - ppc64-functional includes functional ppc changes in addition to the > cosmetic ones > - ppc64 tracks the "final" work-in-progress (Two patches from Olaf's > branch I still need to apply there.) > - ppc64-todo sometimes has changes on top of ppc64, to keep TODOs out > of the patches > Getting rebased all the time, I admit they are not comfortable to read > log-wise but the patches posted in Bugzilla can be extracted by `git > diff master2..ppc64-cleanup`, `git diff ppc64-cleanup..ppc64- > functional` etc. > > Regarding the time frame, I've worked on the port since Q2 2007 as > time permits, and the big obvious hurdles have been taken; now it's > mostly rebasing against breaking changes in trunk and about debugging. > Any help and ideas where the crashes/hangs/whatever-it's-currently may > stem from are highly appreciated. > > If we could get an okay to apply some of our smaller non-intrusive > changes (below) to trunk, it would greatly help our porting effort and > Geoff, Paolo or whomever with the review of the "real" JIT changes. > > Regards, > > Andreas > > [1] > http://lists.ximian.com/pipermail/mono-devel-list/2008-August/028757.html > [2] > http://lists.ximian.com/pipermail/mono-devel-list/2008-January/026484.html > (slightly updated in Git, but pending since 2007) > [3] > http://lists.ximian.com/pipermail/mono-devel-list/2008-August/028755.html > (non-libgc part) > [4] > http://lists.ximian.com/pipermail/mono-devel-list/2008-August/028760.html > (generic) > > > Am 03.10.2008 um 04:14 schrieb Andrew Jorgensen: > >> It's in the works. The mono team and some of the SuSE folks are >> working >> on it. I cannot promise anything regarding how long it will take. >> It's >> not trivial. >> >>>>> Paul 10/02/08 6:40 PM >>> >> Hi, >> >> Just a quick question. Is there a "true" PPC64 version of Mono and not >> just a PPC32 running on PPC64? >> >> TTFN >> >> Paul >> -- >> Sie k?nnen mich aufreizen und wirklich hei? machen! >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- View this message in context: http://www.nabble.com/PPC64---is-it-any-closer-tp19790278p20098328.html Sent from the Mono - Dev mailing list archive at Nabble.com. From monodanmorg at yahoo.com Tue Oct 21 16:41:35 2008 From: monodanmorg at yahoo.com (Daniel Morgan) Date: Tue, 21 Oct 2008 13:41:35 -0700 (PDT) Subject: [Mono-dev] Oracle and Mono In-Reply-To: <20097391.post@talk.nabble.com> Message-ID: <680576.41580.qm@web30808.mail.mud.yahoo.com> Build Mono from Subversion http://mono-project.com/Compiling_Mono#Building_Mono_from_the_Subversion_Repository Oracle Documentation http://tahiti.oracle.com/ Oracle Call Interface Programmer's Guide http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14250/toc.htm Read chapter 2 to get a basic understanding of how to use OCI. Build and Run the Tests for Oracle client mcs/class/System.Data.OracleClient/Test See the README and config files there. You will need to edit the config files for you connection string To build the tests in mcs/class/System.Data.OracleClient, run: $ make test To run the tests: $ make run-test BitConverter is a class usefull for conversion of integers from little-endian to big-endian. However, it has its problems. Mono provides a much improved class called Mono.DataConvert. http://www.mono-project.com/Mono_DataConvert OCI uses handles to do almost anything: environment, server, session, error, statement, binding, etc. In our implementation of System.Data.OracleClient, we wrap these handles. Such as, the environment handle is wrapped via OciEnvironmentHandle. All these specific OCI wrapper classes are internal and exist in the namespace System.Data.OracleClient.oci. The calls to OCI native library are in a static class called OciCalls. These calls call methods in a private class called OciNativeCalls. This is done so any call to OCI can be traced. The classes in System.Data.OracleClient are the classes that implement the .net compatible API and wrap the classes in System.Data.OracleClient.oci. --- On Tue, 10/21/08, Thracx wrote: > From: Thracx > Subject: Re: [Mono-dev] Oracle and Mono > To: mono-devel-list at lists.ximian.com > Date: Tuesday, October 21, 2008, 3:24 PM > Hello All, > > I'm interested in helping to get Oracle working on a > Solaris 10 Sparc > machines. Has any work been started recently that I can > help with, or is > there someone familiar with this section of the code which > could help me get > started? > > Thanks, > -Thracx > > > PABLOSANTOSLUAC at terra.es wrote: > > > > Hi Daniel, > > > > > > I can give hacker access to a Solaris 10 SPARC box. > Putting the latest > > mono there is what I'm really trying to do these > days. > > > > About 4: it's not normally an option, talk to > Miguel. > > > > > > pablo > > > > Daniel Morgan escribi?: > >> When I say "supported", it means it has > not been tested nor developed for > >> the platform. Thus, it probably does not work on > these platforms. > >> > >> However, if you need access to Oracle via Mono on > these platforms, there > >> are some things you can do to get it > "supported". > >> > >> 1. contribute patches which fixes any bugs to > allow it to work on those > >> platofrms > >> > >> -- or -- > >> > >> 2. provide some hacker remote access to a sparc > machine with a recent > >> version of mono/mcs working on the machine, and > access to an oracle > >> database. ssh? > >> > >> -- or -- > >> > >> 3. donate or lend a developer a sparc machine with > a recent mono which > >> runs a recent version of mono > >> > >> -- or -- > >> > >> 4. Your best bet - pay Novell for the support. > There is some wiki page > >> where you can get paid support to add a feature of > fix a bug for mono. > >> > >> http://www.mono-project.com/Kickstart > >> > >> Note, I do not work for Novell nor am I getting > anything for this message > >> - just a public message. > >> > >> Most people running oracle is on linux/x86, > windows, or hp these days. > >> > >> --- On Wed, 10/8/08, pablosantosluac at terra.es > > >> wrote: > >> > >> > >>> From: pablosantosluac at terra.es > > >>> Subject: [Mono-dev] Oracle and Mono > >>> To: > "mono-devel-list at lists.ximian.com" > >>> > >>> Date: Wednesday, October 8, 2008, 11:33 AM > >>> Hi there, > >>> > >>> I've read that Oracle is not supported on > SPARC nor PPC > >>> here > >>> http://www.mono-project.com/Oracle. Is that > correct? > >>> > >>> > >>> Thanks > >>> > >>> > >>> pablo > >>> > _______________________________________________ > >>> Mono-devel-list mailing list > >>> Mono-devel-list at lists.ximian.com > >>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list > >>> > >> > >> > >> > >> > >> > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > -- > View this message in context: > http://www.nabble.com/Oracle-and-Mono-tp19881320p20097391.html > Sent from the Mono - Dev mailing list archive at > Nabble.com. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From atsushi at ximian.com Wed Oct 22 00:47:46 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Wed, 22 Oct 2008 13:47:46 +0900 Subject: [Mono-dev] [Fwd: [Mono-patches] r116660 - trunk/mono/data/net_2_0] Message-ID: <48FEB072.5030604@ximian.com> Hi grendel, How does this break 2.0 apps? They do not exist in .NET, but they do in our 2.0 profile (lib/mono/2.0). Atsushi Eno -------- Original Message -------- Subject: [Mono-patches] r116660 - trunk/mono/data/net_2_0 Date: Tue, 21 Oct 2008 14:40:56 -0400 (EDT) From: Marek Habersack (grendello at gmail.com) To: mono-patches at lists.ximian.com, ximian.monolist at gmail.com, mono-svn-patches-garchive-20758 at googlegroups.com Author: mhabersack Date: 2008-10-21 14:40:56 -0400 (Tue, 21 Oct 2008) New Revision: 116660 Modified: trunk/mono/data/net_2_0/web.config Log: Revert r116595 - the 3.5 assemblies mustn't be included in the system web.config - it breaks all 2.0 applications Modified: trunk/mono/data/net_2_0/web.config =================================================================== --- trunk/mono/data/net_2_0/web.config 2008-10-21 18:40:38 UTC (rev 116659) +++ trunk/mono/data/net_2_0/web.config 2008-10-21 18:40:56 UTC (rev 116660) @@ -75,11 +75,9 @@ - - @@ -96,10 +94,6 @@ - - - - _______________________________________________ Mono-patches maillist - Mono-patches at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-patches From grendel at twistedcode.net Wed Oct 22 10:32:51 2008 From: grendel at twistedcode.net (Marek Habersack) Date: Wed, 22 Oct 2008 16:32:51 +0200 Subject: [Mono-dev] [Fwd: [Mono-patches] r116660 - trunk/mono/data/net_2_0] In-Reply-To: <48FEB072.5030604@ximian.com> References: <48FEB072.5030604@ximian.com> Message-ID: <20081022163251.11b67c36@twistedcode.net> On Wed, 22 Oct 2008 13:47:46 +0900 Atsushi Eno wrote: > Hi grendel, Hey Atsushi, > How does this break 2.0 apps? They do not exist in .NET, but > they do in our 2.0 profile (lib/mono/2.0). If you have an application which uses System.Web.Extensions 1.0, it will break. The Telerik controls (for 2.0), for instance, failed to compile because the compiler complained about duplicate symbols in the assemblies. .NET leaves the assemblies out for the same reason - to support legacy 2.0 apps painlessly. If you want to make it easier to reference 3.5 libraries in a project, I'd recommend adding a .NET 3.5 rule to mconfig (in the similar fashion AJAX is added). See mcs/tools/mconfig/data/config.xml and http://www.mono-project.com/Howto_Mconfig best, marek > Atsushi Eno > > -------- Original Message -------- > Subject: [Mono-patches] r116660 - trunk/mono/data/net_2_0 > Date: Tue, 21 Oct 2008 14:40:56 -0400 (EDT) > From: Marek Habersack (grendello at gmail.com) > > To: mono-patches at lists.ximian.com, ximian.monolist at gmail.com, > mono-svn-patches-garchive-20758 at googlegroups.com > > Author: mhabersack > Date: 2008-10-21 14:40:56 -0400 (Tue, 21 Oct 2008) > New Revision: 116660 > > Modified: > trunk/mono/data/net_2_0/web.config > Log: > Revert r116595 - the 3.5 assemblies mustn't be included in the system > web.config - it breaks all 2.0 applications > > Modified: trunk/mono/data/net_2_0/web.config > =================================================================== > --- trunk/mono/data/net_2_0/web.config 2008-10-21 18:40:38 UTC (rev 116659) > +++ trunk/mono/data/net_2_0/web.config 2008-10-21 18:40:56 UTC (rev 116660) > @@ -75,11 +75,9 @@ > namespace="System.Text.RegularExpressions" /> > > - > > > > - > > > > @@ -96,10 +94,6 @@ > > > > - > - > - > - > > > > _______________________________________________ > Mono-patches maillist - Mono-patches at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-patches > From atsushi at ximian.com Wed Oct 22 12:44:25 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Thu, 23 Oct 2008 01:44:25 +0900 Subject: [Mono-dev] [Fwd: [Mono-patches] r116660 - trunk/mono/data/net_2_0] In-Reply-To: <20081022163251.11b67c36@twistedcode.net> References: <48FEB072.5030604@ximian.com> <20081022163251.11b67c36@twistedcode.net> Message-ID: <48FF5869.1030007@ximian.com> Hey Marek, Marek Habersack wrote: > On Wed, 22 Oct 2008 13:47:46 +0900 > Atsushi Eno wrote: > >> Hi grendel, > Hey Atsushi, > >> How does this break 2.0 apps? They do not exist in .NET, but >> they do in our 2.0 profile (lib/mono/2.0). > If you have an application which uses System.Web.Extensions 1.0, it will break. The > Telerik controls (for 2.0), for instance, failed to compile because the compiler > complained about duplicate symbols in the assemblies. .NET leaves the assemblies out > for the same reason - to support legacy 2.0 apps painlessly. If you want to make it > easier to reference 3.5 libraries in a project, I'd recommend adding a .NET 3.5 rule > to mconfig (in the similar fashion AJAX is added). See > mcs/tools/mconfig/data/config.xml and http://www.mono-project.com/Howto_Mconfig Oh, right. Actually I found an section in my sample DynamicData application (that I sent you before). So it must be included in every web app instead of having those references in our global web.config. Then there should be different problem in our build manager that blocks compiling DynamicData sites. Maybe it is insufficient support for / (there is a configuration element which is " References: <48FEB072.5030604@ximian.com> <20081022163251.11b67c36@twistedcode.net> <48FF5869.1030007@ximian.com> Message-ID: <20081022184850.3484d521@twistedcode.net> On Thu, 23 Oct 2008 01:44:25 +0900 Atsushi Eno wrote: > Hey Marek, > > Marek Habersack wrote: > > On Wed, 22 Oct 2008 13:47:46 +0900 > > Atsushi Eno wrote: > > > >> Hi grendel, > > Hey Atsushi, > > > >> How does this break 2.0 apps? They do not exist in .NET, but > >> they do in our 2.0 profile (lib/mono/2.0). > > If you have an application which uses System.Web.Extensions 1.0, it will break. > > The Telerik controls (for 2.0), for instance, failed to compile because the > > compiler complained about duplicate symbols in the assemblies. .NET leaves the > > assemblies out for the same reason - to support legacy 2.0 apps painlessly. If >