December 01, 2011
> btw, 2 other small issues:

Oh just found out DDT gets confused by parens in strings:

symName.startsWith("PROVIDE ("))
December 01, 2011
I think it's GDC what you mean. And that's already good news. You could perhaps try somehow use the CDT's implementation of the GDB debugger communication, but GDB doesn't support D anywhere near to be usefully comfortable so there's a little gap in the toolchain atm, unfortunately.

On 1 December 2011 19:07, Trass3r <un@known.com> wrote:

> btw, 2 other small issues:
>>> - if you use autocompletion when the cursor is at the start of another identifier, it overwrites it instead of inserting.
>>>
>>
>> That is actually a matter of preference - believe it or not! Some IDEs offer the option to either insert or overwrite on auto-complete.
>>
>
> If you want overwrite mode, press your INS key ;)
> I'm ok with it becoming an option, but the default has to be insertion.
>
>
>  - GDB support would be awesome of course, but no hurry.
>>
> Already done in trunk.
>


December 01, 2011
I'm looking in to the type inference thing but it could take for a
while to implement it.
On the GDB issue I'm afraid GDB support isn't in the best shape yet,
but hopefully it would change at some point. Without a decent D
support of GDB maybe it won't be exactly the best experience, but
perhaps we should utilitize the CDT's GDB interface. see here:
http://groups.google.com/group/ddt-ide/browse_thread/thread/619e8192e9fb6ca3
and this:

Main problem - D DWARF extensions: http://d.puremagic.com/issues/show_bug.cgi?id=4180

Second: we should provide unittests for gdb for all basic test case for DMD/GDC/LDC. I start write it (you can try search patch in gdb-patches archive). But it cannot be done before than we resolve conflict with DWARF. DMD/GDC/LDC provide slightly different debug information. We should contact with compiler dev teams and try unify debug information (IMHO it should by close as possible to C/C++ form GCC).

Third: add support associative arrays and other D specific  features.

You can see all registered problems in debug information for DMD: http://d.puremagic.com/issues/show_bug.cgi?id=4044

Feel free to ask me about this subj. If I can I try help, but I am not DWARF/GDB expert ;)

2011/11/8, Gyula Gubacsi <gyula.gubacsi@gmail.com>:

> Hi,
>
> I was directed to you from the GDB mailing list as I was trying to get some information about what is the progress on D support in GDB. As I understand the only D specific extension was to add the dynamic arrays (I reckon, extension compared to C) and the name mangling rules.
>
> I am a newbie contributor to the DDT Eclipse plug-in project which doesn't make much sense without a useful, multi-platform command-line debugger and so far I couldn't find alternative to GDB. In fact, given that the GDB communication is already solved in the CDT plug-in, it would be the best idea to use the GDB.
>
> However, I had difficulties using GDB with D programs. I am willing to improve the D support in GDB but I need some description what should I start with, and what are the critical issues implementing a language interface for GDB.
>
> I hope you can clarify some issues if you have some time to write me.
>
> Sincerely
>
> Gyula Gubacsi / progician
>

I'm maybe overambitious over my time though :D


On 1 December 2011 18:29, Marco Leise <Marco.Leise@gmx.de> wrote:
>
> Am 01.12.2011, 17:54 Uhr, schrieb Trass3r <un@known.com>:
>
>
>> btw, 2 other small issues:
>> - if you use autocompletion when the cursor is at the start of another identifier, it overwrites it instead of inserting.
>
>
> That is actually a matter of preference - believe it or not! Some IDEs offer the option to either insert or overwrite on auto-complete.
>
> My personal wish list is:
> - Check Unicode identifiers. They are sometimes confusing the parser. (I should post example code here, really.)
> - Inference of 'auto' types like 'x' in 'foreach (ref x; list)'
> - I am using a symlinked Makefile in my projects instead of the build.rf. It's not like I'm doing anything fancy there for a debug build, but it has the advantage that updates to the options are propagated to all projects and I have the other targets (profile, unittest, release, ...) all in one place. Some way to support a custom Makefile build would be nice, even though the auto-generated script is quite handy to get started with D.
> - GDB support would be awesome of course, but no hurry.
December 02, 2011
> I think it's GDC what you mean

Indeed.
December 02, 2011
On 2011-12-01 19:29, Marco Leise wrote:
> Am 01.12.2011, 17:54 Uhr, schrieb Trass3r <un@known.com>:
>
>> btw, 2 other small issues:
>> - if you use autocompletion when the cursor is at the start of another
>> identifier, it overwrites it instead of inserting.
>
> That is actually a matter of preference - believe it or not! Some IDEs
> offer the option to either insert or overwrite on auto-complete.

Eclipse has that option, I don't know if it's for all editors or just for JDT.

-- 
/Jacob Carlborg
December 02, 2011
Am 01.12.2011, 20:35 Uhr, schrieb Trass3r <un@known.com>:

>> btw, 2 other small issues:
>
> Oh just found out DDT gets confused by parens in strings:
>
> symName.startsWith("PROVIDE ("))

