www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - DDT 0.10.1 released

reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
A new version of DDT is out. Some fixes, and debugger and build 
improvements. Full changelog:
https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.10.1

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
May 02 2014
next sibling parent reply "Derix" <derix dexample.com> writes:
I'm on Linux 64-bit. I recently upgraded Eclipse to 4.3.2 and DDT
to 0.10.1 ... and at first I couldn't compile a thing anymore.

After googling some more, and burning a few more neurons, I
finally gathered some clues and narrowed the quest to the
dub.json file. I pieced together the following :

{
       "name" : "gtklessons",
       "description" : "A minimal D bundle.",
       "targetType" : "executable",
       "dependencies" : {
           "gtk-d:gtkd": ">=2.3.1"
       }
}

which somehow enables the build to complete.

The keys here were the line

       "targetType" : "executable",

together with the "dependencies" section.

There still are a bunch of things I don't get. First, building
takes forever, even with a very simple and short source, where it
used to take an insignificant number of seconds.

Then, a whole bunch of files I didn't ask for poped up in my
userland, more or less the whole gtkd package, sources and all,
even though it is already installed on the system (namely
/usr/include/dmd/gtkd2/). There must be a more clever way.

Third, isn't there a way to set all this at the IDE or working
set level instead of project-by-project ?

And finally I find that the number of options that can and must
go in this dub.json file is way too high, and that said options
are somehow poorly documented. Are there some easy-access
reference out there ?


And oh, the reason I updated in the first place was that I
understood that debugging was better with the newest version of
DDT. I must have missed something here too, because I still
can't properly debug as in "step-by-step in the source code". Any
hint ?
May 24 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 25/05/2014 04:44, Derix wrote:

 I'm on Linux 64-bit. I recently upgraded Eclipse to 4.3.2 and DDT
 to 0.10.1 ... and at first I couldn't compile a thing anymore.

 After googling some more, and burning a few more neurons, I
 finally gathered some clues and narrowed the quest to the
 dub.json file. I pieced together the following :

 {
        "name" : "gtklessons",
        "description" : "A minimal D bundle.",
        "targetType" : "executable",
        "dependencies" : {
            "gtk-d:gtkd": ">=2.3.1"
        }
 }

 which somehow enables the build to complete.

 The keys here were the line

        "targetType" : "executable",

 together with the "dependencies" section.

 There still are a bunch of things I don't get. First, building
 takes forever, even with a very simple and short source, where it
 used to take an insignificant number of seconds.

 Then, a whole bunch of files I didn't ask for poped up in my
 userland, more or less the whole gtkd package, sources and all,
 even though it is already installed on the system (namely
 /usr/include/dmd/gtkd2/). There must be a more clever way.


DDT does little more than call 'dub build' (for building) and 'dub 
describe' for resolving dependencies and figuring out the import path.
This sounds more like a DUB issue. What happens if you run 'dub build' 
in the linux console for your project? Is it quick or fast?

Same as with the gtkd sources. That seems like either a DUB issue, or an 
issue in how GTKD is packaged. Note that DUB should only download the 
gtkd bundle once per user, so it's not much of an issue, even if it 
duplicates /usr/include/dmd/gtkd2 .


 Third, isn't there a way to set all this at the IDE or working
 set level instead of project-by-project ?


What exactly do you want to set at working set level or IDE level? If it 
is project dependencies, then no, these should be set on a per-project 
basis, it makes little sense otherwise (for a variety of reasons).


 And finally I find that the number of options that can and must
 go in this dub.json file is way too high, and that said options
 are somehow poorly documented. Are there some easy-access
 reference out there ?


Bottom line, you must have a basic understanding of DUB to use DDT.
The reference for dub.json is:
http://code.dlang.org/package-format


 And oh, the reason I updated in the first place was that I
 understood that debugging was better with the newest version of
 DDT. I must have missed something here too, because I still
 can't properly debug as in "step-by-step in the source code". Any
 hint ?


