[Mono-dev] Invitation to Unite11
Hi, Every year Unity has a conference where we bring together employees, customers and friends, for a multiday learning, laughing and dancing event. This year it is held in San Francisco, September 28-29-30. This is an invitation for every contributor to the mono project to attend the conference. I hope some of you will be able to make it. If you want to come, please let me know beforehand, so I can put you on the guestlist. for more info: http://www.unity3d.com/unite Hope to see you there, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] debug embedded mono
On 8/25/10 10:59 PM, Michael Hutchinson wrote: I tried to create a dummy start up C sharp project and call my C sharp code from there. The mono debugger works for the C sharp code, but it does not find the C++ functions that are called from within C sharp. MethodNotImplemented exception is thrown. The mono debugger does not work on C++ and regular debugger cannot access to the Mono code in C sharp. So, any information on how to do it? I often just use MonoDevelop to debug the c# parts, and simultanously attach xcode/visualstudio/gdb to the process to debug the c++ part. You can also use XDebug ( http://www.mono-project.com/Debugging ), if you use gdb on linux, to make gdb smarter about the c# parts. it won't be as good as the monodevelop softdebugger, but at least you get to see the names of the managed methods on the stack. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] reloading mono domain or assemblies
On 8/13/10 4:04 PM, Robert Jordan wrote: Well, it doesn't really matter who's creating the domains and loading the assemblies. It's by far easier to implement this in C# and then mono_runtime_invoke it from C++. Of course, you can invoke everything from C++ but this will likely triplicate the amount of code to be written. Furthermore, the only safe way to create a domain in C++ is mono_runtime_invoke-ing System.AppDomain.CreateDomain(), IIRC. you can use mono_domain_create() and mono_domain_unload() just fine from c. In fact, I suspect it's actually easier to do from native code these days. basically what you should do is: create domain set it active load your assemblies run your code when you want to reload code, unload the domain load your assemblies again run your code. It gets tricky though, as you need to somehow maintain the state of your program. We use custom serialization to remember the state of all objects, tear down everything, load new assemblies, recreate all objects, and reconfigure them the way they were. not an easy task by any means. also make sure you load your assemblies from memory instead of from disk. at least on windows, if you read them from disk, you will not be allowed to overwrite your assemblies with new ones. domain unloading/reloading is a bit of a notorious area, with plenty of memory leaks and bugs. mostly because it is a way to use mono that not that many people seem to be doing. I would say from all the mono related work I do at Unity, about 80% is related to problems relating to domain unloading. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Unite 2010 Invitation
Lovely mono people, Unity will soonish(tm) be launching Unity3, which contains a lot of your work. We're upgrading to Mono2.6 (from mono 1.1.14 no less!), bundling a version of MonoDevelop, as well as supporting the wonderful new soft debugger. This November 10-12 we are organizing another Unite conference in Montreal. ( http://unity3d.com/unite/ ) All mono contributors are invited. If you want to join the fun, shoot me an email, and I'll get you on the guestlist. We also have a call for speakers, should you feel chatty: http://unity3d.com/unite/call-for-speakers Thanks for helping make Unity what it is today. It's very exciting to offer all these new goodies to our customers. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH: fix memory leak in MonoSymbolFile unloading
Hi.
Mono forgets to release the memory of any debug image file that was
loaded from memory. Attach patch fixicates.
Bye, Lucas
Index: debug-mono-symfile.c
===
--- debug-mono-symfile.c(revision 42294)
+++ debug-mono-symfile.c(working copy)
@@ -123,10 +123,11 @@
symfile-raw_contents = p = g_malloc (size);
memcpy (p, raw_contents, size);
symfile-filename = g_strdup_printf (LoadedFromMemory);
+ symfile-was_loaded_from_memory = TRUE;
} else {
MonoFileMap *f;
symfile-filename = g_strdup_printf (%s.mdb,
mono_image_get_filename (handle-image));
-
+ symfile-was_loaded_from_memory = FALSE;
if ((f = mono_file_map_open (symfile-filename))) {
symfile-raw_contents_size = mono_file_map_size (f);
if (symfile-raw_contents_size == 0) {
@@ -165,7 +166,12 @@
g_hash_table_destroy (symfile-method_hash);
if (symfile-raw_contents)
- mono_file_unmap ((gpointer) symfile-raw_contents,
symfile-raw_contents_handle);
+ {
+ if (symfile-was_loaded_from_memory)
+ g_free(symfile-raw_contents);
+ else
+ mono_file_unmap ((gpointer) symfile-raw_contents,
symfile-raw_contents_handle);
+ }
if (symfile-filename)
g_free (symfile-filename);
Index: debug-mono-symfile.h
===
--- debug-mono-symfile.h(revision 42294)
+++ debug-mono-symfile.h(working copy)
@@ -91,6 +91,7 @@
gchar *filename;
GHashTable *method_hash;
MonoSymbolFileOffsetTable *offset_table;
+ gboolean was_loaded_from_memory;
};
#define MONO_SYMBOL_FILE_MAJOR_VERSION 50
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] JIT floating point behaviour change between 2.4.2 and 2.6
Hi,
In our process to upgrade to mono 2.6, we've hit a snag where floating
point behaviour of the JIT is slightly differently. This program prints
PASS on mono2.6, and FAIL on mono2.4, on both osx, and win32.
using System;
public class Test
{
static private float x;
static private float y;
private static void Main()
{
//input
float a = DecodeSingle(0x3070787f);
float b = DecodeSingle(0x48a296ba);
float c = DecodeSingle(0x3ddc0d93);
x = DecodeSingle(0xbfc2f2e5);
y = DecodeSingle(0xbd35e18b);
// test
float abc = (a * b * c);
float s = ((a * b * c) / sqrMagnitude);
//same calculation,just using a temporary variable, which seems to matter
float t = ((abc) / sqrMagnitude);
Console.WriteLine(Test: {0}, ((s == t) ? PASSED :
FAILED));
}
static private float sqrMagnitude
{
get { return ((x * x) + (y * y)); }
}
private static float DecodeSingle(uint value)
{
return
BitConverter.ToSingle(BitConverter.GetBytes(value), 0);
}
}
The good news is that mono2.6 behaviour looks correct, and Mono2.4
behaviour wrong. I would really like to find out which svn revision has
caused this change. We like the new behaviour, but want to temporarily
get the old behaviour back, so we can succesfully run all our
integrationtests, and feel confident that the mono upgrade didn't break
anything. Because of the floating point difference, it's causing a lot
of games in our regression suite to play back completely differently,
which makes it hard to see if something else changed as well, or if the
different playback is purely due to the floating point differences.
I hope one of the JIT guys has a rough guess where this change might
have been introduced, if not I'll start a the big boring svn based
binary search.
Thanks in advance,
Lucas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] softdebugger integration
Hey, With the help of kangaroo, I've gotten a very long way integrating the softdebugger. I can set breakpoints, have our embedded mono break on the breakpoints. I'm stuck now in the situation where embedded mono hits a breakpoint, tells monodevelop about it. Monodevelop then wants information from mono, such as the stacktrace, and later the stacktraces of all threads. Monodevelop asks for this information. Embedded mono sends it back, and at this point monodevelop seems stuck. my debugger log ends with this: [34CC] Sent event TYPE_LOAD, suspend=2. [dbg] Received command TYPE(1), id=1049. [dbg] Received command TYPE(6), id=1050. [34CC] Suspended. [dbg] Received command VM(4), id=1051. [3210] Resuming vm... [34CC] Resumed. [34CC] Breakpoint hit, method=OnEnable, offset=0x12. [34CC] Suspending vm... [34CC] Interrupting 2C2C... [34CC] Interrupting 00DC... [34CC] Sent event BREAKPOINT, suspend=2. [dbg] Received command OBJECT_REF(5), id=1052. [34CC] Suspended. [dbg] Received command OBJECT_REF(1), id=1053. [dbg] Received command VM(2), id=1054. [dbg] Received command OBJECT_REF(5), id=1055. [dbg] Received command OBJECT_REF(1), id=1056. [dbg] Received command THREAD(2), id=1057. [dbg] Received command THREAD(2), id=1058. I singlestepped trough mono to see that those last 7 requests were met, and okay looking response packets were sent to monodevelop. At this point monodevelop just freezes for me. I'm pretty sure it's stuck in the GetBackTrace() method. It's hard to tell though, as I managed to have VisualStudio break all threads and inspect what's going on once, all the other tries visualstudio actually crashes with a gdi+ error (ugh). I'm hoping this gives someone a hunch on what might be the problem. Unfortunattely I can't yet singlestep trough Mono.Debugger.Soft, as I can't really succesfully build the classlibs on windows yet. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch: implement mono_chain_signal for win32
Hey,
Attached is a patch with an implementation for signal chaining on
windows. We use this to make crashes in the mono runtime, or (much more
often :) ), crashes in the Unity host, properly trickle down to our
toplevel excetion filter, which invokes our BugReporter appliaction,
which allows the user to send us the details of the crash.
at a glance, the changes are:
- have mono_chain_signal, call the old toplevel exception filter.
- exception filters (signal handler on win32) actually have a
returntype, so we store the result, and return that result from mono's
toplevel exception handler.
- not pass EXCEPTION_RECORD*, but EXCEPTION_POINTERS*, as that is
required to create a minidump file, which can later on be reconstructed
to a stacktrace if the original .pdb's are still around.
I haven't been able to test the amd64 implementation.
Let me know if something would need to change for this to go into mainline.
Bye, Lucas
Index: exceptions-amd64.c
===
--- exceptions-amd64.c (revision 32648)
+++ exceptions-amd64.c (working copy)
@@ -38,10 +38,12 @@
static MonoW32ExceptionHandler ill_handler;
static MonoW32ExceptionHandler segv_handler;
-static LPTOP_LEVEL_EXCEPTION_FILTER old_handler;
+LPTOP_LEVEL_EXCEPTION_FILTER old_win32_toplevel_exception_filter;
+guint64 win32_chained_exception_filter_result;
+gboolean win32_chained_exception_filter_didrun;
#define W32_SEH_HANDLE_EX(_ex) \
- if (_ex##_handler) _ex##_handler(0, er, sctx)
+ if (_ex##_handler) _ex##_handler(0, ep, sctx)
/*
* Unhandled Exception Filter
@@ -54,6 +56,7 @@
MonoContext* sctx;
LONG res;
+ win32_chained_exception_filter_didrun = FALSE;
res = EXCEPTION_CONTINUE_EXECUTION;
er = ep-ExceptionRecord;
@@ -114,17 +117,20 @@
g_free (sctx);
+ if (win32_chained_exception_filter_didrun)
+ res = win32_chained_exception_filter_result;
+
return res;
}
void win32_seh_init()
{
- old_handler = SetUnhandledExceptionFilter(seh_handler);
+ old_win32_toplevel_exception_filter =
SetUnhandledExceptionFilter(seh_handler);
}
void win32_seh_cleanup()
{
- if (old_handler) SetUnhandledExceptionFilter(old_handler);
+ if (old_win32_toplevel_exception_filter)
SetUnhandledExceptionFilter(old_win32_toplevel_exception_filter);
}
void win32_seh_set_handler(int type, MonoW32ExceptionHandler handler)
Index: exceptions-x86.c
===
--- exceptions-x86.c(revision 32648)
+++ exceptions-x86.c(working copy)
@@ -34,10 +34,12 @@
static MonoW32ExceptionHandler ill_handler;
static MonoW32ExceptionHandler segv_handler;
-static LPTOP_LEVEL_EXCEPTION_FILTER old_handler;
+LPTOP_LEVEL_EXCEPTION_FILTER old_win32_toplevel_exception_filter;
+guint64 win32_chained_exception_filter_result;
+gboolean win32_chained_exception_filter_didrun;
#define W32_SEH_HANDLE_EX(_ex) \
- if (_ex##_handler) _ex##_handler(0, er, sctx)
+ if (_ex##_handler) _ex##_handler(0, ep, sctx)
/*
* mono_win32_get_handle_stackoverflow (void):
@@ -167,6 +169,7 @@
struct sigcontext* sctx;
LONG res;
+ win32_chained_exception_filter_didrun = FALSE;
res = EXCEPTION_CONTINUE_EXECUTION;
er = ep-ExceptionRecord;
@@ -219,6 +222,9 @@
g_free (sctx);
+ if (win32_chained_exception_filter_didrun)
+ res = win32_chained_exception_filter_result;
+
return res;
}
@@ -228,12 +234,12 @@
if (!restore_stack)
restore_stack = mono_win32_get_handle_stackoverflow ();
- old_handler = SetUnhandledExceptionFilter(seh_handler);
+ old_win32_toplevel_exception_filter =
SetUnhandledExceptionFilter(seh_handler);
}
void win32_seh_cleanup()
{
- if (old_handler) SetUnhandledExceptionFilter(old_handler);
+ if (old_win32_toplevel_exception_filter)
SetUnhandledExceptionFilter(old_win32_toplevel_exception_filter);
}
void win32_seh_set_handler(int type, MonoW32ExceptionHandler handler)
Index: mini-windows.c
===
--- mini-windows.c (revision 32648)
+++ mini-windows.c (working copy)
@@ -50,6 +50,10 @@
#include jit-icalls.h
+extern LPTOP_LEVEL_EXCEPTION_FILTER old_win32_toplevel_exception_filter;
+extern guint64 win32_chained_exception_filter_result;
+extern gboolean win32_chained_exception_filter_didrun;
+
void
mono_runtime_install_handlers (void)
{
@@ -67,9 +71,24 @@
win32_seh_cleanup();
}
+
+/* mono_chain_signal:
+ *
+ * Call the original signal handler for the signal given by the arguments,
which
+ * should be the same as for a signal handler. Returns TRUE if the original
handler
+ * was called, false otherwise.
+ */
gboolean
SIG_HANDLER_SIGNATURE (mono_chain_signal)
{
+ int signal = _dummy;
+ GET_CONTEXT;
+
[Mono-dev] monowrap.cs patch
Hey,
The attached patch makes monowrap work on windows machines whose user
has a space in its name. It turns out MSBuild places its responsefile in
the users' temp folder, which almost always will have a space in its
name (C:\Users\Lucas Meijer\Temp).
The patch assumes that when it finds a @ in the compiler arguments,
everything that follows after that is going to be the responsefile, and
inserts quotes so that the real mcs.exe won't trip up over them.
Bye, Lucas
PS Not sure if you need it for simple patches like this, but fwiw, it's
released under MIT-X11 license.
Index: monowrap.cs
===
--- monowrap.cs (revision 148912)
+++ monowrap.cs (working copy)
@@ -115,12 +115,19 @@
}
Environment.SetEnvironmentVariable (MONO_PATH,
sb.ToString ());
+ string compilerargs = compiler + + String.Join (
, args);
+ int responseFileStart = compilerargs.IndexOf(@);
+ if (responseFileStart!=-1)
+ compilerargs =
compilerargs.Insert(responseFileStart+1,\) + '\';
+
Console.WriteLine (Compiler: {0}, compiler);
Console.WriteLine (MONO_PATH: {0}, sb.ToString ());
+ Console.WriteLine (Arguments: {0}, compilerargs);
+
var pi = new ProcessStartInfo() {
FileName = mono_cmd,
WindowStyle = ProcessWindowStyle.Hidden,
- Arguments = compiler + + String.Join ( ,
args),
+ Arguments = compilerargs,
UseShellExecute = false
};
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Hiring Mono Runtime hacker
Hey, Since I've received several mails asking: Yes, we want to upstream this work. We dislike maintaining forked code as much as the next guy, so an integral part of the job is being friendly with the core mono team, and doing the work in such a way that they deem it fit for inclusion in mainline mono. Sometimes we might have to hack something to be done quicker, and those hacks might not be suitable for mainline, but that's supposed to be the exception, not the rule. Bye, Lucas Lucas Meijer wrote: Hey, Unity Technologies creates a game development tool called Unity. Mono is an essential component of Unity. We are looking for a mono runtime hacker to join our team, who can help us achieve the following: - more quickly be able to support new platforms by taking care of porting mono to the platforms in question - reducing mono's memory and size footprints. Many games can be developed using only a small subset of what Mono provides. Currently they still have to pay for a large part of the stuff they don't use. We want to get into a situation where games that don't use much, can get a lower footprint. You can work remotely, or choose to work at one of our offices (Copenhagen, San Francisco, Vilnius, Kaunas, London) You can expect a relaxed working atmosphere at Unity. We're a bunch of hackers that just love creating cool tech, and care about having a work environments in which developers feel comfortable, and can be productive. Please feel free to contact me directly at lu...@unity3d.com, if you're interested, or would like some more information. Bye, Lucas ___ 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] Hiring Mono Runtime hacker
Hey, Unity Technologies creates a game development tool called Unity. Mono is an essential component of Unity. We are looking for a mono runtime hacker to join our team, who can help us achieve the following: - more quickly be able to support new platforms by taking care of porting mono to the platforms in question - reducing mono's memory and size footprints. Many games can be developed using only a small subset of what Mono provides. Currently they still have to pay for a large part of the stuff they don't use. We want to get into a situation where games that don't use much, can get a lower footprint. You can work remotely, or choose to work at one of our offices (Copenhagen, San Francisco, Vilnius, Kaunas, London) You can expect a relaxed working atmosphere at Unity. We're a bunch of hackers that just love creating cool tech, and care about having a work environments in which developers feel comfortable, and can be productive. Please feel free to contact me directly at lu...@unity3d.com, if you're interested, or would like some more information. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Invitation Unite Conference San Francisco October 27-30.
Hi, Next week, (October 27-30), Unity is organizing its Unite conference in San Francisco. ( www.unity3d.com/unite ) As Unity is grateful to the mono community for making such a cool product, we'd like to invite all mono contributors to be our guests at the conference. It's unfortunate that this conference directly overlaps with the MonoSpace conference. However if you're in the bay area, and are not going to MonoSpace, please send me an email, and I'll get your VIP badge sorted out :) Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Invitation Unite Conference San Francisco October 27-30.
Hi, Next week, (October 27-30), Unity is organizing its Unite conference in San Francisco. ( www.unity3d.com/unite ) As Unity is grateful to the mono community for making such a cool product, we'd like to invite all mono contributors to be our guests at the conference. It's unfortunate that this conference directly overlaps with the MonoSpace conference. However if you're in the bay area, and are not going to MonoSpace, please send me an email, and I'll get your VIP badge sorted out :) Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Which file did a method come from?
Hey, If I have a .dll + .mdb, is there a way for me to find out which file a certain method came from? (without having to run it) Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Hacking mono to make it more deterministic
Hey, At Unity we have this internal testing system where we 1) play a game, and record all inputs 2) can replay that game, based on the recorded inputs 3) whenever we do a checkin on our sourcecode, we run all games in the testing setup against this new unity build, by making screenshots every 5 seconds, and comparing those to the previous run. This has proven to be very useful, as it finds regressions in our users games that we had not anticipated when committing a certain change to the unity codebase. Currently, not all games are playing back deterministically on a single unity build. We don't think we'll ever reach full deterministicality (is that a word?) for 100% of our games, but the higher we get the number, the better we like it. In order to do this, we mock out things like System.Random, DateTime.Now, to return the recorded values. A frequent case where games fail to run identically is when our users iterate over a dictionary which has a custom type as its key. Since the dictionary uses GetHashCode() internally, and Object.GetHashCode() is based on the memory address of the object, it means that the order in which the KeyValuePair's get returned can differ per run. Naturally our users shouldn't be doing this. But they do, as they don't realize that consistent ordering of iterating over a dictionary isn't guaranteed. it just works most of the time so most people don't notice. I didn't realize this myself untill I started investigating this issue :) I'm looking for advice on what would be the best solution to this. So far the best idea I've came up with is to make mono_object_hash just return 0. That probably has some severe performance implications, but we can live with those. I'm hoping this will only make things go a lot slower, but wanted to ask this list: - if I should expect other problems than slowdown - if you can think of a better/different way to make our users code deterministic Thanks, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] using coreclr in mono embedding sample project
On Sun, 2009-06-14 at 01:34 +0200, Lucas Meijer wrote: Hey, In order to figure out how to properly use the new coreclr functionality, verifiers etc, I've taken the test-metadata.c sample that shows how to simply embed mono, and I'm adding some coreclr stuff to it. The sample works and runs fine with core clr disabled. If I add: mono_security_enable_core_clr (); As Sebastien pointed out offlist, I should have added here that I actually also call mono_security_set_core_clr_platform_callback. The function provided however never gets called. I guess I was a bit overzealous in making a as-minimal-as-I-can reprocase. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] assert in mono_local_regalloc in head/trunk
Mark Probst wrote: On Fri, Jun 12, 2009 at 4:45 PM, Lucas Meijerlu...@lucasmeijer.com wrote: I'm getting this stacktrace. (embedded mono trunk, windows). If I replace the trunk dll with a mono 2.4 dll, things work fine. For whoever gets this stacktrace in the future: You're doing it wrong :) your cpu-x86.h file is likely out of date, because that gets autogenerated from cpu-x86.md, by the genmdesc program, which you probably omitted to run. That was my problem at least. Thanks to Zoltan for pointing this out to me, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] using coreclr in mono embedding sample project
Hey, In order to figure out how to properly use the new coreclr functionality, verifiers etc, I've taken the test-metadata.c sample that shows how to simply embed mono, and I'm adding some coreclr stuff to it. The sample works and runs fine with core clr disabled. If I add: mono_security_enable_core_clr (); before mono_jit_init(), the mscorlib fails to load. When stepping trough the program with a debugger, the point where these two (with coreclr and without) diverge, is that line 465 of coree.c: ModuleHandle = LoadLibrary(FileName); returns a valid handle when coreclr is turned off, and it returns 0 when coreclr is turned on. This is on windows, with r135921 runtime+corlib, using msvc2008 built mono using the stock msvc projectfile. I'm a bit surprised by this actually, as I wouldn't expect a call into the win32 api to behave differently based on the coreclr settings. (the FileName variable is identical in both cases). Am I doing something wrong? A verifier related question: in do_mono_image_load(), there are these calls: mono_verifier_verify_pe_data(). this one requires image-raw_data_len to be set. (in verify_msdos_header) mono_verifier_load_pe_data(). this one actually sets image-raw_data_len. (in do_load_header) they're executed in the order above, which causes the first one to always fail for me. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] assert in mono_local_regalloc in head/trunk
Hey, I'm getting this stacktrace. (embedded mono trunk, windows). If I replace the trunk dll with a mono 2.4 dll, things work fine. Here's the stacktrace. I'm hoping someone has a hunch on what might be causing this: asserts in line 1070 in mono_local_regalloc, with the following stacktrace: g_assert (ins-dreg != -1); mono-1-vc.dll!mono_local_regalloc(MonoCompile * cfg=0x08cc7470, MonoBasicBlock * bb=0x08cc8030) Line 1070 + 0x26 bytesC mono-1-vc.dll!mono_codegen(MonoCompile * cfg=0x08cc7470) Line 2918 + 0xd bytesC mono-1-vc.dll!mini_method_compile(_MonoMethod * method=0x08cc62a0, unsigned int opts=64055807, _MonoDomain * domain=0x08b14ea0, int run_cctors=1, int compile_aot=0, int parts=0) Line 3714 + 0x9 bytesC mono-1-vc.dll!mono_jit_compile_method_inner(_MonoMethod * method=0x08cc62a0, _MonoDomain * target_domain=0x08b14ea0, int opt=64055807) Line 4041 + 0x17 bytesC mono-1-vc.dll!mono_jit_compile_method_with_opt(_MonoMethod * method=0x08cc62a0, unsigned int opt=64055807) Line 4231 + 0x11 bytesC mono-1-vc.dll!mono_jit_compile_method(_MonoMethod * method=0x08cc62a0) Line 4249 + 0xf bytesC mono-1-vc.dll!mono_jit_runtime_invoke(_MonoMethod * method=0x08cc61e8, void * obj=0x09154fc0, void * * params=0x002ddee4, MonoObject * * exc=0x) Line 4386 + 0x9 bytesC mono-1-vc.dll!mono_runtime_invoke(_MonoMethod * method=0x08cc61e8, void * obj=0x09154fc0, void * * params=0x002ddee4, MonoObject * * exc=0x) Line 2529 + 0x18 bytesC mono-1-vc.dll!create_exception_two_strings(_MonoClass * klass=0x08cc5aa8, MonoString * a1=0x09153fc0, MonoString * a2=0x) Line 128 + 0x13 bytesC mono-1-vc.dll!mono_exception_from_name_two_strings(_MonoImage * image=0x08c918e8, const char * name_space=0x08a01910, const char * name=0x08a018f8, MonoString * a1=0x09153fc0, MonoString * a2=0x) Line 151 + 0x11 bytesC mono-1-vc.dll!mono_runtime_init(_MonoDomain * domain=0x08b14ea0, void (unsigned int, void *, void *)* start_cb=0x088c9270, void (unsigned int, void *)* attach_cb=0x088c92e0) Line 226 + 0x1c bytesC mono-1-vc.dll!mini_init(const char * filename=0x08132048, const char * runtime_version=0x) Line 5086 + 0x13 bytesC mono-1-vc.dll!mono_jit_init(const char * file=0x08132048) Line 1810 + 0xb bytesC webplayer_win.dll!InitializeMonoFromMain(const std::basic_stringchar,std::char_traitschar,std::allocatorchar monoFrameworkPath=C:/Program Files (x86)/Unity/WebPlayer/mono/2.x.x/Data/lib, const std::basic_stringchar,std::char_traitschar,std::allocatorchar resourcePath=C:/Program Files (x86)/Unity/WebPlayer/player/2.x.x/Data/lib, int argc=1, const char * * argv=0x08131cd8) Line 2133 + 0x13 bytesC++ webplayer_win.dll!LoadMono(const std::basic_stringchar,std::char_traitschar,std::allocatorchar monoPath=C:/Program Files (x86)/Unity/WebPlayer/mono/2.x.x, const std::basic_stringchar,std::char_traitschar,std::allocatorchar unityPath=C:/Program Files (x86)/Unity/WebPlayer/player/2.x.x, const std::basic_stringchar,std::char_traitschar,std::allocatorchar monoDll=C:/Program Files (x86)/Unity/WebPlayer/mono/2.x.x/mono-1-vc.dll, const char * stdoutFile=0x049d7ba0) Line 79 + 0x21 bytesC++ webplayer_win.dll!PreInitializeCommon(HINSTANCE__ * dllInstance=0x1000, const char * playerPath=0x049d9230, const char * monoPath=0x049d92a0, const char * monoDllPath=0x049d92a0, const char * openalDllPath=0x049d9230, const char * stdoutPath=0x049d7ba0, CrashHandler * crhandler=0x049d2968, const char * instanceID=0x049d2810) Line 461 + 0x73 bytesC++ webplayer_win.dll!UnityWinWebStartData(UnityLoaderData * data=0x002df5f0) Line 489 + 0x3d bytesC++ using mono runtime and corlib from r135921 Any ideas? Thanks, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono.Tasklest naming
Hey, Before mono2.6 ships, and the API for tasklets/continuations cannot be changed anymore: Why is the class itself called Continuation, and the namespaceassembly it lives in Tasklet ? I don't have a strong preference for any of the two, but I'd say it make sense not to give this thing two names, there's enough confusion over how these things work already imho. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Win32 sockets regression on trunk.
Hey.
While upgrading our mono to get all the latest bugfixes, I'm running into the
following, which looks like a win32 socket regression.
When the program below is executed on mono trunk (r126917)
it outputs:
error on socket s
error on socket s2
available data on socket s
available data on socket s2
When run on a previous mono. (Mono2.0ish don't have the exact svn for this one,
but around november 29, 2008), this program outputs:
available data on socket s2
Which seems to me like the correct output.
Reported as: https://bugzilla.novell.com/show_bug.cgi?id=476138
Here's the program. you need to make sure to actually have something listening
on port 1234.
using System;
using System.Collections.Generic;
using System.Net.Sockets;
using System.Net;
class Program
{
static void Main(string[] args)
{
var s = new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp);
var ep = new IPEndPoint(IPAddress.Parse(127.0.0.1), 5655);
s.Blocking = false;
s.Bind(ep);
s.Listen(5);
var s2 = new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp);
s2.Bind(new IPEndPoint(IPAddress.Any, 0));
s2.Blocking = false;
try
{
//You actally need to be running something on port 1234.
s2.Connect(IPAddress.Parse(127.0.0.1), 1234);
}
catch (SocketException se)
{
// ignore blocking connect exception. shouldn't there be some other
way to do this...
if (se.ErrorCode != 10035)
throw se;
}
var errorList = new ListSocket();
var readList = new ListSocket();
var writeList = new ListSocket();
readList.Add(s);
readList.Add(s2);
errorList.Add(s);
errorList.Add(s2);
Socket.Select(readList, null, errorList, 100);
if (errorList.Contains(s))
Console.WriteLine(error on socket s);
if (errorList.Contains(s2))
Console.WriteLine(error on socket s2);
if (readList.Contains(s))
Console.WriteLine(available data on socket s);
if (readList.Contains(s2))
Console.WriteLine(available data on socket s2);
}
}
-- Lucas Meijer | GameDev Unity3D Consulting
-- Blog: http://lucasmeijer.com/blog
-- twitter: lucasmeijer
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] correction for Compiling Mono on WIndows' page.
Adar Wesley wrote: This depends on the shell you are using. If you are using /bin/bash or other /bin/sh derivative the instructions are correct. Call the script directly as: /tmp/build_deps/env.sh to run the commands in a sub-shell, or . /tmp/build_deps/env.sh to run the commands in the current shell (notice the '.' in the beginning of the line) Aha. The dot at the beginning off the line threw me off. Since I'm used to run shell scripts just like /tmp/whatever.sh. I'm guessing this will happen to other users as well, especially since the how to make this work on windows guide is likely to be read by people not intimately fermiliar with linux customs. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] correction for Compiling Mono on WIndows' page.
Hey, Note sure if this list is the right place to send this, but on this page: http://www.mono-project.com/Compiling_Mono_on_Windows it explains the way you can build mono from svn on windows. In this process a env.sh gets created that sets up environment variables. The isntructions to run it says: /tmp/build_deps/env.sh however, I believe that is incorrect, and that it should instead be: source /tmp/build_deps/env.sh Bye, Lucas -- Lucas Meijer | GameDev Unity3D Consulting -- Blog: http://lucasmeijer.com/blog -- twitter: lucasmeijer ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Hey, Our team has been busy porting some unit testing related frameworks to mono. porting is probably not the right word, it's mostly creating repro cases of mono bugs, reporting them, and waiting for them to be fixed. (Which happens fast by the way. Thanks!) So far we're looking at NInject, Moq and xUnit. There are / have been bugs in mono that prevent all of these projects from running. Most of them are valid mono bugs, nothing special here. In addition to real mono bugs, there's also the fact that many of these frameworks, use this commonly used trick: FieldInfo remoteStackTraceString = typeof(Exception).GetField(_remoteStackTraceString, BindingFlags.Instance | BindingFlags.NonPublic); This doesn't work on mono, since in mono the private field storing the stacktrace is called remote_stack_trace. This issue has been reported before as issue 425512 ( https://bugzilla.novell.com/show_bug.cgi?id=425512 ) One could argue, and the reason for the wontfix status of the issue does so, that these folks rely on undocumented internals. They shouldn't do it, and Mono shouldn't rename it's own private field to match that of the CLR. However, in the real world(tm), this prevents many projects from running on Mono unmodified. I would like to argue that in this specific case, where the (percieved by me, maybe incorrectly) amount of work for mono to change it's private fieldname to match that of the CLR, is a reasonable cost for enabling this quite frequently found in the wild trick of grabbing the internal stack trace of an exception. Maybe I'm underestimating the amount of work to rename the mono fieldname to match the clr one. If that's the case, please consider this message as another datapoint of three useful .net frameworks unable to run on mono unmodified. Here's a bit more info on the trick: Here is a bit more background on the trick: http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Alan McGovern wrote: But it's the hacks that you added to your program which are causing the issue in the first place ;) You want a hack to make your hack work. What you really need is another hack which will work in all cases. Unfortunately I can't think of a way which will work in all cases. I didn't add these hacks to a program. Consider a new user trying out mono. He tries mono with some useful tool that he uses in .NET Turns out it doesn't work. Yes, maybe it's the tools fault. But the end result is that it doesn't work, and the user thinks arg, apparenlty mono doesn't run my .net stuff, I'm sticking to clr thank you very much. Bye, Lucas PS Please note that there is no official way to do what these programs are doing trough their hack. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Hey. Take the reverse situation, why would Mono devs care on supporting application X because some users would like to run X on Mono ? It depends on what the mono team sees as the goal of mono. If it is to provide a nice programming environment for linux programmers to make linux applications, then no reason to change. If it also is to make it easy for .net applications to run on linux, and to have windows .net developers try mono, and adopt mono as one of their platforms, then it would make sense to cahnge. Also, all of the applications cited are open-source AND free software which allow you to patch them freely. They are all opensource, and I have submitted patches (except for xunit, upcomig). The reason I bring this up is not to make my life easier. I can make all these tools work for me and move on. I bring it up because I feel mono is a really great project, and I would love to make it work more out of the box, even for programs that sometimes cross the line of what they are allowed to be doing. You could also say that from the 3 projects I would like to use on mono, 100% of them didn't work because of this. That means there are probably a lot of other projects out there using this as well, that don't know about mono, and didn't receive a patch for me to provide mono compatibility. Anyway, I think most arguments for and against have been made, and from this point the mono team should just do what it feels is right. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Hey Miguel, It seems to me that talking to upstream developers and get them to provide a more robust implementation from the get-go would be a much better outcome. Have them probe for .NET version, fall back to Mono and if none of those are available, gracefully degrade the functionality. This should defenitely happen, and we're talking to the upstream developers to deal with this situation in a better way. The main theme of my message is not how to get these 3 projects from running on mono, but if we can make the N others that we do not know about run on mono as well. I'm not advocating for _not_ implementing more proper behaviour upstream. I did not get the feeling (or maybe it is part of my lost email) that I have heard the againsts yet. So far I think it can be summarized as: 1) It takes nonzero time, and there are a zillion more important things to do. 2) It could break projects that are mono-only and rely on the same hack. 3) In the original comment on the bugzilla issue, it was noted that the field is shared with the runtime, and that that would make a fix ugly. I actually think #1 is a good argument against, #2 is not very likely, but not totally impossible either, and to what extent #3 is a problem, I don't know. Bye, Lucas -- -- Game Development Blog: http://lucasmeijer.com/blog ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] cruisecontrol.net on mono.
Hey, I mentioned to Miguel that we're running cruisecontrol.net on mono on osx, to produce Unity3D generated builds of our game. Miguel insisted I write to mono-devel and tell a bit more about it. Unsure why, as I'd rather talk about how nice it is that I can run mono in Unity3D in a browser, and have it communicate with a server built on mono on the backend, how we can use visualstudio to write debug c#, how we get to use continuations, and how the switch to mono has been such a breath of fresh air for us. But none of that :-), Cruisecontrol.net. This what often gets referred to as a Continous Integration server. Which is fancy talk for something that builds your project on every commit, and maybe or maybe not does something with the results. Usually people use it to check up on themselves and teammembers to make sure nobody broke any unit tests, makes sure the project still builds on all the platforms it is supposed to build on, etc. (you'd have a seperate CI server per platform for that scenario in most cases). Anyway, CruiseControl.net is written in c#. I just tried to run it on mono, and it ran out of the box. The parts we've tried work as advertised. I haven't used the webinterface part of the tool. We use CCNet.Tray to control it. It's a windows only system tray application that you can use to make it start a build, and that turns red if something is wrong with a build. We're happy with how it works. It's mono running cruisecontrol.net, which is running mono to run gmcs, which is compiling our c# code to CIL. then it runs mono to run nunit on our unit tests. it tells unity3d to make a build, and uses a custom rsync setup to distribute the results in an easy way for our teammembers to quickly get the results of the build. Ironically enough, if you google for stackTraceString, the #3 thing you find is somebody who was unable to run cc.net on mono because of the stackTraceString thing. ducking. It got properly fixed upstream. :-) Bye, Lucas -- Lucas Meijer | GameDev Unity3D Consulting -- Blog: http://lucasmeijer.com/blog -- twitter: lucasmeijer ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Exception not carrying .Msg when thrown from IL called constructor.
Excuse the verbose subjectline :)
When investigating the necessary steps to get NInject to work on Mono, I
found several failing tests.
One category of failing tests boil down to the following behaviour. It
looks like a bug to me, but I could be wrong.
The attached repro program prints out SomeImportantMessage on the CLR,
and prints out on mono.
It looks like the .Msg property of an exception thrown in a constructor
is not available to a catchblock, if the constructor
was called trough dynamically generated IL.
If someone can confirm I'm not doing anything silly, and this is indeed
a bug, I'll file a bugzilla on it.
I tested on 2.0 and svn trunk.
Bye, Lucas
using System;
using System.Reflection;
using System.Reflection.Emit;
public class MonoTest1
{
static void Main()
{
try
{
ILTest();
}
catch (Exception e)
{
Console.WriteLine(Test1: Exception caught. Msg: + e.Message+
Type: +e.GetType());
Console.WriteLine(On the CLR Msg = SomeImportantMessgage);
Console.WriteLine(On Mono, Msg = nothing);
}
}
public static void ILTest()
{
var constructor =
typeof(ClassWithThrowingConstructor).GetConstructor(Type.EmptyTypes);
var dm = new DynamicMethod(String.Empty, typeof(object), new[] {
typeof(object[]) });
ILGenerator il = dm.GetILGenerator();
il.Emit(OpCodes.Newobj, constructor);
il.Emit(OpCodes.Ret);
var md = dm.CreateDelegate(typeof(MyDelegate)) as MyDelegate;
md.Invoke(new object[0]);
}
public delegate object MyDelegate(params object[] arguments);
public class ClassWithThrowingConstructor
{
public ClassWithThrowingConstructor()
{
throw new Exception(SomeImportantMessage);
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] GC.Collect() CLRMono difference.
Here's another one. (Unsure if these are considered ontopic. If not,
please let me know)
This small test program shows GC.Collect() + WeakReference working
different on CLR
than they do on Mono. In mono, the WeakReference is still alive after
GC.Collect(),
in the clr, the WeakReference is no longer active.
using System;
public class MonoTest2
{
public static void Main()
{
var obj = new Version();
WeakReference reference = new WeakReference(obj);
obj = null;
GC.Collect();
Console.WriteLine(reference.IsAlive: + reference.IsAlive);
//mono outputs true
//clr outputs false
}
}
If people think this is a a bug, I'll file a report.
Bye, Lucas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] problem compiling on cygwin.
Robert Jordan wrote: When I do a which mcs I get: /cygdrive/h/Program\ Files/Mono-2.0/bin/mcs which seems okay to me. The space in Program Files might break the build system. At least it did it in the past. Try to reinstall Mono into c:\Mono\, adjust the path, re-autogen and rebuild. To anybody running into this in the future: I got past this bump by doing a make clean after changing mono to live in a path without spaces. The next bump was after mono had succesfully compiled, this error would come up when trying to run mono: entry point g_spawn_command_line_sync_utf8 not found in libglib-2.2.0. I'm pretty new at this, but I believe this is because the windows build instructions (http://www.mono-project.com/Compiling_Mono#Windows_Compilation) are out of date. It lists a glib and a glib dev package as dependencies. However, the error above went away as soon as I replaced those glib's linked to in the instructions by a more recent libglib downloaded from gtk. (http://www.gtk.org/download-windows.html) It looks like this was the last bump. After a few full days of pulling my hair out, I have a self built mono on windows, with monoco. Hurray! Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] problem compiling on cygwin.
Hey, I'm compiling mono on windows in sygwin. After a few bumps on the road that google and the mono-devel archive took care of, I'm now running into this one: snip make[7]: Entering directory `/usr/src/mono/mcs/build' make[7]: Leaving directory `/usr/src/mono/mcs/build' make[6]: Leaving directory `/usr/src/mono/mcs/build' make[6]: Entering directory `/usr/src/mono/mcs/jay' make all-local make[7]: Entering directory `/usr/src/mono/mcs/jay' make[7]: Nothing to be done for `all-local'. make[7]: Leaving directory `/usr/src/mono/mcs/jay' make[6]: Leaving directory `/usr/src/mono/mcs/jay' make[6]: Entering directory `/usr/src/mono/mcs/mcs' make all-local make[7]: Entering directory `/usr/src/mono/mcs/mcs' MCS [basic] mcs.exe Unhandled Exception: System.ArgumentException: Illegal enum value: 2051. Parameter name: access at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name, Assembly BuilderAccess access, String dir, Evidence evidence, PermissionSet requiredPermi ssions, PermissionSet optionalPermissions, PermissionSet refusedPermissions, Sta ckCrawlMark stackMark, IEnumerable`1 unsafeAssemblyAttributes) at System.AppDomain.DefineDynamicAssembly(AssemblyName name, AssemblyBuilderA ccess access, String dir) at Mono.CSharp.CodeGen.Init(String name, String output, Boolean want_debuggin g_support) at Mono.CSharp.Driver.Compile() at Mono.CSharp.Driver.Main(String[] args) make[7]: *** [../class/lib/basic/mcs.exe] Error 77 make[7]: Leaving directory `/usr/src/mono/mcs/mcs' make[6]: *** [do-all] Error 2 make[6]: Leaving directory `/usr/src/mono/mcs/mcs' make[5]: *** [all-recursive] Error 1 /snip Does this ring a bell for anybody? When I do a which mcs I get: /cygdrive/h/Program\ Files/Mono-2.0/bin/mcs which seems okay to me. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] problem compiling on cygwin.
Robert Jordan wrote: I'm compiling mono on windows in sygwin. After a few bumps on the road that google and the mono-devel archive took care of, I'm now running into this one: snip MCS [basic] mcs.exe This is a MS.NET exception: Unhandled Exception: System.ArgumentException: Illegal enum value: 2051. Parameter name: access at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name, It seems that you've somehow managed to run mcs on MS.NET's runtime. This is not supported and not intended but it could be caused by this: When I do a which mcs I get: /cygdrive/h/Program\ Files/Mono-2.0/bin/mcs which seems okay to me. I uninstalled mono, and reinstalled it at H:\Mono-2.0. I updated my .bashrc, source'd it, reran autogen.sh, and ran make. I get the exact same error. At least I now realizes this error actually comes from the CLR, instead from the mono runtime. Now to find out why this is happening. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Coroutines, Monoco, and why we love them.
Hi,
At the Unite conference, I was delighted to meet up with Miguel, as that
would let me underline the parts of mono (existing or nonexisting) that
are very important to our mono using projects. He asked me if I could
write a message to mono-dev explaining not only privately why these
things are important to us.
We're working on a multiplayer MMO game. The backend is written in c#
running on mono, the client uses Unity3D, whose scripting is powered by
mono.
Eariler in the project the plan was to write the backend in Stackless
Python, because of its coroutines support. I was thrilled to find Tomi
Valkeinen's MonoCo. (http://www.bat.org/~tomba/monoco.html) (Thanks
Tomi!). MonoCo brings stackless style coroutines to mono, and this made
us switch to mono.
Monoco makes my life a lot easier. Often monoco or stackless python are
mistaken for a solution to multithreaded problems. It is not. I consider
it an elegant implementation of asynchronous programming. Imagine this
piece of backend code asking a player what move to make:
//excuse the c# pseudocode mix.
public class ImaginaryBackend
{
public void NeverEndingGameLoop()
{
while (players.Count 0)
{
PlayerAction pa =
players[playerIndex].AskWhatToDo(timeout=20sec);
//this call has blocked our microthread'
//the returned message is immidiately available on the
next line of code.
if (!pa.Validate()) pa = new EndTurnPlayerAction();
pa.Execute();
}
}
}
where the meat is in the AskWhatToDo method call. Somewhere in this
methodcall, a request packet gets sent to our player, with some
questionID. this microthread then gets put in the fridge. while the
packet is travelling trough a series of tubes, my other microthreads are
happily running. When the player responds (tagged with the same
questionID), the network reading code sees that there is a microthread
in the fridge, that is waiting for an answer to the question that this
incoming message is answering. So it requeues the microthread, and
supplies it the incoming message.
So I can program as if the call were a blocking call, but the behaviour
does not block my (most likely only) thread. my other code can keep on
running. Basically it's an alternative to a state machine.
Another example is in scripting behaviour for computer controlled agents
in a game:
public class AnnoyingDragon
{
public void MicroThreadEntryPoint()
{
WalkTo(bridge);
Open(bridge);
WalkTo(castle);
Open(castledoor);
PutOnFire(wholefreakincastle);
}
}
With each of these calls blocking the microthread untill the action
has actually completed.. The non-coroutines solution to this problem
would look like:
public class AnnoyingDragon
{
public void Update()
{
DragonState mystate = DragonState.Idle;
switch (mystate)
{
case DragonState.Nothing:
mystate = DragonState.WalkingToBridge;
break;
case DragonState.WalkingToBridge:
if (!closeEnoughTo(bridge)) return MoveMoreTowards(bridge);
bridge.Open();
mystate = DragonState.OpeningBridge:
break;
case DragonState.OpeningBridge:
if (!Bridge.FullyOpen()) return Wait();
mystate = DragonState.WalkingToCastle;
case DragonState.WalkingToCastle:
if (!closeEnoughTo(castle)) return MoveMoreTowards(castle);
castledoor.Open();
mystate = DragonState.OpeningCastleDoor;
break;
case DragonState.OpeningCastleDoor:
if (!castledoor.FullyOpen()) return Wait();
mystate = DragonState.PuttingWholeFreakinCastleOnFire;
break;
case DragonState.PuttingWholeFreakinCastleOnFire:
if (!EverythingBurning(castle)) return ThrowMoreFire();
exit;
}
}
so the coroutine approach basically allows us to store the state of an
object on the callstack, instead of having to remember it myself from
one frame to the next. Granted the statemachine example here could
probably be written a bit more elegantly, and I am not showing the code
inside the methods that the coroutine variant is calling, but I hope
this example illustrate the convenience coroutines bring to people who
would otherwise have to resort to a statemachine to deal with their
asynchronous programming problems.
Please realize I'm not saying that the current implementation of MonoCo
is good (or bad). I'm just looking at it from a user's point of view. I
know next to nothing about the internals of the VM.
Other elements that are very important to our game development
activities, are being able to use the visual studio debugger on a mono
process. I just cannot wait until that beta starts. We
[Mono-dev] Coroutines, Monoco, and why we love them.
Hi,
At the Unite conference, I was delighted to meet up with Miguel, as that
would let me underline the parts of mono (existing or nonexisting) that
are very important to our mono using projects. He asked me if I could
write a message to mono-dev explaining not only privately why these
things are important to us.
We're working on a multiplayer MMO game. The backend is written in c#
running on mono, the client uses Unity3D, whose scripting is powered by
mono.
Eariler in the project the plan was to write the backend in Stackless
Python, because of its coroutines support. I was thrilled to find Tomi
Valkeinen's MonoCo. (http://www.bat.org/~tomba/monoco.html) (Thanks
Tomi!). MonoCo brings stackless style coroutines to mono, and this made
us switch to mono.
Monoco makes my life a lot easier. Often monoco or stackless python are
mistaken for a solution to multithreaded problems. It is not. I consider
it an elegant implementation of asynchronous programming. Imagine this
piece of backend code asking a player what move to make:
//excuse the c# pseudocode mix.
public class ImaginaryBackend
{
public void NeverEndingGameLoop()
{
while (players.Count 0)
{
PlayerAction pa =
players[playerIndex].AskWhatToDo(timeout=20sec);
//this call has blocked our microthread'
//the returned message is immidiately available on the
next line of code.
if (!pa.Validate()) pa = new EndTurnPlayerAction();
pa.Execute();
}
}
}
where the meat is in the AskWhatToDo method call. Somewhere in this
methodcall, a request packet gets sent to our player, with some
questionID. this microthread then gets put in the fridge. while the
packet is travelling trough a series of tubes, my other microthreads are
happily running. When the player responds (tagged with the same
questionID), the network reading code sees that there is a microthread
in the fridge, that is waiting for an answer to the question that this
incoming message is answering. So it requeues the microthread, and
supplies it the incoming message.
So I can program as if the call were a blocking call, but the behaviour
does not block my (most likely only) thread. my other code can keep on
running. Basically it's an alternative to a state machine.
Another example is in scripting behaviour for computer controlled agents
in a game:
public class AnnoyingDragon
{
public void MicroThreadEntryPoint()
{
WalkTo(bridge);
Open(bridge);
WalkTo(castle);
Open(castledoor);
PutOnFire(wholefreakincastle);
}
}
With each of these calls blocking the microthread untill the action
has actually completed.. The non-coroutines solution to this problem
would look like:
public class AnnoyingDragon
{
public void Update()
{
DragonState mystate = DragonState.Idle;
switch (mystate)
{
case DragonState.Nothing:
mystate = DragonState.WalkingToBridge;
break;
case DragonState.WalkingToBridge:
if (!closeEnoughTo(bridge)) return MoveMoreTowards(bridge);
bridge.Open();
mystate = DragonState.OpeningBridge:
break;
case DragonState.OpeningBridge:
if (!Bridge.FullyOpen()) return Wait();
mystate = DragonState.WalkingToCastle;
case DragonState.WalkingToCastle:
if (!closeEnoughTo(castle)) return MoveMoreTowards(castle);
castledoor.Open();
mystate = DragonState.OpeningCastleDoor;
break;
case DragonState.OpeningCastleDoor:
if (!castledoor.FullyOpen()) return Wait();
mystate = DragonState.PuttingWholeFreakinCastleOnFire;
break;
case DragonState.PuttingWholeFreakinCastleOnFire:
if (!EverythingBurning(castle)) return ThrowMoreFire();
exit;
}
}
so the coroutine approach basically allows us to store the state of an
object on the callstack, instead of having to remember it myself from
one frame to the next. Granted the state machine example here could
probably be written a bit more elegantly, and I am not showing the code
inside the methods that the coroutine variant is calling, but I hope
this example illustrate the convenience coroutines bring to people who
would otherwise have to resort to a state machine to deal with their
asynchronous programming problems.
Please realize I'm not saying that the current implementation of MonoCo
is good (or bad). I'm just looking at it from a user's point of view. I
know next to nothing about the internals of the VM.
Other elements that are very important to our game development
activities, are being able to use the visual studio debugger on a mono
process. I just cannot wait until that beta starts. We type all our
code in Visual
Re: [Mono-dev] Ideas for Mono on Windows
Atsushi Eno wrote: Classlib hackers who uses Visual Studio: how do you do those tasks? I'm no classlib hacker, but do use Visual Studio for my game project that is running ontop of mono. We currently use scons as our build software, and have visualstudiosolution as a seperate target. the scons script will basically scan trough my project's filesystem in a way I have told it to, and look for all .cs files. It then creates .csproj's for each assembly, and a .sln file containing all those projects. Creating those files is as simple as taking a template .csproj file prepared by me, and adding a line for each .cs file. When you do an svn-update you just have to regenerate your visualstudio solution, which takes about a second. When you add new files yourself trough visual studio, you don't need to do anything. I might not have a helicopter view of the problems with building mono, but at least this works great for our project. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Socket.Select() behaviour difference between osxlinux.
Hi,
It looks like Socket.Select() behaves differently on osx linux in the
case
where a socket instance is placed in both the readlist, and the errorlist.
On osx, after having called socket.Listen(), calling Socket.Select()
with the socket
instance being in the read and errorlist, the select call will return
once a connection
is established, however it will return with empty readlist and errorlists.
on linux, the resulting readlist is filled with the socket instance.
(Which I believe is the correct
behaviour)
Attached is a demo program that exhibits this behaviour for me.
Bye, Lucas
PS I hope it's okay to pre-report a bug on this list. I'd file an
official bug report, but I'm
new to mono, so I figured I'd check with people in the know if it's
really a bug or some
form of pilot error.
using System;
using System.Net;
using System.Net.Sockets;
using System.Collections.Generic;
public class Server
{
static void Main()
{
Socket ms = new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp);
ms.Blocking = false;
ms.Bind(new IPEndPoint(IPAddress.Any,5656));
ms.Listen(10);
Console.WriteLine(Waiting for incoming connection);
ListSocket readList = new ListSocket();
ListSocket errorList = new ListSocket();
readList.Add(ms);
//comment out the line below to make osx behave like linux.
errorList.Add(ms);
Socket.Select(readList,null,errorList,-1);
if (readList.Count0)
Console.WriteLine(read event); //this happens on linux
else
Console.WriteLine(no read event); //this happens on osx
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