It also doesn't like:

enum maxGroupNumber = 2^^19; // <- Syntax error on token "^", Expression expected after this token
December 02, 2011
On 12/1/11 12:18 PM, Bruno Medeiros wrote:
> On 27/11/2011 18:29, Trass3r wrote:
>> Does DDT use a separate thread for parsing?
>> Editing bigger files can be extremely laggy.
>
> It does use a separate thread for parsing (standard practice with any
> Eclipse IDE). Doesn't mean there can't be issues causing laggyness.
>
> I'm getting increasingly concerned with these reports of DDT becoming
> slow when editing large files, but I don't know how to replicate them (I
> don't program in D with large enough files to ever come across it), so
> unless someone gives me some test data - the files they are editing,
> machine specs, what they were doing (just typing or also doing content
> assist, etc.) - it will be very hard to address this issue!
>

Descent also started to work slowly with large files.

In my humble opinion, the problem is not the editor. If you have to edit a file 8000 lines long, then something's wrong with either how you program or the language (too verbose? not too compact?).

Might also be a problem with Eclipse... though I remember editing Java files that long and it worked more or less OK.
December 04, 2011
On 2011-12-02 17:24, Ary Manzana wrote:

> Descent also started to work slowly with large files.
>
> In my humble opinion, the problem is not the editor. If you have to edit
> a file 8000 lines long, then something's wrong with either how you
> program or the language (too verbose? not too compact?).

I completely agree with you, but it may be someone else code. std.datetime in Phobos is around 35+k lines of code, that's just completely mad in my opinion. The OS module in DWT/SWT is around 10k lines of code. Most of that code consists of declarations of OS specific functions, I guess they wanted to keep that in one file.

-- 
/Jacob Carlborg
December 06, 2011
On 01/12/2011 16:54, Trass3r wrote:
>>> Does DDT use a separate thread for parsing?
>>> Editing bigger files can be extremely laggy.
>>
>> It does use a separate thread for parsing (standard practice with any
>> Eclipse IDE). Doesn't mean there can't be issues causing laggyness.
>>
>> I'm getting increasingly concerned with these reports of DDT becoming
>> slow when editing large files, but I don't know how to replicate them
>> (I don't program in D with large enough files to ever come across it),
>> so unless someone gives me some test data - the files they are
>> editing, machine specs, what they were doing (just typing or also
>> doing content assist, etc.) - it will be very hard to address this issue!
>
> Ok, I'll try to come up with some test set the next time I experience this.
>
> btw, 2 other small issues:
> - if you use autocompletion when the cursor is at the start of another
> identifier, it overwrites it instead of inserting.
>
> So the cursor is left to foo, I press Ctrl+Space, choose something and
> it overwrites foo.
> Partial completion works correctly though: |foo -> dem|foo -> Ctrl+Space
> -> demangle|foo -> I choose my own demangleBla -> demangleBla| -> no foo
> anymore
>

Go to Preferences/DDT/Editor/Content Assist, change option "Completion Overwrites", to "Completion Inserts", and there you go. The default shall remain "Completion Overwrites" though, as I think that is more sensible. (even though in JDT the default is inserts :p )

Partial completion should always work according to this preference setting, so it's a bug that it always inserts. Opened:
http://code.google.com/a/eclipselabs.org/p/ddt/issues/detail?id=69

> - Is there a way to disable automatic builds on every save?
> I currently just delete the response file contents in D Compile Options
> and replace the command with echo "ok".

Go to Project in the main menu, deselect "Build automatically". Note, this is a workspace-global setting, nor per project. So now if you want to build use the menu or press "Ctrl-B" to start a workspace build: all projects whose resources have changed since the last build will be built.

-- 
Bruno Medeiros - Software Engineer
January 17, 2012
On 01/12/2011 17:44, Jacob Carlborg wrote:
> On 2011-12-01 16:18, Bruno Medeiros wrote:
>> On 27/11/2011 18:29, Trass3r wrote:
>>> Does DDT use a separate thread for parsing?
>>> Editing bigger files can be extremely laggy.
>>
>> It does use a separate thread for parsing (standard practice with any
>> Eclipse IDE). Doesn't mean there can't be issues causing laggyness.
>>
>> I'm getting increasingly concerned with these reports of DDT becoming
>> slow when editing large files, but I don't know how to replicate them (I
>> don't program in D with large enough files to ever come across it), so
>> unless someone gives me some test data - the files they are editing,
>> machine specs, what they were doing (just typing or also doing content
>> assist, etc.) - it will be very hard to address this issue!
>
> Well, just put a large library in a project, like Phobos, Tango or DWT.
> std.datetime in Phobos is 35+k lines of code. Then try different
> features like autocompletion and similar.
>

I'll try something like this, eventually. But we know that the performance of the parser is not that good.
What I was more concerned about, at least in more immediate terms, is significant performance regressions. That is, stuff that has gotten significantly slower with newer DDT releases... that shouldn't be happening at all. But a performance bug could have been introduced.

-- 
Bruno Medeiros - Software Engineer