Board index » delphi » Re: Do you have a Road Map?

Re: Do you have a Road Map?


2005-08-15 03:37:05 AM
delphi202
Brian Moelk writes:
Quote

No, I do understand how .NET is supposed to work. I also understand
whose responsibility it is on each side of the implementation.

But what I also understand is that Theory and Practice are two
different things. I also understand that I cannot rely on a vendor
that officially doesn't support something, to actually support that
something just because it is "supposed to work". I also understand
that in this case, mono has more of an interest in making sure their
C# compiler works as designed and less incentive to ensure that
Delphi for .NET does.
That you keep equating Mono's implementation with the C# language shows
quite clearly that you *do not* understand.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"The two most abundant elements in the universe are hydrogen and
stupidity." - Harlan Ellison
 
 

Re: Do you have a Road Map?

Brian Moelk writes:
Quote

With Delphi for .NET I can only go to Borland, and if I try to go
back to the mono guys I suspect their help will be more limited since
they are more focused on C# support. And if Delphi for .NET actually
has it wrong but it still works on Windows, what to do then?
If you have Delphi code that works in .Net but not on Mono, then what you
take to the Mono people is the IL produced by Delphi and ask them why that
IL doesn't work *even though it is legal verfiable IL code*. They have no
valid recourse in claiming it is Borland's fault or that they don;t support
Delphi because it has nothing to do with it. It would only be Borland's
problem if the IL produced is actually incorrect (in which case, it would
have problems running on Windows .Net as well).
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"We've all heard that a million monkeys banging on a million
typewriters will eventually reproduce the entire works of Shakespeare.
Now, thanks to the Internet, we know this is not true." - Robert
Wilensky
 

Re: Do you have a Road Map?

Brian Moelk writes:
Quote
>The point is that Borland is only responsible for testing against the
>MS spec and implementation.

No, Borland chooses to only test against the MS spec and
implementation. They could test against mono if they wanted to.
If Mono fails to conforn to the MS spec, and thus fails to run IL code
produced by *any* .Net language that correctly conforms to the MS spec, then
there is nothing Borland can do about it, it is up to Mono to *fix* their
implementation.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
SpaceShipOne; GovernmentZero
 

Re: Do you have a Road Map?

Brian Moelk writes:
Quote

