Hi, all.
I'd like to chip in our Grasshopper experience with Mono. We found it always
extremely useful and productive to be able to build the Mono class libraries
from Visual Studio (in the Grasshopper version).
To me it would seem that the 1.1 profile is much less important then 2.0 and
above.
Hello,
Let us please not use stop energy from preventing this incredibly
important project from moving ahead.
The Mono Build on Visual Studio will not be able to solve every problem
ever, but for that we already have the Cygwin fallback.
This discussion is about how we can gradually improve th
Hello,
I think it would help to keep in mind what the objective is for the
second approach: to make Mono easier to hack on for Windows developers
and to encourage contributions.
We agreed on the second approach (Hit F5 in Visual Studio, get a
fully built Mono):
> 1. What's the impact of
Hello,
First of all I'm not aware of any of "concensus on #monodev". Actually
I find almost no reason to use VS to build our classlibs. The classlib
build is not much slower on cygwin. The remarkable difference would
happen only on the runtime build.
VS integration has another problem. You cannot
Hey Jonathan,
My interest is mainly the first approach, but building class libraries
is an important part of either approach, so thank you for your effort on
this. :)
I would say especially for your use case, we probably don't need to
worry about the 1.1 profile currently. All contributing i
Hi,
The attached patches should only apply to COM interop.
They fix some inconsistencies that we found in mono dealing with
VARIANTs. When an IUnknown (or IDispatch) object is passed as a
VARIANT to native code the vt field was different with mono.
There is not great documentation for this but
Hello,
I broke down the 'Mono on Windows' topic into two distinct approaches.
I have mainly been working on the second approach as it seemed to be easier
and provide more value.
The first approach is to provide a way to build mono on windows without
cygwin installed. This approach provides
El mar, 09-12-2008 a las 11:40 -0500, Geoff Norton escribió:
> Actually scratch that, the SIGFPE is expected there, it gets translated
> into an exception by our runtime. Have you tried compiling with
> sigaltstack off as asked by zoltan? I updated my 7.0 VM to mono trunk,
> and fail in exception
El mar, 09-12-2008 a las 12:57 +0100, Romain Tartière escribió:
> I have just discovered that a patch in the FreeBSD port remove the
> explicit activation of sigaltstack [1].
It looks that what it does, is let configure decide, if to use it or
not.
Reading the comments, it seems that a more usefu
Actually scratch that, the SIGFPE is expected there, it gets translated
into an exception by our runtime. Have you tried compiling with
sigaltstack off as asked by zoltan? I updated my 7.0 VM to mono trunk,
and fail in exceptions.cs with the altstack code on. (I havn't tested
with it off yet)
-
Please file a bug for this issue in bugzilla and assign it to me.
-g
On Tue, 2008-12-09 at 12:57 +0100, Romain Tartière wrote:
> On Mon, Dec 08, 2008 at 04:14:45PM +0100, Romain Tartière wrote:
> > > As for the exception failures, running configure with
> > > ./configure --with-sigaltstack=no
> >
Thanks for taking this on, Romain. You probably saw my earlier messages on the
bsd-sharp mailing list about a2c failing under Mono 2 under FreeBSD. This
caused at least one project that was going to use a2c to now shun it. If we can
fix this issue, it would help greatly.
On Mon, Dec 08, 2008 at 04:14:45PM +0100, Romain Tartière wrote:
> > As for the exception failures, running configure with
> > ./configure --with-sigaltstack=no
> > might help.
> Just tried it. Instead of hanging-on, mono aborts. The backtrace in gdb
> is almost the same, plus ~10 frames that look
Hi again,
sorry I was not attentive enough for your question.
It's not related for your problem.
And it looks that it was fixing already.
Thank you and sorry for confusing.
kambei wrote:
>
> Hi,
>
> It looks like that the problem related with the latest (120960) revision
> of mono/mini/aot-
Hi,
i've a strange problem where the type of a control in an registered assembly
is not being found.
Weird is that some controls defined in the assembly are found, and some not.
Parser Error
Description: Error parsing a resource required to service this request.
Review your source file and modi
Hi,
It looks like that the problem related with the latest (120960) revision of
mono/mini/aot-compiler.c file.
Thus in unwind.c file 'map_hw_reg_to_dwarf_reg' is defined in this way:
13 #ifdef __x86_64__
14 static int map_hw_reg_to_dwarf_reg [] = { 0, 2, 1, 3, 7, 6, 4, 5, 8, 9,
10, 11, 12, 13,
16 matches
Mail list logo