This should work, yes. Are you sure the executable is being compiled 
with debugging symbols?
If so, I'll need more info. What does the GDB console in Eclipse say 
after you run a D application in a debug launch?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
May 28 2014
parent "Derix" <derix dexample.com> writes:
Thanks a lot for this detailed answers :-)

I did not have time to look into it yet, but I will as soon as I
can.
Jun 06 2014
prev sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Friday, 2 May 2014 at 17:27:37 UTC, Bruno Medeiros wrote:

 A new version of DDT is out. Some fixes, and debugger and build 
 improvements. Full changelog:
 https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.10.1


Is there a way how to add phobos autocompletion support. Because 
it is not usefull when it does not make autocompletion for import 
std... or stri... and anything from druntime or phobos library.
Jun 23 2014
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Monday, 23 June 2014 at 18:12:14 UTC, Daniel Kozak wrote:

 On Friday, 2 May 2014 at 17:27:37 UTC, Bruno Medeiros wrote:

 A new version of DDT is out. Some fixes, and debugger and 
 build improvements. Full changelog:
 https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.10.1


 Is there a way how to add phobos autocompletion support. 
 Because it is not usefull when it does not make autocompletion 
 for import std... or stri... and anything from druntime or 
 phobos library.


Ok I have found it, Window->Preferences->DDT->Compilers select 
compiler (dmd,gdc,ldc) Edit...->Add.. compiler system libraries
Jun 23 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 23/06/2014 19:17, Daniel Kozak wrote:

 On Monday, 23 June 2014 at 18:12:14 UTC, Daniel Kozak wrote:

 On Friday, 2 May 2014 at 17:27:37 UTC, Bruno Medeiros wrote:

 A new version of DDT is out. Some fixes, and debugger and build
 improvements. Full changelog:
 https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.10.1


 Is there a way how to add phobos autocompletion support. Because it is
 not usefull when it does not make autocompletion for import std... or
 stri... and anything from druntime or phobos library.


 Ok I have found it, Window->Preferences->DDT->Compilers select compiler
 (dmd,gdc,ldc) Edit...->Add.. compiler system libraries


Yeah, someone else had a similar problem recently. DDT tries to detect 
the location of the library source code folders relative to the compiler 
binary, but every other linux distro has its own different layout (plus 
with DMD/GDC/LDC variations).

What's yours so I can add to the auto-detection? Is it:
/usr/bin/dmd
/usr/include/dlang   (location of D runtime and Phobos source)
?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 24 2014
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Tuesday, 24 June 2014 at 14:33:44 UTC, Bruno Medeiros wrote:

 On 23/06/2014 19:17, Daniel Kozak wrote:

 On Monday, 23 June 2014 at 18:12:14 UTC, Daniel Kozak wrote:

 On Friday, 2 May 2014 at 17:27:37 UTC, Bruno Medeiros wrote:

 A new version of DDT is out. Some fixes, and debugger and 
 build
 improvements. Full changelog:
 https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.10.1


 Is there a way how to add phobos autocompletion support. 
 Because it is
 not usefull when it does not make autocompletion for import 
 std... or
 stri... and anything from druntime or phobos library.


 Ok I have found it, Window->Preferences->DDT->Compilers select 
 compiler
 (dmd,gdc,ldc) Edit...->Add.. compiler system libraries


 Yeah, someone else had a similar problem recently. DDT tries to 
 detect the location of the library source code folders relative 
 to the compiler binary, but every other linux distro has its 
 own different layout (plus with DMD/GDC/LDC variations).

 What's yours so I can add to the auto-detection? Is it:
 /usr/bin/dmd
 /usr/include/dlang   (location of D runtime and Phobos source)
 ?


