[Mono-dev] Cannot compile mono today
after : svn up make clean ./autogen.sh make ... /bin/sh ../../libtool --tag=CC --mode=link gcc -O -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 -mno-tls-direct-seg-refs -o pedump pedump.o libmonoruntime.la ../io-layer/libwapi.la ../utils/libmonoutils.la ../../libgc/libmonogc.la -pthread -lgthread-2.0 -lglib-2.0 -Wl,--export-dynamic -lgmodule-2.0 -ldl -lglib-2.0 -lm -lpthread -lm gcc -O -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 -mno-tls-direct-seg-refs -o pedump pedump.o -pthread -Wl,--export-dynamic ./.libs/libmonoruntime.a ../io-layer/.libs/libwapi.a ../utils/.libs/libmonoutils.a ../../libgc/.libs/libmonogc.a /usr/lib/libgthread-2.0.so /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libglib-2.0.so -lpthread -lm ./.libs/libmonoruntime.a(domain.o): In function `mono_domain_create': /home/hubert/mono/mono/mono/metadata/domain.c:470: undefined reference to `mono_g_hash_table_new_type' /home/hubert/mono/mono/mono/metadata/domain.c:476: undefined reference to `mono_g_hash_table_new' ./.libs/libmonoruntime.a(domain.o): In function `mono_domain_free': /home/hubert/mono/mono/mono/metadata/domain.c:1038: undefined reference to `mono_g_hash_table_destroy' /home/hubert/mono/mono/mono/metadata/domain.c:1055: undefined reference to `mono_g_hash_table_destroy' /home/hubert/mono/mono/mono/metadata/domain.c:1082: undefined reference to `mono_g_hash_table_destroy' /home/hubert/mono/mono/mono/metadata/domain.c:1078: undefined reference to `mono_g_hash_table_destroy' /home/hubert/mono/mono/mono/metadata/domain.c:1074: undefined reference to `mono_g_hash_table_destroy' ./.libs/libmonoruntime.a(image.o):/home/hubert/mono/mono/mono/metadata/image.c:1147: more undefined references to `mono_g_hash_table_destroy' follow ./.libs/libmonoruntime.a(reflection.o): In function `mono_image_typedef_or_ref':/home/hubert/mono/mono/mono/metadata/reflection.c:2276: undefined reference to `mono_g_hash_table_insert' ./.libs/libmonoruntime.a(reflection.o): In function `mono_image_basic_method': /home/hubert/mono/mono/mono/metadata/reflection.c:997: undefined reference to `mono_g_hash_table_insert' /home/hubert/mono/mono/mono/metadata/reflection.c:970: undefined reference to `mono_g_hash_table_insert' ./.libs/libmonoruntime.a(reflection.o): In function `create_dynamic_mono_image':/home/hubert/mono/mono/mono/metadata/reflection.c:4355: undefined reference to `mono_g_hash_table_new_type' /home/hubert/mono/mono/mono/metadata/reflection.c:4360: undefined reference to `mono_g_hash_table_new_type' ./.libs/libmonoruntime.a(reflection.o): In function `mono_image_basic_init': /home/hubert/mono/mono/mono/metadata/reflection.c:5205: undefined reference to `mono_g_hash_table_lookup' /home/hubert/mono/mono/mono/metadata/reflection.c:5205: undefined reference to `mono_g_hash_table_new_type' /home/hubert/mono/mono/mono/metadata/reflection.c:5205: undefined reference to `mono_g_hash_table_insert' ./.libs/libmonoruntime.a(reflection.o): In function `register_module': /home/hubert/mono/mono/mono/metadata/reflection.c:5211: undefined reference to `mono_g_hash_table_lookup' ./.libs/libmonoruntime.a(reflection.o): In function `mono_image_module_basic_init': /home/hubert/mono/mono/mono/metadata/reflection.c:5211: undefined reference to `mono_g_hash_table_new_type' /home/hubert/mono/mono/mono/metadata/reflection.c:5211: undefined reference to `mono_g_hash_table_insert' ./.libs/libmonoruntime.a(reflection.o): In function `mono_image_insert_string': /home/hubert/mono/mono/mono/metadata/reflection.c:4120: undefined reference to `mono_g_hash_table_insert' ./.libs/libmonoruntime.a(reflection.o): In function `mono_assembly_get_object': /home/hubert/mono/mono/mono/metadata/reflection.c:5264: undefined reference to `mono_g_hash_table_lookup' /home/hubert/mono/mono/mono/metadata/reflection.c:5264: undefined reference to `mono_g_hash_table_new_type' /home/hubert/mono/mono/mono/metadata/reflection.c:5264: undefined reference to `mono_g_hash_table_lookup' /home/hubert/mono/mono/mono/metadata/reflection.c:5271: undefined reference to `mono_g_hash_table_lookup' /home/hubert/mono/mono/mono/metadata/reflection.c:5271: undefined reference to `mono_g_hash_table_new_type' /home/hubert/mono/mono/mono/metadata/reflection.c:5271: undefined reference to `mono_g_hash_table_insert' ./.libs/libmonoruntime.a(reflection.o): In function `mono_module_get_object': /home/hubert/mono/mono/mono/metadata/reflection.c:5283: undefined reference to `mono_g_hash_table_lookup' /home/hubert/mono/mono/mono/metadata/reflection.c:5283: undefined reference to `mono_g_hash_table_new_type' /home/hubert/mono/mono/mono/metadata/r
Re: [Mono-dev] [PATCH] Correction to the r65131 inSystem.Web.UI.WebControls/ObjectDataSourceView.cs
That's by documentation, quoting the msdn (ObjectDataSource.TypeName Property): To create an instance of the object that the ObjectDataSource control binds to, the control uses reflection to load the type that is identified by the type name at run time. Therefore, the value of the TypeName property can be a partially qualified type for code that is located in the Bin or App_Code directories or a fully qualified type name for code that is registered in the global assembly cache. If you use the global assembly cache, you must add the appropriate reference to the assemblies section of the Machine.config or Web.config file. Regards, Konstantin Triger -Original Message- From: Gonzalo Paniagua Javier [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 7:29 AM To: Konstantin Triger Cc: mono-devel-list@lists.ximian.com; [EMAIL PROTECTED] Subject: Re: [PATCH] Correction to the r65131 inSystem.Web.UI.WebControls/ObjectDataSourceView.cs On Sun, 2006-10-08 at 06:58 -0700, Konstantin Triger wrote: > Hello all, > The r65131 changed the implementation to iterate over the currently > loaded assemblies and try to load the type from there. This operation > is relatively heavy and especially very untrivial for Java profile. > The attached patch uses Type.GetType() for the same purpose, which > should be equal. > > Please approve commit. Type.GetType will work fine *if* the type if fully qualified. If not, it will just search in the executing assembly and corlib. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Oracle LOB help
I read the post "[Mono-devel-list] System.Data.OracleClient and CLOB's", and I would like to ask you if exist a way in mono, to insert a lob without inserting first an empty_clob, the next code work in .NET but I can't make it work in mono
OracleConnection conn = new OracleConnection("server=MyServer; integrated security=yes;");conn.Open();OracleTransaction tx = conn.BeginTransaction();OracleCommand cmd = conn.CreateCommand();
cmd.Transaction = tx;cmd.CommandText = "declare xx blob; begin dbms_lob.createtemporary(xx, false, 0); :tempblob := xx; end;";cmd.Parameters.Add(new OracleParameter("tempblob", OracleType.Blob)).Direction =
ParameterDirection.Output;cmd.ExecuteNonQuery();OracleLob tempLob = (OracleLob)cmd.Parameters[0].Value;tempLob.BeginBatch(OracleLobOpenMode.ReadWrite);tempLob.Write(tempbuff,0,tempbuff.Length);tempLob.EndBatch
();cmd.Parameters.Clear();cmd.CommandText = "myTable.myProc";cmd.CommandType = CommandType.StoredProcedure; cmd.Parameters.Add(new OracleParameter("ImportDoc", OracleType.Blob)).Value = tempLob;
cmd.ExecuteNonQuery();tx.Commit();
it is from MSDN.
I realy appreciate any help from you.
sorry because my english, I speak spanish.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Web.UI.CssStyleCollection
On Sun, 2006-10-08 at 04:52 -0700, Igor Zalmanovich wrote: > Hello Gonzalo, > > > > r66332 made ~60 regressions in tests for profile 2.0 > I believe this should be fixed in r66437. Let me know if there's still any problem. I don't usually run the 2.0 tests and nothing broke in the 1.x profile after that patch :-/. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] XPathNavigator.CanEdit
Hello, The attached patch and a test case set the CanEdit property according to msdn. Please review. Regards, Konstantin Triger CanEdit.patch Description: CanEdit.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Compiling current svn?
Hi all Apologies if this appears twice - I sent it from a wrong address initially. Hi there I have a problem with compiling current svn: bin/sh ../../libtool --tag=CC --mode=link gcc -O -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 -mno-tls-direct-seg-refs -o pedump pedump.o libmonoruntime.la ../io-layer/libwapi.la ../utils/libmonoutils.la ../../libgc/libmonogc.la -pthread -lgthread-2.0 -lglib-2.0 -Wl,--export-dynamic -lgmodule-2.0 -ldl -lglib-2.0 -lm -lpthread -lm gcc -O -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 -mno-tls-direct-seg-refs -o pedump pedump.o -Wl,--export-dynamic ./.libs/libmonoruntime.a ../io-layer/.libs/libwapi.a ../utils/.libs/libmonoutils.a ../../libgc/.libs/libmonogc.a -pthread /usr/lib/libgthread-2.0.so /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libglib-2.0.so -lpthread -lm ./.libs/libmonoruntime.a(domain.o): In function `mono_domain_create': /home/madsdyd/xIntegra/MONOTRUNK/mono/mono/metadata/domain.c:470: undefined reference to `mono_g_hash_table_new_type' There are _tons_ of undef. references, all to mono_g_hash_table_*. Worked friday. Broken after svn update today. Tried autogen.sh, make clean, make, etc. Looking around, it seems I should compile with eglib. However, that I am unable to do (autogen.sh, make): gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -Wall -Werror -D_FORTIFY_SOURCE=2 -g -O0 -MT libeglib_la-gmodule.lo -MD -MP -MF .deps/libeglib_la-gmodule.Tpo -c gmodule.c -fPIC -DPIC -o .libs/libeglib_la-gmodule.o gmodule.c:43: error: parse error before '*' token gmodule.c:44: error: parse error before "GModuleFlags" gmodule.c:45: warning: return type defaults to `int' gmodule.c: In function `g_module_open': gmodule.c:47: error: `GModule' undeclared (first use in this function) gmodule.c:47: error: (Each undeclared identifier is reported only once gmodule.c:47: error: for each function it appears in.) gmodule.c:47: error: `module' undeclared (first use in this function) gmodule.c:49: error: `flags' undeclared (first use in this function) gmodule.c:49: error: `G_MODULE_BIND_MASK' undeclared (first use in this function) gmodule.c:50: error: `G_MODULE_BIND_LAZY' undeclared (first use in this function) gmodule.c:52: error: `G_MODULE_BIND_LOCAL' undeclared (first use in this function) gmodule.c:59: error: `file' undeclared (first use in this function) gmodule.c: At top level: gmodule.c:64: error: parse error before '*' token gmodule.c: In function `g_module_symbol': gmodule.c:66: error: `symbol_name' undeclared (first use in this function) gmodule.c:66: error: `symbol' undeclared (first use in this function) gmodule.c:69: error: `module' undeclared (first use in this function) gmodule.c: At top level: gmodule.c:83: error: parse error before '*' token gmodule.c: In function `g_module_close': gmodule.c:86: error: `module' undeclared (first use in this function) make[2]: *** [libeglib_la-gmodule.lo] Error 1 make[2]: Leaving directory `/home/madsdyd/xIntegra/MONOTRUNK/mono/eglib/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/madsdyd/xIntegra/MONOTRUNK/mono/eglib' make: *** [all] Error 2 I am a bit at loss with what to do. Any help appriciated. Regards, Mads -- Mads Bondo Dydensborg [EMAIL PROTECTED] http://www.madsdydensborg.dk/ Who do you trust? Nobody? Good, let's put Nobody in charge then... - The Register on TCPA/Palladium, 20021109 --- -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] ASP.NET 2.0 processing pipeline order correction
Hello,
According to http://msdn2.microsoft.com/en-us/library/ms178473.aspx,
the PostResolveRequestCache event should be raised before creating the
handler object. Mono currently does it after the handler creation. The
attached diff fixes that. Please review and let me know if I can commit,
thanks
marek
Index: HttpApplication.cs
===
--- HttpApplication.cs (revision 66446)
+++ HttpApplication.cs (working copy)
@@ -864,6 +864,12 @@
foreach (bool stop in RunHooks (ResolveRequestCache))
yield return stop;
+#if NET_2_0
+ if (PostResolveRequestCache != null)
+foreach (bool stop in RunHooks (PostResolveRequestCache))
+ yield return stop;
+#endif
+
// Obtain the handler for the request.
IHttpHandler handler = null;
try {
@@ -884,10 +890,6 @@
yield return true;
#if NET_2_0
- if (PostResolveRequestCache != null)
-foreach (bool stop in RunHooks (PostResolveRequestCache))
- yield return stop;
-
if (PostMapRequestHandler != null)
foreach (bool stop in RunHooks (PostMapRequestHandler))
yield return stop;
signature.asc
Description: PGP signature
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Oracle LOB help
On 10/8/06, Jorge Landrián Garcia <[EMAIL PROTECTED]> wrote:
> I read the post "[Mono-devel-list] System.Data.OracleClient and CLOB's", and
> I would like to ask you if exist a way in mono, to insert a lob without
> inserting first an empty_clob, the next code work in .NET but I can't make
> it work in mono
>
> OracleConnection conn = new
> OracleConnection("server=MyServer; integrated
> security=yes;");
> conn.Open();
> OracleTransaction tx = conn.BeginTransaction();
> OracleCommand cmd = conn.CreateCommand();
> cmd.Transaction = tx;
> cmd.CommandText = "declare xx blob; begin dbms_lob.createtemporary(xx,
> false, 0); :tempblob := xx; end;";
> cmd.Parameters.Add(new OracleParameter("tempblob",
> OracleType.Blob)).Direction = ParameterDirection.Output;
> cmd.ExecuteNonQuery();
> OracleLob tempLob = (OracleLob)cmd.Parameters[0].Value;
> tempLob.BeginBatch(OracleLobOpenMode.ReadWrite);
> tempLob.Write(tempbuff,0,tempbuff.Length);
> tempLob.EndBatch ();
> cmd.Parameters.Clear();
> cmd.CommandText = "myTable.myProc";
> cmd.CommandType = CommandType.StoredProcedure;
> cmd.Parameters.Add(new OracleParameter("ImportDoc", OracleType.Blob)).Value
> = tempLob;
> cmd.ExecuteNonQuery();
> tx.Commit();
>
> it is from MSDN.
>
> I realy appreciate any help from you.
>
> sorry because my english, I speak spanish.
Just for reference, the code is from
http://msdn2.microsoft.com/en-us/library/cydxhzhz.aspx , and MSDN guys
have a very bad habbit of not disposing IDisposable objects. I have
not tried it, but instead always used the double-shot approach (insert
empty [or create with a stored procedure], update).
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Parch for Enum support in Custom attributes
Hi Eyal,
The patch looks mostly good. Please use the new interface
IRequireResolving I've just commited for the changes in CustomAttribute.
Please also follow the coding guideline used in Cecil.
I would also prefer a patch using a parameter instead of the
ForceResolving property.
Also please send me the patch once it's done instead of commiting, I
have to check that everything works fine on the writing part.
Thanks a lot,
Jb
Eyal Alaluf wrote:
> Hi, JB.
>
> I worked a bit further on the patch and implemented the ForceRead logic
> for custom attributes.
> I aded a ForceResolving property to SignatureReader (it was the easiest way
> with the previous patch I made). If the patch if acceptable I'll prepare a
> separate and smaller patch to simplify SignatureReader abit and remove this
> property (pass it as a parameter).
> Attached is the patch and slightly modified test case.
>
> Eyal.
>
> On Thu, 5 Oct 2006, Jb Evain wrote:
>
>> Date: Thu, 05 Oct 2006 19:16:47 +0200
>> From: Jb Evain <[EMAIL PROTECTED]>
>> To: Eyal Alaluf <[EMAIL PROTECTED]>
>> Cc: mono-devel-list@lists.ximian.com
>> Subject: Re: [Mono-dev] Parch for Enum support in Custom attributes
>>
>> Hi Eyal,
>>
>> Thanks for working on this. I don't want to commit it as it is, but
>> I'll surely use part of it. I don't want to load the assembly
>> referenced only for reading a custom attribute body. Instead, I'll
>> create an interface that CustomAttribute and SecurityDeclaration will
>> share, and will allow one to load the content of something that needs
>> to load a reference.
>>
>> Something like:
>>
>> CustomAttribute ca = ...;
>> if (!ca.Read) {
>> ca.ForceRead ();
>> }
>>
>> Otherwise, for a lot of assemblies, Cecil will have to load the
>> corelib while the user don't necessary need to read the content of the
>> custom attribute.
>>
>> Jb
>>
>> Eyal Alaluf wrote:
>>> Hi, JB.
>>>
>>> Attached is patch for supporting enums in cutom attributes. Support
>>> is added
>>> for enums as ctor parameters as fields and as properties.
>>>
>>> The main problem with Enums is to identify their underlying integral
>>> type.
>>> Without this integral type the custom attribute cannot be read. The
>>> patch
>>> uses the assembly resolver for this purpose.
>>>
>>> I have attached a simple test scenraio with 3 C# files.
>>> * Test1.cs is a DLL defining enums and an attribute that has
>>> enums as
>>> field properties and ctor params.
>>> * Test2.cs is another DLL that uses the attribute and enums from
>>> Test1.
>>> This exercise the new code that resolves enum types from
>>> another DLL.
>>> * ReadTest2.cs is an EXE written using Cecil that parses
>>> test2.dll and
>>> prints the custom attributes of its types. It gets as argument
>>> the path
>>> to the dll it parses.
>>> Note that Test1 uses ClassUsageAttaribute from mscorlib. For some
>>> reason the
>>> assembly resolver didn't find mscorlib.dll from the GAC when I ran
>>> ReadTest2
>>> on Test2 until I put mscorlib.dll in the same dir as Test2 & ReadTest2.
>>>
>>> Eyal.
>>>
>>>
>>>
>>>
>>> Index: Mono.Cecil/ReflectionReader.cs
>>> ===
>>> --- Mono.Cecil/ReflectionReader.cs(revision 66216)
>>> +++ Mono.Cecil/ReflectionReader.cs(working copy)
>>> @@ -65,7 +65,24 @@
>>> protected CodeReader m_codeReader;
>>> protected ISymbolReader m_symbolReader;
>>> -public ModuleDefinition Module {
>>> +internal AssemblyNameReference Corlib
>>> +{
>>> +get +{
>>> +if (m_corlib == null) {
>>> +foreach (AssemblyNameReference ar in
>>> m_module.AssemblyReferences) {
>>> +if (ar.Name == Constants.Corlib) {
>>> +m_corlib = ar;
>>> +break;
>>> +}
>>> +}
>>> +}
>>> +return m_corlib;
>>> +}+}
>>> +
>>> +public ModuleDefinition Module +{
>>> get { return m_module; }
>>> }
>>> @@ -295,19 +312,11 @@
>>> TypeReference coreType = m_module.TypeReferences
>>> [fullName];
>>> if (coreType == null) {
>>> -if (m_corlib == null) {
>>> -foreach (AssemblyNameReference ar in
>>> m_module.AssemblyReferences) {
>>> -if (ar.Name == Constants.Corlib) {
>>> -m_corlib = ar;
>>> -break;
>>> -}
>>> -}
>>> -}
>>> string [] parts = fullName.Split ('.');
>>> if (parts.Length != 2)
>>> throw new ReflectionException ("Unvalid core
>>> type name");
>>> -
Re: [Mono-dev] [PATCH] Minor XML serialization fixes
Hello, > All changes are covered by unit tests and pass using both the > reflection-based and the code-based serializer, and on .NET. > > Let me know if its ok to commit. They look fine to me. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling current svn?
On 10/9/06, Mads Bondo Dydensborg <[EMAIL PROTECTED]> wrote: > > Hi there > > I have a problem with compiling current svn: > svn update then make clean and rebuild. Should fix it. -- Ivan N. Zlatev Web: http://www.i-nZ.net "It's all some kind of whacked out conspiracy." ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] new parser for C#
In his blog, Miguel says that the current yacc based parser is planned to be replaced with a new hand written parser. Is that just for gmcs, or will it be used for both gmcs and mcs? Will this further consolidate the code base for the two compilers? I driect reply would be apprecated as I am trying to finish my monthly column and want to have this in it. Thanks Dennis [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling current svn?
You should not build with eglib. Unless, you are helping Miguel and Gonzalo with eglib. You should be building with glib 2.0 or higher. --- Mads Bondo Dydensborg <[EMAIL PROTECTED]> wrote: > Hi all > > Apologies if this appears twice - I sent it from a > wrong address initially. > > Hi there > > I have a problem with compiling current svn: > > bin/sh ../../libtool --tag=CC --mode=link > gcc -O -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 > -mno-tls-direct-seg-refs -o pedump pedump.o > libmonoruntime.la ../io-layer/libwapi.la > ../utils/libmonoutils.la > ../../libgc/libmonogc.la -pthread -lgthread-2.0 > -lglib-2.0 > -Wl,--export-dynamic -lgmodule-2.0 -ldl -lglib-2.0 > -lm -lpthread -lm gcc > -O -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 > -mno-tls-direct-seg-refs -o pedump > pedump.o -Wl,--export-dynamic > ./.libs/libmonoruntime.a > ../io-layer/.libs/libwapi.a > ../utils/.libs/libmonoutils.a > ../../libgc/.libs/libmonogc.a -pthread > /usr/lib/libgthread-2.0.so > /usr/lib/libgmodule-2.0.so -ldl > /usr/lib/libglib-2.0.so -lpthread -lm > ./.libs/libmonoruntime.a(domain.o): In function > `mono_domain_create': > > /home/madsdyd/xIntegra/MONOTRUNK/mono/mono/metadata/domain.c:470: > undefined > reference to `mono_g_hash_table_new_type' > > There are _tons_ of undef. references, all to > mono_g_hash_table_*. > > Worked friday. Broken after svn update today. > > Tried autogen.sh, make clean, make, etc. > > Looking around, it seems I should compile with > eglib. However, that I am > unable to do (autogen.sh, make): > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -Wall -Werror > -D_FORTIFY_SOURCE=2 -g -O0 > -MT libeglib_la-gmodule.lo -MD -MP -MF > .deps/libeglib_la-gmodule.Tpo -c > gmodule.c -fPIC -DPIC -o > .libs/libeglib_la-gmodule.o > gmodule.c:43: error: parse error before '*' token > gmodule.c:44: error: parse error before > "GModuleFlags" > gmodule.c:45: warning: return type defaults to `int' > gmodule.c: In function `g_module_open': > gmodule.c:47: error: `GModule' undeclared (first use > in this function) > gmodule.c:47: error: (Each undeclared identifier is > reported only once > gmodule.c:47: error: for each function it appears > in.) > gmodule.c:47: error: `module' undeclared (first use > in this function) > gmodule.c:49: error: `flags' undeclared (first use > in this function) > gmodule.c:49: error: `G_MODULE_BIND_MASK' undeclared > (first use in this > function) > gmodule.c:50: error: `G_MODULE_BIND_LAZY' undeclared > (first use in this > function) > gmodule.c:52: error: `G_MODULE_BIND_LOCAL' > undeclared (first use in this > function) > gmodule.c:59: error: `file' undeclared (first use in > this function) > gmodule.c: At top level: > gmodule.c:64: error: parse error before '*' token > gmodule.c: In function `g_module_symbol': > gmodule.c:66: error: `symbol_name' undeclared (first > use in this function) > gmodule.c:66: error: `symbol' undeclared (first use > in this function) > gmodule.c:69: error: `module' undeclared (first use > in this function) > gmodule.c: At top level: > gmodule.c:83: error: parse error before '*' token > gmodule.c: In function `g_module_close': > gmodule.c:86: error: `module' undeclared (first use > in this function) > make[2]: *** [libeglib_la-gmodule.lo] Error 1 > make[2]: Leaving directory > `/home/madsdyd/xIntegra/MONOTRUNK/mono/eglib/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/home/madsdyd/xIntegra/MONOTRUNK/mono/eglib' > make: *** [all] Error 2 > > I am a bit at loss with what to do. > > Any help appriciated. > > Regards, > > Mads > > -- > Mads Bondo Dydensborg [EMAIL PROTECTED] > http://www.madsdydensborg.dk/ > > Who do you trust? Nobody? Good, let's put Nobody in > charge then... > >- The Register on TCPA/Palladium, > 20021109 > > --- > > -- > Med venlig hilsen/Regards > > Systemudvikler/Systemsdeveloper cand.scient.dat, > Ph.d., Mads Bondo Dydensborg > Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 > Ballerup, Tlf. +45 44 86 77 34 > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-l
Re: [Mono-dev] new parser for C#
As I understand it the goal is for both compilers to move to a hand-written parser, with possible reuse of big parts. I, personally, think a single parser and tokenizer for both compilers is possible, with some conditional logic enabling to have the control of the syntax scope in use. This would, in truth, allow to have just one compiler, however, the impact on performance of such runtime conditionals has to be measured to see if the compromise is acceptable. :) On 10/9/06, Dennis Hayes <[EMAIL PROTECTED]> wrote: > > > > In his blog, Miguel says that the current yacc based parser is planned to be > replaced with a new hand written parser. > > Is that just for gmcs, or will it be used for both gmcs and mcs? > > Will this further consolidate the code base for the two compilers? > > I driect reply would be apprecated as I am trying to finish my monthly > column and want to have this in it. > > Thanks > > Dennis > > [EMAIL PROTECTED] > > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > -- Rafael "Monoman" Teixeira --- "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Replacing/Removing I18N
Hi *, I've been looking into this topic for quite some time now. However my knowledge (especially of the internals of the VM) is potentially not enough, so please correct me if I make wrong statements or assumptions: Current situation: I18N is located in multiple separate assemblies that contain encoding classes that are autogenerated. The single-byte encodings (my current focus) use a potentially big CASE-Structure to compute the output. Problems: * I18N is loaded through Reflection-Mechanisms, which triggers a HUGE amount of other code, so Mono loads/jits and instatiates a considerable portion of the entire corelib when I18N is used. * Initializing the I18N is slow and creates a huge amount of objects. * (At least on windows) I18N is basically ALWAYS used, because a single access to Console (which even the corelib contains a lot for debug output) is enough to instantiate it. I'm assuming this doesn't happen on Linux? * The I18N classes themselves consist of considerable amount of IL-Code making them slow to JIT and using a considerable amount of memory to hold the IL and produced native code. * The I18N classes are potentially slow (especially when assuming that optimization is probably sub-optimal because of the often huge IL-size). * Pressure on the GC because of big number of generated objects. Considerations for change: * Data must not be in private memory but shared as much as possible (currently most is shareable) * If possible avoid internal-calls and other direct runtime-support (currently does not need any) Goals: * Drop additional libraries * Use less memory * Make instantiation faster * Try to limit the needed JITted code to a reasonable amount * Possibly make encoding faster I started with the single-byte encodings, because these are the most simple ones and the most numerous: The idea is to only use a single class for all single-byte encodings that is instantiated with lookuptables suited for the relevant codepage. The lookuptables would be binary data that should be shared. A solution seems to be embedding these as resource-files into corelib and then getting a pointer to the binary data through Assembly.GetManifestResourceStream. The data would be uncompressed and complete for maximum performance and minimal code requirement (about 65kb per encoding). The data should already be memmaped is embedded as a resource (how big would be one of the pages??). Some ballpark figures as rationale (See the attached text-files which show an app using only I18N, one with String and Globalization and one without all): For String and Globalization Mono uses about 15kb memory for code and 7kb for data in 246 objects. With I18N mono uses (Codepage 1250) > 140kb for code and 81kb for private data in 1800 objects (potentially putting pressure on the GC) So the 65kb (how much could be saved because of memmapping - ALL single-byte encodings do not use a part of the unicode-range?) we need for an encoding is actually far less than the current overhead for I18N (obviously that may not hold true if a lot of different encodings are used). And obviously the lookup would be faster and we would not need any time spent in the JIT. Open questions: * Creating the binary data should be simple when generating from a .Net VM. Would it be allowed to gernerate directly from MS.Net? From Portable.Net? (obviously from Mono is no problem, but would not allow to ADD data) * Size of a memmaped page? * Growth in *file*size for corelib acceptable? Altogether probably 5-10MB * Other sideeffects possible? Greetings Andreas Mono Jit statistics Compiled methods: 80 Methods from AOT: 0 Methods cache lookup: 70 Method trampolines: 1210 Basic blocks: 482 Max basic blocks: 35 Allocated vars: 372 Analyze stack repeat: 0 Compiled CIL code size: 4895 Native code size: 12278 Max code size ratio:32,00 (Object::.ctor) Biggest method: 1126 (Hashtable::.cctor) Code reallocs: 6 Allocated code size:12278 Inlineable methods: 0 Inlined methods:0 Created object count: 246 Initialized classes:72 Used classes: 43 Static data size: 148 VTable data size: 7460 Generic instances: 0 Initialized classes:0 Inflated methods: 0 / 0 Inflated types: 0 Generics metadata size: 0 Total time spent compiling 80 methods (sec): 0 Time(ms) Count P/call(ms) Method name Total number of calls: 268 Allocation profiler Total mem Method Total memory allocated: 7 KB Test Mono Jit statistics Compiled methods: 466 Methods from AOT: 0 Methods cache lookup: 511 Method trampolines: Basic blocks: 3939 Max basic blocks: 237 Allocated vars: 3102 Analyze stack repeat: 0 Compiled CIL code size: 40443 Native code size: 93100 Max code size ratio:32,00 (Object::.ctor) Biggest method: 4930 (SimpleCollator::CompareInternal) Code reallocs
Re: [Mono-dev] Replacing/Removing I18N
Hello, > * Creating the binary data should be simple when generating from a .Net VM. > Would it be allowed to gernerate directly from MS.Net? From Portable.Net? > (obviously from Mono is no problem, but would not allow to ADD data) I did not understand this question at all. > * Size of a memmaped page? 4k or 8k, depending on the platform. > * Growth in *file*size for corelib acceptable? Altogether probably 5-10MB Do we really need to grow corlib? What do you have in mind? Couldnt we just use static data, and access that as a resource? (Mono uses mmap for resources in the file) Am not sure how much code vs tables lives in the I18N libraries, do you have details? > * Other sideeffects possible? > > > Greetings > Andreas > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Miguel de Icaza <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] new parser for C#
Hello, > In his blog, Miguel says that the current yacc based parser is planned > to be replaced with a new hand written parser. > > Is that just for gmcs, or will it be used for both gmcs and mcs? Its only needed for gmcs, but it might be possible to share it; Its too early to tell. But really, this is a long-term project, not something we are thinking of doing right now. It is not really something for public consumption, its more of an internal discussion among developers. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
