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,
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
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,
However, I think Mono isn't meant to be a *reimplementation* of .NET, it's
an implementation of the *specifications* defined at ECMA/ISO.
Now, if developers are using implementation specific details they are
shooting themselves in the foot and should go fix their mess themselves, not
blame Mono
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
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
Lucas Meijer wrote:
However, in the real world(tm), this prevents many projects from
running on Mono unmodified.
How about if, for a change, those projects were finally starting
to perceive mono as a platform with its own internals?
It's a no brainer to add a `if (Type.GetType(Mono.Runtime)
Your opinion makes sense, but then, why bother with Windows.Forms (or other
things like pseudo-Windows registry support), for example? The Mono team
seems a bit torn between adding hacky stuff for the sake of compatibility
(note: I'm not bashing, I rely on the Windows.Forms support of Mono
Alan McGovern wrote:
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
All I'm saying is, if hacky stuff does not satisfy the business need then
it's a useless effort. We (well not me I'm not writing for mono yet) have to
consider who's ultimately going to be using it and what their needs are.
On Thu, Feb 12, 2009 at 5:56 AM, Stifu st...@free.fr wrote:
Your
PS: to clear things up, I got the wrong URL at the end of my post...
I meant to paste this one: http://go-mono.com/forums/#nabble-td21954562
Paige Thompson wrote:
All I'm saying is, if hacky stuff does not satisfy the business need
then
it's a useless effort. We (well not me I'm not
There is a difference between implementing a public API used by lot of
people and implementing low-level internals that 1/ you aren't supposed to
know in the first place, 2/ are used by 2-3 projects that could fix the bug
with a two lines change if they cared about Mono.
--
Jérémie Laval
Stifu wrote:
Your opinion makes sense, but then, why bother with Windows.Forms (or other
things like pseudo-Windows registry support), for example? The Mono team
You're missing the point. WinForms, Registry are publicly documented
APIs.
Robert
___
What about developers who don't care about Mono, but some of their users
being interested in running their app in Mono?
Sure, they could contact the devs to insist on supporting Mono, but then,
first, the app must still be under development, which is not obviously the
case, and second, the devs
Take the reverse situation, why would Mono devs care on supporting
application X because some users would like to run X on Mono ?
The only difference here is that, in your case, the developer has to take
care of one platform with minimal change involved where Mono would get ton
of request
About taking developer time: point taken. No matter how small the change is,
if there are 50 such demands, things get different quickly. Unless, of
course, the patch is submitted by a 3rd party, in which case the it's only
reviewing time, which in most cases should be negligible.
And although
Hey.
Take the reverse situation, why would Mono devs care on supporting
application X because some users would like to run X on Mono ?
It depends on what the mono team sees as the goal of mono.
If it is to provide a nice programming environment for linux programmers
to make linux applications,
Have you opened bugs on their bug tracking systems? If yes, this
discussion should be placed there. If not, you should open them, and
provide patches (maybe they didn't do it on purpose, and would be very
grateful of someone trying to remove workarounds/hacks from their code).
Regards,
Hm yeah, he gave the link to the bug report (in the message you quoted), and
it's obvious it's not been closed by mistake. And it's not about removing
workarounds or hacks from Mono, the hacks would be in the programs working
around the difference between .NET and Mono. :|
knocte wrote:
I'm talking about bugs opened *against* the frameworks, not against
Mono, because it's not a Mono bug.
Andrés
Stifu wrote:
Hm yeah, he gave the link to the bug report (in the message you quoted), and
it's obvious it's not been closed by mistake. And it's not about removing
Hello,
It depends on what the mono team sees as the goal of mono.
If it is to provide a nice programming environment for linux
programmers
to make linux applications, then no reason to change.
If it also is to make it easy for .net applications to run on linux,
and
to have windows
Hey Miguel,
It seems to me that talking to upstream developers and get them to
provide a more robust implementation from the get-go would be a much
better outcome. Have them probe for .NET version, fall back to Mono
and if none of those are available, gracefully degrade the functionality.
On Thu, Feb 12, 2009 at 7:40 PM, Lucas Meijer lu...@lucasmeijer.com wrote:
I'm not advocating for _not_ implementing more proper behaviour upstream.
I did not get the feeling (or maybe it is part of my lost email) that
I have heard the againsts yet.
So far I think it can be summarized as:
For what it's worth, you could argue that devs who added hacks to target .NET
or Mono are more likely to react and update their app to match a new Mono
behavior... Which, on the other hand, means that'd make like harder for
people who actually care about targeting Mono (but then, they're relying
Hello,
I added some comments to the bug, we can apply Robert's patch and
encourage developers in the meantime to use the graceful fallback setup
for now as it will be needed for anyone trying to run the software on
any Mono versions pre-2.6 (as this fix wont make it into Mono until Mono
2.6)
25 matches
Mail list logo
