[Mono-dev] patch for property method location
Hi,
I made a tiny patch to set property method location correctly.
A repro case is also attached.
Atsushi Eno
Index: class.cs
===
--- class.cs(revision 48814)
+++ class.cs(working copy)
@@ -5704,7 +5704,7 @@
ReturnParameter return_attributes;
public AbstractPropertyEventMethod (MemberBase member, string
prefix)
- : base (null, SetupName (prefix, member), null)
+ : base (null, SetupName (prefix, member,
member.Location), null)
{
this.prefix = prefix;
IsDummy = true;
@@ -5712,21 +5712,21 @@
public AbstractPropertyEventMethod (MemberBase member, Accessor
accessor,
string prefix)
- : base (null, SetupName (prefix, member),
+ : base (null, SetupName (prefix, member,
accessor.Location),
accessor.Attributes)
{
this.prefix = prefix;
this.block = accessor.Block;
}
- static MemberName SetupName (string prefix, MemberBase member)
+ static MemberName SetupName (string prefix, MemberBase member,
Location loc)
{
- return new MemberName (member.MemberName.Left, prefix +
member.ShortName);
+ return new MemberName (member.MemberName.Left, prefix +
member.ShortName, loc);
}
public void UpdateName (MemberBase member)
{
- SetMemberName (SetupName (prefix, member));
+ SetMemberName (SetupName (prefix, member, Location));
}
#region IMethodData Members
using System;
public class Test
{
public static void Main () {}
public string get_Value () { return null; }
public string Value {
set { }
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] help: how to compile mono for arm or some link to download binary for ARM
Hi, Is there some link to download mono for ARM? or How Can I compile mono for ARM? I have a sarge debian working on ARM board!! thank you in advanced! best regards ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Obtain the available memory
Hi, I have seen that the PerformanceCounter class is yet unimplemented in mono, yet, I would like to emulate with mono, the following code PerformanceCounter counter = new PerformanceCounter(Memory, Available Bytes); /code There is the possibility to resort to command-line and to parse the output of the top -b command, but I feel that this option is very poor because the top output is not standardised at all (also this solution may yield very poor performance). Somehow mono do know already (I guess) such information at least for the GC purpose. What would you suggest to get such information on mono? Thanks in advance, Joannès ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Obtain the available memory
Hi, I have seen that the PerformanceCounter class is yet unimplemented in mono, yet, I would like to emulate with mono, the following code PerformanceCounter counter = new PerformanceCounter(Memory, Available Bytes); /code There is the possibility to resort to command-line and to parse the output of the top -b command, but I feel that this option is very poor because the top output is not standardised at all (also this solution may yield very poor performance). I'm not sure what you mean with the top output not being standardised (it certainly wouldn't work on machines which didn't have the top program). You may be right over the performance hit though. What would you suggest to get such information on mono? Wait until PerformanceCounter is implemented? Memory is handled differently by different hardware, it's therefore very hard to get a standardised method. TTFN Paul -- Logic, my dear Zoe, is merely the ability to be wrong with authority - Dr Who ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored Ssl Streams in Mono.Security
Hello JD, On Wed, 2005-24-08 at 21:12 -0700, JD Conley wrote: I took the plunge and fully implemented async Ssl streams for both client and server. This fixes http://bugzilla.ximian.com/show_bug.cgi?id=75687 as well as other bugs I've been talking with Sebastien and Carlos about off list. This patch passes the SocketHell tests that I contributed to them last week (multi threaded concurrent async streaming through TCP sockets). Wow! That's the kind of surprise I like when I wake up :-) It's also a bit of a re-factor, though I only touched two classes and added one. I pulled most of the code out of the individual SslClientStream and SslServerStream and moved it down into a new abstract SslStreamBase. Client and server are now practically the same implementation. I left all existing interfaces present, but obviously had to add some new ones. We always sticked to the Fx 1.2 preview specs for the Ssl[Client| Server]Stream API and didn't planned to change this before implementing the new SslStream (in System.dll) for 2.0 - BUT this isn't a major problem if it doesn't break binary compatibility (for current applications linked with Mono.Security.dll). The only gotcha is if you start running low on threadpool threads. Then the Ssl Stream will fall back to a synchronous handshake. The other option here is to spawn a thread ourselves for the handshake instead of using Delegate.BeginInvoke(), use the IO ThreadPool (is that available to Mono.Security?), or just live with a synchronous handshake. Of course, 99.999% of the time this issue won't occur and won't be a problem unless you have both client and server sharing the same Threadpool causing a deadlock. That's not worse than the original (where the handshake was always synchronous). I hope this helps and gets integrated. It's definitely necessary for our implementation. 1. I'll review the patch and, in doing so, check for possible binary compatibility problems. I'm sure Carlos will do likewise; 2. I'll make public a new Mono.Security.dll assembly so that people that depends on Ssl*Stream may tests it and report any problem/difference; 3. I'll run the regressions tests, the tools under /mcs/class/ Mono.Security/Test/tools/*, to see if it works in previously reported conditions. 4. Commit (both the patch and your SocketHell tests). Hopefully we can do all this before the next release. Many thanks! -- Sebastien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Glib files required from Linux\PPC machine
Hello, If anyone is running Mono on a Linux\PPC machine, could you please mail me the following files from your machine *) glibconfig.h *) gtypes.h Thanks in advance, Best regards, Gary ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Build error in svn
I get the following when trying to build the latest from svn: make[8]: Entering directory `/src/mono/mcs/class/System.Drawing' MONO_PATH=../../class/lib/default:$MONO_PATH /src/mono/mono/runtime/mono-wrapper ../../class/lib/default/mcs.exe -d:NET_1_1 -d:ONLY_1_1 -debug /noconfig /unsafe /r:mscorlib.dll /r:System.dll /nowarn:649 /nowarn:169 -target:li brary -out:../../class/lib/default/System.Drawing.dll @System.Drawing.dll.sources syntax error, got token `CLOSE_PARENS' System.Drawing/ComIStreamMarshaler.cs(570,51): error CS1002: Expecting `;' Compilation failed: 1 error(s), 0 warnings make[8]: *** [../../class/lib/default/System.Drawing.dll] Error 1 make[8]: Leaving directory `/src/mono/mcs/class/System.Drawing' make[7]: *** [do-all] Error 2 make[7]: Leaving directory `/src/mono/mcs/class/System.Drawing' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/src/mono/mcs/class' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/src/mono/mcs' make[4]: *** [profile-do--default--all] Error 2 make[4]: Leaving directory `/src/mono/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/src/mono/mcs' make[2]: *** [all-local] Error 1 make[2]: Leaving directory `/src/mono/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/src/mono/mono' make: *** [all] Error 2 The code looks good though. I'm not sure why I get this error. Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build error in svn
This has to be an mcs bug as I (nor anybody else) did not modify this file for 2 months and it compiled on previous mcs versions (it is part of the class library so it has to) and it compiles on csc.exe. Kornél - Original Message - From: Jonathan S. Chambers [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Thursday, August 25, 2005 3:58 PM Subject: [Mono-dev] Build error in svn I get the following when trying to build the latest from svn: make[8]: Entering directory `/src/mono/mcs/class/System.Drawing' MONO_PATH=../../class/lib/default:$MONO_PATH /src/mono/mono/runtime/mono-wrapper /../class/lib/default/mcs.exe-d:NET_1_1 -d:ONLY_1_1 -debug /noconfig /unsafe /r:mscorlib.dll /r:System.dll /nowarn:649 /nowarn:169 -target:li brary -out:../../class/lib/default/System.Drawing.dll @System.Drawing.dll.sources syntax error, got token `CLOSE_PARENS' System.Drawing/ComIStreamMarshaler.cs(570,51): error CS1002: Expecting `;' Compilation failed: 1 error(s), 0 warnings make[8]: *** [../../class/lib/default/System.Drawing.dll] Error 1 make[8]: Leaving directory `/src/mono/mcs/class/System.Drawing' make[7]: *** [do-all] Error 2 make[7]: Leaving directory `/src/mono/mcs/class/System.Drawing' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/src/mono/mcs/class' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/src/mono/mcs' make[4]: *** [profile-do--default--all] Error 2 make[4]: Leaving directory `/src/mono/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/src/mono/mcs' make[2]: *** [all-local] Error 1 make[2]: Leaving directory `/src/mono/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/src/mono/mono' make: *** [all] Error 2 The code looks good though. I'm not sure why I get this error. Thanks, Jonathan ___ 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-dev] Build error in svn
Kornél Pál wrote: This has to be an mcs bug as I (nor anybody else) did not modify this file for 2 months and it compiled on previous mcs versions (it is part of the class library so it has to) and it compiles on csc.exe. Or might be bugs in Encoding class if the build fixes after my patch. If so please tell us what locale you are using, Jonathan. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Build error in svn
I took Kornel's name out of the file and it compiled ok. Then I got the follwoing error. That file also has non ascii characters in the contributors names. So I believe the issue involves this in some way. Thanks for the help. make[8]: Entering directory `/src/mono/mcs/class/System.Web' MONO_PATH=../../class/lib/default:$MONO_PATH /src/mono/mono/runtime/mono-wrapper ../../class/lib/default/mcs.exe -d:NET_1_1 -d:ONLY_1_1 -debug /noconfig /nowar n:649 /r:mscorlib.dll /r:System.dll /r:System.Drawing.dll /r:System.Data.dll /r:Sy stem.Xml.dll /r:System.EnterpriseServices.dll -target:library -out:../../class/l ib/default/System.Web.dll @System.Web.dll.sources syntax error, got token `OP_OR' System.Web/HttpUtility.cs(685,31): error CS1002: Expecting `;' syntax error, got token `RETURN' System.Web/HttpUtility.cs(699,4): error CS8025: Parsing error Compilation failed: 2 error(s), 0 warnings make[8]: *** [../../class/lib/default/System.Web.dll] Error 1 make[8]: Leaving directory `/src/mono/mcs/class/System.Web' make[7]: *** [do-all] Error 2 make[7]: Leaving directory `/src/mono/mcs/class/System.Web' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/src/mono/mcs/class' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/src/mono/mcs' make[4]: *** [profile-do--default--all] Error 2 make[4]: Leaving directory `/src/mono/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/src/mono/mcs' make[2]: *** [all-local] Error 1 make[2]: Leaving directory `/src/mono/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/src/mono/mono' make: *** [all] Error 2 -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: Thu 8/25/2005 10:27 AM To: Kornél Pál Cc: Jonathan S. Chambers; mono-devel-list@lists.ximian.com Subject:Re: [Mono-dev] Build error in svn Kornél Pál wrote: This has to be an mcs bug as I (nor anybody else) did not modify this file for 2 months and it compiled on previous mcs versions (it is part of the class library so it has to) and it compiles on csc.exe. Or might be bugs in Encoding class if the build fixes after my patch. If so please tell us what locale you are using, Jonathan. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Build error in svn
Unicode (UTF-8) utf-8 65001 - Jonathan -Original Message- From: Kornél Pál [mailto:[EMAIL PROTECTED] Sent: Thu 8/25/2005 10:56 AM To: Jonathan S. Chambers; Atsushi Eno Cc: mono-devel-list@lists.ximian.com Subject:Re: [Mono-dev] Build error in svn Run the attached code on the system you try to compile mcs tree. And tell us the results. (It prints some redundant information but why not. :) Kornél - Original Message - From: Jonathan S. Chambers [EMAIL PROTECTED] To: Atsushi Eno [EMAIL PROTECTED]; Kornl Pl [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Thursday, August 25, 2005 4:42 PM Subject: RE: [Mono-dev] Build error in svn Please tell the newbie how to determine what encoding I am using. Thanks. -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: Thu 8/25/2005 10:27 AM To: Kornl Pl Cc: Jonathan S. Chambers; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Build error in svn Kornl Pl wrote: This has to be an mcs bug as I (nor anybody else) did not modify this file for 2 months and it compiled on previous mcs versions (it is part of the class library so it has to) and it compiles on csc.exe. Or might be bugs in Encoding class if the build fixes after my patch. If so please tell us what locale you are using, Jonathan. Atsushi Eno ___ 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-dev] Obtain the available memory
On 08/25/05 Joannes Vermorel wrote: I have seen that the PerformanceCounter class is yet unimplemented in mono, yet, I would like to emulate with mono, the following code PerformanceCounter counter = new PerformanceCounter(Memory, Available Bytes); /code There is the possibility to resort to command-line and to parse the output of the top -b command, but I feel that this option is very poor because the top output is not standardised at all (also this solution may yield very poor performance). While PerformanceCounter is not implemented, on Linux you can read the /proc/meminfo file: ~$ cat /proc/meminfo MemTotal: 1035740 kB [...] As for PerformanceCounter: as I suggested in the past, someone running windows should collect the names, types, and meanings of the counters that we should make available and write them all in one place. When we'll have that doc, we'll implement the support in mono. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] AssemblyName ctor (yes, again)
On 08/24/05 Carlos Alberto Cortez wrote:
The attached patches contain some changes to runtime functions to
support the new AssemblyName ctor. They also add an internal call for
this ctor.
I added a pair of new fields to MonoAssemblyName (is_persistent and
is_version_defined) to define if the public_key was parsed (should be
freed) or is persistent (image metadata). The second is used for
avoiding creating the version if it was not defined (I need it to
mimic .Net behavior).
Comments?
PD - The run rests fine with the patches.
Index: assembly.c
===
--- assembly.c(revisión: 48811)
+++ assembly.c(copia de trabajo)
@@ -449,6 +449,7 @@
mono_metadata_decode_row (t, 0, cols, MONO_ASSEMBLY_SIZE);
+ aname-is_persistent = TRUE;
aname-hash_len = 0;
aname-hash_value = NULL;
aname-name = mono_metadata_string_heap (image, cols
[MONO_ASSEMBLY_NAME]);
@@ -458,6 +459,7 @@
aname-minor = cols [MONO_ASSEMBLY_MINOR_VERSION];
aname-build = cols [MONO_ASSEMBLY_BUILD_NUMBER];
aname-revision = cols [MONO_ASSEMBLY_REV_NUMBER];
+ aname-is_version_defined = TRUE;
aname-hash_alg = cols [MONO_ASSEMBLY_HASH_ALG];
if (cols [MONO_ASSEMBLY_PUBLIC_KEY]) {
gchar* token = g_malloc (8);
@@ -1169,23 +1171,35 @@
g_free ((void *) aname-name);
g_free ((void *) aname-culture);
g_free ((void *) aname-hash_value);
+
+ if (!aname-is_persistent)
+ g_free ((void *) aname-public_key);
}
static gboolean
-build_assembly_name (const char *name, const char *version, const char
*culture, const char *token, MonoAssemblyName *aname)
+build_assembly_name (const char *name, const char *version, const char
*culture, const char *token, const char *key, MonoAssemblyName *aname)
{
gint major, minor, build, revision;
memset (aname, 0, sizeof (MonoAssemblyName));
if (version) {
- if (sscanf (version, %u.%u.%u.%u, major, minor, build,
revision) != 4)
+ gchar **tmp, **parts = g_strsplit (version, ., 4);
+
+ tmp = parts;
+ major = *tmp ? atoi (*tmp++) : -1;
Use strtol() for proper error checking.
+ aname-major = (guint16) major;
Why the cast?
@@ -1197,8 +1211,35 @@
aname-culture = g_strdup (culture);
}
- if (token strncmp (token, null, 4) != 0)
+ if (token strncmp (token, null, 4) != 0) {
+ if (strlen (token) != MONO_PUBLIC_KEY_TOKEN_LENGTH - 1)
+ return FALSE;
+
g_strlcpy ((char*)aname-public_key_token, token,
MONO_PUBLIC_KEY_TOKEN_LENGTH);
+ }
+
+ if (key strncmp (key, null, 4) != 0) {
+ gchar *arr, *tok, *encoded;
+ int i, j;
+
+ if (strlen (key) != MONO_PUBLIC_KEY_LENGTH)
+ return FALSE;
Can't the length change based on the flags? Sebastien?
+ arr = g_malloc (160);
+ for (i = 0, j = 0; i 160; i++) {
+ arr [i] = g_ascii_xdigit_value (key [j++]) 4;
+ arr [i] |= g_ascii_xdigit_value (key [j++]);
+ }
+ aname-public_key = (guint8*) arr;
+
+ // We also need to generate the key token
+ tok = g_malloc (8);
Ugh, just alloc it on the stack.
+ mono_digest_get_public_token ((guchar*) tok, aname-public_key,
160);
+ encoded = encode_public_tok ((guchar*) tok, 8);
+ g_strlcpy ((char*)aname-public_key_token, encoded,
MONO_PUBLIC_KEY_TOKEN_LENGTH);
+ g_free (tok);
+ g_free (encoded);
+ }
return TRUE;
}
@@ -1215,7 +1256,7 @@
return FALSE;
}
- res = build_assembly_name (name, parts[0], parts[1], parts[2], aname);
+ res = build_assembly_name (name, parts[0], parts[1], parts[2], NULL,
aname);
g_strfreev (parts);
return res;
}
@@ -1236,6 +1277,7 @@
gchar *version = NULL;
gchar *culture = NULL;
gchar *token = NULL;
+ gchar *key = NULL;
gboolean res;
gchar *value;
gchar **parts;
@@ -1270,12 +1312,18 @@
tmp++;
continue;
}
+
+ if (!g_ascii_strncasecmp (value, PublicKey=, 10)) {
+ key = g_strstrip (value + 10);
+ tmp++;
+ continue;
+ }
g_strfreev (parts);
return FALSE;
}
- res = build_assembly_name (dllname, version, culture, token, aname);
+ res = build_assembly_name (dllname, version, culture, token, key,
aname);
g_strfreev (parts);
return res;
}
Index: image.h
Re: [Mono-dev] Fatal Error In GC: Too Many Threads
On 08/23/05 JD Conley wrote: I get this error message box in Mono under Windows running some of the more interesting tests that I have. At the time it shows up there are 200 and some odd threads in mono.exe (which, I found this pretty funny, is less than an iexplore.exe process I have). Basically all of the threads are in Sleep/Wait. Why would I see this exception? What can I do about it? The default in the GC for windows is to use 256 threads MAX. We should increase this. Now, the fact that you have 200+ threads running: is that by design in your app or is that a bug in itself? lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Novell.Directory.Ldap in the Mono tree
Hello, Miguel, do you think this change can be made? Can we get some contact developer in Novell to discuss the latest changes and to synchronize the code trees? Is it possible to switch the development to the common repository? In my last contact with them (a very long time ago, more than six months) they said something along the lines of: * We can not keep the trees in sync very often, but they can merge the code every once in a while. Dont know what that means to us in reality. * They seemed to be very busy. * They seemed to not want to move their development from their current repository into ours. My preference is for someone at Novell to take care of this merging, but I see this as being a painful and not very responsive process. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build error in svn
UTF-8 should ignore invalid character representations like é (0xe9). BTW the code compiles with csc.exe with code page set to UTF-8 (csc -codepage:65001 -target:library ComIStreamMarshaler.cs) altough I got error when I used é in identifiers. But UTF8Encoding should simply ignore invalid character representations. I think other code pages are parsing all bytes as well so there should be no problems using non-ascii characters after // because it's very unlikely to parse these characters as line break and any other characters will be ignored. The above things are regarding the behaviour of mcs and UTF8Encoding not the source files of Mono. Maybe we should use UTF-8 for source files. Kornél - Original Message - From: Jonathan S. Chambers [EMAIL PROTECTED] To: Kornl Pl [EMAIL PROTECTED]; Atsushi Eno [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Thursday, August 25, 2005 4:59 PM Subject: RE: [Mono-dev] Build error in svn Unicode (UTF-8) utf-8 65001 - Jonathan -Original Message- From: Kornl Pl [mailto:[EMAIL PROTECTED] Sent: Thu 8/25/2005 10:56 AM To: Jonathan S. Chambers; Atsushi Eno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Build error in svn Run the attached code on the system you try to compile mcs tree. And tell us the results. (It prints some redundant information but why not. :) Kornl - Original Message - From: Jonathan S. Chambers [EMAIL PROTECTED] To: Atsushi Eno [EMAIL PROTECTED]; Kornl Pl [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Thursday, August 25, 2005 4:42 PM Subject: RE: [Mono-dev] Build error in svn Please tell the newbie how to determine what encoding I am using. Thanks. -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: Thu 8/25/2005 10:27 AM To: Kornl Pl Cc: Jonathan S. Chambers; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Build error in svn Kornl Pl wrote: This has to be an mcs bug as I (nor anybody else) did not modify this file for 2 months and it compiled on previous mcs versions (it is part of the class library so it has to) and it compiles on csc.exe. Or might be bugs in Encoding class if the build fixes after my patch. If so please tell us what locale you are using, Jonathan. Atsushi Eno ___ 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
Re: [Mono-dev] help: how to compile mono for arm or some link to download binary for ARM
Hi, or How Can I compile mono for ARM? The exact same way as with any other architecture: follow the instructions for building from svn. At this time the port can't build all of mcs/ and even if it could you likely don't want to do it, since ARM processors are quite slow, WHAT? Slow in comparison to what? For some things, a 600MHz X-Scale ARM processor can blow a 2GHz x86 out of the water. Please don't make such rash statements! TTFN Paul -- A lot of football success is in the mind. You must believe you are the best and then make sure that you are. In my time at Liverpool we always said we had the best two teams on Merseyside, Liverpool and Liverpool Reserves. - Bill Shankly ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Assembly version 2.0.0.0 with centralizedassembly references
Did we get this patch on SVN yet? It's on SVN as of revisions 48519 (mcs) and 48520 (mono). And I think notice about this version change has to be included in release notes. Kornél - Original Message - From: Miguel de Icaza [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Thursday, August 25, 2005 5:20 PM Subject: Re: [Mono-dev] [PATCH] Assembly version 2.0.0.0 with centralizedassembly references Hello, This patch is quite big. The 2.0.0.0 patch was much smaller but you wanted this bigger one.:) It may be more difficult to review but will result in a much reliable class library. Did we get this patch on SVN yet? It contains only assembly version related things nothing else. Note that I corrected all the version issues I found in any file type. For example: v2.0.40607 - v2.0.50215 (config) 1:0:33000:0 - 1:0:3300:0 (comment) 1.0.3102.0 - 1.0.3300.0 (resx) I did not modify any InformationalVersion or FileVersion attributes but they should be modified at a later time. I did not modified tests to use the common Consts.cs because they are designed differently but I updated the version numbers to 2.0.0.0. I did not added any ChangeLog entry and I'm not going to do it by hand. If you want to have ChangeLog entries please let me know how can I generate them. To Ben: I am sick of explaining that this task is in fact quite easy. The idea behind this task is easy to understand but actually it took a lot of hours to create this patch as all the results has to be examined even with regular expressions matching only the right version numbers. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Miguel de Icaza [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build error in svn
Hi, Run the attached code on the system you try to compile mcs tree. And tell us the results. (It prints some redundant information but why not. :) Not able to compile either (UK, UTF-8, 65001) TTFN Paul -- A lot of football success is in the mind. You must believe you are the best and then make sure that you are. In my time at Liverpool we always said we had the best two teams on Merseyside, Liverpool and Liverpool Reserves. - Bill Shankly ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build error in svn
As a quick workaround I added /codepage:28591 for all problematic
assemblies. After that I feel reluctant to fix those bugs :-/
Kornél Pál wrote:
UTF8Encoding should ignore them anyway when throwOnInvalidBytes = false
(default) so i think UTF8Encoding is bugous as well.
However the example code below did not show different results
between MS.NET and Mono.
using System;
using System.Text;
public class Test
{
public static void Main ()
{
string s = Encoding.UTF8.GetString (new byte [] {0xE9});
foreach (char c in s)
Console.WriteLine ({0:x02} , (int) c);
}
}
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build error in svn
Ok, now am removing all characters that is not accepted by UTF8Encoding from mcs sources. Maybe they are mostly contributor names, but don't get me wrong. They should not be in the international project. Atsushi Eno Kornél Pál wrote: UTF-8 should ignore invalid character representations like é (0xe9). BTW the code compiles with csc.exe with code page set to UTF-8 (csc -codepage:65001 -target:library ComIStreamMarshaler.cs) altough I got error when I used é in identifiers. But UTF8Encoding should simply ignore invalid character representations. I think other code pages are parsing all bytes as well so there should be no problems using non-ascii characters after // because it's very unlikely to parse these characters as line break and any other characters will be ignored. The above things are regarding the behaviour of mcs and UTF8Encoding not the source files of Mono. Maybe we should use UTF-8 for source files. Kornél - Original Message - From: Jonathan S. Chambers [EMAIL PROTECTED] To: Kornl Pl [EMAIL PROTECTED]; Atsushi Eno [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Thursday, August 25, 2005 4:59 PM Subject: RE: [Mono-dev] Build error in svn Unicode (UTF-8) utf-8 65001 - Jonathan -Original Message- From: Kornl Pl [mailto:[EMAIL PROTECTED] Sent: Thu 8/25/2005 10:56 AM To: Jonathan S. Chambers; Atsushi Eno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Build error in svn Run the attached code on the system you try to compile mcs tree. And tell us the results. (It prints some redundant information but why not. :) Kornl - Original Message - From: Jonathan S. Chambers [EMAIL PROTECTED] To: Atsushi Eno [EMAIL PROTECTED]; Kornl Pl [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Thursday, August 25, 2005 4:42 PM Subject: RE: [Mono-dev] Build error in svn Please tell the newbie how to determine what encoding I am using. Thanks. -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: Thu 8/25/2005 10:27 AM To: Kornl Pl Cc: Jonathan S. Chambers; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Build error in svn Kornl Pl wrote: This has to be an mcs bug as I (nor anybody else) did not modify this file for 2 months and it compiled on previous mcs versions (it is part of the class library so it has to) and it compiles on csc.exe. Or might be bugs in Encoding class if the build fixes after my patch. If so please tell us what locale you are using, Jonathan. Atsushi Eno ___ 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
Re: [Mono-dev] Build error in svn
First of all:
I get error when try to compile mcs tree:
System.Xml.Schema\XmlSchemaSimpleTypeRestriction.cs(634) error CS0019:
Operator
`' cannot be applied to operands of type `bool' and `int'
This seems to be false alarm. Do you get it as well?
Back to the original problem:
You are right, UTF8Encoding works as expected.
The the problem may be in SeekableStreamReader.
The following code skipped é and á as expected so mcs should compile the
code without problems as it does not get them from UTF8Encoding:
using System;
using System.IO;
using System.Text;
public class Test
{
public static void Main ()
{
StreamReader reader = new StreamReader(ComIStreamMarshaler.cs, new
UTF8Encoding(false, false), false);
StreamWriter writer = new StreamWriter(ComIStreamMarshaler1.cs, false,
new UTF8Encoding(false, false));
writer.Write(reader.ReadToEnd());
reader.Close();
writer.Close();
}
}
Kornél
- Original Message -
From: Atsushi Eno [EMAIL PROTECTED]
To: Kornél Pál [EMAIL PROTECTED]
Cc: Jonathan S. Chambers [EMAIL PROTECTED];
mono-devel-list@lists.ximian.com
Sent: Thursday, August 25, 2005 6:18 PM
Subject: Re: [Mono-dev] Build error in svn
As a quick workaround I added /codepage:28591 for all problematic
assemblies. After that I feel reluctant to fix those bugs :-/
Kornél Pál wrote:
UTF8Encoding should ignore them anyway when throwOnInvalidBytes = false
(default) so i think UTF8Encoding is bugous as well.
However the example code below did not show different results
between MS.NET and Mono.
using System;
using System.Text;
public class Test
{
public static void Main ()
{
string s = Encoding.UTF8.GetString (new byte [] {0xE9});
foreach (char c in s)
Console.WriteLine ({0:x02} , (int) c);
}
}
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cairo
I'm answering your question in a separate message that should hit the list in a few minutes. Cheers, Peter -Original Message- From: Paul [EMAIL PROTECTED] To: mono-devel Mono-devel-list@lists.ximian.com Date: 25 August, 2005 11:18 Subject: [Mono-dev] Cairo Hi, Seems that Cairo 1.0 has been released. How close is mono/mcs to using 1.0? ISTR work being done for 0.6, but that it was still not complete. TTFN Paul -- A lot of football success is in the mind. You must believe you are the best and then make sure that you are. In my time at Liverpool we always said we had the best two teams on Merseyside, Liverpool and Liverpool Reserves. - Bill Shankly ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] AssemblyName ctor (yes, again)
On Thu, 2005-25-08 at 15:42 +0200, Paolo Molaro wrote:
@@ -1197,8 +1211,35 @@
aname-culture = g_strdup (culture);
}
- if (token strncmp (token, null, 4) != 0)
+ if (token strncmp (token, null, 4) != 0) {
+ if (strlen (token) != MONO_PUBLIC_KEY_TOKEN_LENGTH - 1)
+ return FALSE;
+
g_strlcpy ((char*)aname-public_key_token, token,
MONO_PUBLIC_KEY_TOKEN_LENGTH);
+ }
+
+ if (key strncmp (key, null, 4) != 0) {
+ gchar *arr, *tok, *encoded;
+ int i, j;
+
+ if (strlen (key) != MONO_PUBLIC_KEY_LENGTH)
+ return FALSE;
Can't the length change based on the flags? Sebastien?
The structure is a CryptoAPI blob who's size change only if the key
length change.
However strongnames can now be bigger than 1024 bits (on 2.0). We don't
support that (yet) and we'll have to change some assumptions in the code
to do so. Anyway we better start now...
Note: but this shouldn't affect the public key tokens
--
Sebastien
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] AssemblyName ctor (yes, again)
This break the ABI: is_version_defined is not needed since you can check the fields anyway. is_persistent can go away some other way (for example by always having public_key allocated, but it would be better to find another which doesn't make us waste memory). No, you can't check the fields. If Version is defined as 0.0.0.0, or if the user didn't specified version, it happens the same. Then Version is created for AssemblyName calling the new ctor, even when it wasn't specified (not compatible with .Net). However, since it could break api, as you mentioned maybe we should find other way to do it (and also change the persistent flag). Carlos. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] COM Interop, or something like it
Hello, In Microsofts implementation of .NET, it is possible to expose a class written in C# via a COM interface. This makes it possible (perhaps even easy!) to instantiate C# objects and call methods on them from, say, a native C++ application. Does Mono have a capability like this? In looking around, Ive found vague references to Corba and Bonobo interop, but no specifics. It doesnt matter much to me what specific technology is used, Id just like an easy way to instantiate managed objects and interact with them from a native C++ application. I know I can embed Mono, and call methods that way, but it seems very cumbersome compared to COM interop. Is there a better way? Thanks! Kevin Ring ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] COM Interop, or something like it
Hi,I don't pretend to be an expert, but I believe the easier way is exposing the functionality through a web service.Regards,On 25/08/05, Ring, Kevin [EMAIL PROTECTED] wrote: Hello, In Microsoft's implementation of .NET, it is possible to expose a class written in C# via a COM interface. This makes it possible (perhaps even easy!) to instantiate C# objects and call methods on them from, say, a native C++ application. Does Mono have a capability like this? In looking around, I've found vague references to Corba and Bonobo interop, but no specifics. It doesn't matter much to me what specific technology is used, I'd just like an easy way to instantiate managed objects and interact with them from a native C++ application. I know I can embed Mono, and call methods that way, but it seems very cumbersome compared to COM interop. Is there a better way? Thanks! Kevin Ring ___Mono-devel-list mailing listMono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Vladimir LushnikovC.E.O and Software DeveloperEverythingX Limited (http://www.everythingx.net)http://mireno.blogspot.com - Of Life and Programming ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] mono on IA64 - help compiling
Did you get monolite; i.e. 'make get-monolite-latest'? - Jonathan -Original Message- From: [EMAIL PROTECTED] on behalf of Kevin Sent: Thu 8/25/2005 8:57 PM To: mono-devel-list@lists.ximian.com Cc: Subject:[Mono-dev] mono on IA64 - help compiling Hello all, I have tried to compile mono on one of the Itanium2 machines at work, but at some point it asks for an existing mcs compiler. I am not sure how to solve this, as i am guessing that installing the binaries won't work there, or will they? Could anyone please advise. PS: I have pasted the error below. Thanks in advance Kevin -- START ERROR--- make[3]: Entering directory `/home/veragoo/mono/mcs' make profile-do--default--all profile-do--net_2_0--all make[4]: Entering directory `/home/veragoo/mono/mcs' make PROFILE=basic all make[5]: Entering directory `/home/veragoo/mono/mcs' *** The compiler 'mcs' doesn't appear to be usable. *** You need a C# compiler installed to build MCS (make sure mcs works from the command line) *** Read INSTALL.txt for information on how to bootstrap a Mono installation. make[5]: *** [do-profile-check] Error 1 make[5]: Leaving directory `/home/veragoo/mono/mcs' make[4]: *** [profile-do--basic--all] Error 2 make[4]: Leaving directory `/home/veragoo/mono/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/home/veragoo/mono/mcs' make[2]: *** [all-local] Error 1 make[2]: Leaving directory `/home/veragoo/mono/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/veragoo/mono/mono' make: *** [all] Error 2 END ERROR-- -- Cheers, Kevin ( http://www. ) Copyright 2005 Kevin Parama Veragoo. Verbatim copying and distribution of this entire article are permitted worldwide without royalty in any medium provided this notice is preserved. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] COM Interop, or something like it
On Thu, 2005-08-25 at 16:27 -0400, Ring, Kevin wrote: In Microsoft’s implementation of .NET, it is possible to expose a class written in C# via a COM interface. This makes it possible (perhaps even easy!) to instantiate C# objects and call methods on them from, say, a native C++ application. Does Mono have a capability like this? Yes. Mono provides an embedding API which allows an unmanaged application to create and use managed objects: http://www.mono-project.com/Embedding_Mono This isn't terribly ideal, as it's a string-based API. There is a program called cilc which will take a managed class and generate a bunch of C wrappers for each method exposed by the class. This makes it easy to use a managed class from C (and thus C++, if not perfectly from C++). http://lists.ximian.com/pipermail/mono-list/2003-April/013529.html I’d just like an easy way to instantiate managed objects and interact with them from a native C++ application. I know I can embed Mono, and call methods that way, but it seems very cumbersome compared to COM interop. Is there a better way? Let cilc handle the cumbersome unmanaged-managed invocation layer. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mcs default encoding: Latin1 or not
Hi, If you don't like ISO 28591 because it's foreign, why do you want to use ASCII in source files?:) Well, ASCII is not foreign for Japanese. All of iso-2022-jp / shift_jis / euc-jp don't contradict ASCII and it is actually part of those encodings. I know there used to be non-ASCII based encodings such as Indian ISSCII-7, Arabic ASMO 449, Banguradesh BDS 1520:1995 etc. but I don't know any modern encoding that contradicts ASCII (I don't think it is possible to publish world-ready applications with those encodings). So AFAIK ASCII is safe, the GCM for us. Latin1 is not the case. I personally hate the fact of having code pages but this has historical reasons. I think UTF-8 is a good solution as it is international, culture-neutral and ASCII compatible. I think we are living in the age of Unicode. So there is no reason to use ASCII. It's OK to use only ASCII in identifiers and use English in comments and texts but I don't think we shouldn't take advantage of Unicode. We can use it for names for example. Can we edit UTF8 files on vim on cygwin? No. This fact simply tells that we are not living in the age of Unicode. I heard a story - there was a Japanese or Chinesee who used Chinese character in his (or her) blog which are aggregated in somewhere (I don't remember the details) and that person got blamed of using Chinese, even though it is written in utf-8 encoding. I think mcs should use Encoding.Default as default encoding as I think this is nearest to the user's need and provides compatiblity with csc.exe. But we should use UTF-8 without signature (BOM) for our .cs source code files and explicitly specify for mcs to use UTF-8. Why? I think we *should* use BOM as we discussed before that mcs (nor csc) does not autodetect encoding correctly. Here I guess that you think BOM-less UTF8 sources could be edited in Latin1 editors. What happens if I put CJK ideographs? Actually we all (really all) Japanese hackers said that they feel reluctant to edit those files that contain Latin1 letters, because our usual editors does not support Latin1 (even as a candidate of encodings to save file). Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
