Re: [Mono-dev] mono_thread_manage causes subsequent mono_jit_cleanup call to hang?
On Fri, Sep 12, 2014 at 12:47 AM, Rodrigo Kumpera kump...@gmail.com wrote: How about internally renaming mono_thread_manage and add a no-op version of it. It would retain compatibility with wine and would not further complicate the shutdown sequence. Sounds good to me. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] pull request, implement System.Threading.Thread.Priority get and set methods
thank you for Robert's comment, Internals calls must not return structs. This is not supported across all platforms. Hzj_jie: but i see GetName_internal and SetName_internal are all using string and InternalThread, do you mean ThreadPriority enum? but i really cannot understand the reason, since the implementation is similar with other internal functions, so anyone can give me more hints on the change? .Hzj_jie From: hzj_...@hotmail.com To: mono-devel-list@lists.ximian.com Date: Thu, 11 Sep 2014 07:36:11 + Subject: [Mono-dev] pull request, implement System.Threading.Thread.Priority get and set methods hi, all,can anyone from the collaborators help to look at the change https://github.com/mono/mono/pull/1272? it's an implementation of System.Threading.Thread.Priority property. thank you. .Hzj_jie ___ 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] How to find extern definition for MonoIO void Lock(
I am trying to find the definition for this: mcs/class/corlib/System.IO/MonoIO.cs: public extern static void Lock (...) I'd like to know how the Lock() method is implemented, so I can understand the valid parameters. (I know the two ints must be = 0, but I'd like to know what else. And generally speaking, know how it's implemented so I can know its limitations). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] peverify vs mono --verify-all
I would really appreciate help with this. I need to check that a dll I generated via reflection is correct, however peverify won't even start: [me@somewhere]$ peverify tmp.dll Could not load class with token 202 * Assertion at class.c:5607, condition `!mono_loader_get_last_error ()' not met Aborted On the other hand, mono --verify-all --security=validil tmp.dll ponders things for a bit, then starts executing the dll file (it's really an executable). Could someone please tell me if the two commands should find the same problems or not. Also, can I just take it that the dll is fine if the Microsoft implementation of peverify says so? Any hints on what to try to get the Mono implementation of peverify working would be especially helpful. I am using mono-3.10.0-branch because it fixes a problem manifesting itself with a triggered assertion inside mono (many thanks to Zoltan for the fix). I have seen similar behaviour under other recent versions of Mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to find extern definition for MonoIO void Lock(
See icall-def.h On Fri, Sep 12, 2014 at 1:08 PM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: I am trying to find the definition for this: mcs/class/corlib/System.IO/MonoIO.cs: public extern static void Lock (...) I'd like to know how the Lock() method is implemented, so I can understand the valid parameters. (I know the two ints must be = 0, but I'd like to know what else. And generally speaking, know how it's implemented so I can know its limitations). ___ 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] peverify vs mono --verify-all
peverify does verify everything eagerly and do very strict checks. mono --verify-all disables some of the strict checks and does perform the checking lazily only on what's executed. Could you file a bug with your binary attached so I can take a look on fixing this assert (I'm the author of this particular assert). -- Rodrigo On Fri, Sep 12, 2014 at 3:28 PM, mono user mono.user...@gmail.com wrote: I would really appreciate help with this. I need to check that a dll I generated via reflection is correct, however peverify won't even start: [me@somewhere]$ peverify tmp.dll Could not load class with token 202 * Assertion at class.c:5607, condition `!mono_loader_get_last_error ()' not met Aborted On the other hand, mono --verify-all --security=validil tmp.dll ponders things for a bit, then starts executing the dll file (it's really an executable). Could someone please tell me if the two commands should find the same problems or not. Also, can I just take it that the dll is fine if the Microsoft implementation of peverify says so? Any hints on what to try to get the Mono implementation of peverify working would be especially helpful. I am using mono-3.10.0-branch because it fixes a problem manifesting itself with a triggered assertion inside mono (many thanks to Zoltan for the fix). I have seen similar behaviour under other recent versions of Mono. ___ 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] Mono 3.10 Threadpool requires remoting??
We have a Mono application that we have been successfully running against Mono 3.2.7 for some time now. We have built Mono ourselves from the source because we're targeting the i586 architecture. We're targeting a headless embedded device, so we've tried to remove things that we don't use. One of those things is Remoting support. I just got done getting 3.10.1 built and moved over to a target and now when I run our app I get a MissingMethodException. ThreadPool.QueueUserWorkItem seems to be calling into Remoting. What's up with that? Here's the inner exception and its stack trace: Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializ er for SolutionFamily.SFTrace --- System.TypeInitializationException: An excepti on was thrown by the type initializer for OpenNETCF.IoC.RootWorkItem --- System. MissingMethodException: Cannot find the requested method. at (wrapper managed-to-native) System.Runtime.Remoting.RemotingServices:IsTrans parentProxy (object) at System.Delegate.IsTransparentProxy () [0x0] in filename unknown:0 at System.Threading.ThreadPool.QueueUserWorkItem (System.Threading.WaitCallback callBack, System.Object state) [0x0] in filename unknown:0 at System.Threading.ThreadPool.QueueUserWorkItem (System.Threading.WaitCallback callBack) [0x0] in filename unknown:0 at OpenNETCF.IoC.WorkItem..ctor () [0x0] in filename unknown:0 at OpenNETCF.IoC.RootWorkItem..cctor () [0x0] in filename unknown:0 --- End of inner exception stack trace --- I can go back and regenerate everything with Remoting support, but I'm wondering why this is getting called at all when it wasn't in 3.2.7. -Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Latest source - build yields Could not load type 'Mono.CSharp.CommandLineParser' (17170)
Bug 17170 is marked as RESOLVED/FIXED but it's still occurring with a git
pull of the latest as of this morning:
https://bugzilla.xamarin.com/show_bug.cgi?id=17170
The proposed workaround of
make EXTERNAL_MCS=${PWD}/mcs/class/lib/monolite/gmcs.exe
After getting monolite and before running make does work, but a straight
make fails with Could not load type 'Mono.CSharp.CommandLineParser'
-Chris
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Latest source - build yields Could not load type 'Mono.CSharp.CommandLineParser' (17170)
Hi,
Just reporting I got similar issues compiling from the 3.8.0 tarball, on a
CentOS system (with or without a previous working mono runtime already
available). Not quite the message in that bug report, but failing to find a
working gmcs (sorry cannot access the message details right now), with or
without the make with EXTERNAL_MCS workaround. Compiling from the 3.2.8
tarball works fine.
Curiously, no problem at all encountered with the same tarball on a Debian
unstable box.
J-M
From: mono-devel-list-boun...@lists.ximian.com
[mono-devel-list-boun...@lists.ximian.com] on behalf of Chris Tacke
[cta...@opennetcf.com]
Sent: Saturday, September 13, 2014 9:09 AM
To: mono-devel-list
Subject: [Mono-dev] Latest source - build yields Could not load type
'Mono.CSharp.CommandLineParser' (17170)
Bug 17170 is marked as RESOLVED/FIXED but it's still occurring with a git
pull of the latest as of this morning:
https://bugzilla.xamarin.com/show_bug.cgi?id=17170
The proposed workaround of
make EXTERNAL_MCS=${PWD}/mcs/class/lib/monolite/gmcs.exe
After getting monolite and before running make does work, but a straight
make fails with Could not load type 'Mono.CSharp.CommandLineParser'
-Chris
___
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
