It seems I didn't explain myself very clearly.
Daniel Keep wrote:
>> The point of non-nullables would be to detect improper usage at compile-time, right? Then I don't believe this problem has an elegant solution until compilers can do a rigorous control-flow analysis. Specifying default pointer values other than null doesn't seem very nice.
> > You don't need control-flow analysis. You just need a type system which supports nullables like D2's supports const.
You need control-flow analysis to know at compile-time if:
* an uninitialized value is read, or
* a null pointer is dereferenced.
>> Nonetheless, a good step forward would be to recognize the distinction between `null' and `uninitialized'. Reading a variable that's uninitialized is an error. Reading a null pointer is fine, but dereferencing it is an error.
> > Uninitialised variables is only a symptom. The larger issue is that it doesn't make sense for most functions to accept null object arguments. It's quite rare, at least in my code, to have a function that can do anything sensible with "nothing" other than HCF [1].
I understand the issue. In my idea, there are non-nullable pointers. In fact, they would probably be the default kind of pointer. But Christopher explained those kinds of pointers have their own problems. How to initialize an array of non-nullables? Or a struct?
So formally introduce the notion of `uninitialized' variables, or in particular, pointers. No need to initialize (even non-nullables) right away. Just initialize anytime. I believe in D you specify this with =void.
But don't you see, you've replaced your null-dereference problem with a uninitialized-reading problem. That's basically the same deal.
> We already have a runtime check, and
> it's not good enough. The major issue is that it notifies us of a
> problem at a time when we generally do not have any useful information
> on how to solve it.
Exactly. This brings me back to the need for rigorous control-flow analysis. Without it, you can't get your info at compile-time in the general case.
--
Michiel Helvensteijn

Leandro Lucarella wrote:
> How many people is using that? How bad would it be to call the next version of DMD that include the Tango/Druntime runtime D 1.100 or something (is really hard to pick right version numbers under the version scheme you use[*]) to make clear there is compatibility break in that version?
> > [*] I really wonder how would you call D2 when it's stable. You will just
> say D 2.134 is D2 final/stable? I think this is another problem with
> D, version naming is really confusing and lame. You can't know
> anything from a D version number. And DMD compiler and D specs are too
> much coupled. It would be nice to have separate version numbers if you
> really want to encourage some kind of D standard and compiler vendors
> to start making D compilers.
For what it's worth, there's at least one other major product that follows a similar versioning scheme.. mysql.
Later,
Brad

Brad Roberts, el 9 de mayo a las 21:42 me escribiste:
> Leandro Lucarella wrote:
> > Brad Roberts, el 9 de mayo a las 12:31 me escribiste:
> >> If there's things that need to change in what the compiler emits, Walter has shown himself to be willing to rapidly change them where the required changes are clearly described in terms of both 'what' and 'why'. In other words, "it's broken" isn't sufficient but "if the frobble was changed to frobnosticator for each wobble, it would work" results in the next release having that change made.
> > > > BTW, here is something that should be fixed in the compiler to improve GNU
> > binutils support =)
> > http://d.puremagic.com/issues/show_bug.cgi?id=2932> > > > A great illustration of a less than ideal bug report. "A tool breaks in some way, fix the compiler." It's entirely possible that dmd is producing the wrong thing, but there's an definite lack of specificity about what's wrong on the compiler side. Those errors are coming out of the linker. It's not even particularly clear that the bug is with dmd and not the new linker (one that's not shipped as the default linker on any distribution yet, unless I've lost track again).
No, it's not (it's shipped but not as the default linker), because they are making sure that it works well with other tools. Usually when you use a tool that is a de facto standard and have some bug, people start relying in that bug as a feature. I know I had some linking bugs because of this, and I spotted them thanks to Gold. I'm not saying that Gold is perfect, but since it's a complete rewrite there are some bugs fixed (or things where is more strict than the old GNU ld) that should be adjusted to work well with the new linker.
I reported the bug because I think that could be the case. If is not, it's a Gold bug and it should be reported. If it is, it should be fixed in DMD. I don't have the knowlegde to check that myself, and that's why I reported the bug to both tools.
> In other words, it's not at all surprising to me that the bug report hasn't received a lot of attention yet.
So you are saying you have to be a compiler hacker to report a bug? Great, that make sense!
I think the error message is pretty clear (the ELF header size is supposed to be wrong). I think somebody that know the compiler can check if this bug report is right or if it's a bug in GNU Gold in a couple of minutes (maybe seconds). And BTW GDC and LDC works just fine. I guess you can argue that GDC uses the GCC backend which can be tightly coupled with GNU binutils being both a GNU product, but LDC is not. So the bug report has a high probability to be right, I wasn't saw the error message and run to the D bugzilla to report the bug, I tested other tools first, and from my own experience with Gold, when it said there was an error and I thought the error was in Gold, I was wrong and Gold was right (because what I said before, I was relying on some bugs in the old GNU ld), so I have some degree of confidence in that Gold is not a piece of crap full of bugs.
And you may take a look to the GNU Gold linker bug report: http://sourceware.org/bugzilla/show_bug.cgi?id=10126
It is having attention. That's why GNU tools are widely used and D isn't. This kind of things make very sad...
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
VECINOS RESCATARON A CABALLITO ATROPELLADO
-- Crónica TV

Leandro Lucarella wrote:
> Walter Bright, el 9 de mayo a las 22:05 me escribiste:
>> Leandro Lucarella wrote:
>>> Official? I don't see any official support for D in GDB. I can only find
>>> this patches:
>>> http://www.dsource.org/projects/gdb-patches/>> Dwarf has an official value for the language, DW_LANG_D = 0x13.
> > I'm talking about GDB. GDB has no official D support.
GDB officially supports Dwarf, and Dwarf officially has a D identifier. While gdb may not go any further than that, it's a start.
> There was a thread
> in the NG asking for possible copyright issues to include the GDB patch
> upstream, and it had no answer for example. I don't think you *have* to
> answer that mail, but I think helping this kind of things happening
> instead of ignoring them is good for D promotion too =)
Can you point me to that thread? There are an awful lot of posts, and I miss things.
>>> How is that? Most runtime code is not used by the user directly. And for
>>> this item I think not merging it does more damage than introducing
>>> a breaking change (is much better to introduce a breaking change to solve
>>> this problem than to add a predefined Posix version ;).
>> Tango chose to use a number of incompatible names and a fundamentally
>> different class hierarchy for the same thing(s).
> > How many people is using that? How bad would it be to call the next
> version of DMD that include the Tango/Druntime runtime D 1.100 or
> something (is really hard to pick right version numbers under the version
> scheme you use[*]) to make clear there is compatibility break in that
> version?
Given all the beating of breasts and rending of robes about D1 not being stable and breaking code even when a bug is fixed in it, I just can't see coming out with a new D1 that substantially breaks every existing D1 code base.
> Seriously, there were several (silly) compatibility breaks since 1.0 was
> out, I think is a huge issue that deserves it...
This is what I mean when I say that it's simply impossible to ask for breaking changes for D1 while pillorying D1 for breaking changes. I also believe it is impractical to divide D1 into two incompatible versions - then there'd be 3 D versions to simultaneously support.
D2 has already taken the steps necessary to support both Phobos and Tango.

Tomas Lindquist Olsen wrote:
> On Sun, May 10, 2009 at 12:05 AM, mpt <mpt@ikikiki.fi> wrote:
>> I keep making 2 mistakes in my D programs, and fixing them feels troublesome.
>>>> 1. Null references. I get a segfault and gdb is useless (ldc thing maybe).
> > Useless how? Generally LDC debug info should be decent. If not, we'd be glad to look into why that is!
I had a problem in the past where gdb would only output a bunch of ???'s like it does for stripped or optimized executables. This seems no longer to be the case. I stand corrected.

Brad Roberts, el 10 de mayo a las 10:12 me escribiste:
> Leandro Lucarella wrote:
> > > How many people is using that? How bad would it be to call the next version of DMD that include the Tango/Druntime runtime D 1.100 or something (is really hard to pick right version numbers under the version scheme you use[*]) to make clear there is compatibility break in that version?
> > > > [*] I really wonder how would you call D2 when it's stable. You will just
> > say D 2.134 is D2 final/stable? I think this is another problem with
> > D, version naming is really confusing and lame. You can't know
> > anything from a D version number. And DMD compiler and D specs are too
> > much coupled. It would be nice to have separate version numbers if you
> > really want to encourage some kind of D standard and compiler vendors
> > to start making D compilers.
> > For what it's worth, there's at least one other major product that follows a similar versioning scheme.. mysql.
At least MySQL uses major, minor, and patchlevel version numbering scheme ;)
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
The biggest lie you can tell yourself is
When I get what I want I will be happy

Walter Bright, el 10 de mayo a las 11:21 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el 9 de mayo a las 22:05 me escribiste:
> >>Leandro Lucarella wrote:
> >>>Official? I don't see any official support for D in GDB. I can only find
> >>>this patches:
> >>>http://www.dsource.org/projects/gdb-patches/> >>Dwarf has an official value for the language, DW_LANG_D = 0x13.
> >I'm talking about GDB. GDB has no official D support.
> > GDB officially supports Dwarf, and Dwarf officially has a D identifier. While gdb may not go any further than that, it's a start.
> > >There was a thread
> >in the NG asking for possible copyright issues to include the GDB patch
> >upstream, and it had no answer for example. I don't think you *have* to
> >answer that mail, but I think helping this kind of things happening
> >instead of ignoring them is good for D promotion too =)
> > Can you point me to that thread? There are an awful lot of posts, and I miss things.
I posted it in this very same thread, just before the link to the GDB
patches link. Here it is again:
http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html> >>>How is that? Most runtime code is not used by the user directly. And for
> >>>this item I think not merging it does more damage than introducing
> >>>a breaking change (is much better to introduce a breaking change to solve
> >>>this problem than to add a predefined Posix version ;).
> >>Tango chose to use a number of incompatible names and a fundamentally different class hierarchy for the same thing(s).
> >How many people is using that? How bad would it be to call the next version of DMD that include the Tango/Druntime runtime D 1.100 or something (is really hard to pick right version numbers under the version scheme you use[*]) to make clear there is compatibility break in that version?
> > Given all the beating of breasts and rending of robes about D1 not being stable and breaking code even when a bug is fixed in it, I just can't see coming out with a new D1 that substantially breaks every existing D1 code base.
It would break all existing D1 code base?
> >Seriously, there were several (silly) compatibility breaks since 1.0 was out, I think is a huge issue that deserves it...
> > This is what I mean when I say that it's simply impossible to ask for
> breaking changes for D1 while pillorying D1 for breaking changes. I also
> believe it is impractical to divide D1 into two incompatible versions
> - then there'd be 3 D versions to simultaneously support.
If the compiler were really open source, and the frontend were in a public repository, and fixes would be well separated patches, you wouldn't have to maintain 3 D version. You probably even have to maintain 2 D versions. Other people could take over and apply fixes to the stable D branches while you with D2. The problem is doing that right now is really hard, because to see what changed in the DMDFE from one version to another you have to download 2 complete compiler version, make a diff yourself and you end up with a big diff that you can't possible break in small chunks with individual bugfixes.
> D2 has already taken the steps necessary to support both Phobos and Tango.
But D2 is not nearly ready for production use. D1 is almost there... Is missing so little that it's frustrating.
In case you are not following the thread about interior pointers, here is another drawback for the Tango vs. Phobos problem, here is copy&pasted fragment:
I think it would be great to have a centralized place where to put this
improvements. This is another situation where I think Tango vs. Phobos
issue is killing D. When I started my work in the thesis I had to decide
whether to work with Phobos or Tango. I finally decided for Tango, because
is the only option for LDC and because is way better organized (and more
receptive to patches). But I hate knowing that my work will be available
(in the best case) only for people using Tango.
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
De tan fina la condesa, por no cagarse, reza.
-- Ricardo Vaporeso

Leandro Lucarella wrote:
> Walter Bright, el 10 de mayo a las 11:21 me escribiste:
> I posted it in this very same thread, just before the link to the GDB
> patches link. Here it is again:
> http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html
Thank you.
>> Given all the beating of breasts and rending of robes about D1 not being
>> stable and breaking code even when a bug is fixed in it, I just can't
>> see coming out with a new D1 that substantially breaks every existing D1
>> code base.
> > It would break all existing D1 code base?
I suspect it would break pretty much all the non-trivial code.
> If the compiler were really open source, and the frontend were in a public
> repository, and fixes would be well separated patches, you wouldn't have
> to maintain 3 D version.
It's not just me, it's the poor sap who has to maintain 3 different versions of his library.
>> D2 has already taken the steps necessary to support both Phobos and Tango.
> But D2 is not nearly ready for production use. D1 is almost there... Is
> missing so little that it's frustrating.
I don't believe that contract inheritance is the key to production use. There shouldn't be anything standing in the way of using D1 for production use, and in fact it is being used that way.
> In case you are not following the thread about interior pointers, here is
> another drawback for the Tango vs. Phobos problem, here is copy&pasted
> fragment:
> > I think it would be great to have a centralized place where to put this
> improvements. This is another situation where I think Tango vs. Phobos
> issue is killing D. When I started my work in the thesis I had to decide
> whether to work with Phobos or Tango. I finally decided for Tango, because
> is the only option for LDC and because is way better organized (and more
> receptive to patches). But I hate knowing that my work will be available
> (in the best case) only for people using Tango.
I don't believe that splitting D into yet another separate version can fix this, as then the user has to decide which D to use.

Leandro Lucarella wrote:
>>> There was a thread
>>> in the NG asking for possible copyright issues to include the GDB patch
>>> upstream, and it had no answer for example. I don't think you *have* to
>>> answer that mail, but I think helping this kind of things happening
>>> instead of ignoring them is good for D promotion too =)
>> Can you point me to that thread? There are an awful lot of posts, and I miss things.
> > I posted it in this very same thread, just before the link to the GDB
> patches link. Here it is again:
> http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html
If someone has a patch ready to submit to GDB, and needs some licensing change for it, I'm happy to provide that.

Leandro Lucarella wrote:
> I reported the bug because I think that could be the case. If is not, it's a Gold bug and it should be reported. If it is, it should be fixed in DMD. I don't have the knowlegde to check that myself, and that's why I reported the bug to both tools.
> >> In other words, it's not at all surprising to me that the bug report hasn't received a lot of attention yet.
> > So you are saying you have to be a compiler hacker to report a bug? Great, that make sense!
You seem to have missed my point. The point was, the more detailed the report, the clearer the steps to reproduce, the more obvious it is that the compiler is what's broken.. all of these things increase the likelihood of a bug report having a higher priority.
The incoming rate is higher than the fix rate (as evidenced by the number of open bugs) and so something has to give. All I was doing was illustrating some reasons that might have contributed to that specific report not having been fixed yet.
Do I encourage filing bugs without the level of detail I suggest help get bugs fixed fast? Absolutely. An un-filed bug is an un-fixed bug.
Take these points as ways to help make sure your important issues can be addressed quickly and easily.
Later,
Brad