On Archlinux:
/usr/bin/dmd -- /usr/include/dlang/dmd
/usr/bin/{ldc2,ldmd2} -- /usr/include/dlang/ldc
/usr/bin/gdc -- /usr/include/dlang/gdc
Jun 24 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 24/06/2014 18:53, Daniel Kozak wrote:

 Yeah, someone else had a similar problem recently. DDT tries to detect
 the location of the library source code folders relative to the
 compiler binary, but every other linux distro has its own different
 layout (plus with DMD/GDC/LDC variations).

 What's yours so I can add to the auto-detection? Is it:
 /usr/bin/dmd
 /usr/include/dlang   (location of D runtime and Phobos source)
 ?


 On Archlinux:
 /usr/bin/dmd -- /usr/include/dlang/dmd
 /usr/bin/{ldc2,ldmd2} -- /usr/include/dlang/ldc
 /usr/bin/gdc -- /usr/include/dlang/gdc



Are these :
/usr/include/dlang/dmd
/usr/include/dlang/ldc
/usr/include/dlang/gdc
the actual standard library import path *roots* ? That is, is there 
where object.d/object.di and core/* and std/* are located, or is another 
subfolder? (DMD sometimes has two import path roots , "druntime/import" 
and "phobos")

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 27 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 27 June 2014 at 15:28:30 UTC, Bruno Medeiros wrote:

 On 24/06/2014 18:53, Daniel Kozak wrote:

 Yeah, someone else had a similar problem recently. DDT tries 
 to detect
 the location of the library source code folders relative to 
 the
 compiler binary, but every other linux distro has its own 
 different
 layout (plus with DMD/GDC/LDC variations).

 What's yours so I can add to the auto-detection? Is it:
 /usr/bin/dmd
 /usr/include/dlang   (location of D runtime and Phobos source)
 ?


 On Archlinux:
 /usr/bin/dmd -- /usr/include/dlang/dmd
 /usr/bin/{ldc2,ldmd2} -- /usr/include/dlang/ldc
 /usr/bin/gdc -- /usr/include/dlang/gdc



 Are these :
 /usr/include/dlang/dmd
 /usr/include/dlang/ldc
 /usr/include/dlang/gdc
 the actual standard library import path *roots* ? That is, is 
 there where object.d/object.di and core/* and std/* are 
 located, or is another subfolder? (DMD sometimes has two import 
 path roots , "druntime/import" and "phobos")


$ ls /usr/include/dlang/dmd/
core  etc  index.d  object.di  std  unittest.d
Jun 27 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 27/06/2014 17:03, Dicebot wrote:

 On Friday, 27 June 2014 at 15:28:30 UTC, Bruno Medeiros wrote:

 On 24/06/2014 18:53, Daniel Kozak wrote:

 Yeah, someone else had a similar problem recently. DDT tries to detect
 the location of the library source code folders relative to the
 compiler binary, but every other linux distro has its own different
 layout (plus with DMD/GDC/LDC variations).

 What's yours so I can add to the auto-detection? Is it:
 /usr/bin/dmd
 /usr/include/dlang   (location of D runtime and Phobos source)
 ?


 On Archlinux:
 /usr/bin/dmd -- /usr/include/dlang/dmd
 /usr/bin/{ldc2,ldmd2} -- /usr/include/dlang/ldc
 /usr/bin/gdc -- /usr/include/dlang/gdc



 Are these :
 /usr/include/dlang/dmd
 /usr/include/dlang/ldc
 /usr/include/dlang/gdc
 the actual standard library import path *roots* ? That is, is there
 where object.d/object.di and core/* and std/* are located, or is
 another subfolder? (DMD sometimes has two import path roots ,
 "druntime/import" and "phobos")


 $ ls /usr/include/dlang/dmd/
 core  etc  index.d  object.di  std  unittest.d


Thanks, then that is indeed be the import root. (and the only one)

Can someone verify the same for LDC?


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jul 02 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 2 July 2014 at 11:05:46 UTC, Bruno Medeiros wrote:

 $ ls /usr/include/dlang/dmd/
 core  etc  index.d  object.di  std  unittest.d


 Thanks, then that is indeed be the import root. (and the only 
 one)

 Can someone verify the same for LDC?


Yes (I am the packager of all D stuff on Arch Linux)
Jul 02 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 02/07/2014 12:47, Dicebot wrote:

 On Wednesday, 2 July 2014 at 11:05:46 UTC, Bruno Medeiros wrote:

 $ ls /usr/include/dlang/dmd/
 core  etc  index.d  object.di  std  unittest.d


 Thanks, then that is indeed be the import root. (and the only one)

 Can someone verify the same for LDC?


 Yes (I am the packager of all D stuff on Arch Linux)


Just to confirm, object.di specifically is in /usr/include/dlang/ldc too ?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jul 02 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 2 July 2014 at 13:55:50 UTC, Bruno Medeiros wrote:

 On 02/07/2014 12:47, Dicebot wrote:

 On Wednesday, 2 July 2014 at 11:05:46 UTC, Bruno Medeiros 
 wrote:

 $ ls /usr/include/dlang/dmd/
 core  etc  index.d  object.di  std  unittest.d


 Thanks, then that is indeed be the import root. (and the only 
 one)

 Can someone verify the same for LDC?


 Yes (I am the packager of all D stuff on Arch Linux)


 Just to confirm, object.di specifically is in 
 /usr/include/dlang/ldc too ?


Yes. All standard stuff can be found using 
-I/usr/include/dlang/<dmd|ldc|gdc>.

It is also planned that bindings to any other D libraries will be 
stored at /usr/include/dlang/<library> (so that single 
-I/usr/include/dlang will locate all of them) but currently there 
are none in Arch repos.
Jul 02 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 02/07/2014 15:19, Dicebot wrote:

 It is also planned that bindings to any other D libraries will be stored
 at /usr/include/dlang/<library> (so that single -I/usr/include/dlang
 will locate all of them) but currently there are none in Arch repos.


For libraries, I don't care about such system specifics - as DUB should 
take care of that (and provide the import paths to other tools).

Hum, in fact, now that I think of it, this functionality I have on DDT 
to detect compiler installations and the standard library import roots, 
it should ideally reside in DUB itself.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jul 02 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 2 July 2014 at 15:26:56 UTC, Bruno Medeiros wrote:

 For libraries, I don't care about such system specifics - as 
 DUB should take care of that (and provide the import paths to 
 other tools).

 Hum, in fact, now that I think of it, this functionality I have 
 on DDT to detect compiler installations and the standard 
 library import roots, it should ideally reside in DUB itself.


For dub it is not really important as basic installation is 
usually taken care of by dmd.conf, it assumes already working 
compiler installation. Same goes for any additional libraries 
installed by distro package manager - dub won't know a single 
thing about those.

I don't know if DDT should care either though.
Jul 02 2014
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 02/07/2014 16:40, Dicebot wrote:

 On Wednesday, 2 July 2014 at 15:26:56 UTC, Bruno Medeiros wrote:

 For libraries, I don't care about such system specifics - as DUB
 should take care of that (and provide the import paths to other tools).

 Hum, in fact, now that I think of it, this functionality I have on DDT
 to detect compiler installations and the standard library import
 roots, it should ideally reside in DUB itself.


 For dub it is not really important as basic installation is usually
 taken care of by dmd.conf, it assumes already working compiler
 installation. Same goes for any additional libraries installed by distro
 package manager - dub won't know a single thing about those.

 I don't know if DDT should care either though.


You're right, for normal DUB operation (building, fetching dependencies, 
etc.), it matters not.
Rather this would be useful only for the "dub describe" layer of 
functionality, which is used only for IDEs and other tools wanting to 
work with DUB bundles (mostly figuring out the import path and other 
resolved information).

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jul 02 2014