Re: [Mono-devel-list] SQLsharpgtk Makefile Bug
This is the better way using a slash to separate a directory. I tested it and it builds successfully on Cygwin and Linux. SQLSHARP_GTK_LIBS = $(GTK_SHARP_LIBS) /r:System.Data.dll /r:Mono.Data.dll /r:../browser/Mono.Data.SqlSharp.DatabaseBrowser.dll The fix has been committed to svn trunk HEAD. --- Emil Emilov [EMAIL PROTECTED] wrote: Is there any way to modify the following line to work with both windows/linux? (i.e. under linux it would be slashes and win does backslashes) SQLSHARP_GTK_LIBS = $(GTK_SHARP_LIBS) /r:System.Data.dll /r:Mono.Data.dll /r:..\browser\Mono.Data.SqlSharp.DatabaseBrowser.dll would that work under win (it works under linux i.e. escaping the slash) SQLSHARP_GTK_LIBS = $(GTK_SHARP_LIBS) /r:System.Data.dll /r:Mono.Data.dll /r:..\/browser\/Mono.Data.SqlSharp.DatabaseBrowser.dll Emil Emilov wrote: Yeah I also noticed that. I fixed the same way. I'll try and make a patch in the evening, when I get home from work. If you can do it earlier, please do. Matthias Felgner wrote: Hi, Just got and built SQLsharpgtk from SVN. The Makefile in subdir sqlsharpgtk defines SQLSHARP_GTK_LIBS with the needed references in order to build sqlsharpgtk, Assembly Mono.Data.SqlSharp.DatabaseBrowser.dll is referenced from the dir ../browser/ But reference is done using backslashes .Result: Build fails on my Unix machine Does this need to be adjusted?? I also needed to copy Mono.Data.SqlSharp.DatabaseBrowser.dll to directory ../browser/ as make was looking for it there Thanks for your thoughts.. Mit freundlichen Grüßen Matthias Felgner * E-Mail von ** **Völcker Informatik AG** Gertrud-Caspari-Straße 13 01109 Dresden Telefon 0351 / 892099409 Telefax 0351/ 892089477 http://www.voelcker.com http://www.voelcker.com/ [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Emil R. Emilov --- mailto:[EMAIL PROTECTED] http://www.emilov.de ___ 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-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
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 [EMAIL PROTECTED]
To: Ben Maurer [EMAIL PROTECTED]; Andreas Nahr
[EMAIL PROTECTED]
Cc: Miguel de Icaza [EMAIL PROTECTED];
mono-devel-list@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 [EMAIL PROTECTED]
To: Ben Maurer [EMAIL PROTECTED]; Andreas Nahr
[EMAIL PROTECTED]
Cc: Miguel de Icaza [EMAIL PROTECTED];
mono-devel-list@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 [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@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@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] MonoDevelop autopackage example
Hi, Last night I put together a basic autopackage of MonoDevelop. I also wrote a simple C stub program to replace the startup shell script, so it can be fully relocatable. I haven't tested the package extensively, beyond a simple does it install and run? check. A MonoDevelop developer would be the best person to create such a package, as they understand their own software better than I ever will. Nonetheless, I wanted to show that it's really not hard at all. To create the package, you feed the specfile to the makeinstaller program, and out pops a package, same as RPM or NSIS or any similar system. Please note: I haven't been able to upload the package anywhere, as I only have web/email access during the week, no ssh or FTP. I'll upload the actual binary package for people to play with at the weekend. OK, here is the specfile: # -*-shell-script-*- [Meta] RootName: @monodevelop.com/monodevelop:$SOFTWAREVERSION DisplayName: MonoDevelop Integrated Development Environment ShortName: monodevelop Maintainer: Todd Berman [EMAIL PROTECTED] Packager: Mike Hearn [EMAIL PROTECTED] Summary: MonoDevelop is a development environment for the .NET platform URL: http://www.monodevelop.com/ License: GNU General Public License, Version 2 SoftwareVersion: 0.7 PackageVersion: 1 AutopackageTarget: 1.0 # Only uncomment InterfaceVersion if your package exposes interfaces # to other software, for instance if it includes DSOs or python/perl # modules. See the developer guide for more info, or ask on # autopackage-dev if you don't understand interface versioning. # # FIXME: MonoDevelop has a plugin interface of some kind so we should set this. # # InterfaceVersion: 0.0 [BuildPrepare] prepareBuild # this stub program should really come with autopackage, and be easier # to integrate. for for a proof of concept we will compile it # ourselves. the stub takes care of making us binary relocatable. cd $source_dir/autopackage gcc -Os -o monodevelop -DPREFIXPATH=\lib/monodevelop/bin/MonoDevelop.exe\ monostub.c binreloc.c cd - [BuildUnprepare] unprepareBuild [Imports] # replace the shell script with a nice C wrapper rm bin/monodevelop cp $source_dir/autopackage/monodevelop bin/monodevelop # we want to ship everything echo '*' | import [Prepare] # # Dependency handling here is interesting. Technically I guess # we should check for GTK#, GNOME#, Gecko# blah blah blah. # # What'd be much better is if the Mono team defined the Mono # Desktop Platform to include all of these things, so we can # depend on everything M-D needs with a single dependency. # # That saves us work, because we don't need to specify everything. # # It saves the user work because they can download the MDP in # one go and not have to wait while extra stuff is installed # later. # # And it saves the developer work: on the website it can just # have a little MDP 1.1 button or badge, instead of a huge list # of separately enumerated dependencies. # # # # For now let's cheat, and only check that Mono itself is available. require @mono-project.org/runtime 1.0 [Install] installExe bin/monodevelop copyFiles lib/monodevelop $PREFIX/lib installPkgconfig lib/pkgconfig/* installDesktop Programming share/applications/*.desktop installLocale share/locale installMime share/mime/packages/*.xml # MD should use the icon theme spec really (and have an SVG icon!) copyFile share/pixmaps/monodevelop.png $PREFIX/share/pixmaps/monodevelop.png [Uninstall] # Usually just the following line is enough to uninstall everything uninstallFromLog A few notes: * It may look quite long, but most of it is metadata and comments to show you what each bit does. A real specfile could be much shorter. I think 95% of it is also very obvious. * You don't have to write all that. The bulk of it is automatically generated by the following command: makeinstaller --mkspec default.apspec Then you just customize it to fit your project. * As you can see, it only does one dependency check, on the Mono runtime itself. Really it should check for all the dependencies, but that would have taken longer to do and as it says in the comments, what we really need is for you guys to define a Mono Desktop Platform. I'm keen on desktop platforms. We need more of them. * A lot of the specfile could be trivially auto-generated on the fly, as it can be written mechanically. But nobody wrote the patches to do that yet. Certainly it'd be easier to simplify writing autopackage specfiles than to create a dedicated Mono installer! This file is normally put in a dedicated autopackage directory in your source tree, but it doesn't have to be. In this case, you need to put the attached files in that directory too so the C stub program can be compiled and shipped. OK, so what do you guys think? Application developers - can you see
[Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 83
);
+ 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@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 [EMAIL PROTECTED]
Subject: Re: [Mono-devel-list] Found a bug in DrawBeziers in
Graphics.cs (I think...)
To: Duncan Mak [EMAIL PROTECTED]
Cc: mono-devel-list@lists.ximian.com
Message-ID: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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/599e7a9e/testit-0001.bin
--
Message: 4
Date: Fri, 29 Jul 2005 11:00:06 +0200
From: Korn?l P?l [EMAIL PROTECTED]
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
To: Andreas Nahr [EMAIL PROTECTED],Ben Maurer
[EMAIL PROTECTED]
Cc: Miguel de Icaza [EMAIL PROTECTED],
mono-devel-list@lists.ximian.com
Message-ID: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
To: Ben Maurer [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 9:32 AM
Subject: Re
AW: [Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 83
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@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 [EMAIL PROTECTED]
Subject: Re: [Mono-devel-list] Found a bug in DrawBeziers in
Graphics.cs (I think...)
To: Duncan Mak [EMAIL PROTECTED]
Cc: mono-devel-list@lists.ximian.com
Message-ID: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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/599e7a9e/testit-0001.bin
--
Message: 4
Date: Fri, 29 Jul 2005 11:00:06 +0200
From: Korn?l P?l [EMAIL PROTECTED]
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
To: Andreas Nahr [EMAIL PROTECTED],Ben Maurer
[EMAIL PROTECTED]
Cc: Miguel de Icaza [EMAIL PROTECTED],
mono-devel-list@lists.ximian.com
Message-ID: [EMAIL PROTECTED]
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
Re: [Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 83
I think you need the devel package for apache. Carlos. El vie, 29-07-2005 a las 09:12 +, Rajesh Kumar Aggani escribió: 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 86
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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
To: Andreas Nahr [EMAIL PROTECTED], Ben Maurer
[EMAIL PROTECTED]
Cc: Miguel de Icaza [EMAIL PROTECTED],
mono-devel-list@lists.ximian.com
Message-ID: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
To: Ben Maurer [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@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 [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@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
Re: AW: [Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 83
/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@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 [EMAIL PROTECTED]
Subject: Re: [Mono-devel-list] Found a bug in DrawBeziers in
Graphics.cs (I think...)
To: Duncan Mak [EMAIL PROTECTED]
Cc: mono-devel-list@lists.ximian.com
Message-ID: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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/599e7a9e/testit-0001.bin
--
Message: 4
Date: Fri, 29 Jul 2005 11:00:06 +0200
From: Korn?l P?l [EMAIL PROTECTED
RE: [Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 86
@lists.ximian.com Message-ID: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions To: Andreas Nahr [EMAIL PROTECTED], Ben Maurer [EMAIL PROTECTED] Cc: Miguel de Icaza [EMAIL PROTECTED], mono-devel-list@lists.ximian.com Message-ID: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Ben Maurer [EMAIL PROTECTED] Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza [EMAIL PROTECTED]; mono-devel-list@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 [EMAIL PROTECTED] To: Andreas Nahr [EMAIL PROTECTED] Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza [EMAIL PROTECTED]; mono-devel-list@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
RE: [Mono-devel-list] Re: Mono-devel-list Digest, Vol 3, Issue 83
;
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@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 [EMAIL PROTECTED]
Subject: Re: [Mono-devel-list] Found a bug in DrawBeziers in
Graphics.cs (I think...)
To: Duncan Mak [EMAIL PROTECTED]
Cc: mono-devel-list@lists.ximian.com
Message-ID: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
To: Andreas Nahr [EMAIL PROTECTED],Ben Maurer
[EMAIL PROTECTED]
Cc: Miguel de Icaza [EMAIL PROTECTED],
mono-devel-list@lists.ximian.com
Message-ID: [EMAIL PROTECTED]
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
[Mono-devel-list] [PATCH] Assembly.GetReferencedAssemblies
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.
Index: ChangeLog
===
--- ChangeLog (revisión: 47832)
+++ ChangeLog (copia de trabajo)
@@ -1,3 +1,11 @@
+2005-07-29 Carlos Alberto Cortez [EMAIL PROTECTED]
+
+ * icall.c (ves_icall_System_Reflection_GetReferencedAssemblies):
+ Fix the last behavior, which used to load the assemblies and
+ extract MonoReflectionAssemblyName information, instead of
+ extract it from the metadata tables. Needed for Reflection
+ Only assemblies.
+
2005-07-28 Zoltan Varga [EMAIL PROTECTED]
* reflection.c (mono_method_get_object): Fix warning.
Index: icall.c
===
--- icall.c (revisión: 47832)
+++ icall.c (copia de trabajo)
@@ -3622,12 +3622,11 @@
}
static MonoObject*
-create_version (MonoDomain *domain, MonoAssemblyName *aname)
+create_version (MonoDomain *domain, guint32 major, guint32 minor, guint32 build, guint32 revision)
{
static MonoClass *System_Version = NULL;
static MonoMethod *create_version = NULL;
MonoObject *result;
- int major, minor, build, revision;
gpointer args [4];
if (!System_Version) {
@@ -3642,10 +3641,6 @@
mono_method_desc_free (desc);
}
- major = aname-major;
- minor = aname-minor;
- build = aname-build;
- revision = aname-revision;
args [0] = major;
args [1] = minor;
args [2] = build;
@@ -3664,6 +3659,7 @@
MonoDomain *domain = mono_object_domain (assembly);
int i, count = 0;
static MonoMethod *create_culture = NULL;
+ MonoImage *image = assembly-assembly-image;
MonoTableInfo *t;
MONO_ARCH_SAVE_REGS;
@@ -3686,52 +3682,46 @@
}
for (i = 0; i count; i++) {
- MonoAssembly *assem;
MonoReflectionAssemblyName *aname;
+ guint32 cols [MONO_ASSEMBLYREF_SIZE];
- /* FIXME: There is no need to load the assemblies themselves */
- mono_assembly_load_reference (assembly-assembly-image, i);
+ mono_metadata_decode_row (t, i, cols, MONO_ASSEMBLYREF_SIZE);
- assem = assembly-assembly-image-references [i];
- if (assem == (gpointer)-1) {
- char *msg = g_strdup_printf (Assembly %d referenced from assembly %s not found , i, assembly-assembly-image-name);
- MonoException *ex = mono_get_exception_file_not_found2 (msg, NULL);
- g_free (msg);
- mono_raise_exception (ex);
- }
-
aname = (MonoReflectionAssemblyName *) mono_object_new (
domain, System_Reflection_AssemblyName);
- aname-name = mono_string_new (domain, assem-aname.name);
+ aname-name = mono_string_new (domain, mono_metadata_string_heap (image, cols [MONO_ASSEMBLYREF_NAME]));
- aname-major = assem-aname.major;
- aname-minor = assem-aname.minor;
- aname-build = assem-aname.build;
- aname-revision = assem-aname.revision;
- aname-hashalg = assem-aname.hash_alg;
- aname-flags = assem-aname.flags;
+ aname-major = cols [MONO_ASSEMBLYREF_MAJOR_VERSION];
+ aname-minor = cols [MONO_ASSEMBLYREF_MINOR_VERSION];
+ aname-build = cols [MONO_ASSEMBLYREF_BUILD_NUMBER];
+ aname-revision = cols [MONO_ASSEMBLYREF_REV_NUMBER];
+ aname-flags = cols [MONO_ASSEMBLYREF_FLAGS];
aname-versioncompat = 1; /* SameMachine (default) */
- aname-version = create_version (domain, assem-aname);
+ aname-hashalg = ASSEMBLY_HASH_SHA1; /* SHA1 (default) */
+ aname-version = create_version (domain, aname-major, aname-minor, aname-build, aname-revision);
if (create_culture) {
gpointer args [1];
- args [0] = mono_string_new (domain, assem-aname.culture);
+ args [0] = mono_string_new (domain, mono_metadata_string_heap (image, cols [MONO_ASSEMBLYREF_CULTURE]));
aname-cultureInfo = mono_runtime_invoke (create_culture, NULL, args, NULL);
}
+
+ if (cols [MONO_ASSEMBLYREF_PUBLIC_KEY]) {
+ const gchar *pkey_ptr = mono_metadata_blob_heap (image, cols [MONO_ASSEMBLYREF_PUBLIC_KEY]);
+ guint32 pkey_len = mono_metadata_decode_blob_size (pkey_ptr, pkey_ptr);
- if (assem-aname.public_key) {
- guint32 pkey_len;
- const char *pkey_ptr = (char*)assem-aname.public_key;
- pkey_len = mono_metadata_decode_blob_size (pkey_ptr, pkey_ptr);
-
- aname-publicKey = mono_array_new (domain, mono_defaults.byte_class, pkey_len);
- memcpy (mono_array_addr (aname-publicKey, guint8, 0), pkey_ptr, pkey_len);
+ if ((cols [MONO_ASSEMBLYREF_FLAGS] ASSEMBLYREF_FULL_PUBLIC_KEY_FLAG)) {
+/* public key token isn't copied - the class library will
+ automatically generate it from the public key if required */
+aname-publicKey = mono_array_new (domain, mono_defaults.byte_class, pkey_len);
+memcpy (mono_array_addr (aname-publicKey, guint8, 0), pkey_ptr, pkey_len);
+ } else {
+
[Mono-devel-list] Problem with accessing C library from MONO
Hi! Im trying to access C library from MONO/C#. The error I get when trying to access the code is: [EMAIL PROTECTED] ~/g2-0.70/mono/src ] make mcs --unsafe --target library g2.cs -o g2.dll Compilation succeeded [EMAIL PROTECTED] ~/g2-0.70/mono/src ] make test mcs -r:g2.dll simple-g2.cs Compilation succeeded mono simple-g2.exe Unhandled Exception: System.DllNotFoundException: libg2 in 0x00053 (wrapper managed-to-native) Mono.G2.G2:g2_open_X11 (int,int) in 0x00015 Mono.G2.G2:OpenX11 (int,int) in 0x00018 G2Test:Main (string[]) make: *** [test] Error 1 -- Basically I tried variations of the libg2.so libg2.so.0.0.70 etc, and updates the ldconf.so cache, but Im wondering where I couldve been wrong. My problem I think is with Installation. Can someone please help me? Thanks, Muthu. PS: someone just said I Love Mono. Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: Problem with accessing C library from MONO
Hello! --- Muthiah Annamalai [EMAIL PROTECTED] wrote: My problem I think is with Installation. Can someone please help me? I fixed the problem, thanks to a bug in compilation of the C library. export MONO_LOG_LEVEL=debug and running my program fixed the issue, its really cool, because I got help directly from http://www.mono-project.com/DllNotFoundException Thanks everyone, sorry for unnecessary bugging. -Muthu Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Error in .Net cole
Friends, I am running Apache on top of XSP. I created a folder /NetLinux and running XSP from that folder. I have index.aspx and index.aspx.cs files available in the same folder. When I used http://localhost:8080 I am getting the following error. Server Error in '/' Application Parser Error Description: Error parsing a resource required to service this request. Review your source file and modify it to fix this error. Error message: File /NetLinux/index.aspx.cs not found File name: /NetLinux/index.aspxLine: 1 Source Error: %@ Page language=c# src=/NetLinux/index.aspx.cs Inherits=SimpleWebApp.SimplePage AutoEventWireup=false% !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN Normal html pages are working fine. Please sugget me. Thanks, Rajesh ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Type.GUID
The implementation of Type.GUID currently always returns an empty GUID. I believe in MS it will return the Guid specified by a GuidAttribute on the Type. I can post a patch if desired. I noticed a lot of other methods on the Type are done as internal calls. Should this be the case with the GUID? Or can I just call GetCustomAttributes on the Type? Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 09:32 +0200, Andreas Nahr wrote:
- Original Message -
From: Ben Maurer [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@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.
stuff on the ldstr table is in unicode. That assumes that the 20 consts
never get used, however. If they are used in the code at all, they will
need to be in the ldstr table.
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.
They don't.
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 ;)
That's correct.
Anyways, as I said to Kornel, Feel free to come back with data about
what effect the optimization will have. Otherwise, let's just spend time
on real performance issues with measurable results.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] mcs
Hi! As part of a project I have to study the mcs, especially those structures corresponding to a symbol table, which shall later be used in a source code analyzer. In the mcs, those symbol-table-like data structures are just parts of the tree created when parsing. To get some snapshots of these data-structures it would be fine to simply dump the tree and watch its contents, because using a debugger is quite cumbersome in this case. There is this ITreeDump Interface in tree.cs in line 16, but it is never implemented. Maybe anyone (of the developers) has used this for debugging purposes when writing the compiler and later, when everything went stable, removed those additional code. I'd be quite grateful to get access to such code or otherwise some information on how this whole tree used to be debugged when writing the compiler. I hope that anyone can help me out here, otherwise I'll have to implement my own methods for dumping, which will take some time I guess. Thanks, Christian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Assembly.GetReferencedAssemblies
Hi, This looks ok to commit. Zoltan On 7/29/05, Carlos Alberto Cortez [EMAIL PROTECTED] wrote: 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. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 18:10 +0200, Andreas Nahr wrote: And as you said it will be near to impossible to measure performance gains, because you would need to instrument the OS itself. From Kornel: Note that the things I said earlier in this thread and above are only a discussion about possible optimizations based on theoritical facts not on measurements. Please don't waste time with performance speculation. If you like speculation, try day trading. If we were to hack up the code every time a blind speculation was made, mono would be unmaintainable. Disk space is cheap. I can get disk space for under $0.50 per Gigabyte. If you want to measure performance gains, they have to be in terms of time (reducing the number of pages read from disk: ie, show that you save at least 1 page from being read from the disk) or memory (show that you save at least one page of memory from being allocated due to mallocs that you save or from being kept paged in by the OS). From Kornel: BTW what about the 2.0.0.0 patch? I'd still like to kill all the #if NET_1_1 crap in the files and use MonoConsts.FxVersion or something. It will save us pain in the future. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Using RSA optimally with both Mono and MS .Net
With Mono's implementation, it's really easy to use the RSA Crypto classes because it doesn't generate a key automatically on construction. I'm developing an application with Windows as a target, since ATM my family uses it and it currently has a large userbase. I've tried out using CspParameters to store a private key for reuse [though I don't particularly like how that key store works, I generally prefer storing it in a location I control]. CspParams doesn't seem to offer any way to load up a public key. Unless there's a good way to work around loading public keys into a Csp I see a few options: 1) Use Mono's managed RSA encryption. However, I wonder how this compares to using the CryptoAPI for Microsoft. 2) Wrap a library like openssl for crypto. [I might just do this to help out Mono and for performance optimization]. As an aside... does .Net 2.0 do the foolish automatic construction of an RSA key? Or perhaps does it offer a constructor that would accept RSAParameters [pretty obtuse not to offer a constructor like that]. -- Thomas Harning Jr. signature.asc Description: OpenPGP digital signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Disk space is cheap. I can get disk space for under $0.50 per Gigabyte. If you want to measure performance gains, they have to be in terms of time (reducing the number of pages read from disk: ie, show that you save at least 1 page from being read from the disk) or memory (show that you save at least one page of memory from being allocated due to mallocs that you save or from being kept paged in by the OS). I belive that altough we could add some random rubbish to compiled files like VB6 compiler does it's better not to include any unnecessary data in files. The point of view hardware is cheap is not good I think. Users could buy faster CPU and more RAM as well altough it is more expensive than HDD. Saying we don't care about HDD is the same as Microsoft does and their operating system is expanding without limits.:) From Kornel: BTW what about the 2.0.0.0 patch? I'd still like to kill all the #if NET_1_1 crap in the files and use MonoConsts.FxVersion or something. It will save us pain in the future. In this case I would like to do some more AssemblyInfo.cs centralization (movig common attributes to a common file and using a common set of attributes in all the assemblies with MS.NET attributes in mind of course) and cleanup because AssemblyInfo.cs files are a bit anarchistic currently. And adding AssemblyFileVersion attributes to all of the assemblies with the version you currently emit to the common MonoVersion.cs. And emit a contant instead of AssemblyVersion attribute that can be used in a common file. Is it OK? (I mean on OK that in addition that it meats your/our plans on Mono it will be approved if the patch is correct, without saying that we want to wait until next millenium or 101 other patches should be committed before that one. Because I don't like to waste time on patches that will not be approved in a resonable time.) Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 19:21 +0200, Kornél Pál wrote: From Kornel: BTW what about the 2.0.0.0 patch? I'd still like to kill all the #if NET_1_1 crap in the files and use MonoConsts.FxVersion or something. It will save us pain in the future. In this case I would like to do some more AssemblyInfo.cs centralization (movig common attributes to a common file and using a common set of attributes in all the assemblies with MS.NET attributes in mind of course) and cleanup because AssemblyInfo.cs files are a bit anarchistic currently. And adding AssemblyFileVersion attributes to all of the assemblies with the version you currently emit to the common MonoVersion.cs. And emit a contant instead of AssemblyVersion attribute that can be used in a common file. Is it OK? (I mean on OK that in addition that it meats your/our plans on Mono it will be approved if the patch is correct, without saying that we want to wait until next millenium or 101 other patches should be committed before that one. Because I don't like to waste time on patches that will not be approved in a resonable time.) Yeah, for assembly versioning, as much as possible should be shared. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Using RSA optimally with both Mono and MS .Net
Hello Thomas, On Fri, 2005-29-07 at 13:07 -0400, Thomas Harning Jr. wrote: With Mono's implementation, it's really easy to use the RSA Crypto classes because it doesn't generate a key automatically on construction. yes, this is done by default. I'm developing an application with Windows as a target, since ATM my family uses it and it currently has a large userbase. I like the currently ;-) I've tried out using CspParameters to store a private key for reuse [though I don't particularly like how that key store works, I generally prefer storing it in a location I control]. CspParams doesn't seem to offer any way to load up a public key. AFAIK you should be able to import a public key in a container. However IIRC there are some bugs related to re-using containers (e.g. the container and the new key must have the same key length). Unless there's a good way to work around loading public keys into a Csp I see a few options: 1) Use Mono's managed RSA encryption. However, I wonder how this compares to using the CryptoAPI for Microsoft. Slower, but you probably won't notice it unless you do: * a lot of RSA ops (which is generally a bad sign for most, non-server, applications); or * key generation; 2) Wrap a library like openssl for crypto. [I might just do this to help out Mono and for performance optimization]. That would be nice and, if done correctly/completely, could be used by most existing applications without any re-compilation. As an aside... does .Net 2.0 do the foolish automatic construction of an RSA key? That was fixed a long time ago (probably even in the 1.2 preview). There was no point to generate a new key each time you create an instance (as was a performance killer for any server-based application). Or perhaps does it offer a constructor that would accept RSAParameters I'm not aware of any new constructor. [pretty obtuse not to offer a constructor like that]. There are some good reasons for this but, sadly, they aren't consistent everywhere in the Fx (so I can't be sure if this is by good or bad design ;-). Sebastien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: [Mono-docs-list] [PATCH] Monodoc Gecko support improved
On Sat, 2005-07-30 at 02:08 +0200, Mario Sopena wrote: Hey everybody, after being stucked for a couple of days because of a stupid error that I made, I've finally added some improvements to the gecko patch. * Gecko support is now only built when gecko-sharp is present (GeckoHtmlRender.dll). Gecko-sharp is not a requirement now. I am curious how this works. My copy of gecko# is 0.6, and it is built against gtk# 2.0, this prevents it from being used to built monodoc. So this check here doesn't work. Is the plan to move monodoc to gtk# 2.0, or to stick with the gecko# version that is built against gtk# 1.0 (Which I think is 0.5, I believe 0.6 has always built against 2.0). --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [PATCH] Monodoc Gecko support improved
Hey everybody,
after being stucked for a couple of days because of a stupid error
that I made, I've finally added some improvements to the gecko patch.
* Gecko support is now only built when gecko-sharp is present
(GeckoHtmlRender.dll). Gecko-sharp is not a requirement now.
* The HtmlRender.cs is splitted in 3 files, the interface and the two
implementations: IHtmlRender.cs, GtkHtmlHtmlRender.cs,
GeckoHtmlRender.cs
* When monodoc is started, it tries to load the gecko renderer and if
it fails, it uses the gtkhtml.
* The --gecko option is changed to --no-gecko because gecko is
(should be) the default
*The GeckoHtmlRender has a new function, checkUrl, that tries to solve
the problem with gecko, who lower-case the scheme part of the url (the
part before the ':'), thus, breaking some URLs like
T:System.Activator.
Things that are left:
* the scrollbar showed is the gecko one
* copy/paste doesn't work
* anchor links (links to the same page) doesn't work either
ok to commit?
Mario.
Index: configure.in
===
--- configure.in (revision 47406)
+++ configure.in (working copy)
@@ -42,8 +42,9 @@
#fi
AC_SUBST(GTK_SHARP_LIBS)
-PKG_CHECK_MODULES(GECKO_SHARP, gecko-sharp = 0.6)
+PKG_CHECK_MODULES(GECKO_SHARP, gecko-sharp = 0.6, enable_gecko=yes, enable_gecko=no)
AC_SUBST(GECKO_SHARP_LIBS)
+AM_CONDITIONAL(ENABLE_GECKO, test x$enable_gecko = xyes)
dnl Intl
GETTEXT_PACKAGE=mono-tools
@@ -55,6 +56,7 @@
GNUNIT_VERSION=0.5
AC_SUBST(GNUNIT_VERSION)
+
AC_OUTPUT([
Makefile
gnunit/Makefile
@@ -76,4 +78,9 @@
echo Configuration summary
echo
echo* Installation prefix = $prefix
+echo* gecko-sharp.dll = $enable_gecko
echo
+echo NOTE: if any of the above say 'no' you may install the
+echo corresponding development packages for them, rerun
+echo autogen.sh to include them in the build.
+echo
Index: ChangeLog
===
--- ChangeLog (revision 47406)
+++ ChangeLog (working copy)
@@ -1,3 +1,6 @@
+2005-08-30 Mario Sopena Novales [EMAIL PROTECTED]
+ * configure.in: make gecko-sharp dependency conditional
+
2005-06-09 Gonzalo Paniagua Javier [EMAIL PROTECTED]
* configure.in: added GNUNIT_VERSION.
Index: docbrowser/IHtmlRender.cs
===
--- docbrowser/IHtmlRender.cs (revision 0)
+++ docbrowser/IHtmlRender.cs (revision 0)
@@ -0,0 +1,38 @@
+//
+// IHtmlRender.cs: Interface that abstracts the html render widget
+//
+// Author: Mario Sopena
+//
+using System;
+using Gtk;
+
+namespace Monodoc {
+public interface IHtmlRender {
+ // Jump to an anchor of the form a name=
+ void JumpToAnchor (string anchor_name);
+
+ //Copy to the clipboard the selcted text
+ void Copy ();
+
+ //Select all the text
+ void SelectAll ();
+
+ //Render the HTML code given
+ void Render (string html_code);
+
+ //Event fired when the use is over an Url
+ event EventHandler OnUrl;
+
+ //Event fired when the user clicks on a Link
+ event EventHandler UrlClicked;
+
+ // Variable that handles the info encessary for the events
+ // As every implementation of HtmlRender will have differents events
+ // we try to homogenize them with the variabel
+ string Url { get; }
+
+ Widget HtmlPanel { get; }
+}
+
+
+}
Index: docbrowser/GeckoHtmlRender.cs
===
--- docbrowser/GeckoHtmlRender.cs (revision 0)
+++ docbrowser/GeckoHtmlRender.cs (revision 0)
@@ -0,0 +1,156 @@
+//
+// GeckoHtmlRender.cs: Implementation of IHtmlRender that uses Gecko
+//
+// Author: Mario Sopena
+//
+using System;
+using System.Text;
+using System.IO;
+using System.Collections;
+using Gecko;
+using Gtk;
+
+namespace Monodoc {
+public class GeckoHtmlRender : IHtmlRender {
+
+ //Images are cached in a temporal directory
+ Hashtable cache_imgs;
+ string tmpPath;
+
+ WebControl html_panel;
+ Viewport panel;
+ public Widget HtmlPanel {
+ get { return (Widget) panel; }
+ }
+
+ string url;
+ public string Url {
+ get { return url; }
+ }
+ RootTree help_tree;
+
+ public event EventHandler OnUrl;
+ public event EventHandler UrlClicked;
+
+ public GeckoHtmlRender (RootTree help_tree)
+ {
+ this.help_tree = help_tree;
+ html_panel = new WebControl(/tmp/monodoc, MonodocGecko); //FIXME
+ html_panel.Show(); //due to Gecko bug
+ html_panel.OpenUri += OnOpenUri;
+ html_panel.LinkMsg += OnLinkMsg;
+ panel = new Viewport();
+ panel.Add (html_panel);
+ cache_imgs = new Hashtable();
+ tmpPath = Path.Combine (Path.GetTempPath(), monodoc);
+ }
+
+ protected void OnOpenUri (object o, OpenUriArgs args)
+ {
+ url = CheckUrl (args.AURI);
+ if (UrlClicked != null)
+ UrlClicked (this, new EventArgs());
+ args.RetVal = true; //this prevents Gecko to continue processing
+ }
+
+ protected void OnLinkMsg (object o, EventArgs args)
+ {
+ url = CheckUrl (html_panel.LinkMessage);
+ if (OnUrl != null)
+
[Mono-devel-list] Re: [Mono-docs-list] [PATCH] Monodoc Gecko support improved
Hola, On 7/30/05, Todd Berman [EMAIL PROTECTED] wrote: I am curious how this works. My copy of gecko# is 0.6, and it is built against gtk# 2.0, this prevents it from being used to built monodoc. So this check here doesn't work. Where did you get this gecko# 0.6? Because the one in SVN is gecko#2 which requires gtk#2 and the gecko# 0.6 from tarballs require gtk# 1.0. AFAIK, gecko# should be built for gtk#1.0 and gecko#2 for gtk#2. Is the plan to move monodoc to gtk# 2.0, or to stick with the gecko# version that is built against gtk# 1.0 (Which I think is 0.5, I believe 0.6 has always built against 2.0). This was discussed before. Look here (post by Ben Maurer): http://lists.ximian.com/pipermail/mono-devel-list/2005-July/013356.html Mario ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: [Mono-docs-list] [PATCH] Monodoc Gecko support improved
On Sat, 2005-07-30 at 02:36 +0200, Mario Sopena wrote: Hola, On 7/30/05, Todd Berman [EMAIL PROTECTED] wrote: I am curious how this works. My copy of gecko# is 0.6, and it is built against gtk# 2.0, this prevents it from being used to built monodoc. So this check here doesn't work. Where did you get this gecko# 0.6? Because the one in SVN is gecko#2 which requires gtk#2 and the gecko# 0.6 from tarballs require gtk# 1.0. AFAIK, gecko# should be built for gtk#1.0 and gecko#2 for gtk#2. Ah, maybe my version is before the pc file was version bumped. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: [Mono-docs-list] [PATCH] Monodoc Gecko support improved
On Fri, 2005-07-29 at 18:23 -0700, Todd Berman wrote: On Sat, 2005-07-30 at 02:36 +0200, Mario Sopena wrote: Hola, On 7/30/05, Todd Berman [EMAIL PROTECTED] wrote: I am curious how this works. My copy of gecko# is 0.6, and it is built against gtk# 2.0, this prevents it from being used to built monodoc. So this check here doesn't work. Where did you get this gecko# 0.6? Because the one in SVN is gecko#2 which requires gtk#2 and the gecko# 0.6 from tarballs require gtk# 1.0. AFAIK, gecko# should be built for gtk#1.0 and gecko#2 for gtk#2. Ah, maybe my version is before the pc file was version bumped. Actually. I found the issue. The issue was I had both the gecko-sharp.pc and gecko-sharp-2.0.pc. And since the gecko-sharp.pc was version 0.6, and points to the gecko-sharp.dll built against 2.0 (because they both point to /usr/lib/mono/gecko-sharp/gecko-sharp.dll, which is a symlink in my case the to 2.0 version). It was 'finding' gecko-sharp 0.6. --Todd ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [Patch] Publisher Policy support
Hello Carlos, I'm attaching a patch which adds support for publisher policy files ( http://msdn.microsoft.com/library/default.asp?url=/library/en- us/cpguide/html/cpconcreatingpublisherpolicyfile.asp ), which allows to redirect one assembly version to another. The patch looks good to me. Does anyone have any objections to get this patch in? Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] mcs
Hello, As part of a project I have to study the mcs, especially those structures corresponding to a symbol table, which shall later be used in a source code analyzer. In the mcs, those symbol-table-like data structures are just parts of the tree created when parsing. To get some snapshots of these data-structures it would be fine to simply dump the tree and watch its contents, because using a debugger is quite cumbersome in this case. mcs contains various different symbol tables. The main repository though is Reflection so you wont really find it in mcs. There is this ITreeDump Interface in tree.cs in line 16, but it is never implemented. Maybe anyone (of the developers) has used this for debugging purposes when writing the compiler and later, when everything went stable, removed those additional code. I'd be quite grateful to get access to such code or otherwise some information on how this whole tree used to be debugged when writing the compiler. That is code from the early days, it has not been touched in many years. You will have to dump your own data am afraid. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [Patch] Publisher Policy support
On Fri, 2005-07-29 at 22:31 -0400, Miguel de Icaza wrote: Hello Carlos, I'm attaching a patch which adds support for publisher policy files ( http://msdn.microsoft.com/library/default.asp?url=/library/en- us/cpguide/html/cpconcreatingpublisherpolicyfile.asp ), which allows to redirect one assembly version to another. The patch looks good to me. Does anyone have any objections to get this patch in? Locking wise, I am not so sure about this path. It adds a domain lock in the assembly loading code path. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Generics - Class Constraint
Trying to compile some C# code that uses generics on mono in
Linux (gentoo). I ran across the following problem (which is probably
just unimplemented functionality).
public static T
QueryInterfaceT(object val)
where T : class
{
if (val == null)
return null;
// First, see if the given object can be directly cast
// to the requested type. This will be a common case,
// especially when checking for standard behavior interface
// implementations (like IXrcDataElement).
T tval = val as T;
if (tval != null)
return tval;
more
}
The error:
Xircle.Core/src/Core/XrcConvert.cs(118) error CS0077: The as
operator should be used with a reference type only (T is a value type)
Line #118 is the line that reads T tval = val as T.
Looks like gmcs isnt honoring the class constraint (where
T:class). I found this bug in bugzilla, which seems related:
http://bugzilla.ximian.com/show_bug.cgi?id=75368
The question: Is that bug the same problem? If
so, Ill try compiling from SVN again (got strange errors last time I
tried), since the bug is marked resolved. If not, is there an ETA on when
GMCS will honor class constraints?
The gmcs Im using is from the bitrock installer of
mono 1.1.8.3.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] TimeStamp support on oracle...
You may need to allocate a TimeStamp descriptor. OciHandle might need to be modified to create a TimeStamp descirptor. See the difference between a DATE and TIMESTAMP in table 3-2 below. Notice how DATE is a char[7] while TIMESTAMP is a descriptor which uses opache type of OCIDateTime. http://download- east.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci03typ.htm#sthref450 Table 3-2 External Datatypes and Codes EXTERNAL DATATYPE CODEPROGRAM VARIABLEOCI DEFINED CONSTANT DATE 12 char[7] SQLT_DAT TIMESTAMP descriptor 187 OCIDateTime* SQLT_TIMESTAMP Also, it looks like you're doing a non-query below. Can I any test cases you have timestamp please? On Fri, 2005-07-29 at 15:31 +0200, Hubert FONGARNAND wrote: I've made a new patch... It worked when I send a timestamp in string format, but with binary format it fails after binding parameters t... with an undebuggable error: Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object in 0x0 unknown method in (wrapper managed-to-native) OciNativeCalls:OCIStmtExecute (intptr,intptr,intptr,uint,uint,intptr,intptr,System.Data.OracleClient.Oci.OciExecuteMode) in 0x0002f System.Data.OracleClient.Oci.OciCalls:OCIStmtExecute (IntPtr svchp, IntPtr stmthp, IntPtr errhp, Boolean iters, UInt32 rowoff, IntPtr snap_in, IntPtr snap_out, OciExecuteMode mode) in 0x000a8 System.Data.OracleClient.Oci.OciStatementHandle:Execute (Boolean nonQuery, Boolean useAutoCommit, Boolean schemaOnly) in 0x00013 System.Data.OracleClient.Oci.OciStatementHandle:ExecuteNonQuery (Boolean useAutoCommit) in 0x0005d System.Data.OracleClient.OracleCommand:ExecuteNonQueryInternal (System.Data.OracleClient.Oci.OciStatementHandle statement, Boolean useAutoCommit) in 0x00081 System.Data.OracleClient.OracleCommand:ExecuteNonQuery () in (wrapper remoting-invoke-with-check) System.Data.OracleClient.OracleCommand:ExecuteNonQuery () i don't know why? Can you have a look on my patch... thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
