Re: DDT 0.9.0 released - GDB debugging integration
Nice. Always keeping master bug fix complete with all completed features make people more likely to use tip. Another related method of managing versions that I've seen is to create forks when you want to do a release. On 2 Dec 2013 18:00, "Bruno Medeiros" wrote: > On 02/12/2013 10:35, eles wrote: > >> On Tuesday, 19 November 2013 at 13:15:43 UTC, Bruno Medeiros wrote: >> >>> On 18/11/2013 15:32, ilya-stromberg wrote: >>> On Monday, 18 November 2013 at 15:28:36 UTC, Jacek Furmankiewicz wrote: > Quick question: with the current version is it possible to use it with > a dub project at all (maybe via a manual project setup)? > > I was trying to manually set it up, pointing "sources" as the source > folder and trying to get the ~/.dub/packages into the list of > libraries, but it did not seem to like it... > Yes, manual setup is possible, but you must use absolute path without `~`. >>> >>> Exactly, although you can use some Eclipse resource variables in the >>> path of linked folders. >>> >> >> why this? >> >> https://github.com/bruno-medeiros/DDT/commit/ >> b7a57f9e0d7915734ba6b175acfc1fd53a7a92f4 >> >> > The commit it reverted was not meant to go to master, but to a branch. The > idea is that master is to be kept potentially shipable at all times, and > dub support is not ready (nor was it disabled in the original commit, which > is another way that it could be allowed to be commited to master). > > -- > Bruno Medeiros - Software Engineer >
Re: DUB 0.9.21 beta 1
On 2013-12-02 21:51, Sönke Ludwig wrote: I need to dig up the old discussions about this topic, I just seemed to remember that we reached a conclusion to require a root file also for libraries, but you are right that technically it's not required in this case (as in the the suggested alternative). Please let me know if you find it. Since DUB operates on packages and I don't really see the compelling advantage over "rdmd -main -unittest foo.d", I'd rather not complicate it further for this use case. An exception would be if foo is a single file package (yet to be implemented). Fair enough. -- /Jacob Carlborg
Re: DUB 0.9.21 beta 1
Am 02.12.2013 17:01, schrieb Jacob Carlborg: > On 2013-12-02 10:10, Sönke Ludwig wrote: > >> It errors out. An alternative would be to put _all_ source files as >> static imports into the generated module, but the main file will also be >> required for dependency based builds (--rdmd and possibly for DUB's own >> build system, once partial rebuilds work), so I figured it would be a >> good idea to already add it now and make sure that most projects have >> one when/if it gets important. > > I don't know why a main module is required for libraries in the first > place. It doesn't make sense. It's perfectly fine to have a library > consisting of two files which don't import each other. This must be > supported. > > To me, for libraries, it would make most sense to just specify a > directory and it would compile all those files in that directory. I need to dig up the old discussions about this topic, I just seemed to remember that we reached a conclusion to require a root file also for libraries, but you are right that technically it's not required in this case (as in the the suggested alternative). > >> Using "dub test --main-file=...". See also "dub test --help". > > I see. > >> Unit tests in a separate folder can for example have their own package >> description file and be handled separately. But "dub test" like it is >> now is just the minimal beginning, everything else still needs to be >> figured out/defined, ideas and opinions are welcome. > > For any testing tool worthy its name I would at least expect to be able > to use it like this: > > $ dub test ./directory > > Runs all test in the given directory, recursively $ dub test --root=./directory This doesn't work recursively, but a --recursive switch may be a good idea to add. > > $ dub test foo.d > > Runs all test in the given file > Since DUB operates on packages and I don't really see the compelling advantage over "rdmd -main -unittest foo.d", I'd rather not complicate it further for this use case. An exception would be if foo is a single file package (yet to be implemented).
Re: DDT 0.9.0 released - GDB debugging integration
On Monday, 2 December 2013 at 15:55:22 UTC, Bruno Medeiros wrote: On 02/12/2013 10:35, eles wrote: On Tuesday, 19 November 2013 at 13:15:43 UTC, Bruno Medeiros wrote: On 18/11/2013 15:32, ilya-stromberg wrote: On Monday, 18 November 2013 at 15:28:36 UTC, Jacek Furmankiewicz wrote: The commit it reverted was not meant to go to master, but to a branch. The idea is that master is to be kept potentially shipable at all times, and dub support is not ready (nor was it disabled in the original commit, which is another way that it could be allowed to be commited to master). Uf! I thought that you dropped the idea of dub support. Glad to hear that you did not.
Re: DUB 0.9.21 beta 1
On 2013-12-02 10:10, Sönke Ludwig wrote: It errors out. An alternative would be to put _all_ source files as static imports into the generated module, but the main file will also be required for dependency based builds (--rdmd and possibly for DUB's own build system, once partial rebuilds work), so I figured it would be a good idea to already add it now and make sure that most projects have one when/if it gets important. I don't know why a main module is required for libraries in the first place. It doesn't make sense. It's perfectly fine to have a library consisting of two files which don't import each other. This must be supported. To me, for libraries, it would make most sense to just specify a directory and it would compile all those files in that directory. Using "dub test --main-file=...". See also "dub test --help". I see. Unit tests in a separate folder can for example have their own package description file and be handled separately. But "dub test" like it is now is just the minimal beginning, everything else still needs to be figured out/defined, ideas and opinions are welcome. For any testing tool worthy its name I would at least expect to be able to use it like this: $ dub test ./directory Runs all test in the given directory, recursively $ dub test foo.d Runs all test in the given file -- /Jacob Carlborg
Re: LLDB support - Re: DDT 0.9.0 released - GDB debugging integration
On Thursday, 21 November 2013 at 13:56:38 UTC, Bruno Medeiros wrote: That claim is based on the observation that the latest GDC binary distributable for Windows (which even so is not quite official and of unknown stability) is based on DMD 2.060 whereas LDC has binary releases based on 2.063.2 ... Finally somebody who appreciates our efforts. ;) David
Re: DDT 0.9.0 released - GDB debugging integration
On 02/12/2013 10:35, eles wrote: On Tuesday, 19 November 2013 at 13:15:43 UTC, Bruno Medeiros wrote: On 18/11/2013 15:32, ilya-stromberg wrote: On Monday, 18 November 2013 at 15:28:36 UTC, Jacek Furmankiewicz wrote: Quick question: with the current version is it possible to use it with a dub project at all (maybe via a manual project setup)? I was trying to manually set it up, pointing "sources" as the source folder and trying to get the ~/.dub/packages into the list of libraries, but it did not seem to like it... Yes, manual setup is possible, but you must use absolute path without `~`. Exactly, although you can use some Eclipse resource variables in the path of linked folders. why this? https://github.com/bruno-medeiros/DDT/commit/b7a57f9e0d7915734ba6b175acfc1fd53a7a92f4 The commit it reverted was not meant to go to master, but to a branch. The idea is that master is to be kept potentially shipable at all times, and dub support is not ready (nor was it disabled in the original commit, which is another way that it could be allowed to be commited to master). -- Bruno Medeiros - Software Engineer
Re: D programming workshop on Dec 15th, Shanghai
On Monday, 2 December 2013 at 12:07:59 UTC, Lionello Lunesu wrote: Hi, I'll be hosting a D workshop on the 15th in the XinCheJian hacker space, in Shanghai, China. ChangLe Rd 1035 2F, 长乐路1035号2楼 It'll take place from 1pm to 5pm and is meant for beginners. There will likely be a longer/advanced workshop the week after, depending on demand. The workshop is free, but 1 month membership to the hacker space is 100RMB, in case you're not a member already. Drop me a mail if you're interested. There'll be a formal announcement on http://www.xinchejian.com later this week. Tips are welcomed as well ;) Lio. Dang, I fly out of Shanghai on the 14th. Heading back to North America.
D programming workshop on Dec 15th, Shanghai
Hi, I'll be hosting a D workshop on the 15th in the XinCheJian hacker space, in Shanghai, China. ChangLe Rd 1035 2F, 长乐路1035号2楼 It'll take place from 1pm to 5pm and is meant for beginners. There will likely be a longer/advanced workshop the week after, depending on demand. The workshop is free, but 1 month membership to the hacker space is 100RMB, in case you're not a member already. Drop me a mail if you're interested. There'll be a formal announcement on http://www.xinchejian.com later this week. Tips are welcomed as well ;) Lio.
Re: DUB 0.9.20
Am 02.12.2013 12:25, schrieb Piotr Szturmaj: > Jordi Sayol wrote: >> El 30/11/13 02:08, Piotr Szturmaj ha escrit: >>> Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: >>> >>> Thanks! Have you considered adding a version number to dub help >>> and/or a --version option? >> >> $ dub help >> >> prints version on last line: >> >> >> DUB version v0.9.20 > > This is my dub help output (Windows): http://pastebin.com/0ENFz28V > Oh okay, that's for post-0.9.20. I've rewritten the command line interface code and forgot to add this. Will do now.
Re: DUB 0.9.20
Jordi Sayol wrote: El 30/11/13 02:08, Piotr Szturmaj ha escrit: Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Thanks! Have you considered adding a version number to dub help and/or a --version option? $ dub help prints version on last line: DUB version v0.9.20 This is my dub help output (Windows): http://pastebin.com/0ENFz28V
Re: DDT 0.9.0 released - GDB debugging integration
On Tuesday, 19 November 2013 at 13:15:43 UTC, Bruno Medeiros wrote: On 18/11/2013 15:32, ilya-stromberg wrote: On Monday, 18 November 2013 at 15:28:36 UTC, Jacek Furmankiewicz wrote: Quick question: with the current version is it possible to use it with a dub project at all (maybe via a manual project setup)? I was trying to manually set it up, pointing "sources" as the source folder and trying to get the ~/.dub/packages into the list of libraries, but it did not seem to like it... Yes, manual setup is possible, but you must use absolute path without `~`. Exactly, although you can use some Eclipse resource variables in the path of linked folders. why this? https://github.com/bruno-medeiros/DDT/commit/b7a57f9e0d7915734ba6b175acfc1fd53a7a92f4
Re: DUB 0.9.21 beta 1
Am 02.12.2013 09:19, schrieb Jacob Carlborg:
> On 2013-12-02 09:10, Sönke Ludwig wrote:
>
>> It's similar. By default, for library projects, it generates a maim
>> module of the form
>> ---
>> module test_main;
>> import ;
>> import std.stdio;
>> import core.runtime;
>>
>> void main() { writeln("All unit tests were successful."); }
>> ---
>> and runs it with build type "unittest".
>
> What if there isn't a main module for the library?
It errors out. An alternative would be to put _all_ source files as
static imports into the generated module, but the main file will also be
required for dependency based builds (--rdmd and possibly for DUB's own
build system, once partial rebuilds work), so I figured it would be a
good idea to already add it now and make sure that most projects have
one when/if it gets important.
>
>> It also supports setting a custom file containing main(), so that for
>> example custom unit test runners can be specified and similar things. In
>> this case, the generated file looks like this:
>> ---
>> module test_main;
>> import ;
>> import ;
>> ---
>
> How is the custom file specified?
Using "dub test --main-file=...". See also "dub test --help".
>
>> For packages with only executable configurations it behaves the same as
>> "dub run --build=unittest".
>
> This doesn't support having the unit tests in a separate folder?
>
Unit tests in a separate folder can for example have their own package
description file and be handled separately. But "dub test" like it is
now is just the minimal beginning, everything else still needs to be
figured out/defined, ideas and opinions are welcome.
Re: DUB 0.9.21 beta 1
On 2013-12-02 09:10, Sönke Ludwig wrote:
It's similar. By default, for library projects, it generates a maim
module of the form
---
module test_main;
import ;
import std.stdio;
import core.runtime;
void main() { writeln("All unit tests were successful."); }
---
and runs it with build type "unittest".
What if there isn't a main module for the library?
It also supports setting a custom file containing main(), so that for
example custom unit test runners can be specified and similar things. In
this case, the generated file looks like this:
---
module test_main;
import ;
import ;
---
How is the custom file specified?
For packages with only executable configurations it behaves the same as
"dub run --build=unittest".
This doesn't support having the unit tests in a separate folder?
--
/Jacob Carlborg
Re: DUB 0.9.21 beta 1
Am 02.12.2013 08:32, schrieb Jacob Carlborg:
> On 2013-11-30 21:48, Sönke Ludwig wrote:
>> Based on the bug reports so far, I've prepared a new beta release of
>> 0.9.21 for testing. Apart from fixes for the reported issues, it
>> contains a revamped command line interface with detailed help for each
>> command and also the new "dub test" command.
>>
>> http://code.dlang.org/download
>>
>> https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md
>>
>
> What exactly does "dub test" do? Is it like running "rdmd -main
> -unittest foo.d"?
>
It's similar. By default, for library projects, it generates a maim
module of the form
---
module test_main;
import ;
import std.stdio;
import core.runtime;
void main() { writeln("All unit tests were successful."); }
---
and runs it with build type "unittest".
It also supports setting a custom file containing main(), so that for
example custom unit test runners can be specified and similar things. In
this case, the generated file looks like this:
---
module test_main;
import ;
import ;
---
For packages with only executable configurations it behaves the same as
"dub run --build=unittest".
