[Mono-dev] mono.cecil
Hi, Mono.Cecil 0.9.4 has been released unto the world and works beautifully. Is there an eta for Mono.Cecil 1.0 and when it arrives, will it see an end to the myriad of packages bundling their own version of mono.cecil as well (e.g. monodevelop has it's own version)? TTFN Paul -- Vertraue mir, ich weiss, was ich mache... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono.cecil
Apparently I'm still having hard times figuring out this email thing. For the record: On Wed, Dec 8, 2010 at 1:42 PM, Jb Evain jbev...@gmail.com wrote: Yes. On Wed, Dec 8, 2010 at 1:40 PM, Paul F. Johnson p...@all-the-johnsons.co.uk wrote: Hi, On Wed, Dec 8, 2010 at 1:25 PM, Paul F. Johnson p...@all-the-johnsons.co.uk wrote: Mono.Cecil 0.9.4 has been released unto the world and works beautifully. Is there an eta for Mono.Cecil 1.0 and when it arrives, will it see an end to the myriad of packages bundling their own version of mono.cecil as well (e.g. monodevelop has it's own version)? There's no ETA, although I'd like to have 1.0 done in time so it is included in whatever Mono 3.0 will be. At that point, we should stop shipping it as an internal library. Thanks. I'm packaging 0.9.4 up for Fedora Rawhide. Only thing is the tarball you have up doesn't include a licence. Is it MIT like the rest of mono? TTFN Paul -- Vertraue mir, ich weiss, was ich mache... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] MonoDroid
I seen the pretty screenshots of MonoDroid sample apps on monologue. Can I beta test MonoDroid pretty please? Or at least open the beta up to the public? I added myself to the beta many months ago but I have not gotten an invite yet. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File not found error when using Activator.CreateInstanceFrom()
Update: Code runs fine under .NET 2.0. Also tried statically linking the second .dll to the first which alleviated the 'file not found' exception, however I am now getting a implement type compare for 1b! message and mono crashes! Has anyone seen this!?? -- View this message in context: http://mono.1490590.n4.nabble.com/File-not-found-error-when-using-Activator-CreateInstanceFrom-tp3064104p3078315.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] File not found error when using Activator.CreateInstanceFrom()
On Wed, Dec 8, 2010 at 12:39 PM, mike mgu...@knology.net wrote: Update: Code runs fine under .NET 2.0. Also tried statically linking the second .dll to the first which alleviated the 'file not found' exception, however I am now getting a implement type compare for 1b! message and mono crashes! Has anyone seen this!?? This is a bug on mono, can you provide a test case that shows this problem and file a bug report? Thanks, Rodrigo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] News about Bug 623477
Well, the most appropriate behavior would be to expose a new runtime
function
that returns the smallest allowed stack size.
Something like:
--in metadata/theads.c
int
mono_thread_get_stack_min_size ()
{
#if defined (PTHREAD_STACK_MIN)
return PTHREAD_STACK_MIN;
#else /*FIXME add more cases. Not sure WINAPI exposes such a thing*/
return mono_pagesize (); /*A sane default*/
#endif
}
Then export it in icalls-def.h to a System.Threading.Thread static method.
And finally use this on managed code to properly check for minimum size.
Such change would be the appropriate way to go.
Torrelo, can you cook up such a patch? Either post it on bugzilla or make a
pull request.
Thanks,
Rodrigo
On Mon, Dec 6, 2010 at 9:00 AM, Torello Querci tque...@gmail.com wrote:
Hi Rodrigo,
this is true but with this sample code:
using System;
using System.Threading;
namespace testThread
{
class Program
{
static void Main(string[] args)
{
Program p = new Program();
Thread t = new Thread(p.ThreadEntryPoint, Int32.Parse(args[0]));
t.Start();
Console.WriteLine(T0 - Chk1);
Thread.Sleep(5000);
Console.WriteLine(T0 - Exit);
}
public void ThreadEntryPoint(Object obj)
{
Console.WriteLine(T1 - Enter);
Thread.Sleep(5000);
Console.WriteLine(T1 - Exit);
}
}
}
if you run:
Thread.exe 64000
after compile it on VS this work while I get exception on Mono and for
me is a bug.
Ok, I compile with 3.5 profile, but also on 2.0 profile works so I
suppose that the original MS specification was not implements by MS :)
Best Regards.
2010/12/6 Rodrigo Kumpera kump...@gmail.com:
This behavior is OS/target dependant, so it's not very useful to try to
match MS behavior on it.
On Thu, Dec 2, 2010 at 11:09 AM, Torello Querci tque...@gmail.com
wrote:
Hi guy,
no news about bug 623477?
Best Regards, Torello
___
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] (Delegate) Trampoline executed twice?
On Tue, Dec 7, 2010 at 10:13 AM, Martin Däumler m...@cs.tu-chemnitz.dewrote: On 07.12.10 10:54, Robert Jordan wrote: On 07.12.2010 08:52, Martin Däumler wrote: I expected a delegate trampoline to be executed only once like common JIT trampolines for a single call instruction. However, it might be executed twice. It could be related to the fact that the code behind Thread.Start () is eventually calling delegate's Invoke method via mono_runtime_invoke (). Hello, thank you for the answer. As you say, the delegate trampoline is called a second time through mono_runtime_invoke(). So I want to know if there might be other trampoline types that might be called a second time. A simple JIT trampoline patches the callsite so it is not possible that this JIT trampoline is called from that memory address. But obviously, this does not hold for delegate trampolines. So, I want to know, if there are other trampoline types that might be called a second time in that way? Quite a few trampolines are not patchable. Direct method delegates trampolines have a per callsite cache of the target method to speedup the trampoline invocation with is per-instance (eg, only the first call takes the tram). Virtual method delegates are only done one per instance but don't feature the per callsite cache for obvious reasons. The generic sharing context fetch trampolines can't be patched out since they are context dependant. Class init trampolines are not, in some generic corner cases, patchable using the rgctx fetch machinery. Monitor enter/exit and generic virtual remoting are also obviously not patchable. The only case of patchable trampolines that we miss is indeed for direct method delegates. It is somewhat easy to implement such thing if you desire. Virtual method delegates creation/first invocation could be speedup if one wanted to spend time on it. There are other parts of the runtime that require proper warm up/AOT for what you want: IMT slots, virtual generic methods and variant type dispatch slots. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