Ok perhaps "need" is the wrong word; mono clearly has an interest in
making their C# compiler and the C# language work with mono. If
there is only one language/compiler that will work on mono, it will
be their C# compiler.
Again this clearly points out a complete misunderstanding of .Net. One of
the whole points of the CLR is to be *language neutral*. All languages emit
IL and it is that IL that must meet standards and that their runtime must
implement. Mono is not being implemented *at all* against C#, it is being
implemented against the CLR. Indeed if they *were* coding against C#
specifically (or limiting their CLR implementation to only the IL that can
be produced by their own C# implementation) then they would be failing
miserably and deservedly so and any sane developer would be running away
from Mono as fast as possible. If they were really doing it this way then
there is no way you could depend on Microsoft's C# compiler to be compliant
with Mono either since it may be different than Mono's, and could be changed
/ enhanced at any time to implement additional CLR features.
Quote
Certainly mono doesn't rely on C#, but we're talking about minimizing
risk in choosing a language if you want to use mono. If you feel
comfortable using Delphi for .NET for mono development, be my guest. But I
wouldn't, because I know if I posted a problem on the NG's or
QC or whereever re: mono, the first thing out of TeamB's and
Borland's mouth would be "Delphi for .NET does not officially support
mono".
Which is *exactly* the same response you will get from Microsoft if you have a
problem with code you produce using C# or VB.Net in Visual Studiio which
fails on Mono.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
Those who disdain wealth as a worthy goal for an individual or a
society seem not to realize that wealth is the only thing that can
prevent poverty. - Thomas Sowell
 

Re: Do you have a Road Map?

Hi Wayne,
Quote

The point is that Borland is only responsible for testing against the MS
spec and implementation. If Borland conforms there, but Mono doesn't work
with Borland generated code, then that is *Mono's* responsibility, not
Borland's.

If there is a general problem running D.Net binaries on Mono, I would bet it's
caused by that "overhead" D.Net adds to every class just to let them look
like D32 classes.
Within this (IMHO) mostly unnessary code, there's maybe something that
Mono hasn't been implemented yet.
D.Net should get a compiler switch to generate "normal" IL code, meaning a
class would have just those members you have declared or that have been
inherited from it is ancestor.
Things could look different that way, regarding Mono compatibility.
Also there would no need for this RTL Assembly (Borland.Delphi.dll).
Chrome creates additional code, too (e.g.: metaclasses, async/locked members).
But it won't require a 2nd RTL beside mscorelib.dll nor does it emit so
much of it, that it maybe can hit a hole in Mono's implementation.
Only guessing here, I didn't touched the D.Net compiler for quite some
time. This just seems to be the only difference between D.Net and other
.Net languages.
--- posted by geoForum on delphi.newswhat.com
 

Re: Do you have a Road Map?

Quote
Which is exactly what you can do with Borland. Absolutely no
difference here. So if that is the level of support you expect that is
what you'd get from Borland.
No, with C#, MS and Borland could help me. With Delphi for .NET, it is only
Borland.
Quote
Why do you keep thinking mono = C#. Mono is a CLR platform. It is
not a language. Period. You keep confusing languages that emit CLR
with the CLR VM. They are not the same.
No, I don't. I clearly understand they are different. But they are certainly
interrelated, and if I am building parts that are interrelated, I am going
to make sure it works for one of those pieces first, before the other. IOW,
making sure it works with C# will take priority over making sure it works
with Delphi for .NET.
Quote
If the mono guys are
presented with valid CLR that they can't handle then you'd think
they'd be concerned about fixing that. You would not be going to the
C# team, but to the mono team. They have different responsibilities.
Sure. But I'd have to rely on Borland only, to make sure that what is
produced from Delphi for .NET is valid or not. As the defacto standard,
C# provides an easier path and a larger number of people walking that path
before I do.
Quote
>And if Delphi for .NET actually has it wrong but
>it still works on Windows, what to do then?
You'd have to find a workaround. But you'd have the same problem when
you want to have one C# code base that VS C# under windows to generate
one CLR (which probably has the same bug or else would not work under
the Windows VM) and then use the Mono project's C# compiler over
there. You have to have two different code bases to do this.
#define/#if hardly equal two different code bases.
Quote
No they should be caring about being a CLR platform. That is the
whole point of mono. You clearly can't understand the difference
between languages and platforms. They are not the same. They are not
the same team on Mono.
I understand.
Quote
There are some people on both, but the C#
compiler team has the responsibility of writing a CLR code emitter for
the C# language.
The same people is a *huge* thing. One organization is an important point.
These are human and resource allocation issues, not technical spec compliance
issues.
Quote
The Mono people have the responsibility to write a
CLR VM. The Mono people should be concentrating on the whole CLR spec
not just the one that their C# compiler accepts.
"should" doesn't hold too much weight for me. Mono will support C#; Delphi
for .NET is up to how well both sides comply with the CLR spec.
Quote
Anders H. is quoted as stating that the current release of Delphi .NET
has more CLR compliance than the current C# compiler from MS, but even
though Delphi .NET emits CLR that the C# compiler for MS doesn't, the
MS VM (which is written to implement the WHOLE CLR spec) still runs
the Delphi .NET code.
Sure, but that illustrates my point even more. Let's say that mono only
supports a partial set of the CLR spec, but enough that C# will actually
run, but not enough that Delphi for .NET will. It doesn't matter who is
more "correct" in this case.
Quote
Oh, so in the end you are just arguing against Delphi just to be
argumentative. This is the first time you have even hinted that you do
not believe in the CLR vision MS presented with the .NET platform.
No. I do believe in the CLR vision. The problem is that there is a difference
between a vision and reality. Things in the real world don't always work
exactly like their specifications. There are inherent risks in making decisions
based on the belief that they do.
Quote
Too bad you can give non contradictory reasons for it.
It's very simple Jeff. Borland doesn't officially support mono with Delphi
for .NET. If I wanted to do mono work, why would I choose that when I know
that the mono guys have a C# compiler? I wouldn't. I would choose C#. Or I'd
select a dotNet language from a vendor that does support mono.
Quote
In the end all
I can conclude is that you don't think CLR is a good thing (since its
two major factors are that it is in of itself cross platform since it
gets compiled to CLR and that it is language neutral) and that you are
against Delphi .NET no matter what.
No. I think it is a great idea. But I am not going to choose a language for
mono from a vendor that doesn't support officially support mono. I don't
understand why that is so difficult to understand.
Quote
Seems to me that you would be
better off with either a) Java that has a complete VM already for
Linux (and mono today is not complete) and runs on some 20 odd other
OSes
Perhaps, I have used Java before but there are things there I don't like either.
Quote
or b) C++ which C# took many of its syntax from and you already
admit you plan on recompiling with different compilers on different
platforms and you have the option of using gcc there.
I've used C++ before as well; C++ is very different from C#.
Brian Moelk
XXXX@XXXXX.COM
www.brainendeavor.com
 

