On Fri, 25 May 2012 15:36:54 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Friday, May 25, 2012 13:52:05 simendsjo wrote:
>> Couldn't dmd automatically add an assert(c) in debug mode before accessing
>> members?
>
> That's been argued for ages. Walter is against it, because the OS already
> takes care of it with segfaults. you can either run the program again (which
> isn't necessarily true, but I believe with the programs that he seems to run
> normally, it is, so he's got somewhat of a skewed perspective on that), or if
> you have core dumps enabled, you can just examine the core dump to see what
> happened. Also, adding all of those assertions would also negatively impact
> non-release mode - and possibly by quite a bit, since it would be happening
> all over the place, so there's that to consider.
>
> Regardless, it's a rather devisive subject. I think that _most_ people would
> like to have such assertions added in non-release mode, but since Walter's
> against it, it's never happened.

No, I'd rather have a stack trace printed from the signal handler...

-Steve

On 05/25/12 21:36, Jonathan M Davis wrote:
> On Friday, May 25, 2012 13:52:05 simendsjo wrote:
>> Couldn't dmd automatically add an assert(c) in debug mode before accessing
>> members?
> 
> That's been argued for ages. Walter is against it, because the OS already takes care of it with segfaults. you can either run the program again (which isn't necessarily true, but I believe with the programs that he seems to run normally, it is, so he's got somewhat of a skewed perspective on that), or if you have core dumps enabled, you can just examine the core dump to see what happened. Also, adding all of those assertions would also negatively impact non-release mode - and possibly by quite a bit, since it would be happening all over the place, so there's that to consider.
> 
> Regardless, it's a rather devisive subject. I think that _most_ people would like to have such assertions added in non-release mode, but since Walter's against it, it's never happened.

It's bad enough that such check is forced by the compiler in non-release mode
when calling methods. That means you get to choose between not supporting
non-release builds at all, or having an awkward, unnatural API, for no other
reason than this compiler limitation.
Checking for non-null refs/pointers before accessing members would actually
be less problematic, as dereferencing null is *always* a bug, unlike the
method case, where it can be perfectly fine.
Tuning this behavior on a per-type basis via attributes would be best, but
that's not likely to happen soon, i guess.

artur

On Fri, 25 May 2012 22:00:21 +0200, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Fri, 25 May 2012 15:36:54 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> On Friday, May 25, 2012 13:52:05 simendsjo wrote:
>>> Couldn't dmd automatically add an assert(c) in debug mode before accessing
>>> members?
>>
>> That's been argued for ages. Walter is against it, because the OS already
>> takes care of it with segfaults.
(...)
>
> No, I'd rather have a stack trace printed from the signal handler...
>

I asked about that in learn some time ago, but I seem to remember the discussion ended as not enough information is present when the signal handler is called or something..?

On 2012-05-25 16:07, Dejan Lekic wrote:

> Well, the OT was about lacking of development tools. The author did not
> specify the level of proficiency. Sure many things are missing from
> current tools, but come on, the fact is that one can do a serious D
> project with Mono-D. Well, at least I think without a second thought
> that it is possible.

I do all my D coding with TextMate with a customized D bundle and the command line.

-- 
/Jacob Carlborg

Am Fri, 25 May 2012 18:25:10 +0400
schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>:

> I tried Mono-D. No dice, it uses about 1.5Gb of RAM on my 2 file "project".

That's odd. I have a few open projects and 180 MB memory use after loading the IDE. That's on 64-bit Linux. I've never had OOM issues with Mono-D.

> But it lacks:
> - fast editor ;)

That's in part due to how unprepared the poor GtkTextView was when it was told to highlight source code. I think it is neither optimized for setting/switching out thousands of tokens, nor for fixed width fonts where applicable (e.g. calculating column/line pixel offsets). GEdit and MonoDevelop both use GtkSourceView/GtkTextView btw.

-- 
Marco

On Monday, 28 May 2012 at 23:01:24 UTC, Marco Leise wrote:
> Am Fri, 25 May 2012 18:25:10 +0400
> schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>
>> But it lacks:
>> - fast editor ;)
>
> That's in part due to how unprepared the poor GtkTextView was when it was told to highlight source code. I think it is neither optimized for setting/switching out thousands of tokens, nor for fixed width fonts where applicable (e.g. calculating column/line pixel offsets). GEdit and MonoDevelop both use GtkSourceView/GtkTextView btw.
MonoDevelop uses Gtk# and created its own sorce editing widget (IIRC since v. 2.0)