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

[Alan McGovern]

But it's the hacks that you added to your program which are causing the
issue in the first place ;) You want a hack to make your hack work. What you
really need is another hack which will work in all cases. Unfortunately I
can't think of a way which will work in all cases.

Alan.

(p.s. i'm not arguing for or against the change, just pointing out the
above)

On Thu, Feb 12, 2009 at 1:45 PM, Stifu <stifu at free.fr> wrote:

>
> 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.
>
> _______________________________________________
> 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/40202de8/attachment-0001.html