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

[Stifu]

I think that'd be a quite bad solution, because it'd add a lot of confusion,
and possibly divide the user base. I can already imagine debugging user
problems, like "Are you using Mono standard edition or the Mono modded by
SomeRandomGuy?"
I'd rather add hacks in the program than having more frameworks to worry
about.


Paige Thompson wrote:
> 
> 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
>>
> 
> _______________________________________________
> 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-tp21975511p21976367.html
Sent from the Mono - Dev mailing list archive at Nabble.com.