View mode: basic / threaded / horizontal-split · Log in · Help
December 01, 2011
Re: DDT 0.5.0 ("Creamfields") released
> btw, 2 other small issues:

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

symName.startsWith("PROVIDE ("))
December 01, 2011
Re: DDT 0.5.0 ("Creamfields") released
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
Re: DDT 0.5.0 ("Creamfields") released
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
Re: DDT 0.5.0 ("Creamfields") released
> I think it's GDC what you mean

Indeed.
December 02, 2011
Re: DDT 0.5.0 ("Creamfields") released
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
Re: DDT 0.5.0 ("Creamfields") released
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
Re: DDT 0.5.0 ("Creamfields") released
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
Re: DDT 0.5.0 ("Creamfields") released
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
Re: DDT 0.5.0 ("Creamfields") released
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
Re: DDT 0.5.0 ("Creamfields") released
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
1 2 3 4
Top | Discussion index | About this forum | D home