Re: DIP83

2016-01-16 Thread deadalnix via Digitalmars-d 

On Saturday, 16 January 2016 at 03:00:33 UTC, rsw0x wrote:
On Friday, 15 January 2016 at 11:58:19 UTC, Márcio Martins 
wrote:

On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:

[...]


True that. I think it's great to keep evolving the language 
and making it better, on the other hand, if D is to get 
serious adoption, then everything, especially the basics like 
debuggability, quality of codegen and compiler bugs will need 
to be solid. D as a language is already powerful enough to 
thrash the competition, this is why we love it. But the reason 
it's experiencing slow adoption, is because of tooling and 
general implementation quality, and the lower threshold of 
tolerance from the general population.


I think what he was pointing out is that many D features are 
currently barely functioning or not working and adding more 
features is just a waste of time.


Yes, that was the larger point.

Re: DIP83

2016-01-16 Thread deadalnix via Digitalmars-d 

On Friday, 15 January 2016 at 15:06:00 UTC, Yazan D wrote:

On Fri, 15 Jan 2016 13:20:18 +, deadalnix wrote:



Well I don't, both on OSX and linux, using the latest release. 
On linux I can do the addr2line dance, but on OSX I can't even 
do that as it require information that are gone once the 
program terminate.



Are you compiling with debug symbols on (-g)? You should get 
stacktraces on linux.


Yes, with function mangled names and symbol instruction's 
address. And only if I link with -export-dynamic , which is 
disabled by default on ld (and, really, shouldn't be necessary).

Re: DIP83

2016-01-15 Thread Márcio Martins via Digitalmars-d 

On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:

Ok I'll bite: it doesn't matter.

This DIP is additive. The problem with D is not that we don't 
have stuff in there, is most of the stuff in there are half 
backed. Adding more half baked things in there only makes 
things worse.


We don't have line number in stack traces, what does a better 
assert error message (that one can configure by code) will do  
? Worse, how is that consistent with the position that 
"Segfault are good enough with a debugger" and null by default 
reference types ?


There is no point in discussing the doorbell when the house has 
no window.


True that. I think it's great to keep evolving the language and 
making it better, on the other hand, if D is to get serious 
adoption, then everything, especially the basics like 
debuggability, quality of codegen and compiler bugs will need to 
be solid. D as a language is already powerful enough to thrash 
the competition, this is why we love it. But the reason it's 
experiencing slow adoption, is because of tooling and general 
implementation quality, and the lower threshold of tolerance from 
the general population.

Re: DIP83

2016-01-15 Thread deadalnix via Digitalmars-d 

On Friday, 15 January 2016 at 11:11:41 UTC, Tofu Ninja wrote:

On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:

We don't have line number in stack traces


Huh? We dont have line numbers in stack traces? I have line 
numbers, I am using latest dmd, or are you talking about one of 
the other compilers?


Well I don't, both on OSX and linux, using the latest release. On 
linux I can do the addr2line dance, but on OSX I can't even do 
that as it require information that are gone once the program 
terminate.

Re: DIP83

2016-01-15 Thread Atila Neves via Digitalmars-d 
On Thursday, 14 January 2016 at 19:51:37 UTC, Jacob Carlborg 
wrote:

On 2016-01-14 15:28, deadalnix wrote:

There is no point in discussing the doorbell when the house 
has no window.


+1. And AST macros would solve the problem (and a lot of other 
problems).


I used to think we didn't need AST macros until I hit the 
problems this DIP tries to address. After 2 years or so, I think 
you've finally convinced me Jacob ;)


Atila

Re: DIP83

2016-01-15 Thread Tofu Ninja via Digitalmars-d 

On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:

We don't have line number in stack traces


Huh? We dont have line numbers in stack traces? I have line 
numbers, I am using latest dmd, or are you talking about one of 
the other compilers?

Re: DIP83

2016-01-15 Thread Tofu Ninja via Digitalmars-d 

On Friday, 15 January 2016 at 13:20:18 UTC, deadalnix wrote:
Well I don't, both on OSX and linux, using the latest release. 
On linux I can do the addr2line dance, but on OSX I can't even 
do that as it require information that are gone once the 
program terminate.


Hmmm, I'm on windows so maybe that's it, pretty odd tho.

Re: DIP83

2016-01-15 Thread Yazan D via Digitalmars-d 
On Fri, 15 Jan 2016 13:20:18 +, deadalnix wrote:

> 
> Well I don't, both on OSX and linux, using the latest release. On linux
> I can do the addr2line dance, but on OSX I can't even do that as it
> require information that are gone once the program terminate.


Are you compiling with debug symbols on (-g)? You should get stacktraces 
on linux.

Re: DIP83

2016-01-15 Thread Jacob Carlborg via Digitalmars-d 

On 2016-01-15 11:21, Atila Neves wrote:


I used to think we didn't need AST macros until I hit the problems this
DIP tries to address. After 2 years or so, I think you've finally
convinced me Jacob ;)


:D

--
/Jacob Carlborg

Re: DIP83

2016-01-15 Thread rsw0x via Digitalmars-d 

On Friday, 15 January 2016 at 11:58:19 UTC, Márcio Martins wrote:

On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:

[...]


True that. I think it's great to keep evolving the language and 
making it better, on the other hand, if D is to get serious 
adoption, then everything, especially the basics like 
debuggability, quality of codegen and compiler bugs will need 
to be solid. D as a language is already powerful enough to 
thrash the competition, this is why we love it. But the reason 
it's experiencing slow adoption, is because of tooling and 
general implementation quality, and the lower threshold of 
tolerance from the general population.


I think what he was pointing out is that many D features are 
currently barely functioning or not working and adding more 
features is just a waste of time.

Re: DIP83

2016-01-15 Thread rsw0x via Digitalmars-d 

On Friday, 15 January 2016 at 13:20:18 UTC, deadalnix wrote:

On Friday, 15 January 2016 at 11:11:41 UTC, Tofu Ninja wrote:

On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:

We don't have line number in stack traces


Huh? We dont have line numbers in stack traces? I have line 
numbers, I am using latest dmd, or are you talking about one 
of the other compilers?


Well I don't, both on OSX and linux, using the latest release. 
On linux I can do the addr2line dance, but on OSX I can't even 
do that as it require information that are gone once the 
program terminate.


dmd generates stack traces on linux now
I think it was either ldc or gdc that did before.

Re: DIP83

2016-01-14 Thread deadalnix via Digitalmars-d 

Ok I'll bite: it doesn't matter.

This DIP is additive. The problem with D is not that we don't 
have stuff in there, is most of the stuff in there are half 
backed. Adding more half baked things in there only makes things 
worse.


We don't have line number in stack traces, what does a better 
assert error message (that one can configure by code) will do  ? 
Worse, how is that consistent with the position that "Segfault 
are good enough with a debugger" and null by default reference 
types ?


There is no point in discussing the doorbell when the house has 
no window.

Re: DIP83

2016-01-14 Thread Jacob Carlborg via Digitalmars-d 

On 2016-01-14 15:28, deadalnix wrote:


There is no point in discussing the doorbell when the house has no window.


+1. And AST macros would solve the problem (and a lot of other problems).

--
/Jacob Carlborg