Re: Do you have a Road Map?

"Jeff Overcash (TeamB)" <XXXX@XXXXX.COM>writes
Quote

FTR, Borland already tells the mono group when they are finding problems
with
mono. Somehow several people in this thread think that there is no
communication, but that is not true.
Thanks Jeff, that is very good to know.
The onus should always be on the (virtual) machine vendors to maximize
compatibility, [ - also they'll get burnt the most]. But it is also in the
dev tools developer's interest to help out here..
- Roddy
 

Re: Do you have a Road Map?

Quote
Yes, but of course the argument Brian wants to make is that even if
DElphi .NET is 100% ECMA standards CLI compliant, mono is not required
to work with it and it is up to Borland to support it.
No, that is not my argument. Stop putting words in my mouth. No one is required
to do anything.
Quote
Instead of
mono having to correct their incorrect implementation of the standard.
I have never said that if Borland is generating incorrect CLI that
they are not responsible to fix that. I have problems that state that
if the problem is on the mono implementation then Borland has some
responsibility on that part.
I have never said such nonsense. Show me where I have said such a thing.
Quote
I also have a problem with expecting any
vendor t certify on a non complete implementation such as mono today.
It's all about commitment.
Brian Moelk
XXXX@XXXXX.COM
www.brainendeavor.com
 

Re: Do you have a Road Map?

Quote
If you have Delphi code that works in .Net but not on Mono, then what
you take to the Mono people is the IL produced by Delphi and ask them
why that IL doesn't work *even though it is legal verfiable IL code*.
They have no valid recourse in claiming it is Borland's fault or that
they don;t support Delphi because it has nothing to do with it.
That's right. If they say "yeah, we know we have issues, we'll get to it
when we can"...what can I do then? IMO, if I am using their C# compiler,
chances are it will work even if they have bugs that they haven't addressed.
Quote
It
would only be Borland's problem if the IL produced is actually
incorrect (in which case, it would have problems running on Windows
.Net as well).
Sure.
Brian Moelk
XXXX@XXXXX.COM
www.brainendeavor.com
 

Re: Do you have a Road Map?

Quote
That you keep equating Mono's implementation with the C# language
shows quite clearly that you *do not* understand.
I have not equated the two at all.
Brian Moelk
XXXX@XXXXX.COM
www.brainendeavor.com
 

Re: Do you have a Road Map?

Robert_G writes:
Quote

If there is a general problem running D.Net binaries on Mono, I would bet
it's caused by that "overhead" D.Net adds to every class just to let
them look like D32 classes.
Any extra code that Delphi may add still has to conform strictly to the CLR,
therefore it is still up to Mono to make sure it is able to handle that.
There is no way Borland should have to dumb down Delphi to conform to lowest
common denominator just because Mono (or anyone else) chooses (if they do)
to not implement the entire CLR correctly.
Quote
D.Net should get a compiler switch to generate "normal" IL code,
All IL produced by Delphi is "normal" IL. And again it would be absolutely
wrong for Borland to dumb things down below what the CLR is capable of.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"Nature abhors the vacuum tube." - J.R. Pierce, Bell Labs engineer who
coined the term 'transistor'
 

Re: Do you have a Road Map?

Quote
I don't know where you are getting this idea that C# is somehow safer
against Mono.
It's about incentive for vendors/communities to fix and provide workarounds.
Borland has no incentive to fix or provide workarounds if there are bugs
that occur due to anything but spec compliance. Borland doesn't officially
support the mono implementation of the CLR.
Mono the organization/community, because they produce the CLR and a C# compiler,
have incentive to make sure both sides work together. They will use the
spec to guide them, but like I said before, specs can be incomplete or ambiguous
in certain areas.
As Jeff pointed out, Mono might also be incomplete in their implementation
of the CLR spec. So chances are that the kinds of IL patterns that C# emits
will be tested more thoroughly than the kinds of IL that Delphi for .NET
emits. I suspect they will test C# IL first, other languages IL second.
It does me no good to know who to blame if my application doesn't work on
Mono. The only one ultimately responsible is me.
Quote
C# has *nothing* to do with the Mono implementation. C#
is just one language that emits IL code.
But C# emits different IL than Delphi for .NET right? They are not identical
in every case?
Quote
It is up to Mono to implement
the entire CLR, Mono does nothing whatsoever that is
language-specific.
Understood.
Quote
>So why is there no risk using Delphi for .NET for mono development?
>
There is exactly the *same* risk, no more and no less, than using C#
or VB.Net because it has *nothing* to do with the language!
If that is the case then why doesn't Borland officially support mono?
Brian Moelk
XXXX@XXXXX.COM
www.brainendeavor.com
 

Re: Do you have a Road Map?

Quote
As long as it is valid IL (which it must be or it would not be
verifiable under .Net, let alone successfully execute) then it doesn't
matter if Delphi emits different IL then a C# compiler (or VB.Net, or
any other) for the equivalent source code. As long as it is legal IL
then it is up to Mono to handle it correctly.
Absolutely it is mono's responsibility.
Quote
What makes you think C#
is going to be any more "safe" with Mono?
I've tried to explain this to no avail.
Quote
Mono is not coded against
C#, it is coded against the CLR.
Sure.
Quote
C# *is not* the CLR. In fact C#
doesn't surface many things that are part of the CLR - it is still up
to Mono to support those parts of the CLR even if not supported by C#.
That's exactly right. So if mono's implementation is currently incomplete,
or perhaps a little buggy or not tested as well in certain areas of the CLR
that Delphi for .NET actually uses and C# doesn't, I am going to run into
some bugs that I wouldn't run into if I simply used C#. No thank you.
Quote
How can Borland be responsible for Mono's implementation?
They aren't responsible, nor do I expect them to be responsible. They aren't
responsible for MS' implementation either. But they will test the hell out
of it and make sure that Delphi for .NET works on MS' implementation. That's
the difference.
Quote
.Net is the
platform, not Mono. It is up to *both* Borland and Mono to officially
support the CLR.
Sure.
Brian Moelk
XXXX@XXXXX.COM
www.brainendeavor.com
 

