I've created a ticket to track this issue:
http://bugzilla.xamarin.com/show_bug.cgi?id=2426
On Thu, Dec 8, 2011 at 2:46 PM, Brian Luczkiewicz wrote:
> Ok, that was easy. This test case crashes within 10s every time for me:
>
> To compile:
>
> $ dmcs /r:System.Drawing foo.cs
outbmp.Height));
}
}
}
}
On Thu, Dec 8, 2011 at 2:35 PM, Brian Luczkiewicz wrote:
> I wanted to report this sooner rather than later in case someone is
> already working on it. I don't yet have an isolated test case to reproduce
> this, but I am working on getting one together.
>
>
I wanted to report this sooner rather than later in case someone is already
working on it. I don't yet have an isolated test case to reproduce this,
but I am working on getting one together.
I've observed this crash on a mac running lion. I am using this mono beta
build:
http://download.mono-proje
While attempting to reproduce this, I ran into another
ConditionalWeakTable/sgen bug + entered it into the bug tracker. Unsure if
this is related to the segv or not:
http://bugzilla.xamarin.com/show_bug.cgi?id=1175
On Sat, Oct 1, 2011 at 12:51 AM, Brian Luczkiewicz wrote:
> Before I tr
Before I track down a tiny repro case for this and file a formal bug report,
I wanted to check and see if these stack traces look like any known bugs.
We've recently added usage of ConditionalWeakTable<,> api to our codebase.
We are now seeing some crashes in the mono runtime. The crashes appear t
hey need to be decorated with a
> special attribute.
>
> See https://github.com/mono/mono/blob/master/mono/mini/aot-compiler.c around
> line 2793.
>
> -g
>
> On 2011-07-29, at 5:03 PM, Brian Luczkiewicz wrote:
>
> I'm having trouble seeing how an arbitrary deleg
I'm having trouble seeing how an arbitrary delegate can be marshalled into
an unmanaged function pointer without runtime code generation to capture the
object pointer.
Is this functionality disabled in full-aot environments or is it
accomplished by some mechanism that I'm not considering?
This code (duplicated below, from gc_locks.h) is a little bit troublesome.
I'm not sure what the best way to resolve is, but I figured I'd raise the
issue anyways.
On most architectures, building for an old CPU then running on a newer one
is safe. For example, running code compiled for i386 on a m
I noticed that the mono distribution includes fsc/fsi but omits
fsyacc/fslex.
These tools have been part of microsoft's F# drops for years and are part of
the vs.net distribution as well. As a result, tons of F# software requires
these tools. Any distribution which includes fsc should probably inc
It's hard to know if I've run into this specific problem or not from your
description, but I have experience with the pitfalls of building mono for
multi-core arm chips. Some things to try:
- Try starting with -O0 and adding your flags back in one by one. I've seen
evidence of buggy GCC code gener
This is with mono 2.10.2 on osx, installed from the binary installer. Am I
doing something wrong here? Any ideas?
brian@brianmbp ~ $ cat t.cs
using System;
class Hello {
public static void Main(string[] args) {
Console.WriteLine("Hello, World");
}
}
brian@brianmbp
I just ran into this myself..and put in a bug report.
https://bugzilla.novell.com/show_bug.cgi?id=686433
(0 - x) is being constant-folded to (x) in mono 2.10.1.
On Thu, Mar 24, 2011 at 7:05 PM, David Mitchell wrote:
> So I was playing around in my Terminal today, and I did the following:
>
>
>
> This is great news, as we just recently enabled this.
>
> Was this with LLVM or with the regular AOT?
Regular AOT.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
> Perhaps we could provide the option for the user to toggle those on
> and off at install time.
>
Sounds good to me.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
When I build mono from source and install on linux, I've noticed that I end
up with .so's next to some of the installed dll's and exe's. This provides a
nice speedup when running compilers/tools from the mono distribution. Now
that we have AOT working on osx, the same optimization makes sense there
>
> I would suggest to fold this into the preexisting section. Does Darwin/x86
> not define __MACH__?
>
__MACH__ is an antiquated way to detect an apple machine. Newer code, both
out in the world and within the mono tree (e.g. mini-x86.h) seems to use
__APPLE__. Obviously, do what you want here, b
bfc89a25204fa14166
Author: Brian Luczkiewicz
Date: Sat Oct 30 21:52:09 2010 -0400
Enable --aot (but not --aot=full) on osx/x86
diff --git a/mono/mini/aot-compiler.c b/mono/mini/aot-compiler.c
index 5088324..70ff8c0 100644
--- a/mono/mini/aot-compiler.c
+++ b/mono/mini/aot-compiler.c
@
startup time by 7x for my app.
It would be great if you could review this and consider incorporating it
into the mono mainline.
Brian
On Fri, Oct 29, 2010 at 12:24 AM, Zoltan Varga wrote:
> Hi
>
> On Wed, Oct 27, 2010 at 7:41 PM, Brian Luczkiewicz wrote:
>
>> I have a cross-
I have a cross-platform (osx+mono/ms.net) app that runs a large piece of
generated code at startup--on windows, 95% of the runtime of this code is in
the JIT compiler and ngen improves startup time for this app dramatically. I
was hoping to try out --aot and potentially see a corresponding improvem
19 matches
Mail list logo
