[Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 83
Colt D. Majkrzak
majkrzak at gmail.com
Fri Jul 29 05:18:52 EDT 2005
Specify with --with-apxs=/etc/httpd/bin/apxs on your configure and it should
run straight from their. Check to make sure apxs exists in that folder. I
also have a Redhat Enterprise Linux server, and this is where my copy of
apxs is located.
-----Original Message-----
From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Rajesh Kumar
Aggani
Sent: Friday, July 29, 2005 11:12 AM
To: mono-devel-list at lists.ximian.com
Subject: [Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 83
Hi Friends,
I want to use Mono on Red Hat linux Server edition. I have installed Mono
with binary file. Apache is already installed during RedHat installation.
I was trying to intall mod_mono module and I am getting the following error.
checking for strrchr... yes
checking for --with-apxs... no
checking for --with-apr-config... not specified
checking for apxs2 in /usr/local/apache/sbin... no
checking for apxs in /usr/local/apache/sbin... no
checking for apr-config in /usr/local/apache/sbin... no
checking for apxs2 in /usr/local/apache2/bin... no
checking for apxs in /usr/local/apache2/bin... no
checking for apr-config in /usr/local/apache2/bin... no
checking for apxs2 in /usr/sbin... no
checking for apxs in /usr/sbin... no
checking for apr-config in /usr/sbin... no
checking for apxs2... no
checking for apxs... no
configure: error: **** apxs was not found, DSO compilation will not be
available.
Mono is installed in /opt/mono-1.1.8.3 folder.
I got the mono module from
http://www.go-mono.com/archive/1.0.5/mod_mono-1.0.5.tar.gz
Please suggest me the next step.
Thanks,
Rajesh
---------- Original Message ----------------------------------
From: mono-devel-list-request at lists.ximian.com
Reply-To: mono-devel-list at lists.ximian.com
Date: Fri, 29 Jul 2005 05:19:19 -0400 (EDT)
>Send Mono-devel-list mailing list submissions to
> mono-devel-list at lists.ximian.com
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>or, via email, send a message with subject or body 'help' to
> mono-devel-list-request at lists.ximian.com
>
>You can reach the person managing the list at
> mono-devel-list-owner at lists.ximian.com
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Mono-devel-list digest..."
>
>
>Today's Topics:
>
> 1. Re: [PATCH] Profile 2.0 assembly versions (Andreas Nahr)
> 2. Re: TimeStamp support on oracle... (Hubert FONGARNAND)
> 3. Re: Found a bug in DrawBeziers in Graphics.cs (I think...)
> (Heinz Mueller)
> 4. Re: [PATCH] Profile 2.0 assembly versions (Korn?l P?l)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 29 Jul 2005 09:11:28 +0200
>From: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>
>Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
>To: Korn?l P?l <kornelpal at hotmail.com>, "Ben Maurer"
> <bmaurer at ximian.com>
>Cc: mono-devel-list at lists.ximian.com
>Message-ID: <005401c5940f$a0b73a30$6464a8c0 at ansirua>
>Content-Type: text/plain; format=flowed; charset="iso-8859-2";
> reply-type=original
>
>I like it a lot ;)
>
>Sorry for the previous discussion. I've gone through this quite a few times
>before.
>Also what I wrote was just a suggestion. I personally would like to have
>seen your initial patch applied if the one for WebContols wasn't created.
>But its just much better this way ;)
>
>So thanks a lot..
>
>Andreas
>
>----- Original Message -----
>From: "Kornél Pál" <kornelpal at hotmail.com>
>To: "Ben Maurer" <bmaurer at ximian.com>; "Andreas Nahr"
><ClassDevelopment at A-SoftTech.com>
>Cc: "Miguel de Icaza" <miguel at ximian.com>;
><mono-devel-list at lists.ximian.com>
>Sent: Friday, July 29, 2005 1:31 AM
>Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
>
>
>> This patch is for System.Web.UI.WebControls.
>>
>> If you find any problems regarding the patch itself feel free to comment
>> it
>> but if you imagine any other non-blocking patches that should be done
>> before
>> committing this one I promise that I will propose no more pathes.
>>
>> Kornél
>>
>> ----- Original Message -----
>> From: "Kornél Pál" <kornelpal at hotmail.com>
>> To: "Ben Maurer" <bmaurer at ximian.com>; "Andreas Nahr"
>> <ClassDevelopment at A-SoftTech.com>
>> Cc: "Miguel de Icaza" <miguel at ximian.com>;
>> <mono-devel-list at lists.ximian.com>
>> Sent: Friday, July 29, 2005 12:41 AM
>> Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
>>
>>
>>> Hi,
>>>
>>> I agree with you that this a better idea but I will never try to submit
>>> such
>>> a big patch for proposal because it would change too much code and it
>>> figured out that it is nearly impossible to make any major change to
Mono
>>> because if there are no mistakes and errors in the patch itself an
>>> endless
>>> list can be created about things that should be done before the patch
can
>>> be
>>> comitted altought they don't block the patch in fact.
>>>
>>> I see a lot of things in Mono that sould be made more reliable using
some
>>> centralization but I don't want to create n+1 wariants of this patch.
>>>
>>> I reported the problem, I proposed a patch, the patch seems to be
correct
>>> (because no notices were provided regarding the patch itself). If you
>>> want
>>> to do hundreds of things that are not required to apply the patch before
>>> applying the patch it's up to you but I don't want to solve all the
>>> problems
>>> you can imagine just to commit this patch.
>>>
>>> Anyway I think having different verion numbers than MS.NET is a more
>>> critical issue than having a weakly centralized assembly referencing
>>> practice.
>>>
>>> Note that the references in System.Web.UI.WebControls are in NET_2_0
only
>>> code blocks and these references are not in other versions. This seems
to
>>> be
>>> consistent practice in System.Web.UI.WebControls. Centralizing the
>>> assembly
>>> reference could save some disk space but currently it is not required.
It
>>> will be required when a new (post 2.0) .NET Framework version will be
>>> released but currently even 2.0 was not released yet so it will be in
the
>>> distant future.
>>>
>>> Kornél
>>>
>>> ----- Original Message -----
>>> From: "Ben Maurer" <bmaurer at ximian.com>
>>> To: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>
>>> Cc: "Kornél Pál" <kornelpal at hotmail.com>; "Miguel de Icaza"
>>> <miguel at ximian.com>; <mono-devel-list at lists.ximian.com>
>>> Sent: Friday, July 29, 2005 12:11 AM
>>> Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
>>>
>>>
>>>> On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
>>>>> No Consts.cs aren't automatically generated.
>>>>> The problem is, that several Attributes of classes in System.Web do
not
>>>>> use
>>>>> the consts scheme, and about one third of your (BIG) patch is just for
>>>>> changing these Attributes.
>>>>> We will then have to change these again later, so it might make sense
>>>>> do
>>>>> do
>>>>> it now instead of doing it twice (and adding lots of changelog entries
>>>>> twice).
>>>>
>>>> If we really want to be clever, and avoid doing things twice, we can
put
>>>> this:
>>>>
>>>> internal class MonoConsts {
>>>> #if ...
>>>> public string FXVersion = ...
>>>> #elif ...
>>>> ...
>>>> #endif
>>>> }
>>>>
>>>> in the common build directory. This way, the next time we need to
target
>>>> another FX, we don't have to do it in 100 places.
>>>>
>>>> The Const.cs is probably still a good idea, since it is really ugly to
>>>> have those magic names lying around the source code.
>>>>
>>>> -- Ben
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 29 Jul 2005 10:02:14 +0200
>From: Hubert FONGARNAND <informatique.internet at fiducial.fr>
>Subject: Re: [Mono-devel-list] TimeStamp support on oracle...
>To: mono-devel-list at lists.ximian.com
>Message-ID: <200507291002.15410.informatique.internet at fiducial.fr>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Le Vendredi 29 Juillet 2005 02:48, vous avez écrit :
>> You need to modify OciDefineHandle to deal with the TIMESTAMP.
>>
>> See Define(), DefineDate(), and GetValue().
>>
>> You can create a new function called DefineTimestamp() based on
>> DefineDate() and allocate space for it based OciDataType.TimeStamp.
>>
>> What about TIMESTAMP WITH TIMEZONE and TIMESTAMP WITH LOCAL TIMEZONE?
>
>For instance, i just need a timestamp... (if it works I will implement the
>others)
>
>>
>> There is also INTERVAL YEAR TO MONTH and INTERVAL DAY TO SECOND data
>> types. This is equivalent to System.TimeSpan and
>> System.Data.OracleClient types OracleMonthSpan and OracleTimeSpan.
>> These have not been implemented either.
>>
>> Also, in OracleParameter, you need to allocate space for the Timestamp
>> for the output parameter, and you need to convert a .NET DateTime to an
>> Oracle TIMESTAMP by using OCIDateTime functions for the input parameter.
>
>For input parameters I think I will just implement a PackTimeStamp and an
>UnPackTimeStamp (like my PackDate function) to build the byte[]
>
>>
>> An Oracle Date uses OCIDate while TIMESTAMP uses an OCIDateTime.
>>
>> You will need to DllImport into function OCIDateTimeConstruct() to
>> create and set the date and time in a OCIDateTime. You will also need
>> to DllImport into function OCIDateTimeGetTime() to get the time from the
>> OCIDateTime and OCIDateTimeGetDate() to get the date from the
>> OCIDateTime. There are other functions for the time zone, etc...
>>
>>
http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci18ma
>>p002.htm#i512069
>>
>
>Thank you...
>
>> Hubert FONGARNAND wrote:
>> >I really need the new TimeStamp type (supported starting from oracle 9).
>> > It's a MS.NET supported type (i've made tests)...
>> >I've begin to do a little patch (attached) to add the timestamp type to
>> >oracle.client...
>> >but... I've a strange error when i try to do a Fill, it failed with:
>> >
>> >Unhandled Exception: System.Data.OracleClient.OracleException:
>> >in <0x0013d> System.Data.OracleClient.Oci.OciStatementHandle:Fetch ()
>> >in <0x0002c> System.Data.OracleClient.OracleDataReader:Read ()
>> >in <0x002f4> System.Data.Common.DbDataAdapter:FillTable
>> > (System.Data.DataTable dataTable, IDataReader dataReader, Int32
>> > startRecord, Int32 maxRecords, System.Int32 counter)
>> >in <0x0011f> System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
>> >dataSet, System.String srcTable, IDataReader dataReader, Int32
>> > startRecord, Int32 maxRecords)
>> >in <0x000d5> System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
>> >dataSet, Int32 startRecord, Int32 maxRecords, System.String srcTable,
>> >IDbCommand command, CommandBehavior behavior)
>> >in <0x00044> System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
>> >dataSet)
>> >in <0x007b8> ConsoleIntranet.Class1:TestTimestamp ()
>> >in <0x00015> ConsoleIntranet.Class1:Main (System.String[] args)
>> >
>> >Could someone help me how to resolve this issue?
>> >thanks
>> >_______________________________________________
>> >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.
>> >
>> >
>> >------------------------------------------------------------------------
>> >
>> >Index:
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParamet
>> >er.cs
===================================================================
>> > ---
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParamet
>> >er.cs (revision 47807) +++
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParamet
>> >er.cs (working copy) @@ -258,7 +258,7 @@
>> > OciDataType bindType = ociType;
>> > IntPtr bindValue = IntPtr.Zero;
>> > int rsize = 0;
>> >-
>> >+ Console.WriteLine("Parametre :
>> > "+ociType.ToString()); // TODO: handle InputOutput and Return
parameters
>> > if (direction == ParameterDirection.Output) { // TODO: need to figure
out
>> > how OracleParameter @@ -324,9 +324,11 @@
>> > bindSize = 0;
>> > }
>> > else {
>> >+ Console.WriteLine("OracleType
>> > "+oracleType.ToString()); // TODO: do other data types and oracle data
>> > types // should I be using IConvertible to convert? if (oracleType ==
>> > OracleType.DateTime) { +
>> > Console.WriteLine("DATE!!!"); string oraDateFormat =
>> > connection.GetSessionDateFormat (); string sysDateFormat =
>> > OracleDateTime.ConvertOracleDateFormatToSystemDateTime (oraDateFormat);
>> >
>> >@@ -637,8 +639,11 @@
>> > dbType = DbType.AnsiStringFixedLength;
>> > ociType = OciDataType.Char;
>> > break;
>> >+ case OracleType.Timestamp:
>> >+ dbType = DbType.DateTime;
>> >+ ociType = OciDataType.TimeStamp;
>> >+ break;
>> > case OracleType.DateTime:
>> >- case OracleType.Timestamp:
>> > case OracleType.TimestampLocal:
>> > case OracleType.TimestampWithTZ:
>> > dbType = DbType.DateTime;
>> >Index:
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDataTy
>> >pe.cs
===================================================================
>> > ---
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDataTy
>> >pe.cs (revision 47807) +++
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDataTy
>> >pe.cs (working copy) @@ -43,6 +43,7 @@
>> > Blob = 0x71,
>> > BFile = 0x72,
>> > OciString = 0x9b,
>> >- OciDate = 0x9c
>> >+ OciDate = 0x9c,
>> >+ TimeStamp = 0xbb
>> > }
>> > }
>> >Index:
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciParame
>> >terDescriptor.cs
>> > =================================================================== ---
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciParame
>> >terDescriptor.cs (revision 47807) +++
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciParame
>> >terDescriptor.cs (working copy) @@ -67,6 +67,7 @@
>> >
>> > public static OracleType OciDataTypeToOracleType
>> > (OciDataType ociType) {
>> >+ Console.WriteLine(ociType.ToString());
>> > switch (ociType) {
>> > case OciDataType.VarChar2:
>> > return OracleType.VarChar;
>> >@@ -120,6 +121,8 @@
>> > return OracleType.VarChar;
>> > case OciDataType.OciDate:
>> > return OracleType.DateTime;
>> >+ case OciDataType.TimeStamp:
>> >+ return OracleType.Timestamp;
>> > default:
>> > throw new NotImplementedException ();
>> > }
>> >@@ -180,6 +183,8 @@
>> > return typeof (System.String);
>> > case "OciDate":
>> > return typeof (System.DateTime);
>> >+ case "TimeStamp":
>> >+ return typeof (System.DateTime);
>> > default:
>> > // FIXME: are these types correct?
>> > return typeof(System.String);
>> >@@ -242,6 +247,8 @@
>> > return "OciString";
>> > case OciDataType.OciDate:
>> > return "OciDate";
>> >+ case OciDataType.TimeStamp:
>> >+ return "TimeStamp";
>> > default:
>> > return "Unknown";
>> > }
>> >Index:
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciStatem
>> >entHandle.cs
>> > =================================================================== ---
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciStatem
>> >entHandle.cs (revision 47807) +++
>> >
mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciStatem
>> >entHandle.cs (working copy) @@ -212,8 +212,9 @@
>> > 1,
>> > 2,
>> > 0);
>> >-
>> >+ Console.WriteLine("FETCH "+status.ToString());
>> > switch (status) {
>> >+
>> > case OciGlue.OCI_NO_DATA:
>> > moreResults = false;
>> > break;
>> >
>> >
>> >------------------------------------------------------------------------
>> >
>> >_______________________________________________
>> >Mono-devel-list mailing list
>> >Mono-devel-list at lists.ximian.com
>> >http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>_______________________________________________
>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.
>
>
>------------------------------
>
>Message: 3
>Date: Fri, 29 Jul 2005 10:17:58 +0200
>From: Heinz Mueller <heinz.mueller at fujitsu-siemens.com>
>Subject: Re: [Mono-devel-list] Found a bug in DrawBeziers in
> Graphics.cs (I think...)
>To: Duncan Mak <duncan at novell.com>
>Cc: mono-devel-list at lists.ximian.com
>Message-ID: <42E9E636.9090702 at fujitsu-siemens.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Duncan Mak wrote:
>> On Mon, 2005-07-25 at 13:36 +0200, Heinz Mueller wrote:
>>
>>>Now to the subject: when trying out a program from the fist
>>>mentioned book (a clock with Bezier spline hands with System.Drawing)
>>>I got an value out of range exception in the points array of
>>>DrawBeziers.
>>>I looked up the source and I think the DrawBeziers for loop should
>>>start with
>>>for (i=0;(i+3)<length;i+=3)...
>>>or the first statement should be
>>>if (i == (length -1)) break;
>>
>>
>> Could you attach a test case that shows the problem?
>>
>Hi all,
>sample (source code) is attached...
>
>Regards, Heinz
>
>
>--
>Heinz Mueller heinz.mueller at fujitsu-siemens.com
>Tel: (+49)5251 815137 Fax: ... 816106
>Disclaimer: All opinions above are my own (at least I think so ;-))
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: testit.cs
>Type: text/x-csharp
>Size: 1214 bytes
>Desc: not available
>Url :
http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050729/599e7
a9e/testit-0001.bin
>
>------------------------------
>
>Message: 4
>Date: Fri, 29 Jul 2005 11:00:06 +0200
>From: Korn?l P?l <kornelpal at hotmail.com>
>Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
>To: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>, "Ben Maurer"
> <bmaurer at ximian.com>
>Cc: Miguel de Icaza <miguel at ximian.com>,
> mono-devel-list at lists.ximian.com
>Message-ID: <BAY22-DAV7EB2745A08751B75E77B7A3CE0 at phx.gbl>
>Content-Type: text/plain; format=flowed; charset="ISO-8859-1";
> reply-type=response
>
>I agree with you. I don't like the fact that the compiler embeds private
>constants altough they are not used at all. Furthermore in a lot of cases
>private enumerations are not required at runtime.
>
>I think we don't need any special obfuscator or Cecil tool we just should
>add two compiler options to mcs:
>- do not add private (invisible outside the assembly) constants
>- do not add enums that are not referenced by type
>
>None of them should be default because constants can be accessed using
>reflection that may be required and field names of enums may be used in
>Parse or ToString.
>
>Kornél
>
>----- Original Message -----
>From: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>
>To: "Ben Maurer" <bmaurer at ximian.com>
>Cc: "Kornél Pál" <kornelpal at hotmail.com>; "Miguel de Icaza"
><miguel at ximian.com>; <mono-devel-list at lists.ximian.com>
>Sent: Friday, July 29, 2005 9:32 AM
>Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
>
>
>>
>> ----- Original Message -----
>> From: "Ben Maurer" <bmaurer at ximian.com>
>> To: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>
>> Cc: "Kornél Pál" <kornelpal at hotmail.com>; "Miguel de Icaza"
>> <miguel at ximian.com>; <mono-devel-list at lists.ximian.com>
>> Sent: Friday, July 29, 2005 1:15 AM
>> Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
>>
>>
>>> On Fri, 2005-07-29 at 00:42 +0200, Andreas Nahr wrote:
>>>> Yes - it would make a lot of sense to put them into a single file.
>>>> However
>>>> it would come at a cost of up to 2kb of size added to EACH assembly
that
>>>> uses Consts.
>>>
>>> Maybe the *FILE* will be 2 kb, but the metadata added probably won't be.
>>> To add a class with a single const we'd need to add:
>>
>> If we merge everything into a single file we probably have about 20
>> consts,
>> each about 50 chars long.
>> Depending whether this is saved in the assembly as unicode or ascii
(which
>> i
>> don't know) this should be 1-2kb just for the strings in the string heap.
>>
>>>
>>> 1) a entry in the classes table
>>> 2) an entry in the fields table
>>> 3) a constant string in the strings heap.
>>>
>>> At runtime, the only datastructure that will ever be allocated due to
>>> this class is the hashtable that goes from Namespace/Class -> class
>>> field. I'm not even sure if that gets created for private classes, I'd
>>> have to dig into the code.
>>>
>>> The fields and string heap data gets loaded lazily on the first access.
>>
>> All the fields are NEVER used at runtime, so I hope they do not get
loaded
>> at all ;)
>> There is no access to these fields. They are only used at compile time,
>> but
>> not at runtime.
>>
>>>
>>>> In fact I think we could do something really clever to our compiler
>>>> here,
>>>> that would also benefit for a lot of other cases.
>>>> AFAIK the compiler can already eliminate dead code. I would propose a
>>>> step
>>>> that allows the compiler to scan for dead code again AFTER constants
are
>>>> resolved. This way the compiler would be able to completely eliminate
>>>> the
>>>> Consts Class after compiling. This would also add lots of added value
to
>>>> other applications. It's quite common to use private consts and
>>>> especially
>>>> enums to structure the code and make it more readable. With the
proposed
>>>> compiler function all of these things could be thrown out at
>>>> compile-time,
>>>> which could help a lot of applications to get smaller.
>>>
>>> A cecil based il-to-il optimizer could do that in the future. Of course,
>>> if you really want to look at "how can we make teh metadata smaller" we
>>> could do a simple obfuscator -- we could rename private / internal
>>> methods/classes to have small names, etc.
>>
>> There are obfuscators out there that you can use, however that is not
>> exactly what I mean:
>>
>> Look at the example:
>>
>> const string a = "Hello ";
>> const string b = "World";
>>
>> [SomeStringAttribute (a+b)]
>> private void Out () { }
>>
>> If I understand thing right we end up having the following strings in the
>> assembly:
>> "Hello World" (as part of the attribute)
>> "Hello ", "World" (in our case these use their own class)
>>
>> However after compilation the strings "Hello " and "World" are never used
>> anywhere at runtime, so we could delete them.
>> AFAIK not even the MS compiler is able to do that ;)
>>
>
>
>
>------------------------------
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>End of Mono-devel-list Digest, Vol 3, Issue 83
>**********************************************
>
>
________________________________________________________________
Sent via the WebMail system at smart-bridge.com
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
More information about the Mono-devel-list
mailing list