[Mono-dev] Crash with sgen on x86_64-apple-darwin
I've been experimenting with running Mono built for x86_64 on OS X. I've been
largely successful using Boehm GC, but today I tried running an app with
—gc=sgen, and I got an immediate crash (if there's output early in the program,
I may get a line or two), even with the simplest programs.
My arguments to autogen.sh looked something like this:
./autogen.sh --with-xen_opt=no --prefix=$MONO_INSTALL_DIRECTORY
--with-mcs-docs=no --disable-nls --build=x86_64-apple-darwin
And my super-simple C# program looks like this:
using System;
internal static class Program
{
private static void Main()
{
Console.WriteLine(hi);
}
}
Can anyone else replicate my result? Does anyone have an idea for a fix?
— Dave
P.S. - Here's the stacktrace I get:
Stacktrace:
Native stacktrace:
0 mono-sgen 0x000100081994
mono_handle_native_sigsegv + 276
1 mono-sgen 0x000136ea
mono_sigsegv_signal_handler + 202
2 libSystem.B.dylib 0x7fff826641ba _sigtramp + 26
3 ??? 0x006b 0x0 + 107
4 mono-sgen 0x0001001bc5dd
mono_sgen_suspend_thread + 173
5 mono-sgen 0x0001001bc74d
mono_sgen_thread_handshake + 157
6 mono-sgen 0x000100198f41 stop_world + 273
7 mono-sgen 0x0001001a2e84 mono_gc_collect + 52
8 mono-sgen 0x00010010d14d mono_domain_finalize
+ 77
9 mono-sgen 0x00011a6a mini_cleanup + 42
10 mono-sgen 0x00010005d04d mono_main + 8189
11 mono-sgen 0x00010e04 start + 52
12 ??? 0x0003 0x0 + 3
Debug info from gdb:
Cannot access memory at address 0x0
Attaching to process 43936.
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
0x7fff8260e464 in read ()
2 0x7fff82603db6 in semaphore_wait_trap ()
* 1 com.apple.main-thread 0x7fff8260e464 in read ()
Thread 2 (process 43936):
#0 0x7fff82603db6 in semaphore_wait_trap ()
#1 0x000100203818 in mono_sem_wait (sem=) at mono-semaphore.c:115
#2 0x00010010c362 in finalizer_thread (unused=0x1d03) at gc.c:1073
#3 0x0001001c91fe in start_wrapper_internal [inlined] () at
/Users/dmitchell/External/mono/mono/metadata/threads.c:571
#4 0x0001001c91fe in start_wrapper (data=0x100532830) at threads.c:619
#5 0x0001001f8cc3 in thread_start_routine (args=0x10087abf8) at
wthreads.c:290
#6 0x000100205216 in inner_start_thread (arg=0x1005322d0) at
mono-threads-posix.c:49
#7 0x7fff8263cfd6 in _pthread_start ()
#8 0x7fff8263ce89 in thread_start ()
Thread 1 (process 43936):
#0 0x7fff8260e464 in read ()
#1 0x000100081af2 in mono_handle_native_sigsegv (signal=43936,
ctx=0x7fff5fbfe3f0) at mini-exceptions.c:2256
#2 0x000136ea in mono_sigsegv_signal_handler (_dummy=11,
info=0x7fff5fbfec90, context=0x7fff5fbfecf8) at mini.c:5904
#3 signal handler called
#4 0x0001001fd7f6 in mono_mach_arch_get_tls_value_from_thread
(thread=0x102a01000, key=4294967295) at mach-support-amd64.c:94
#5 0x0001001bc5dd in mono_sgen_suspend_thread (info=0x102b0) at
sgen-os-mach.c:77
#6 0x0001001bc74d in mono_sgen_thread_handshake (suspend=1606414816) at
sgen-os-mach.c:127
#7 0x000100198f41 in stop_world () at sgen-gc.c:6133
#8 0x0001001a2e84 in mono_gc_collect (generation=1) at sgen-gc.c:6369
#9 0x00010010d14d in mono_domain_finalize (domain=0x10050a820,
timeout=2000) at gc.c:366
#10 0x00011a6a in print_jit_stats [inlined] () at
/Users/dmitchell/External/mono/mono/mini/mini.c:6702
#11 0x00011a6a in mini_cleanup (domain=0x10050a820) at mini.c:6706
#12 0x00010005d04d in mono_main (argc=1606415312, argv=0x7fff5fbff3d0) at
driver.c:1905
#13 0x00010e04 in start ()
=
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=
Abort trap
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mixed Mode Assemblies
As I understand it, Mono on Windows does support running mixed-mode assemblies. My guess is the primary reason for not supporting it on other platforms has more to do with the hassle of developing a C++/CLI compiler than concerns about cross-platform compatibility. A long time ago, there was a mention on twitter of C++/CLI support being added to Clang (https://twitter.com/#!/atoker/status/5830794151), but I've not seen anything about it since then. Personally, I'd love to see C++/CLI and mixed-mode assembly support, as it would allow us to eliminate a lot of code (our Windows product uses C++/CLI for part of the product, while Mac goes the P/Invoke route with a lot of error-prone code duplication along the way). However, I expect to find myself in the minority on this issue; I'm sure there are many more issues to be addressed that would help a much greater number of Mono users. -- Dave On 7/7/11 8:55 AM, arkain king...@gmail.com wrote: I understand the reasons why the developers chose to leave out support for developing mixed-mode assemblies using mono: the lack of cross-platform compatibility in such assemblies. However, I would argue that such things are not a consideration for those who would choose to develop such assemblies. Consider something. When a developer want's to do mixed-mode development, it's almost invariably because there is some functionality, usually in a platform-specific native library, that the developer want's access to in a .NET language. Likewise, when a developer wants to use P/Invoke, the same logic applies. That also means that the resulting assembly will be of little to no use unless all platforms that the assembly will be used on will have an appropriate version of the same native library available. In either case, it's up to the developer to be aware of such issues. I would no more expect a mixed-mode assembly to work cross platform than I would a native executable. Listing such as the reason to leave out this functionality denies the very reason why it was included in Microsoft's implementation. Without a doubt, every case where I've wanted/needed to use C++.NET has been to create a mixed mode assembly with the intent of creating a clean, optimized .NET interface for some piece of unmanaged code. If P/Invoke and System.Runtime.InteropServices formed a complete solution for importing native functionality into .NET, then I doubt Microsoft would have bothered allowing for mixed-mode assemblies at all. However, there are a great many things that cannot be cleanly handled using P/Invoke when it comes to importing library functionality. One such case I encountered was a library with functions that returned char* containing buffered data if it existed, NULL if no data existed, or -1 on error. With C++.NET, I separated the single return value into a return code and an out parameter, relieving me of the need to convert IntPtr's into 2 different things on the .NET side. I'm not claiming that this couldn't have been done without mixed-mode, but I am saying that the mixed mode-solution was superior. Things become even more interesting when the parameter list of the native function includes either (...) or (va_list). While .NET's params keyword helps, there's often a much more elegant solution that can be devised using mixed-mode code. Put in short, P/Invoke is just fine for importing a few functions every now and again, but when a native library of code needs to be exposed, nothing beats mixed mode using C++.NET. The absence of this functionality from mono is an oversight that most certainly should be corrected. -- View this message in context: http://mono.1490590.n4.nabble.com/Mixed-Mode-Assemblies-tp3651901p3651901. html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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-dev] Possible regression in Mono 2.10.1
So I was playing around in my Terminal today, and I did the following: ws1331:macintosh dmitchell$ /Library/Frameworks/Mono.framework/Versions/Current/bin/mono --version Mono JIT compiler version 2.10.1 (tarball Fri Feb 25 15:56:49 MST 2011) Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com TLS: normal SIGSEGV: normal Notification: Thread + polling Architecture: x86 Disabled: none Misc: debugger softdebug LLVM: yes(2.9svn-mono) GC:Included Boehm (with typed GC) ws1331:macintosh dmitchell$ /Library/Frameworks/Mono.framework/Versions/Current/bin/csharp csharp csharp2 ws1331:macintosh dmitchell$ /Library/Frameworks/Mono.framework/Versions/Current/bin/csharp2 Mono C# Shell, type help; for help Enter statements below. csharp double f = -5.0; csharp f = 0 - f; csharp f; -5 csharp Does anyone think that this might be something of a problem? Perhaps one worthy of another point release? Thanks, — Dave ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Minimal required set to Redistribute Mono
We distribute a subset of Mono in our application bundle. We do a lot of pretty weird stuff (our app is actually a Cocoa/Objective-C application that calls into managed code for much of its logic), and we had to make a custom build of Mono to fix a number of blocking bugs that we discovered along the way. Because of this, we've had to roll our own solution for distribution, which may or may not be similar to how the standard tools do it. We've found that we need the following native libraries: - mono.*.dylib (or mono-2.*.dylib, if using Mono 2.8+) - MonoPosixHelper.*.dylib - gdiplus.*.dylib For managed dependencies, we have a program that starts by doing a reflection-only load of our top-level assemblies. We then recursively walk through the referenced assemblies (doing a reflection-only load on each of them) to generate a full map of the assemblies that might be used by our app. After we have this list, we walk the GAC and stage any dependencies we need. We also add any assemblies that start with I18N. because while they're not directly referenced by any assemblies, some of the mono assemblies will load them at runtime. This sort of static analysis won't catch everything (like the I18N assemblies, mentioned above), but it works pretty well for us. If you'd like more details of how our process works, feel free to e-mail me directly. ‹ Dave On 3/22/11 10:54 PM, vinay_rk vinay.kash...@ironmountain.com wrote: Hi, I' am trying to understand what are the minimal required runtime libraries needed if I need to redistribute Mono with my application. We had the impression initially that we would have installation of Mono Framework as a pre-requisit on end computers (mostly Mac). Now it has been decided to go with the redistribution option. So is it required to package the complete Mono framework installation with our application installer ? I' am interested in finding if there is minimal subset of the complete framework that are enough to get our App running under mono ? Regards -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Minimal-required-set-to-Redistribute-Mon o-tp3398547p3398547.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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-dev] Using Mono.CSharp in a syntax highlighting engine
A couple weeks ago, I started playing around with Mono.CSharp to see if I could get enough information from it to hook it up to a syntax highlighter. In order to do so, I would need to be able to get a mapping of ranges of characters to lexical values (keyword, type name, etc.). After some poking around, I was finally able to get a very limited amount of information (mostly with respect to the namespaces found in a file), but not nearly enough to do what I want. Was this an anticipated use of Mono.CSharp? Does anyone have any pointers for how to use it in this manner? Thanks, — Dave ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] explicit conversion to bool and bool? on XElement
It seems that it's been fixed on a more recent revision. Apologies
-- Dave (on the iPhone)
On Jul 15, 2010, at 3:55 AM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com wrote:
Hello,
I don't see such a problem.
$ cat x.cs
using System;
using System.Xml.Linq;
public class Test
{
public static void Main ()
{
XName n = XName.Get (x);
Console.WriteLine ((bool?) new XElement (n, true));
Console.WriteLine ((bool?) new XElement (n, True));
Console.WriteLine ((bool?) new XElement (n, false));
Console.WriteLine ((bool?) new XElement (n, False));
}
}
$ gmcs x.cs -r:System.Xml.Linq.dll
$ ./x.exe
True
True
False
False
$ mono ./x.exe
True
True
False
False
Atsushi Eno
On 2010/07/15 5:53, David Mitchell wrote:
Currently (or at least as of revision 147679), the explicit conversion to
bool for XElement calls System.Xml.XmlConvert.ToBoolean(), which is case
sensitive. However, Microsoft's implementation of the explicit conversion is
case insensitive.
Attached is a patch that corrects this issue by converting the convent of
the XElement to lower case before sending it to XmlConvert.ToBoolean().
I would very much appreciate it if someone would review/apply this patch (or
fix the issue in some other way).
Thanks!
-- Dave
___
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-dev] explicit conversion to bool and bool? on XElement
Currently (or at least as of revision 147679), the explicit conversion to bool
for XElement calls System.Xml.XmlConvert.ToBoolean(), which is case sensitive.
However, Microsoft's implementation of the explicit conversion is case
insensitive.
Attached is a patch that corrects this issue by converting the convent of the
XElement to lower case before sending it to XmlConvert.ToBoolean().
I would very much appreciate it if someone would review/apply this patch (or
fix the issue in some other way).
Thanks!
-- Dave
Index: mcs/class/System.Xml.Linq/System.Xml.Linq/XElement.cs
===
--- mcs/class/System.Xml.Linq/System.Xml.Linq/XElement.cs (revision
147679)
+++ mcs/class/System.Xml.Linq/System.Xml.Linq/XElement.cs (working copy)
@@ -83,7 +83,7 @@
{
if (element == null)
throw new ArgumentNullException (element);
- return XmlConvert.ToBoolean (element.Value);
+ return XmlConvert.ToBoolean (element.Value.ToLower
(System.Globalization.CultureInfo.InvariantCulture));
}
public static explicit operator bool? (XElement element)
@@ -91,7 +91,7 @@
if (element == null)
return null;
- return element.Value == null ? (bool?) null :
XmlConvert.ToBoolean (element.Value);
+ return element.Value == null ? (bool?) null :
XmlConvert.ToBoolean (element.Value.ToLower
(System.Globalization.CultureInfo.InvariantCulture));
}
public static explicit operator DateTime (XElement element)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for System.ServiceModel.Web (Take 2)
Here¹s another try at fixing the second issue. Tests are included, this time. --Dave syndication.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for System.ServiceModel.Web
Attached is another patch for System.ServiceModel.Web with two simple changes. One is that feed elements in the atom namespace will be recognized as valid feeds (per the Atom spec). The other is that the names/namespaces of syndication element extensions are now properly retrieved and made available. I would appreciate it if someone would review/commit this patch to both the development and 2.6 branches. Thanks! --Dave syndication.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for XmlConvert and System.ServiceModel.Syndication
I would very much appreciate it if someone would review/apply this patch. Apologies for being too lazy to write a test case (the changes are pretty simple). Here¹s what you¹ll find: - Calling XmlConvert.ToDateTimeOffset (all overloads) no longer results in a stack overflow. Moreover, the return value should actually be correct. - Atom10ItemFormatter now uses XmlConvert.ToDateTimeOffset to parse the publish date and last updated time. - Atom10FeedFormatter¹s ReadItem returns real values (specifying a SyndicationItem in the constructor for Atom10ItemFormatter doesn¹t work right now: it eventually gets overwritten with a new value). Thanks! --Dave syndication.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Trivial patch for xbuild
Ankit Jain wrote: Probably we should be checking the guid instead of the file extension? To what guid do you refer? I can find nothing else in the my sln file (generated by Visual Studio) that would tell me what kind of project I'm about to load except the file extension. --Dave -- View this message in context: http://www.nabble.com/Trivial-patch-for-xbuild-tp23512673p23597804.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Trivial patch for xbuild
Does anyone have any feedback on this? Should I be submitting it elsewhere?
--Dave
On 5/12/09 4:39 PM, David Mitchell dmitch...@logos.com wrote:
Below is a small patch for xbuild that causes vcproj files to be ignored.
Unless I'm missing out on some huge secret, vcproj files aren't actually valid
msbuild project files anyway, so ignoring them should do no harm (and will do
a lot of good in the case of solutions that contain both csproj and vcproj
files--provided that the csproj files have no dependencies on the vcproj
files).
I would appreciate it very much if someone would review/apply this patch. It
is blocking my organization's adoption of xbuild as our build tool on
Unix-based systems.
I'm providing this patch under the same license as xbuild itself.
--Dave
Index: SolutionParser.cs
===
--- SolutionParser.cs(revision 134016)
+++ SolutionParser.cs(working copy)
@@ -100,6 +100,12 @@
Match m = projectRegex.Match (line);
while (m.Success) {
+if (m.Groups[3].Value.EndsWith(.vcproj)) {
+// Ignore C++ projects
+m = m.NextMatch ();
+continue;
+}
+
ProjectInfo projectInfo = new ProjectInfo (m.Groups[2].Value,
m.Groups[3].Value);
if (String.Compare (m.Groups [1].Value, solutionFolderGuid,
StringComparison.InvariantCultureIgnoreCase) == 0) {
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Trivial patch for xbuild
Below is a small patch for xbuild that causes vcproj files to be ignored.
Unless I'm missing out on some huge secret, vcproj files aren't actually
valid msbuild project files anyway, so ignoring them should do no harm (and
will do a lot of good in the case of solutions that contain both csproj and
vcproj files--provided that the csproj files have no dependencies on the
vcproj files).
I would appreciate it very much if someone would review/apply this patch. It
is blocking my organization's adoption of xbuild as our build tool on
Unix-based systems.
I'm providing this patch under the same license as xbuild itself.
--Dave
Index: SolutionParser.cs
===
--- SolutionParser.cs(revision 134016)
+++ SolutionParser.cs(working copy)
@@ -100,6 +100,12 @@
Match m = projectRegex.Match (line);
while (m.Success) {
+if (m.Groups[3].Value.EndsWith(.vcproj)) {
+// Ignore C++ projects
+m = m.NextMatch ();
+continue;
+}
+
ProjectInfo projectInfo = new ProjectInfo
(m.Groups[2].Value, m.Groups[3].Value);
if (String.Compare (m.Groups [1].Value, solutionFolderGuid,
StringComparison.InvariantCultureIgnoreCase) == 0)
{
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedded: storing extra data on objects?
Robert Jordan wrote: David Mitchell wrote: When embedding mono, is there a way to store a little bit of extra information (pointer-sized) along with a MonoObject (or similar structure)? My scenario is that I have unmanaged wrappers for managed objects, and I¹d like to ensure that there is never more than one unmanaged wrapper per object (and also be able to get the unmanaged wrapper if all I have is the object). I¹m sure I know that I could use a hash table for this, and that may end up being what I do, but actually storing the pointer on the MonoObject seems more natural, in my case. I wonder why your wrapper must have 1:1 relationship with the object it wraps. I'm working on a bridging scenario between Objective C and Mono that is not addressed by existing solutions. Supposing you really need this 1:1 relationship, how do you handle the liveness of the wrapper? If there is only one pointer to its instance, it will go away together with the MonoObject when the latter gets garbage collected, so you won't be able to free it. The wrapper has an unpinned gchandle to the object, so the MonoObject won't be garbage collected until I release the wrapper--whose lifetime is handled by Objective C code. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- View this message in context: http://www.nabble.com/Embedded%3A-storing-extra-data-on-objects--tp22787556p22805218.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Embedded: storing extra data on objects?
When embedding mono, is there a way to store a little bit of extra information (pointer-sized) along with a MonoObject (or similar structure)? My scenario is that I have unmanaged wrappers for managed objects, and I¹d like to ensure that there is never more than one unmanaged wrapper per object (and also be able to get the unmanaged wrapper if all I have is the object). I¹m sure I know that I could use a hash table for this, and that may end up being what I do, but actually storing the pointer on the MonoObject seems more natural, in my case. A related question: if this isn¹t possible, would a patch to facilitate scenarios like mine be welcomed, or is it something that the community is thoroughly disinterested in? --Dave ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedded: storing extra data on objects?
I need to interact with classes in third party libraries, so fields are out--unless there's a way to modify classes as they're loaded... --Dave (on the iPhone) On Mar 30, 2009, at 7:02 PM, BGB cr88...@hotmail.com wrote: - Original Message - From: David Mitchell To: mono-devel-list@lists.ximian.com Sent: Tuesday, March 31, 2009 2:49 AM Subject: [Mono-dev] Embedded: storing extra data on objects? When embedding mono, is there a way to store a little bit of extra information (pointer-sized) along with a MonoObject (or similar structure)? My scenario is that I have unmanaged wrappers for managed objects, and I’d like to ensure that there is never more than one unmanaged w rapper per object (and also be able to get the unmanaged wrapper if all I have is the object). I’m sure I know that I could use a hash t able for this,and that may end up being what I do, but actually storing the pointer on the MonoObject seems more natural, in my case. A related question: if this isn’t possible, would a patch to facilit ate scenarios like mine be welcomed, or is it something that the com munity is thoroughly disinterested in? --Dave beyond a hash table, have you also considered whether it would make sense to put the pointer in an ordinary field (or slot/member/...), and then retrieve the value from the field as needed?... (sorry, I am no expert on mono's internals, so I don't know how reasonable this is either...). ___ 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] inherited event
The reason that you cannot called inherited events is because the
syntax you use for OnBar is really syntactic sugar for something like this:
protected event OnBar
{
add { _onBar = Delegate.Combine(_onBar, value); }
remove { _onBar = Delegate.Remove(_onBar, value); }
}
private EventHandler _onBar;
Once you expand this, it¹s easy to see that you can¹t call _onBar in child
classes because it¹s private. In most cases, this really does make sense,
but if you want different behavior, you can either explicitly define OnBar
in this way and make _onBar protected (or whatever), or you can provide a
protected method (RaiseBar?) that raises the event if OnBar is not null.
--Dave
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.4 Preview 3...
Here's another: http://bugzilla.novell.com/show_bug.cgi?id=478313 Thanks, --Dave Thomas Wiest wrote: Hey Everyone, We've just released Mono 2.4 Preview 3 today! Please help us out by giving it a try with your applications. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.4 here: https://bugzilla.novell.com/buglist.cgi?query_format=advancedclassification=Monotarget_milestone=2.4.xorder=bugs.bug_status%2Cbugs.bug_severity The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you add [Regression] to the beginning of the summary of the bug, then it is much more likely your bug will get fixed. Please help the Mono team to make 2.4 the best ever. Thanks! Mono QA ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- View this message in context: http://www.nabble.com/Announcing-Mono-2.4-Preview-3...-tp22067791p22126038.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Cannot build from fresh svn checkout (patch to fix it attached)
I would greatly appreciate if someone would review/apply this patch. Earlier today, it seems that someone added a call to GetType() in System.Web.UI.TemplateControl.ReadStringResource(). However, ReadStringResource is static if the NET_2_0 symbol is not defined, making GetType() unavailableand thus preventing a fresh svn checkout from compiling. The attached patch fixes that issue. --Dave patch.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for Bug #477447
Attached is a patch for https://bugzilla.novell.com/show_bug.cgi?id=477447. Would someone mind reviewing/applying it? I would attach the patch to the bug itself, but I can¹t access Novell¹s Bugzilla right now. Here¹s the text that I would have added as a comment: I am still unable to create a concise test case that exposes this bug, but I have supplied a patch that fixes the issue. It seems that, in certain cases, an AnonymousMethodStorey used by an anonymous delegate may not always be available in the AnonymousMethodStorey associated with that delegate. The attached patch detects this situation and attempts to compose an expression that accesses the desired AnonymousMethodStorey indirectly. I know that it may be a tough sell to get code committed for which no test case can be supplied, but a review of my patch should reveal that the only code paths affected are those in which the compiler would have crashed, anyway, so there shouldn't be much danger in applying it. bug477447.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for Bugzilla bug #475860
Attached is a patch to address http://bugzilla.novell.com/show_bug.cgi?id=475860. I would appreciate it if someone would review/commit it (it¹s also attached directly to the bug). I determined that the error was occurring because child classes were being defined in the compiler before their base classes (this, in turn, was happening because the base class referred to the child classes in generic parameters to the interfaces it implemented). Because of this, the HashTable that keeps track of method overrides was not being appropriately populated, and method overload resolution would fail in certain cases. The attached patch ensures that no MemberCache (which is responsible for populating the HashTable) is created for a class before its parent class has been defined. It not only works for the test case attached to the bug, but also for a much larger internal project with a pretty comprehensive test suite. --Dave bug475860.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.4 Preview 3...
I just found this one: http://bugzilla.novell.com/show_bug.cgi?id=477378 Thanks, --Dave Thomas Wiest wrote: Hey Everyone, We've just released Mono 2.4 Preview 3 today! Please help us out by giving it a try with your applications. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.4 here: https://bugzilla.novell.com/buglist.cgi?query_format=advancedclassification=Monotarget_milestone=2.4.xorder=bugs.bug_status%2Cbugs.bug_severity The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you add [Regression] to the beginning of the summary of the bug, then it is much more likely your bug will get fixed. Please help the Mono team to make 2.4 the best ever. Thanks! Mono QA ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- View this message in context: http://www.nabble.com/Announcing-Mono-2.4-Preview-3...-tp22067791p22085761.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.4 Preview 3...
I found this one today: https://bugzilla.novell.com/show_bug.cgi?id=476811 --Dave Thomas Wiest wrote: Hey Everyone, We've just released Mono 2.4 Preview 3 today! Please help us out by giving it a try with your applications. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.4 here: https://bugzilla.novell.com/buglist.cgi?query_format=advancedclassification=Monotarget_milestone=2.4.xorder=bugs.bug_status%2Cbugs.bug_severity The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you add [Regression] to the beginning of the summary of the bug, then it is much more likely your bug will get fixed. Please help the Mono team to make 2.4 the best ever. Thanks! Mono QA ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- View this message in context: http://www.nabble.com/Announcing-Mono-2.4-Preview-3...-tp22067791p22068575.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Bugzilla Bug 475860, or, the wrong patch for the right job
I'm investigating http://bugzilla.novell.com/show_bug.cgi?id=475860; I've
come up with a patch that addresses the issue, but I'm certain that it's the
wrong way to solve the problem. Here's the patch:
---
Index: ecore.cs
===
--- ecore.cs(revision 126868)
+++ ecore.cs(working copy)
@@ -4027,6 +4027,12 @@
Methods [j++] = m;
}
nmethods = j;
+
+ if (nmethods == 0 candidate_overrides !=
null) {
+ foreach (MethodBase m in
candidate_overrides)
+ Methods [j++] = m;
+ nmethods = j;
+ }
}
//
@@ -4291,11 +4297,11 @@
// If the method is a virtual function, pick an
override closer to the
LHS type.
//
if (!IsBase best_candidate.IsVirtual) {
- if (TypeManager.IsOverride (best_candidate))
+/* if (TypeManager.IsOverride (best_candidate))
throw new InternalErrorException (
- Should not happen. An
'override' method took part in overload
resolution: + best_candidate);
+ Should not happen. An
'override' method took part in overload
resolution: + best_candidate);*/
- if (candidate_overrides != null) {
+ if (!TypeManager.IsOverride (best_candidate)
candidate_overrides !=
null) {
Type[] gen_args = null;
bool gen_override = false;
if (TypeManager.IsGenericMethod
(best_candidate))
---
The reason that the code listed in the Bugzilla bug fails to compile is that
at the time of overload resolution, the method table for the family of
Reference classes has not been completely initialized. Because of this, when
TypeManager.TryGetBaseDefinition is called, it fails, and no candidates are
added to the list of method overloads.
The patch included above addresses this problem by allowing overrides to be
added to the list of candidates if no other candidates have been found.
While this allows the example code to compile and even produces correct
results at runtime, I'm pretty sure that the most appropriate way to solve
this problem would be to instead make sure that the method table is
appropriately populated before we even get to this code (also, a comparison
of the IL produced by gmcs and the IL produced by csc reveals that csc
produces virtual calls to Reference::CompareTo(), while gmcs produces
virtual calls to ReferencePoint::CompareTo() and
ReferenceRange::CompareTo()).
I'm afraid that fixing this bug will require a deeper knowledge of the
compiler than I currently possess. Can anyone suggest a more appropriate way
of solving this problem?
--Dave
PS-I've extended the example code attached to the Bugzilla a bit to improve
my ability to test it. Here's a copy of my current version (which can be
compiled/run as a program):
using System;
namespace MonoBug
{
public abstract class Reference :
IEquatableReference,
IComparableReference,
IComparableReferencePoint,
IComparableReferenceRange
{
public abstract bool Equals(Reference other);
public int CompareTo(Reference other)
{
if (other == null)
return 1;
var otherRange = other as ReferenceRange;
if (otherRange != null)
return CompareTo(otherRange);
else
return CompareTo((ReferencePoint)other);
}
public abstract int CompareTo(ReferencePoint other);
public abstract int CompareTo(ReferenceRange other);
}
public class ReferencePoint : Reference, IEquatableReferencePoint
{
public ReferencePoint(int value)
{
_value = value;
}
public override bool Equals(Reference other)
{
return Equals(other as ReferencePoint);
}
public bool Equals(ReferencePoint other)
{
if (other == null)
return false;
return _value == other._value;
}
public override int CompareTo(ReferencePoint
[Mono-dev] Trouble running subversion builds in OSX
I've been trying to build/run a copy of Mono from Subversion so that I can
test how some recent fixes, but the version that I've built is now crashing
hard in unrelated areas.
I'm using a Mac Pro running OS X 10.5.5, and I've reverted to revision
122917 (tagged as mono-2-2), so the code I'm running should be largely the
same as the packaged release. I'm trying to run tests for Wintellect's
PowerCollections (available at http://www.codeplex.com/PowerCollections)
using version 2.4 of MbUnit (available at
http://code.google.com/p/mb-unit/downloads/list).
If I use my packaged version of Mono, running MbUnit as follows:
mono /path/to/MbUnit.Cons.exe /v
/ft:Wintellect.PowerCollections.Tests.ListBaseTests UnitTests.exe
works just fine (32 tests, 32 successes, assuming that
QuickGraph.Algorithms.dll, QuickGraph.dll, TestFu.dll, and
MbUnit.Framework.dll are all available). However, if I run it in the copy
that I built, this is my output:
---
Parsed arguments:
-- Parsed Arguments
Files:
UnitTests.exe
Assembly paths:
Report folder:
Report Name Format: mbunit-{0}{1}
Report types:
Show reports: False
Filter Category:
Exclude Category:
Filter Author:
Filter Namespace:
Filter Type: Wintellect.PowerCollections.Tests.ListBaseTests
Verbose: True
ShadowCopyFiles: False
Start time: 11:06 AM
[info] Loading test assemblies
[info] Starting execution
[info] Sorting assemblies by dependencies
[info] Setting up fixture colors
[info] Loading UnitTests
[info] Found 32 tests
[info] Running fixtures.
[success] ListBaseTests.ReadOnlyListBase
[success] ListBaseTests.ReadWriteListBase
**
ERROR:mini-exceptions.c:770:get_exception_catch_class: assertion failed:
(mono_class_has_parent_and_ignore_generics (class, method_container_class))
Stacktrace:
at (wrapper managed-to-native) System.Threading.Thread.Join_internal
(int,intptr) 0x4
at (wrapper managed-to-native) System.Threading.Thread.Join_internal
(int,intptr) 0x
at System.Threading.Thread.Join (System.TimeSpan) 0x00052
at MbUnit.Core.Remoting.FixtureRunnerBase.RunFixture (MbUnit.Core.Fixture)
0x00146
at MbUnit.Core.Remoting.DependencyFixtureRunner.RunFixtures () 0x00303
at MbUnit.Core.Remoting.FixtureRunnerBase.Run
(MbUnit.Core.Remoting.FixtureExplorer,MbUnit.Core.Reports.Serialization.ReportListener)
0x000e0
at MbUnit.Core.Remoting.RemoteTestEngine.RunPipes () 0x000a1
at (wrapper runtime-invoke) object.runtime_invoke_void__this__
(object,intptr,intptr,intptr) 0x
at (wrapper managed-to-native)
System.Runtime.Remoting.RemotingServices.InternalExecute
(System.Reflection.MethodBase,object,object[],object[]) 0x4
at (wrapper managed-to-native)
System.Runtime.Remoting.RemotingServices.InternalExecute
(System.Reflection.MethodBase,object,object[],object[]) 0x
at System.Runtime.Remoting.RemotingServices.InternalExecuteMessage
(System.MarshalByRefObject,System.Runtime.Remoting.Messaging.IMethodCallMessage)
0x001ae
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage
(System.Runtime.Remoting.Messaging.IMessage) 0x000c6
at
System.Runtime.Remoting.Messaging.ServerObjectTerminatorSink.SyncProcessMessage
(System.Runtime.Remoting.Messaging.IMessage) 0x00060
at System.Runtime.Remoting.Lifetime.LeaseSink.SyncProcessMessage
(System.Runtime.Remoting.Messaging.IMessage) 0x0002d
at
System.Runtime.Remoting.ClientActivatedIdentity.SyncObjectProcessMessage
(System.Runtime.Remoting.Messaging.IMessage) 0x00073
at
System.Runtime.Remoting.Messaging.ServerContextTerminatorSink.SyncProcessMessage
(System.Runtime.Remoting.Messaging.IMessage) 0x00153
at System.Runtime.Remoting.Contexts.CrossContextChannel.SyncProcessMessage
(System.Runtime.Remoting.Messaging.IMessage) 0x000c4
at System.Runtime.Remoting.Channels.ChannelServices.SyncDispatchMessage
(System.Runtime.Remoting.Messaging.IMessage) 0x0003d
at System.AppDomain.ProcessMessageInDomain
(byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[],System.Runtime.Remoting.Messaging.CADMethodReturnMessage)
0x00076
at (wrapper remoting-invoke-with-check)
System.AppDomain.ProcessMessageInDomain
(byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[],System.Runtime.Remoting.Messaging.CADMethodReturnMessage)
0x
at
System.Runtime.Remoting.Channels.CrossAppDomainSink.ProcessMessageInDomain
(byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage) 0x00050
at (wrapper runtime-invoke)
object.runtime_invoke_CrossAppDomainSink/ProcessMessageRes_object_object
(object,intptr,intptr,intptr) 0x
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke
(object,object[],System.Exception) 0x4
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke
(object,object[],System.Exception) 0x
at System.AppDomain.InvokeInDomainByID
(int,System.Reflection.MethodInfo,object,object[]) 0x00069
at System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage
Re: [Mono-dev] XmlWriter.WriteAttributeString incompatible with MS implementation
Currently, when I go to http://bugzilla.novell.com, I get a 504 error. When
that clears up, I'll be happy to file an official bug, but until then,
here's a snippet of code:
using System;
using System.IO;
using System.Xml;
namespace FunWithXmlAttributes
{
class MainClass
{
public static void Main(string[] args)
{
using (StringWriter writerString = new StringWriter())
{
using (XmlWriter writerXml =
XmlWriter.Create(writerString, new
XmlWriterSettings { Indent = false,
CloseOutput = false, OmitXmlDeclaration
= true }))
{
writerXml.WriteStartElement(root);
writerXml.WriteAttributeString(xmlns,
abc, null,
uri:abcnamespace);
writerXml.WriteAttributeString(abc,
def, null, value);
writerXml.WriteEndElement();
}
Console.WriteLine(writerString.ToString());
}
}
}
}
On Windows (with the MS implementation), the output is this:
root xmlns:abc=uri:abcnamespace abc:def=value /
While in OSX, I get this exception:
Unhandled Exception: System.ArgumentException: Namespace URI must not be
null when prefix is not an empty string.
at System.Xml.XmlTextWriter.WriteStartAttribute (System.String prefix,
System.String localName, System.String namespaceUri) [0x00272] in
/private/tmp/monobuild/build/BUILD/mono-2.2/mcs/class/System.XML/System.Xml/XmlTextWriter2.cs:886
at System.Xml.XmlWriter.WriteAttributeString (System.String prefix,
System.String localName, System.String ns, System.String value) [0x0] in
/private/tmp/monobuild/build/BUILD/mono-2.2/mcs/class/System.XML/System.Xml/XmlWriter.cs:243
at FunWithXmlAttributes.MainClass.Main (System.String[] args) [0x0004a] in
/Users/dmitchell/Projects/FunWithXmlAttributes/FunWithXmlAttributes/Main.cs:18
Thanks,
--Dave
Atsushi Eno wrote:
Hello,
If you file a bug on our bugzilla, I might fix the implementation
difference, depending on the repro, without the patch you have.
http://bugzilla.novell.com
Atsushi Eno
David Mitchell wrote:
I'm currently trying to port the back-end of a very large project over to
OSX
from Windows, and I've encountered a rather vexing incompatibility
between
Mono and Microsoft's implementation of .NET.
The documentation for XmlWriter.WriteAttributeString(string prefix,
string
localName, string ns, string value) seems to indicate that if a prefix is
provided and a namespace is not, that the method may throw an
ArgumentException, and this is what Mono does. However, Microsoft's
implementation allows this scenario if the given prefix has already been
associated with a namespace.
This wouldn't be a terribly big deal, except that the XmlWriter provides
no
way to determine the namespace associated with a prefix, and we have many
cases in which we only have a prefix to work with. Is there any chance of
getting this behavior modified to conform to Microsoft's implementation?
I'd
submit a patch myself, but as I was investigating this issue with a
coworker, he opened up the relevant classes in Reflector, so I'm
tainted...
Thanks,
--Dave
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
View this message in context:
http://www.nabble.com/XmlWriter.WriteAttributeString-incompatible-with-MS-implementation-tp21815568p21834689.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] XmlWriter.WriteAttributeString incompatible with MS implementation
I'm currently trying to port the back-end of a very large project over to OSX from Windows, and I've encountered a rather vexing incompatibility between Mono and Microsoft's implementation of .NET. The documentation for XmlWriter.WriteAttributeString(string prefix, string localName, string ns, string value) seems to indicate that if a prefix is provided and a namespace is not, that the method may throw an ArgumentException, and this is what Mono does. However, Microsoft's implementation allows this scenario if the given prefix has already been associated with a namespace. This wouldn't be a terribly big deal, except that the XmlWriter provides no way to determine the namespace associated with a prefix, and we have many cases in which we only have a prefix to work with. Is there any chance of getting this behavior modified to conform to Microsoft's implementation? I'd submit a patch myself, but as I was investigating this issue with a coworker, he opened up the relevant classes in Reflector, so I'm tainted... Thanks, --Dave -- View this message in context: http://www.nabble.com/XmlWriter.WriteAttributeString-incompatible-with-MS-implementation-tp21815568p21815568.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Bug in (and patch for) UTF32Encoding.GetBytes()
I discovered today that UTF32Encoding.GetByteCount() will report the wrong result anytime that the start index is nonzero. Attached is a patch to fix the issue. Would someone mind reviewing/committing it? Thanks, --Dave UTF32Encoding.patch Description: UTF32Encoding.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Failing tests on Mac OS
According to http://mono.ximian.com/monobuild, the runtime tests on Mac OS for the PowerPC have been timing out for quite some time, and the same tests on Mac OS for Intel have been outright failing. I have access to both of these platforms, and I've been considering trying to track down the source of these problems. So far, I've only been building Mono on Intel, and aside from the name of the test that is failing (handleref), I don't know too much about it, other than the fact that some sort of signal is being triggered. Does anyone know more about this, or am I pretty much on my own? Also, this is sort of a noob question, but is there any way to either hook into Monobuild or into the Subversion repository so that I can trigger a build on my own machines when things are updated? My development work tends to expose a number of bugs in Mono, and I don't always have the time to track them down (although I do most of the time). It would be nice if continuous integration process that I'll be setting up over the next few days (I finally have something to continuously integrate!) could also check to see if bugs had been fixed in the main repository. --Dave ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Generic type naming
You're right...there's no difference in the implementation for the names of
Generic types. The weirdness in the type name that I was seeing comes from
using the fancy new 'yield return' syntax that was introduced in C# 2.0.
To illustrate, try this block of code in Mono and on .NET:
--
using System;
using System.Collections.Generic;
using System.Collections;
namespace MonoBug
{
public class ListBug
{
public static IEnumerableT EnumerableFromArrayT(T[]
array)
{
foreach (T t in array)
yield return t;
}
public static IEnumerableint IntEnumerableFromArray(int[]
array)
{
foreach (int i in array)
yield return i;
}
public static void Main()
{
Console.WriteLine(EnumerableFromArray(new int[] { 1,
2, 3 }).GetType());
Console.WriteLine(IntEnumerableFromArray(new int[] {
1, 2, 3 }).GetType());
}
}
}
--
You'll get different results on each platform, although I'm not entirely
certain if the naming convention is part of the C# spec or not. I'm looking
into this because I'm trying to get all of the Wintellect.PowerCollections
tests to succeed in Mono (http://www.wintellect.com/PowerCollections.aspx).
If you download it right now, four of the tests will fail, and the first one
does so because the test makes assumptions about the type name.
--Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Jordan
Sent: Monday, March 05, 2007 11:26 PM
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Generic type naming
David Mitchell wrote:
My apologies if I am dredging up an issue that has already been resolved
and
put to rest, but my curiosity compels me to do so.
I have noticed that Mono's algorithms for providing names to specific
generic types is significantly different to that of Microsoft's
implementation of .Net. Where Microsoft's implementation usually has lots
of
fancy angle brackets and full type listings of the arguments, Mono often
has
weird accent marks and numbers.
Like Mono, MS uses the accent marks as well. For example,
Dictionary`2[K, T] denotes the non-instantiated generic type
DictionaryK, T (C# notation), whereas Dictionary`2[[String, Int32]]
is an instantiated Dictionarystring, int (C# notation).
When full names are requested, the type names become ever weirder:
System.Collections.Generic.Dictionary`2
[
[
System.String, mscorlib,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089
],
[
System.Int32, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089
]
]
Is this difference between the two implementations the result of an
architectural decision, developer laziness (hey, the best developers are
all
a bit lazy, right?), or of something in between the two extremes?
There should be no differences. Please file bugs if you find some.
Robert
___
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-dev] (More) Bugzilla bugs with patches
So.I've been kind of busy, and consequently, I've made patches for the following three bugs: http://bugzilla.ximian.com/show_bug.cgi?id=81046 http://bugzilla.ximian.com/show_bug.cgi?id=81047 http://bugzilla.ximian.com/show_bug.cgi?id=81048 All three of these are very minor patches related to the kinds of exceptions that ListT can throw when it is accessed through the IList interface. I'd appreciate it if someone could review/apply them. --Dave ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Regression of bug 80260?
I just did a Subversion get and attempted to build a project that used to be affected by this bug: http://bugzilla.ximian.com/show_bug.cgi?id=80260 Yesterday, the patch to fix it was applied, and everything worked fine. However, after my most recent update, it is broken again. Does anyone know about why this may have changed? --Dave ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Bugzilla bugs needing attention
I would like to direct your attention to the following Bugzilla bugs that require attention from someone. Patches exist to fix all of these, but I do not have write access to SVN, so I cannot apply them, myself. http://bugzilla.ximian.com/show_bug.cgi?id=80260 http://bugzilla.ximian.com/show_bug.cgi?id=80928 http://bugzilla.ximian.com/show_bug.cgi?id=80929 http://bugzilla.ximian.com/show_bug.cgi?id=80904 http://bugzilla.ximian.com/show_bug.cgi?id=80930 http://bugzilla.ximian.com/show_bug.cgi?id=81025 The first bug in this list is over a month old, and no one has even so much as added a comment to the bug since I attached the patch. Is there anything that can be done to speed up this process a bit? I understand the need for quality control and whatnot, but I fear that a number of people who are new to the project may become discouraged if they submit patches like this and then do not receive a response. --Dave ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Generic type naming
My apologies if I am dredging up an issue that has already been resolved and put to rest, but my curiosity compels me to do so. I have noticed that Mono's algorithms for providing names to specific generic types is significantly different to that of Microsoft's implementation of .Net. Where Microsoft's implementation usually has lots of fancy angle brackets and full type listings of the arguments, Mono often has weird accent marks and numbers. Is this difference between the two implementations the result of an architectural decision, developer laziness (hey, the best developers are all a bit lazy, right?), or of something in between the two extremes? Thanks, --Dave ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] mono SDL linux/win32 SDL.DLL - my brain hurts!
Oh, and you'll also want to make sure SDL (http://www.libsdl.org) is installed on your machine. David David Mitchell wrote: Try this: http://prdownloads.sourceforge.net/cs-sdl/SdlDotNet-3.1.2-1.zip?download Looks like the latest linux version to me. David ted leslie wrote: (After my preamble, I am essentially asking .. how does a wrapper to .Net/Mono work .) There must not be to many people writting cross platform apps that need sound? Searching for sound (audio, mp3, sound) on mono-project.com via mail list, etc returns almost nothing. Anyways I came across SDL on the Resources page wow!!! this will solve my problems! I go to cs-sdl.sourceforge.net and check it out, It has SDL.NET for Win32 and Linux (mono is supported, it says) So i download the support libraries for SDL.NET which are the traditional SDL libs .. put them on Win32 and updated my ones on my Suse box. I ran the Examples just fine on Win32 Now on to Linux and Mono ... First off the latest SDL.NET downloads on sourceforge seem to be for Win32 only (as an aside they have a nice installer that does everything for you on the Win32 side of things) So i dig back a COUPLE years and get a gz file (of SDL.NET) that has linux support (incidently i see screen caps in SDL.NET project page of SDL apps running on linux so even thought the linux support in the project seems old, it infact looks like it run and works) I build the SDL.NET on Linux (using latest stable release Mono), but there is an error in the Makefile, the pathing slash is of the windows variety (hm...?), so i fix that and Makefile the SDL.NET DLL's and the examples. The Examples compile/build fine but the give a Mono runtime error that they can't find System DLL:SDL.dll --An exception was thrown by the type initializer for SdlDotNet.Music --- System.DllNotFoundException: SDL.dll So this is were I hit a dead end because I don't know anything about .Net/C# wrappers to traditional C based libraries on Linux. I looked at the gtk-sharp wrapper (cause i know it works), I see a mixer of C and CS files and traditional gcc references in makefiles, but basically it looks like a big job to figure out gtk-sharp's process of a wrapper. On that note, is there a doucmentation section somewhere on that - i.e. building wrappers? To me, I am thinking in the end SDL.NET has to get hold of the routines in the SDL .so file right? how does that happen? I know how it happens in a traditional C/gcc compile, link, create a .so file, and compile your apps with dynamic support againt the .so what bit of magic get Mono to see/do that (with its wrapper)? I check around the SDL.NET code and see in the Natives.cs file this: const string SDL_DLL = SDL; const string MIX_DLL = SDL_mixer; // General [DllImport(SDL_DLL, CallingConvention=CallingConvention.Cdecl), SuppressUnmanagedCodeSecurity] public static extern int SDL_Init(int flags); which I am thinking is pretty key to the process ... but why reference SDL.DLL ... I don't have that on Linux, thats on Win32. Anyone shed light? Also, would it be a hard job making the same wrapper to the SDL lib on MAC-OSX to complete a good cross-platfrom SDL.NET class for Mono ? -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- David Mitchell Software Engineer Telogis ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
