[Mono-dev] Embedding Mono - NULL return value in C#
Hi, I call a c++ function from C# using mono. For instance, [MethodImplAttribute(MethodImplOptions.InternalCall)] extern internal static Object get_ai_behavior_object(int id); When the function returns a NULL object, there is a NullReferenceException. I think it occurs because C# tries to cast null to System.Object. Is there a way to avoid this without using try-catch which slows the program or a dummy Null object I need to create? Thanks, Mesut, ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.8.1 on OSX and Winforms regression fixed.
Hi, I have noticed that the download page has changed a little on the Mono web site. On the 22nd November, I downloaded 2.8.1 for OSX got the file MonoFramework-2.8.1_4.macos10.novell.universal.dmg whereas if you download it now, you get MonoFramework-2.8.1_3.macos10.novell.universal.dmg and the problems with running Winforms apps returns. Has the patch been intentionally removed? Steven -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-2-8-1-on-OSX-and-Winforms-regression-fixed-tp3054815p3088749.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] Mono 2.8.1 on OSX and Winforms regression fixed.
Hi, 2.8.1_4+ are still there, you just need to browse http://ftp.novell.com/pub/mono/archive/2.8.1/macos-10-x86/ Novell's FTP directory . For example, http://ftp.novell.com/pub/mono/archive/2.8.1/macos-10-x86/5/MonoFramework-2.8.1_5.macos10.novell.x86.dmg here you can find 2.8.1_5 . However, I'd also like to ask why http://www.go-mono.com/mono-downloads/download.html points to an old Mono (2.8.1_3) for the mac. The regression in 2.8.1_3 may break any application that makes use of System.Drawing, not just WinForms ones. -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-2-8-1-on-OSX-and-Winforms-regression-fixed-tp3054815p3088815.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] Embedding Mono - NULL return value in C#
On 15.12.2010 09:51, marcus julius wrote: Hi, I call a c++ function from C# using mono. For instance, [MethodImplAttribute(MethodImplOptions.InternalCall)] extern internal static Object get_ai_behavior_object(int id); When the function returns a NULL object, there is a NullReferenceException. I think it occurs because C# tries to cast null to System.Object. Is there a way to avoid this without using try-catch which slows the program or a dummy Null object I need to create? This is expected to work. Please show more code or better file a bug with a self-contained test case. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CS0584 Internal compiler error in gmcs.exe (master)
Hello, In membercache.cs.AddBaseType () line 219, if entry.Value.Count == 1, entry.Value is a MemberSpec[] which will cause the list.Add(ce) on Line 234 to fail. Gmcs.exe fails with CS0584: Internal compiler error: Collection is read-only (in ecore.cs:433) when this case is encountered. I ran across this error while compiling our code with Mono 2.9 from master today. I'm not sure how to reproduce the error, otherwise I'd have submitted a test case. This issue should now be fixed. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Too many open files when adding many embedded resources
Hello, Building Mono 2.9 from git master, we're encountering an issue where an assembly with lots of embedded resources (approx 4000), where gmcs is throwing Too many open files exception. The culprit seems to be that a new file handle is opened for every embedded resource when it's added. Mono 2.6 doesn't have this problem, so it appears to be a regression The issue should be fixed. Could you please test it? Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 2.8 with sgen on Solaris 10 SPARC
Hi all, Just wanted to let you know that our main internal Plastic SCM server has been running now for more than 1 month without issues on Solaris SPARC using Mono 2.8 and sgen! Cheers, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Service crashs
2010/12/14 Robert Jordan robe...@gmx.net: On 14.12.2010 16:16, Chakotey STME wrote: Hello Community, I have a problem with a mono-service. I have a mono-service in which I host a WCF-Service. I start the software with mono-service2 and it works fine. After a while (I can't say when exactly - sometimes after 1 hour, sometimes after 4 hours) the service crashs. There is no more mono-service-process on the linux-system. The lock-file in the /tmp-Directory still exists. So it have to be a crash as the reason the service isn't there anymore, haven't it? So what can I do to identify the problem? Is it a unhandled exception? How can I find it out? Because in the ServiceHost of the service I catch all Exception (or I believe it). Is there something like a log-file to identify this problem? The service worked in the background, so I had no messages at the console. Use the --debug switch to redirect stdout+err to a log file of your choice and put the whole thing into background with the trailing nohup mono-service2 --debug /tmp/mylogfile 21 Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Hi, thanks for your answer. I will try this. I think it will help. Thanks chakoteystme ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono/.NET Framework Very Different Stack Traces
On Wed, Dec 15, 2010 at 12:26 AM, jmalcolm malcolm.jus...@gmail.com wrote: I cannot speak to changing the stack trace offered by Mono. What I can say is that I tend to use inner exceptions in this situation to get better insight into where the real problem lies. Unfortunately, at least for this test case, this does not help me. There is no InnerException. Thanks, Bryan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono/.NET Framework Very Different Stack Traces
Hi,
This is:
https://bugzilla.novell.com/show_bug.cgi?id=322158
On Tue, Dec 14, 2010 at 8:27 PM, Bryan Murphy bmurphy1...@gmail.com wrote:
I have a very simple test program:
01 using System;
02
03 public static class Program {
04public static void ThrowCatchRethrow() {
05try {
06throw new InvalidOperationException();
07} catch (Exception) {
08throw;
09}
10}
11
12public static void Main(string[] args) {
13try {
14ThrowCatchRethrow();
15} catch (Exception ex) {
16Console.Error.WriteLine(ex);
17}
18}
19 }
I compile this using the following:
$ gmcs -debug -out:ExceptionTest.exe ExceptionTest.cs
$ csc.exe /debug /out:ExceptionTest.exe ExceptionTest.cs
When I execute it under the .NET framework, I get the following stack
trace:
$ ./ExceptionTest.exe
System.InvalidOperationException: Operation is not valid due to the current
state of the object.
at Program.ThrowCatchRethrow() in
u:\Workspace\MonoTest\ExceptionTest.cs:line 8
at Program.Main(String[] args) in
u:\Workspace\MonoTest\ExceptionTest.cs:line 14
When I execute it under Mono, I get the following:
$ mono --debug ./ExceptionTest.exe
System.InvalidOperationException: Operation is not valid due to the current
state of the object
at Program.ThrowCatchRethrow () [0x0] in
U:\Workspace\MonoTest\ExceptionTest.cs:6
Here you can clearly see that the stack traces are *very* different. In
fact, while it's nice that Mono shows line #06 as the place where the
exception is actually thrown, it loses the fact that line #14 was also part
of the stack at the time of the error.
The .NET framework shows line #08 as the place where the exception was
thrown, which is not ideal, however it includes line #14 which is what I
really want.
Is there a way we can get the stack traces to look more like the .NET
framework stack traces? I actually find it significantly easier to track
down the location of a problem when presented with the .NET stack trace.
I know I can wrap and rethrow, but that loses the type of the initial
exception so it's not a feasible solution. We're going to add a centralized
logging service and audit our code to try and track down these issues,
however, that's a rather painful way to go about this and we keep running
into this problem again and again.
Thanks,
Bryan
___
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] Mono/.NET Framework Very Different Stack Traces
On Wed, Dec 15, 2010 at 11:14 AM, Zoltan Varga var...@gmail.com wrote: Hi, This is: https://bugzilla.novell.com/show_bug.cgi?id=322158 Thanks. That's my problem to a T. I knew there was a ticket for it somewhere but had yet to find it. Bryan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] CS0136 Error - C# parser bug (master)
The following code gives a CS0136 error when it shouldn't (running today's git
master)
namespace N
{
public class C
{
public event EventHandler MyDelegate = delegate { };
internal void DoSomething (bool bValue)
{
if (!bValue)
{
}
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CS0136 Error - C# parser bug (master)
Just noticed I forgot a using System; at the top
If also, if you replace the {} from under if (!bValue) with an empty statement
(I.e. ;) the code compiles without error.
From: Tom Philpot tom.phil...@logos.commailto:tom.phil...@logos.com
Date: Wed, 15 Dec 2010 10:27:37 -0800
To: mono-devel-l...@ximian.commailto:mono-devel-l...@ximian.com
mono-devel-l...@ximian.commailto:mono-devel-l...@ximian.com
Subject: [Mono-dev] CS0136 Error - C# parser bug (master)
{
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] CS1692: Invalid number warning for #pragma restore?
One more thing I'm seeing today. The following gives a CS1692 for line 3 below.
Is this expected behavior or a bug?
#pragma warning disable 1591
public class C {}
#pragma warning restore 1591
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Winforms on Mac: Clipboard patches
Yeah I'm pretty sure those clipboard changes are meant to allow copying and pasting between mono and mac applications, instead of just X11 applications. I worked with Ralph briefly when he started working on patching mono and this was one of the problems that came up. I haven't tried these patches, but if it does work you wouldn't notice any difference if you're still only testing between X11 applications. This would be what he meant by 'Mac native Clipboard' and why MONO_MWF_MAC_FORCE_X11 shouldn't affect the clipboard changes. Stifu wrote: I don't think you should use the MONO_MWF_MAC_FORCE_X11 flag to try these changes, as then you wouldn't be using the native Mac driver anymore, which means you wouldn't notice any changes before and after the patches, then. In the first place, as Ralph was trying to get his app to work on Mono, I proposed him to look into the MONO_MWF_MAC_FORCE_X11 flag, and he replied: Thanks for the X11 solution tip. I tried it and it does seem more stable but it does not support a Mac native Clipboard which is a mandatory in my case. - Mail Original - De: matteo tesser matteo.tes...@gmail.com À: Miguel de Icaza mig...@novell.com Cc: Stifu st...@free.fr, mono-devel-list@lists.ximian.com Envoyé: Jeudi 25 Novembre 2010 00:37:15 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: Mono Winforms on Mac: Clipboard patches Hi, I gave a first look at the clipboard patch. I applied the patch in my version and tried it. Honestly I have to say that I never saw clipboard (copy and paste) working on WinForms/OSX, and unfortunately I did noticed any change (but no regressions either) in the behavior of tests launched after the patch have been applied: this either by setting MONO_MWF_MAC_FORCE_X11=1 or by unsetting it. I want to remark that the code in the static constructor of XplatUI.cs tests only for the existence of the environment variable MONO_MWF_MAC_FORCE_X11 but not for its value: I do not now if setting MONO_MWF_MAC_FORCE_X11=0 is considered a valid option or not. I will continue to look after the other changes, Matteo -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-Winforms-on-Mac-Clipboard-patches-tp3053049p3089667.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] Mono Tasklets (microthread resuming with different stack, and possibly microthread migration)
I was wondering a few things concerning Mono.Taskets: 1/ By modifying mono to not throw an exception when marking top-most frame a second time (using Mono.Continuation.Mark), I figured more behavior could be covered. As an example, let's say I Mark and Store in the following stack frame: == Stack C2() - Here I Store(0) == Stack C1() - Here I Mark == Stack A2() == Stack A1() Next run, I could run B1 again from a different stack to restore B2: == Stack C2() - Here I Store(0) == Stack C1() - Here I Mark _again_ to update current stack topmost frame, and then Restore(0) which will add C2 on top of new stack == Stack B3() == Stack B2() == Stack B1() Basically, this enables Continuation to be resumed later in time, even if calling stack frame is different. As a result, MicroThread Scheduler could be rewritten so that it runs in a Step() mode every frame instead of a Run() loop (which force to create thread) This could even allow to migrate MicroThread on a different Thread (not tested yet). So far it seems to work on simple case, can anyone tell me if it could lead to any issues I could not foresee? I was especially worried about internal pointer to stack (if there is any) becoming invalid if base ESP gets shifted (but in that case, I could always manage to call this function with the same call stack so ESP would be the same between each Step()). 2/ I noticed a bug in continuation_mark_frame that could lead to random crash: https://bugzilla.novell.com/show_bug.cgi?id=659827 3/ So far it is only available on x86/ia64. Is there anything that would prevent it to work on other platform (esp. ARM/PS3 etc...) in the future? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
