[Mono-dev] Arguing for reconsideration of WONTFIX status of 425512

[Paige Thompson]

maybe field names should be driven off of an XML file at compile time or
something instead of hard coded. I mean yeah that dances on the line of
still having to modify mono but at least in that case it wouldn't be hard
coded. Then everybody could be happy. I guess what I'm trying to say is,
perhaps rather than arguing about who's is better and more worth efforts
rather have a compatibility layer for the inorite way and the tried and
true.

-Adele

On Thu, Feb 12, 2009 at 5:13 AM, Stifu <stifu at free.fr> wrote:

>
> I have to agree.
>
> Reverse-engineering complicated algorithms for the sake of matching MS .NET
> perfectly is one thing, and may not be worth the time and efforts, but
> simply changing a string to improve compatibility is an easy win.
>
> Many things in the past of Mono have been done to improve compatibility
> with
> existing .NET apps and get Windows developers interested (such as
> Windows.Forms support, for example). Simply put, it doesn't make much sense
> to me to try that hard to catch high-hanging fruits if you're going to
> ignore low-hanging ones.
>
>
> Lucas Meijer-4 wrote:
> >
> > Hey,
> >
> > Our team has been busy porting some unit testing related frameworks to
> > mono.
> > porting is probably not the right word, it's mostly creating repro cases
> > of mono bugs,
> > reporting them, and waiting for them to be fixed. (Which happens fast by
> > the way. Thanks!)
> >
> > So far we're looking at NInject, Moq and xUnit.
> >
> > There are / have been bugs in mono that prevent all of these projects
> > from running.
> > Most of them are valid mono bugs, nothing special here.
> >
> > In addition to real mono bugs, there's also the fact that many of these
> > frameworks, use this
> > commonly used "trick":
> >
> > FieldInfo remoteStackTraceString =
> > typeof(Exception).GetField("_remoteStackTraceString",
> > BindingFlags.Instance | BindingFlags.NonPublic);
> >
> > This doesn't work on mono, since in mono the private field storing the
> > stacktrace is called "remote_stack_trace".
> >
> > This issue has been reported before as issue 425512 (
> > https://bugzilla.novell.com/show_bug.cgi?id=425512 )
> >
> > One could argue, and the reason for the wontfix status of the issue does
> > so,  that these folks rely on undocumented internals.
> > They shouldn't do it, and Mono shouldn't rename it's own private field
> > to match that of the CLR.
> >
> > However, in the real world(tm),  this prevents many projects from
> > running on Mono unmodified.
> >
> > I would like to argue that in this specific case, where the (percieved
> > by me, maybe incorrectly) amount of work for mono to change it's private
> > fieldname to
> > match that of the CLR, is a reasonable cost for enabling this quite
> > frequently found in the wild trick of grabbing the internal stack trace
> > of an exception.
> >
> > Maybe I'm underestimating the amount of work to rename the mono
> > fieldname to match the clr one. If that's the case, please consider this
> > message
> > as another datapoint of three useful .net frameworks unable to run on
> > mono unmodified.
> >
> > Here's a bit more info on the trick:
> >
> > Here is a bit more background on the trick:
> >
> http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx
> >
> > Bye, Lucas
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21975728.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090212/ef92fadc/attachment.html