On Sep 21, 2013, at 5:33 PM, Walter Bright <newshound2@digitalmars.com> wrote:

> On 9/21/2013 5:11 PM, Sean Kelly wrote:
>>> Tracking the column number is certainly doable, but it comes at a cost of memory consumption and some compile speed, since it has to be tracked in every token. I used to do it in the Digital Mars C compiler, but it was of only marginal utility and I dropped it.
>> 
>> Can't you just hold a pointer to the beginning of the line and subtract to find the column?  I agree that it's generally of marginal utility though.
> 
> Holding the pointer has a cost of memory consumption and compile speed :-) as well as having to have the source file buffer stay around throughout the compile (to compute column number you need the source in order to account for tabs & Unicode).
> 
> Of course, we can cheat and use a byte to store the column number, as after all, nobody has more than 256 columns.
> 
> Then you get a bug report where someone does. So raise it to an unsigned short, then, sigh, you get another bug report where someone's entire source file is on one line, and on it goes.

A single pointer per file isn't much memory and a write per line isn't much of a speed hit. Fair point about holding the file in memory except that DMD does this anyway. Mine wasn't a general comment so much as one specifically about the D front end. As for the rest, if you can see the problems with an approach before starting then don't do it that way. :-)

On 9/21/2013 6:09 PM, Sean Kelly wrote:
> A single pointer per file isn't much memory and a write per line isn't much
> of a speed hit. Fair point about holding the file in memory except that DMD
> does this anyway. Mine wasn't a general comment so much as one specifically
> about the D front end. As for the rest, if you can see the problems with an
> approach before starting then don't do it that way. :-)


It isn't once per file, it's once per node in the AST, plus all the copying around of the value(s).

On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote:
> On 9/21/2013 5:11 PM, Sean Kelly wrote:
>>> Tracking the column number is certainly doable, but it comes at a cost of
>>> memory consumption and some compile speed, since it has to be tracked in
>>> every token. I used to do it in the Digital Mars C compiler, but it was of
>>> only marginal utility and I dropped it.
>>
>> Can't you just hold a pointer to the beginning of the line and subtract to
>> find the column?  I agree that it's generally of marginal utility though.
>
> Holding the pointer has a cost of memory consumption and compile speed :-) as well as having to have the source file buffer stay around throughout the compile (to compute column number you need the source in order to account for tabs & Unicode).
>
> Of course, we can cheat and use a byte to store the column number, as after all, nobody has more than 256 columns.
> [...]

That would do: 255 means column 256 or higher (256+). You would please more than 99.99% of users :-)

On Sunday, September 22, 2013 04:38:40 Paul Jurczak wrote:
> That would do: 255 means column 256 or higher (256+). You would
> please more than 99.99% of users :-)

Except that most of us don't care about the column number. It's of marginal benefit at best, and it harms compilation speed, so it's not worth it IMHO.

- Jonathan M Davis

On 2013-09-22 01:45:33 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 9/21/2013 6:09 PM, Sean Kelly wrote:
>> A single pointer per file isn't much memory and a write per line isn't much
>> of a speed hit. Fair point about holding the file in memory except that DMD
>> does this anyway. Mine wasn't a general comment so much as one specifically
>> about the D front end. As for the rest, if you can see the problems with an
>> approach before starting then don't do it that way. :-)
> 
> It isn't once per file, it's once per node in the AST, plus all the copying around of the value(s).

You could *replace* the line number with a "byte from start of file" and then compute lazily either the line number or the column number for the rare times where you actually need to get the line or column number. (Ideally you'd also keep a map of the byte offset for the start of each line in a file to make that computation fast.)

Column values are of interest in an IDE because it can pinpoint the error more precisely. The IDE can show exactly where the error is (for instance with a dotted red underline), often allowing you to fix the error without even reading the error message (especially when it's a typo). With a background-compilation-as-you-type system you know almost immediately when you make an error, and you know where it is.

I do agree that it is of minor interest when you're reading the error log.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Saturday, 21 September 2013 at 19:51:42 UTC, Andrei Alexandrescu wrote:
> On 9/21/13 12:28 PM, QAston wrote:
>> Containers as planned for phobos need solving the issue of allocators
>> for them.  Andrei which is working on them is probably stuck in void
>> somewhere between compiletime and runtime worlds :)
>
> FWIW I am making solid progress on allocators. In places the design comes together really really unexpectedly nice.
>

That is the sign of great design, or because the error is so obviously that nobody checked against it. Can you give q quick update on that in some topic ?

On Saturday, September 21, 2013 23:17:23 Michel Fortin wrote:
> Column values are of interest in an IDE because it can pinpoint the error more precisely. The IDE can show exactly where the error is (for instance with a dotted red underline), often allowing you to fix the error without even reading the error message (especially when it's a typo). With a background-compilation-as-you-type system you know almost immediately when you make an error, and you know where it is.

A lexer being used by an IDE definitely needs the column number, but the normal compiler doesn't.

- Jonathan M Davis

From what I see, as a new user of D, D's current feature set is so exciting and rich enough that I'm willing to give it a try. However, I feel frustrated because some simple usage about some feature I excerice failed, take AA for example, it's a basic feature as described in TDPL, but I even can't use it to store an array indexed by a string (http://d.puremagic.com/issues/show_bug.cgi?id=10970),no matter whatever you explaned, it's the truth that I feel AA is not usable and I give up AA (or maybe whole D given that AA is advertised to be a very basic feature).It's really a big problem and you guys should focus more on it if D wanna gain more popularity IMHO.
On the other hand, D's feature is attractive, no matter how much buggy is it, the expectation that it'll be solved once D gain more popularity and more and more programmers are innvolved in D may keep me learn and practise D as a hobby, but where's the expectation comes from? IMHO, D need a more organized team, meet once a week or two on irc, report your effort and finally post it to public (maybe filtered) like Rust meeting on its wiki page. So that every new user is convinced that D's in a virtuous circle and every issue they care about is being worked on, as well as a future plan (if not being worked ATM) on those issues most mentioned in NG/IRC etc like GC.
FYI, as a new user both to D and Rust, Rust is more convinced to me in every aspect except for its current unstable status.Its mainpage, wiki page and github repo are far more informative and active than D's counter-part, why don't we learn from Rust?

Sincerely hope/wish D to be more successful!

On Sunday, 22 September 2013 at 03:37:02 UTC, Zhouxuan wrote:
> feature as described in TDPL, but I even can't use it to store an array indexed by a string

If you use the built in arrays instead of the std.container Array type it will work. It still shouldn't be segfaulting, but this isn't quite as basic a flaw as it seems, since the library Array type is pretty complex.

On 2013-09-22 03:32:26 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:

> On Saturday, September 21, 2013 23:17:23 Michel Fortin wrote:
>> Column values are of interest in an IDE because it can pinpoint the
>> error more precisely. The IDE can show exactly where the error is (for
>> instance with a dotted red underline), often allowing you to fix the
>> error without even reading the error message (especially when it's a
>> typo). With a background-compilation-as-you-type system you know almost
>> immediately when you make an error, and you know where it is.
> 
> A lexer being used by an IDE definitely needs the column number, but the normal
> compiler doesn't.

I was referring to how the IDE can show the compiler's error messages better when the column number is available, not to how it does syntax highlighting. Xcode uses this a lot, and clang's error log provides full character ranges for errors, not just a column number, making the visualization of errors much better and pleasant to work with.

But indeed, no one *needs* that. Like everything else, it's just a convenience.

I don't think it should be a priority, but rejecting the idea outright is shortsighted in my opinion.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca