Re: foo => "bar" key/value literals in D!

[Vladimir Panteleev via Digitalmars-d-announce]

On Tuesday, 31 May 2016 at 06:21:03 UTC, Andrei Alexandrescu 
wrote:

On 5/27/16 10:17 PM, Taylor Hillegeist wrote:
On Friday, 27 May 2016 at 18:10:59 UTC, Vladimir Panteleev 
wrote:

On Monday, 23 May 2016 at 19:00:40 UTC, Adam D. Ruppe wrote:

Have I gone completely mad?!?!


Yes, though what does it have to do with this thread? :D

This is by far the most appealing way to implement named 
arguments

that I've seen so far:

https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d


This is very nice... way more clean than I imagined possible.


s/args/make/g and we have a nice function for std.conv. -- 
Andrei


Do I gather from that that you propose adding only the overload 
that creates structs?

Re: foo => "bar" key/value literals in D!

[Vladimir Panteleev via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 09:19:46 UTC, John wrote:
On Friday, 27 May 2016 at 18:10:59 UTC, Vladimir Panteleev 
wrote:
This is by far the most appealing way to implement named 
arguments that I've seen so far:


https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d


Another cool thing this enables: object initializers.


Already in the link you quoted, FYI.

Re: Button: A fast, correct, and elegantly simple build system.

[H. S. Teoh via Digitalmars-d-announce]

On Mon, May 30, 2016 at 07:16:50PM +, Jason White via 
Digitalmars-d-announce wrote:
> I am pleased to finally announce the build system I've been slowly
> working on for over a year in my spare time:
> 
> Docs:   http://jasonwhite.github.io/button/
> Source: https://github.com/jasonwhite/button
> 
> Features:
> 
> - Correct incremental builds.
> - Automatic dependency detection (for any build task, even shell scripts).
> - Build graph visualization using GraphViz.
> - Language-independent. It can build anything.
> - Can automatically build when an input file is modified (using inotify).
> - Recursive: It can build the build description as part of the build.
> - Lua is the primary build description language.

Finally got around to looking at this (albeit just briefly). It looks
very nice!  Perhaps I'll try using it for my next project.

I'm particularly pleased with the bipartite graph idea. It's a very nice
way of sanely capturing the idea of build commands that generate
multiple outputs.  Also big plusses in my book are implicit dependencies
and use of inotify to eliminate the infamous "thinking pause" that older
build systems all suffer from (this idea was also advanced by tup, but
IMO Button looks a tad more polished than tup in terms of overall
design).  Of course, being written in D is a bonus in my book. :-D
Though realistically speaking it probably doesn't really matter to me as
an end user, other than just giving me warm fuzzies.

Unfortunately I don't have the time right now to actually do anything
non-trivial with it... but I'll try to give feedback when I do get
around to it (and I definitely plan to)!


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what 
you have now either.

Re: LDC+Dub+Vibe.d work on SmartOS 64bit now

[Oleg Nykytenko via Digitalmars-d-announce]

On Friday, 10 June 2016 at 21:40:22 UTC, flamencofantasy wrote:

In another one I get the following;
]# dub
Performing "debug" build using ldc2 for x86_64.
vibe-d:utils 0.7.28: target for configuration "library" is up 
to date.
vibe-d:data 0.7.28: target for configuration "library" is up to 
date.

vibe-d:core 0.7.28: building configuration "libevent"...
../../../.dub/packages/vibe-d-0.7.28/vibe-d/source/vibe/core/core.d(570): Error: static 
assert  "Unsupported OS!"
ldc2 failed with exit code 1.



My pull request with fix this issue merged to version 0.7.29. Use 
please version 0.7.29 or higher.

Re: LDC+Dub+Vibe.d work on SmartOS 64bit now

[Oleg Nykytenko via Digitalmars-d-announce]

On Friday, 10 June 2016 at 21:40:22 UTC, flamencofantasy wrote:

ld: fatal: library -levent: not found



I think need install libevent.

In howto on 
https://wiki.dlang.org/LDC%2BDub%2BVibe.d_on_SmartOS_64bit.

I think misprint in line:
# pkgin in binutils gmake cmake scmgit python35 autoconf gcc49 
gcc49-libs unzip libconfig livevent


change "livevent" -> "libevent".

Re: LDC+Dub+Vibe.d work on SmartOS 64bit now

[flamencofantasy via Digitalmars-d-announce]

On Thursday, 9 June 2016 at 12:30:30 UTC, Alexandr Basko wrote:
On Wednesday, 8 June 2016 at 14:13:48 UTC, flamencofantasy 
wrote:
On Wednesday, 8 June 2016 at 13:41:59 UTC, Alexandr Basko 
wrote:
On Wednesday, 8 June 2016 at 12:19:08 UTC, flamencofantasy 
wrote:
On Wednesday, 8 June 2016 at 08:00:03 UTC, Alexandr Basko 
wrote:

[...]


Excellent! Please post a howto. I would very much like to 
move my server from an LX branded zone to SmartOS.


Can I post howto in this thread? If yes, than i`m post it 
tomorrow also


Yes, please. Or if that's too much trouble just send to my 
email.

Thanks!


I wrote and post howto on 
https://wiki.dlang.org/LDC%2BDub%2BVibe.d_on_SmartOS_64bit.

It need to format, but it fully functional.


Thank you very much!

I followed the instructions and I was able to build ldc, dub but 
not vibe.d's examples.


I get some errors, in one case I get this;

# dub
Performing "debug" build using ldc2 for x86_64.
vibe-d:utils 0.7.30-alpha.2+commit.13.g4fcdbe9: target for 
configuration "library" is up to date.
vibe-d:data 0.7.30-alpha.2+commit.13.g4fcdbe9: target for 
configuration "library" is up to date.
vibe-d:core 0.7.30-alpha.2+commit.13.g4fcdbe9: target for 
configuration "libevent" is up to date.
vibe-d:http 0.7.30-alpha.2+commit.13.g4fcdbe9: target for 
configuration "library" is up to date.
http-server-example ~master: building configuration 
"application"...

ld: fatal: library -levent: not found
ld: fatal: library -levent_pthreads: not found
ld: fatal: file processing errors. No output written to 
.dub/build/application-debug-posix.solaris-x86_64-ldc_0-A00A2E31B9B960EA3878168DFC41B6A8/http-server-example

collect2: error: ld returned 1 exit status
Error: /opt/local/bin/gcc failed with status: 1
ldc2 failed with exit code 1.

In another one I get the following;
]# dub
Performing "debug" build using ldc2 for x86_64.
vibe-d:utils 0.7.28: target for configuration "library" is up to 
date.
vibe-d:data 0.7.28: target for configuration "library" is up to 
date.

vibe-d:core 0.7.28: building configuration "libevent"...
../../../.dub/packages/vibe-d-0.7.28/vibe-d/source/vibe/core/core.d(570): Error: static 
assert  "Unsupported OS!"
ldc2 failed with exit code 1.


I'll see if I can figure out what's happening sometime later when 
I have more time.


Thanks again!

Re: Berlin D Meetup June 2016

[Adil Baig via Digitalmars-d-announce]

Thank you!

On Fri, Jun 10, 2016 at 11:53 PM, Mike Parker via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 10 June 2016 at 16:39:41 UTC, Adil Baig wrote:
>
>> PS : When are the DConf 2016 videos coming to youtube?
>>
>
> http://forum.dlang.org/post/cmowazdybxcseeyax...@forum.dlang.org
>

Re: The Official D Blog is Live

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-06-10 20:21, Mike Parker wrote:


I didn't realize anything special was needed for that. How can I make it
so?


Unfortunately there doesn't seem to be an exact specification of what's 
required for the reader mode to be available. I can do some digging to 
see if I can find something.


--
/Jacob Carlborg

Re: The Official D Blog is Live

[Mike Parker via Digitalmars-d-announce]

On Thursday, 9 June 2016 at 09:06:18 UTC, Jacob Carlborg wrote:



I would prefer if the text did not hyphenate the words. I think 
it's easier to read whole words.


Agreed. Thanks for reminding me. They weren't showing up for me 
in Chrome at all and I had forgotten that I saw them in Firefox 
(and Safari). I got rid of the indented paragraphs as well. That 
was just ugly.




If possible, it would be great if the blog worked with the 
Safari reader mode.


I didn't realize anything special was needed for that. How can I 
make it so?

Re: Berlin D Meetup June 2016

[Mike Parker via Digitalmars-d-announce]

On Friday, 10 June 2016 at 16:39:41 UTC, Adil Baig wrote:

PS : When are the DConf 2016 videos coming to youtube?


http://forum.dlang.org/post/cmowazdybxcseeyax...@forum.dlang.org

Re: Beta release DUB 1.0.0-beta.1

[Nick Sabalausky via Digitalmars-d-announce]

On 06/08/2016 11:04 AM, Kagamin wrote:

BTW do people find nested comments particularly useful?


God yes. It's the *only* block comment I ever use. Non-nesting comment 
blocks are a worthless PITA with no real benefit: You can't comment out 
a block if the block already contains a block comment. You can't include 
a block comment inside documentation's sample code. All for...why?


The only real reason is C-compatibility, which I don't see much of a 
benefit in either - if you're porting C code to D that actually *relies* 
on the goofy behavior of /* */, then the C code's comments are a 
terrible mess and need fixing anyway.


I wish we could just abolish non-nesting comment syntax entirely.

Re: Berlin D Meetup June 2016

[Adil Baig via Digitalmars-d-announce]

PS : When are the DConf 2016 videos coming to youtube?

On Fri, Jun 10, 2016 at 8:21 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 10 June 2016 at 14:40:41 UTC, Ali Çehreli wrote:
>
>> On 06/10/2016 05:11 AM, Stefan Koch wrote:
>>
>>> On Wednesday, 8 June 2016 at 16:31:47 UTC, Ben Palmer wrote:
>>>
>>
>> Danny Arends will be giving a more detailed version of his lightning
 talk he gave at the D conference on his web server, "DaNode".

>>>
>> What presentation will there be  ?
>>>
>>
>> I think it's Danny Arends, giving a more detailed version of his
>> lightning talk he gave at the D conference on his web server, "DaNode". :p
>>
>> Ali
>>
>
> Oh Boy I overlooked it in the post.
> Shame on me :)
>

Re: Berlin D Meetup June 2016

[Stefan Koch via Digitalmars-d-announce]

On Friday, 10 June 2016 at 14:40:41 UTC, Ali Çehreli wrote:

On 06/10/2016 05:11 AM, Stefan Koch wrote:

On Wednesday, 8 June 2016 at 16:31:47 UTC, Ben Palmer wrote:


Danny Arends will be giving a more detailed version of his 
lightning

talk he gave at the D conference on his web server, "DaNode".



What presentation will there be  ?


I think it's Danny Arends, giving a more detailed version of 
his lightning talk he gave at the D conference on his web 
server, "DaNode". :p


Ali


Oh Boy I overlooked it in the post.
Shame on me :)

Re: Berlin D Meetup June 2016

[Ali Çehreli via Digitalmars-d-announce]

On 06/10/2016 05:11 AM, Stefan Koch wrote:

On Wednesday, 8 June 2016 at 16:31:47 UTC, Ben Palmer wrote:



Danny Arends will be giving a more detailed version of his lightning
talk he gave at the D conference on his web server, "DaNode".



What presentation will there be  ?


I think it's Danny Arends, giving a more detailed version of his 
lightning talk he gave at the D conference on his web server, "DaNode". :p


Ali

Re: The D language online tour - tour.dlang.org

[Seb via Digitalmars-d-announce]

On Friday, 10 June 2016 at 09:18:07 UTC, Martin Tschierschke 
wrote:

On Monday, 16 May 2016 at 17:32:06 UTC, André wrote:

Hi,

after another round of polishing, bug fixing, very useful user 
contributions and suggestions, I'd like to present the new 
home of the D language online tour:


http://tour.dlang.org/

Thank you very much to the D foundation for hosting this 
service!


If you would like to report errors or have suggestions, please 
use GitHub:


https://github.com/stonemaster/dlang-tour

Thanks & regards,
André


I just yesterday managed to go trough the tour - great work!

Just a few suggestions:
a) There should be a direct link to a form on every page to 
give feedback, if you find an error, if you are new it is way 
to complicated to search for the "right" place to put

hints for broken links or similar errors.


Yep we are aware of this 
(https://github.com/stonemaster/dlang-tour/issues/37) and once we 
split the tour into separate files (PR is already pending - 
https://github.com/stonemaster/dlang-tour/pull/224), this will 
happen!



b) The broken link is here:
http://tour.dlang.org/tour/welcome/4

Dub Repository points to: (http:// is missing) 
http://tour.dlang.org/tour/welcome/code.dlang.org


Reported: https://github.com/stonemaster/dlang-tour/pull/230

Thanks!

c) It would be very nice if the "swipe gesture" on an pad would 
be detected.
Or alternatively the forward an back button should be on the 
top to.


Hehe we have had similar ideas:

https://github.com/stonemaster/dlang-tour/pull/221

d) It would be very useful to add direct links to the chapters 
of:

Programming in D from Ali Çehreli


Already part of our roadmap - we just need a bit more man power 
;-)


https://github.com/stonemaster/dlang-tour/issues/193

Re: Berlin D Meetup June 2016

[Stefan Koch via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 16:31:47 UTC, Ben Palmer wrote:

Hi All,

The June Berlin D Meetup will be happening at 20:00 (note new 
time) on Friday the 17th of June at Berlin Co-Op 
(http://co-up.de/) on the fifth floor.


Danny Arends will be giving a more detailed version of his 
lightning talk he gave at the D conference on his web server, 
"DaNode".


Both alcoholic and non-alcoholic drinks will be available.

More details and an abstract of the talk are available on the 
meetup page here: 
http://www.meetup.com/Berlin-D-Programmers/events/231746496/


Thanks,
Ben.


Ah nice about the later start time :)

I'll be there.
What presentation will there be  ?

Re: Beta release DUB 1.0.0-beta.1

[Rory McGuire via Digitalmars-d-announce]

hmm, actually thats not quite the issue, I made a mock set of projects
and it works with both versions.
With 0.9.25 I get:
Sub package onyx-config: doesn't exist.

Whereas with 0.9.24 my package compiles. I'll see if I can figure out
why, sorry for the noise.

On Fri, Jun 10, 2016 at 11:53 AM, Rory McGuire  wrote:
> BTW: One other question, do you know of a bug where relative paths in
> dub packages have stopped working in recent versions?
>
> It seems like it always uses the path of the package being built
> rather than the dependencies own directory. I currently have to use
> 0.9.24.
>
> On Fri, Jun 10, 2016 at 11:00 AM, Sönke Ludwig
>  wrote:
>> Am 10.06.2016 um 10:02 schrieb Rory McGuire via Digitalmars-d-announce:
>>>
>>> I made a version that ignores comment like characters in strings.
>>> I've also made a version that requires the recipe to be on the second
>>> line.
>>>
>>> Both are in my fork of dub. I can fix my pull request to which ever
>>> one you guys prefer.
>>>
>>> The one that handles recipe anywhere has a flaw where it will still
>>> recognize a dub recipe even
>>> if the recipe is inside a nested comment (one would expect that to be
>>> commented out.
>>>
>>> (...)
>>
>>
>> My preference would be to use the one that requires the recipe to be at the
>> top for 1.0.0 and to get the generic version flawless for 1.1.0.

Re: The D language online tour - tour.dlang.org

[Martin Tschierschke via Digitalmars-d-announce]

On Monday, 16 May 2016 at 17:32:06 UTC, André wrote:

Hi,

after another round of polishing, bug fixing, very useful user 
contributions and suggestions, I'd like to present the new home 
of the D language online tour:


http://tour.dlang.org/

Thank you very much to the D foundation for hosting this 
service!


If you would like to report errors or have suggestions, please 
use GitHub:


https://github.com/stonemaster/dlang-tour

Thanks & regards,
André


I just yesterday managed to go trough the tour - great work!

Just a few suggestions:
a) There should be a direct link to a form on every page to give 
feedback, if you find an error, if you are new it is way to 
complicated to search for the "right" place to put

hints for broken links or similar errors.

b) The broken link is here:
http://tour.dlang.org/tour/welcome/4

Dub Repository points to: (http:// is missing) 
http://tour.dlang.org/tour/welcome/code.dlang.org


c) It would be very nice if the "swipe gesture" on an pad would 
be detected.
Or alternatively the forward an back button should be on the top 
to.


d) It would be very useful to add direct links to the chapters of:
Programming in D from Ali Çehreli

Re: Beta release DUB 1.0.0-beta.1

[Sönke Ludwig via Digitalmars-d-announce]

Am 10.06.2016 um 10:02 schrieb Rory McGuire via Digitalmars-d-announce:

I made a version that ignores comment like characters in strings.
I've also made a version that requires the recipe to be on the second line.

Both are in my fork of dub. I can fix my pull request to which ever
one you guys prefer.

The one that handles recipe anywhere has a flaw where it will still
recognize a dub recipe even
if the recipe is inside a nested comment (one would expect that to be
commented out.

(...)


My preference would be to use the one that requires the recipe to be at 
the top for 1.0.0 and to get the generic version flawless for 1.1.0.

Re: Beta release DUB 1.0.0-beta.1

[Rory McGuire via Digitalmars-d-announce]

On Fri, Jun 10, 2016 at 8:30 AM, Rory McGuire  wrote:
> On Thu, Jun 9, 2016 at 10:48 PM, Steven Schveighoffer via
> Digitalmars-d-announce  wrote:
>> On 6/9/16 4:37 PM, Sönke Ludwig wrote:
>>>
>>> Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:

 On 6/8/16 2:45 PM, Sönke Ludwig wrote:
 (...)
>
> Apart from what I've already mentioned in my first reply to Jacob, I
> think there is nothing else that couldn't be solved in either case.


 "It's still possible to put something else in front of it"

 I didn't get this. How is /+ different from /*? I thought the only issue
 was the nesting.
>>>
>>>
>>> I mean together with the restriction that it has to be the first /+ +/
>>> comment, it is possible to put // and /* style comments in front of it
>>> without interference.
>>
>>
>> Oh, didn't see that aspect. I'll answer this with your last point.
>>
>>>
> Okay, so at least 3 people favor supporting other comment styles, while
> I'm not convinced that supporting all comment styles is necessarily
> better, I wouldn't mind pulling an update. The relevant code section is
> here:
>
> https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288
>
>

 Thanks. Perhaps more debate is fruitless until someone steps up with an
 implementation :)
>>>
>>>
>>> Rory has started an implementation: https://github.com/dlang/dub/pull/872
>>>
>>> But this has brought up another issue. The idea was to allow the recipe
>>> comment to be anywhere in the file and be of any comment style. However,
>>> that basically almost requires a full D lexer (at least string literals
>>> need to be parsed in addition to the comment styles).
>>>
>>> I'm reluctant to include this in the current state, because the results
>>> for a program such as the following will be very confusing:
>>>
>>> bool foo(string str)
>>> {
>>> return str.startsWith("/*");
>>> }
>>>
>>> /* dub.sdl: ... */
>>> void main()
>>> {
>>> }
>>>
>>> The string literal will be recognized as the start of a comment and thus
>>> the real comment below will not be recognized. So I think we should
>>> either have a generic and correct version, or one that is restricted
>>> similar to the current one to sidestep such issues.
>>
>>
>> I think the idea to include it anywhere in the file is not worth the
>> trouble. I also wouldn't want to scroll through an entire file for such a
>> thing.
>>
>> But it also brings up the point, what if the first /+ comes after:
>>
>> return str.startsWith("/+");
>>
>>>
> 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then
> to avoid stretching the release schedule (it's technically a breaking
> change!).


 How would this be a breaking change? It seems an additive feature, and
 I'm not sure it's required to be there before the first 1.0 release.
>>>
>>>
>>> There could be a /* */ comment before the /+ dub.*: +/ one, which is now
>>> not considered as a recipe comment candidate. Depending on its contents,
>>> the behavior could change once /* */ is also recognized. However, that
>>> case would be easily detectable and a warning could be emitted instead,
>>> while falling back to the old behavior. So it's not really an issue
>>> after all.
>>>
>>
>> Yeah, comments are not hard to parse, if they are the first thing you are
>> expecting.
>>
>> I would say it doesn't have to be the first comment, but it has to be one of
>> the first things in the file. You can simply throw away other comments.
>>
>> You may want to just tell the user: look, this isn't perfect, it's not a D
>> parser. Expect reasonable results for reasonable situations :) If you have a
>> line of code that looks like it could match the sdl file, then put the true
>> sdl file above it.
>>
>> -Steve
>
>
>
> Could we not just make it a requirement that if the file starts with
> #!... on the first line then the second line _must_ be a comment with
> the dub file definition?
>
> It will be frustrating to try find the dub definition if its not near
> the top and if the definition starts to be complicated so that you
> can't see the copyright or whatever would usually be in the first
> comment then you probably shouldn't be using a single file dub project
> anyway.
>
> If that is released with dub 1.0 then the restriction can always be
> loosened up if there is enough demand.

I made a version that ignores comment like characters in strings.
I've also made a version that requires the recipe to be on the second line.

Both are in my fork of dub. I can fix my pull request to which ever
one you guys prefer.

The one that handles recipe anywhere has a flaw where it will still
recognize a dub recipe even
if the recipe is inside a nested comment (one would expect that to be
commented out.

The one that handles recipe on second line only 

Re: Beta release DUB 1.0.0-beta.1

[Rory McGuire via Digitalmars-d-announce]

On Thu, Jun 9, 2016 at 10:48 PM, Steven Schveighoffer via
Digitalmars-d-announce  wrote:
> On 6/9/16 4:37 PM, Sönke Ludwig wrote:
>>
>> Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:
>>>
>>> On 6/8/16 2:45 PM, Sönke Ludwig wrote:
>>> (...)

 Apart from what I've already mentioned in my first reply to Jacob, I
 think there is nothing else that couldn't be solved in either case.
>>>
>>>
>>> "It's still possible to put something else in front of it"
>>>
>>> I didn't get this. How is /+ different from /*? I thought the only issue
>>> was the nesting.
>>
>>
>> I mean together with the restriction that it has to be the first /+ +/
>> comment, it is possible to put // and /* style comments in front of it
>> without interference.
>
>
> Oh, didn't see that aspect. I'll answer this with your last point.
>
>>
 Okay, so at least 3 people favor supporting other comment styles, while
 I'm not convinced that supporting all comment styles is necessarily
 better, I wouldn't mind pulling an update. The relevant code section is
 here:

 https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288


>>>
>>> Thanks. Perhaps more debate is fruitless until someone steps up with an
>>> implementation :)
>>
>>
>> Rory has started an implementation: https://github.com/dlang/dub/pull/872
>>
>> But this has brought up another issue. The idea was to allow the recipe
>> comment to be anywhere in the file and be of any comment style. However,
>> that basically almost requires a full D lexer (at least string literals
>> need to be parsed in addition to the comment styles).
>>
>> I'm reluctant to include this in the current state, because the results
>> for a program such as the following will be very confusing:
>>
>> bool foo(string str)
>> {
>> return str.startsWith("/*");
>> }
>>
>> /* dub.sdl: ... */
>> void main()
>> {
>> }
>>
>> The string literal will be recognized as the start of a comment and thus
>> the real comment below will not be recognized. So I think we should
>> either have a generic and correct version, or one that is restricted
>> similar to the current one to sidestep such issues.
>
>
> I think the idea to include it anywhere in the file is not worth the
> trouble. I also wouldn't want to scroll through an entire file for such a
> thing.
>
> But it also brings up the point, what if the first /+ comes after:
>
> return str.startsWith("/+");
>
>>
 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then
 to avoid stretching the release schedule (it's technically a breaking
 change!).
>>>
>>>
>>> How would this be a breaking change? It seems an additive feature, and
>>> I'm not sure it's required to be there before the first 1.0 release.
>>
>>
>> There could be a /* */ comment before the /+ dub.*: +/ one, which is now
>> not considered as a recipe comment candidate. Depending on its contents,
>> the behavior could change once /* */ is also recognized. However, that
>> case would be easily detectable and a warning could be emitted instead,
>> while falling back to the old behavior. So it's not really an issue
>> after all.
>>
>
> Yeah, comments are not hard to parse, if they are the first thing you are
> expecting.
>
> I would say it doesn't have to be the first comment, but it has to be one of
> the first things in the file. You can simply throw away other comments.
>
> You may want to just tell the user: look, this isn't perfect, it's not a D
> parser. Expect reasonable results for reasonable situations :) If you have a
> line of code that looks like it could match the sdl file, then put the true
> sdl file above it.
>
> -Steve



Could we not just make it a requirement that if the file starts with
#!... on the first line then the second line _must_ be a comment with
the dub file definition?

It will be frustrating to try find the dub definition if its not near
the top and if the definition starts to be complicated so that you
can't see the copyright or whatever would usually be in the first
comment then you probably shouldn't be using a single file dub project
anyway.

If that is released with dub 1.0 then the restriction can always be
loosened up if there is enough demand.