[Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 86
Colt D. Majkrzak
majkrzak at gmail.com
Fri Jul 29 05:52:16 EDT 2005
Which version of apache are you running, and was it an rpm install or source
install?
-----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:38 AM
To: mono-devel-list at lists.ximian.com
Subject: [Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 86
Friend,
I tried with your suggestion.
But bin folder itself is not available in /etc/httpd folder.
I have only "conf conf.d logs modules run" folders under /etc/httpd
I tried to find 'apxs*' but nothing was returned in console.
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:42:16 -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: Re: Mono-devel-list Digest, Vol 3, Issue 83 (Colt D. Majkrzak)
> 2. [PATCH] Assembly.GetReferencedAssemblies (Carlos Alberto Cortez)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 29 Jul 2005 11:18:52 +0200
>From: "Colt D. Majkrzak" <majkrzak at gmail.com>
>Subject: RE: [Mono-devel-list] Re: Mono-devel-list Digest, Vol 3,
> Issue 83
>To: <raggani at smart-bridge.com>, <mono-devel-list at lists.ximian.com>
>Message-ID: <42e9f484.6cf95678.564f.ffffefb8 at mx.gmail.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>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/599e
7
>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
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 29 Jul 2005 02:22:53 -0500
>From: Carlos Alberto Cortez <calberto.cortez at gmail.com>
>Subject: [Mono-devel-list] [PATCH] Assembly.GetReferencedAssemblies
>To: Mono Devel <mono-devel-list at lists.ximian.com>
>Message-ID: <1122621773.5315.4.camel at localhost.localdomain>
>Content-Type: text/plain; charset="us-ascii"
>
>Hey,
>
>The attached patch fixes the behavior for GetReferencedAssemblies (it
>used to load the references and get the info from them, instead of
>getting it from the metadata tables, just like MS impl).
>
>It also fix a problem when calling this with a Reflection Only assembly.
>
>The corlib nunit tests ran just fine (both for default and 2_0
>profiles).
>
>May I commit it?
>
>Carlos.
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: icall.patch
>Type: text/x-patch
>Size: 5499 bytes
>Desc: not available
>Url :
http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050729/1dd2d
e2f/icall.bin
>
>------------------------------
>
>_______________________________________________
>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 86
>**********************************************
>
>
________________________________________________________________
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