Re: Do you have a Road Map?

Brian Moelk writes:
Quote

Sure, but that illustrates my point even more. Let's say that mono
only supports a partial set of the CLR spec, but enough that C# will
actually run, but not enough that Delphi for .NET will. It doesn't matter
who
is more "correct" in this case.
Yes it does, it clearly means Mono is knowingly *failing* not only
technically, but in the entire goal of the CLR - to be *language-neutral*.
Why should Delphi be dumbed down just to cater to an incomplete
implementation of the CLR?
Quote
It's very simple Jeff. Borland doesn't officially support mono with
Delphi for .NET.
Neither does Visual Studio.
Quote
No. I think it is a great idea. But I am not going to choose a
language for mono from a vendor that doesn't support officially
support mono. I don't understand why that is so difficult to
understand.
That in itself is not hard to understand, that is your choice. What I don't
understand is the idea that Borland should dumb down Delphi in order to
cater to the limits of an incomplete or incorrect CLR implementation.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"The legitimate powers of government extend to such acts only as are
injurious to others. But it does me no injury for my neighbor to say
there are twenty gods, or no God. It neither picks my pocket nor breaks
my leg." - Thomas Jefferson
 

Re: Do you have a Road Map?

Quote
If Mono fails to conforn to the MS spec, and thus fails to run IL code
produced by *any* .Net language that correctly conforms to the MS
spec, then there is nothing Borland can do about it, it is up to Mono
to *fix* their implementation.
Sure. I never disagreed with that point.
Brian Moelk
XXXX@XXXXX.COM
www.brainendeavor.com