subject:"Re\: Beta release DUB 1.0.0\-beta.1"

Re: Beta release DUB 1.0.0-beta.1

2016-06-17 Thread Sönke Ludwig via Digitalmars-d-announce


Am 17.06.2016 um 13:06 schrieb mark_mcs:

I'm not sure if this is a defect or a conscious decision so I thought
I'd ask the question first. Is there a reason why Dub on Windows uses
the APPDATA environment variable, rather than LOCALAPPDATA? The APPDATA
variable points to the roaming profile directory which means that my
entire Dub cache is uploaded when I log out, then downloaded again when
I log back in. Should I raise a github issue for this? Seems like an
easy fix for a 1.0.0 release.


It currently stores both, the configuration and cached packages in the 
same folder, while it should put the configuration in APPDATA and the 
cached packages in LOCALAPPDATA (so it's indeed a defect). It's an easy 
fix, but too late in the release process now. It could go into 1.0.1, 
though.

Re: Beta release DUB 1.0.0-beta.1

2016-06-17 Thread mark_mcs via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages, which can be used to write 
shebang-style scripts on Posix systems:


#!/usr/bin/env dub
/++ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/

void main()
{
import std.stdio : writefln;
import std.experimental.color.conv;
import std.experimental.color.hsx;
import std.experimental.color.rgb;

auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
writefln("Yellow in HSV: %s", 
yellow.convertColor!(HSV!()));

}

With "chmod +x" it can then simply be run as ./colortest.d.

Apart from that, the release contains some bug fixes, most 
notably it doesn't query the registry for each build any more.


Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

Download (Latest Preview):
http://code.dlang.org/download


I'm not sure if this is a defect or a conscious decision so I 
thought I'd ask the question first. Is there a reason why Dub on 
Windows uses the APPDATA environment variable, rather than 
LOCALAPPDATA? The APPDATA variable points to the roaming profile 
directory which means that my entire Dub cache is uploaded when I 
log out, then downloaded again when I log back in. Should I raise 
a github issue for this? Seems like an easy fix for a 1.0.0 
release.

Re: Beta release DUB 1.0.0-beta.1

2016-06-15 Thread Nick Sabalausky via Digitalmars-d-announce


On 06/13/2016 07:31 AM, Kagamin wrote:

On Friday, 10 June 2016 at 17:45:54 UTC, Nick Sabalausky wrote:

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.


Block comments are low-level: the commented code changes its lexical
structure completely, but you probably don't expect it and want it to
behave and be properly commented at a higher level, which is provided by
version statement.


No, I WANT commenting-out to be low-level, but just not have a stupid, 
useless, badly-chosen rule for when the block ends.


Version(none) is too high-level. I can't use it *within* a statement, 
which means I'd have to use one method to "comment-out" blocks of code 
and a different method when I comment out ex., params, args, or parts of 
an expression (all of which I occasionally do). But why would I want to 
do that when there's one construct (nesting block comments) that works 
perfectly for both AND actually gets highlighted as "disabled" in every 
editor and HTML highlighter out there so I can actually see at a glance 
what's disabled?

Re: Beta release DUB 1.0.0-beta.1

2016-06-13 Thread Sönke Ludwig via Digitalmars-d-announce


Am 13.06.2016 um 11:21 schrieb Andre Pany:

On Thursday, 9 June 2016 at 12:15:24 UTC, Sönke Ludwig wrote:

You need to use the --single switch:

dub build --single=app.d --build=release

For the commandline that you have used, the arguments "build
--build=release" will be passed to the compiled app.d executable
instead. I'll deploy proper documentation together with the release.


It is still not working. I have an easy example:

 file app.d ---

/+ dub.sdl:
  name "app"
+/

void main()
{
 import std.stdio;
 writeln("ABC");
}
 file app.d ---

While executing command:
dub --single=app.d

there is the error:
Error processing arguments: Can't parse string: bool should be
case-insensitive 'true' or 'false'

Is this a bug?

Kind regards
André


Oh sorry, I misremembered the type of the --single switch. Should be 
"dub --single app.d" instead, because it's actually a boolean switch.


BTW, it would be nice if std.getopt.getopt() would print the name of the 
argument in the error message.

Re: Beta release DUB 1.0.0-beta.1

2016-06-13 Thread Kagamin via Digitalmars-d-announce


On Friday, 10 June 2016 at 17:45:54 UTC, Nick Sabalausky wrote:

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.


Block comments are low-level: the commented code changes its 
lexical structure completely, but you probably don't expect it 
and want it to behave and be properly commented at a higher 
level, which is provided by version statement.

Re: Beta release DUB 1.0.0-beta.1

2016-06-13 Thread Saurabh Das via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages, which can be used to write 
shebang-style scripts on Posix systems:


[...]


That is really useful! Thanks again for all the work you put into 
dub and Vibe.

Re: Beta release DUB 1.0.0-beta.1

2016-06-13 Thread Andre Pany via Digitalmars-d-announce


On Thursday, 9 June 2016 at 12:15:24 UTC, Sönke Ludwig wrote:

You need to use the --single switch:

dub build --single=app.d --build=release

For the commandline that you have used, the arguments "build 
--build=release" will be passed to the compiled app.d 
executable instead. I'll deploy proper documentation together 
with the release.


It is still not working. I have an easy example:

 file app.d ---

/+ dub.sdl:
 name "app"
+/

void main()
{
import std.stdio;
writeln("ABC");
}
 file app.d ---

While executing command:
dub --single=app.d

there is the error:
Error processing arguments: Can't parse string: bool should be 
case-insensitive 'true' or 'false'


Is this a bug?

Kind regards
André

Re: Beta release DUB 1.0.0-beta.1

2016-06-11 Thread Manu via Digitalmars-d-announce

On 7 June 2016 at 19:54, Sönke Ludwig
 wrote:
> DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support for
> single-file packages, which can be used to write shebang-style scripts on
> Posix systems:
>
> #!/usr/bin/env dub
> /++ dub.sdl:
> name "colortest"
> dependency "color" version="~>0.0.3"
> +/
>
> void main()
> {
> import std.stdio : writefln;
> import std.experimental.color.conv;
> import std.experimental.color.hsx;
> import std.experimental.color.rgb;
>
> auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
> writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
> }
>
> With "chmod +x" it can then simply be run as ./colortest.d.
>
> Apart from that, the release contains some bug fixes, most notably it
> doesn't query the registry for each build any more.
>
> Full change log:
> https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
>
> Download (Latest Preview):
> http://code.dlang.org/download

Hey cool, thanks for the endorsement in your example! :P

Re: Beta release DUB 1.0.0-beta.1

2016-06-10 Thread 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: Beta release DUB 1.0.0-beta.1

2016-06-10 Thread 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: Beta release DUB 1.0.0-beta.1

2016-06-10 Thread 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

2016-06-10 Thread 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

2016-06-10 Thread 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.

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread Dechcaudron via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages, which can be used to write 
shebang-style scripts on Posix systems:


[...]


I've barely started using D, but dub works like a charm and makes 
development so easy! Thank you for creating such a great tool! :D

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread Steven Schveighoffer via Digitalmars-d-announce

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

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread Sönke Ludwig via Digitalmars-d-announce

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.

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

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()
{
}

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.

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread Steven Schveighoffer via Digitalmars-d-announce

On 6/8/16 2:45 PM, Sönke Ludwig wrote:

Am 08.06.2016 um 16:58 schrieb Steven Schveighoffer:

I agree with Jacob. A comment is a comment.

Well, there are normal comments, doc comments and now DUB recipe
comments. But at least if doc comments serve as an analogy, those are
possible with all three comment styles, so that could be taken as a
consistency argument.

There is no reason one needs
to use specifically /+. In fact the only reason for the existence of /+
is to allow nesting of comments -- which doesn't apply here. I'd say you
should support // comments as well.

SDLang supports C and C++ style comments as well, so could in fact apply
here. But probably you'd usually use // style comments in that case.

So this is definitely something concerning for allowing all comment
styles. If one wants to put comments in their sdl file, then one must
use an alternate style of commenting inside their sdl file. This makes
/+ much more attractive than the other styles.

But I think this is really just a documentation issue. The biggest
problem I would see is if someone used /* style comments in their sdl
file definition, but wanted to use /* style comments to include it, the
parser would prematurely close the whole comment block.

There's another aspect here, in that most people (even core D
developers) use the /* comment style */. So someone seeing the /+
comment might think this is a specialized dub thing.

Would there be any harm? Looking it up in either DUB's or DMD's
documentation would clarify that.

Not "harm", but confusion. I can see someone never looking this up,
because it may seem "obvious" the /+ is dub special. It's very minimal
impact, but something I just thought of.

I will finally say this: if such an implementation update existed, what
would be the reason NOT to pull it? That is, I think literally the only
reason not to support /* for this purpose is that nobody has done the
work. If you can give no better reason, it should take away any barriers
for anyone wishing to create this improvement.

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.

Thanks. Perhaps more debate is fruitless until someone steps up with an
implementation :)

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.

-Steve

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread Andre Pany via Digitalmars-d-announce


On Thursday, 9 June 2016 at 12:15:24 UTC, Sönke Ludwig wrote:

You need to use the --single switch:

dub build --single=app.d --build=release

For the commandline that you have used, the arguments "build 
--build=release" will be passed to the compiled app.d 
executable instead. I'll deploy proper documentation together 
with the release.


Thanks :)

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread Sönke Ludwig via Digitalmars-d-announce


Am 09.06.2016 um 12:23 schrieb Andre Pany:

On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:

DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is
support for single-file packages, which can be used to write
shebang-style scripts on Posix systems:

Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

Download (Latest Preview):
http://code.dlang.org/download


Hi,

Following command does not work:
dub app.d build --build=release

I want to compile the application without starting it.
Error: Expected one or zero arguments.

Is this by intention?

Kind regards
André


You need to use the --single switch:

dub build --single=app.d --build=release

For the commandline that you have used, the arguments "build 
--build=release" will be passed to the compiled app.d executable 
instead. I'll deploy proper documentation together with the release.

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread Andre Pany via Digitalmars-d-announce


On Thursday, 9 June 2016 at 10:43:31 UTC, drug wrote:

09.06.2016 13:23, Andre Pany пишет:
Untested, but try
```
dub build app.d --build=release
```


Unfortunately it is not working:
dub answers: Failed to find a package named 'app.d'.

Kind regards
André

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread drug via Digitalmars-d-announce


09.06.2016 13:23, Andre Pany пишет:

On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:

DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is
support for single-file packages, which can be used to write
shebang-style scripts on Posix systems:

Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

Download (Latest Preview):
http://code.dlang.org/download


Hi,

Following command does not work:
dub app.d build --build=release

I want to compile the application without starting it.
Error: Expected one or zero arguments.

Is this by intention?

Kind regards
André

Untested, but try
```
dub build app.d --build=release
```

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread Andre Pany via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages, which can be used to write 
shebang-style scripts on Posix systems:


Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

Download (Latest Preview):
http://code.dlang.org/download


Hi,

Following command does not work:
dub app.d build --build=release

I want to compile the application without starting it.
Error: Expected one or zero arguments.

Is this by intention?

Kind regards
André

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread Andre Pany via Digitalmars-d-announce


On Thursday, 9 June 2016 at 08:02:21 UTC, Mike Parker wrote:

On Thursday, 9 June 2016 at 07:35:35 UTC, Andre Pany wrote:


while calling dub within the directory containing app.d I


dub app.d

Without passing a file name, dub will look for a project 
configuration.


Thanks for the info. In my use case this behavior is cumbersome.

I created a build script for cloud foundry. Command "dub" is 
called
for the source files uploaded to cloud foundry. This command is 
buried

in the build script.

While seeing this new feature I thought I can develop a file app.d
instead of dub.json/source folder/app.d

I would vote for a fallback of command dub. If there is no 
dub.json/dub.sdl & source
folder but a app.d (convention) then as fallback dub is called 
with this file.


Any chance for this feature request? :)

As workaround I can adapt the build script to check for the files 
mentioned

and call dub one way or the other way.

Kind regards
André

Re: Beta release DUB 1.0.0-beta.1

2016-06-09 Thread Mike Parker via Digitalmars-d-announce


On Thursday, 9 June 2016 at 07:35:35 UTC, Andre Pany wrote:


while calling dub within the directory containing app.d I


dub app.d

Without passing a file name, dub will look for a project 
configuration.

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Nordlöw via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 
is...


Great work! I've spread the news to all my hackish friends.

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Rory McGuire via Digitalmars-d-announce

I made a little parser, it doesn't handle nested + comments (just
needs a depth check).
https://github.com/dlang/dub/pull/871


On Wed, Jun 8, 2016 at 9:44 PM, Rory McGuire  wrote:
> regex version pull request:
> https://github.com/dlang/dub/pull/869
>
> On Wed, Jun 8, 2016 at 8:50 PM, Rory McGuire  wrote:
>> On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig
>>  wrote:
>>> Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:

 On 2016-06-07 20:42, Sönke Ludwig wrote:

> No, it has to be the "+" variant (the first /+ +/ comment is evaluated).


 That's unfortunate.
>>>
>>>
>>> I generally really do appreciate your critique, but without backing reasons
>>> it doesn't really have a constructive effect.
>>>
>>> Two good properties about restricting to /+ +/ is that it's still possible
>>> to put something else in front of it, and that it stands out from the usual
>>> /* */ comments. Sure arguments can be made for supporting all comment types,
>>> but it shouldn't be forgotten that in the end this is a question of
>>> absolutely minimal impact.
>>>
>>> Just to be clear: If anyone has a good argument for supporting more/all
>>> comment types and there are no equally good arguments against it, please go
>>> ahead and implement it and it will be included. Let's just make this a quick
>>> decision, because changing it later on will mean breakage no matter how it's
>>> done.
>>
>> The only thing I can think to change would be that it doesn't have to
>> be the _first_ '/+...' but rather the first regex:
>> \n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n
>>
>> See [0] for regex in action on the code below.
>>
>> Sometimes we might want to put the dub config just above the main
>> function, and a lot of people like that to be at the bottom of the
>> file (who knows what comments might be above that and we wouldn't want
>> to break the way /+ ... +/ can be used anywhere to comment out code /
>> comments.
>>
>> concrete example:
>> #!/usr/bin/env dub
>> /**
>>  * Copyright (C) blah blah blah
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>> */
>> /+
>> // Example and/or documentation on changing this program
>> Some codeSome codeSome codeSome code
>> Some codeSome codeSome codeSome code
>> /*
>>  * Note that when doing the below !not threadsafe!...
>>  * see next example for threadsafe version.
>>  */
>> Some codeSome codeSome codeSome code
>> Some codeSome codeSome codeSome code
>> Some codeSome codeSome codeSome code
>> Some codeSome codeSome codeSome code
>> /*
>>  * This is the threadsafe version of above both are provided.
>>  * threadsafe version is not quite as fast
>>  */
>> Some codeSome codeSome codeSome code
>> Some codeSome codeSome codeSome code // this line has to be here
>> Some codeSome codeSome codeSome code
>>
>> +/
>>
>> /+ dub.sdl:
>> name "colortest"
>> dependency "color" version="~>0.0.3"
>> +/
>>
>> // implementation of support functions
>>
>> void main(string[] args) {
>> ...
>> }
>>
>>
>> [0] https://regex101.com/r/dR7xY1/1

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Rory McGuire via Digitalmars-d-announce

regex version pull request:
https://github.com/dlang/dub/pull/869

On Wed, Jun 8, 2016 at 8:50 PM, Rory McGuire  wrote:
> On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig
>  wrote:
>> Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:
>>>
>>> On 2016-06-07 20:42, Sönke Ludwig wrote:
>>>
 No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
>>>
>>>
>>> That's unfortunate.
>>
>>
>> I generally really do appreciate your critique, but without backing reasons
>> it doesn't really have a constructive effect.
>>
>> Two good properties about restricting to /+ +/ is that it's still possible
>> to put something else in front of it, and that it stands out from the usual
>> /* */ comments. Sure arguments can be made for supporting all comment types,
>> but it shouldn't be forgotten that in the end this is a question of
>> absolutely minimal impact.
>>
>> Just to be clear: If anyone has a good argument for supporting more/all
>> comment types and there are no equally good arguments against it, please go
>> ahead and implement it and it will be included. Let's just make this a quick
>> decision, because changing it later on will mean breakage no matter how it's
>> done.
>
> The only thing I can think to change would be that it doesn't have to
> be the _first_ '/+...' but rather the first regex:
> \n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n
>
> See [0] for regex in action on the code below.
>
> Sometimes we might want to put the dub config just above the main
> function, and a lot of people like that to be at the bottom of the
> file (who knows what comments might be above that and we wouldn't want
> to break the way /+ ... +/ can be used anywhere to comment out code /
> comments.
>
> concrete example:
> #!/usr/bin/env dub
> /**
>  * Copyright (C) blah blah blah
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
> */
> /+
> // Example and/or documentation on changing this program
> Some codeSome codeSome codeSome code
> Some codeSome codeSome codeSome code
> /*
>  * Note that when doing the below !not threadsafe!...
>  * see next example for threadsafe version.
>  */
> Some codeSome codeSome codeSome code
> Some codeSome codeSome codeSome code
> Some codeSome codeSome codeSome code
> Some codeSome codeSome codeSome code
> /*
>  * This is the threadsafe version of above both are provided.
>  * threadsafe version is not quite as fast
>  */
> Some codeSome codeSome codeSome code
> Some codeSome codeSome codeSome code // this line has to be here
> Some codeSome codeSome codeSome code
>
> +/
>
> /+ dub.sdl:
> name "colortest"
> dependency "color" version="~>0.0.3"
> +/
>
> // implementation of support functions
>
> void main(string[] args) {
> ...
> }
>
>
> [0] https://regex101.com/r/dR7xY1/1

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Rory McGuire via Digitalmars-d-announce

On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig
 wrote:
> Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:
>>
>> On 2016-06-07 20:42, Sönke Ludwig wrote:
>>
>>> No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
>>
>>
>> That's unfortunate.
>
>
> I generally really do appreciate your critique, but without backing reasons
> it doesn't really have a constructive effect.
>
> Two good properties about restricting to /+ +/ is that it's still possible
> to put something else in front of it, and that it stands out from the usual
> /* */ comments. Sure arguments can be made for supporting all comment types,
> but it shouldn't be forgotten that in the end this is a question of
> absolutely minimal impact.
>
> Just to be clear: If anyone has a good argument for supporting more/all
> comment types and there are no equally good arguments against it, please go
> ahead and implement it and it will be included. Let's just make this a quick
> decision, because changing it later on will mean breakage no matter how it's
> done.

The only thing I can think to change would be that it doesn't have to
be the _first_ '/+...' but rather the first regex:
\n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n

See [0] for regex in action on the code below.

Sometimes we might want to put the dub config just above the main
function, and a lot of people like that to be at the bottom of the
file (who knows what comments might be above that and we wouldn't want
to break the way /+ ... +/ can be used anywhere to comment out code /
comments.

concrete example:
#!/usr/bin/env dub
/**
 * Copyright (C) blah blah blah
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
*/
/+
// Example and/or documentation on changing this program
Some codeSome codeSome codeSome code
Some codeSome codeSome codeSome code
/*
 * Note that when doing the below !not threadsafe!...
 * see next example for threadsafe version.
 */
Some codeSome codeSome codeSome code
Some codeSome codeSome codeSome code
Some codeSome codeSome codeSome code
Some codeSome codeSome codeSome code
/*
 * This is the threadsafe version of above both are provided.
 * threadsafe version is not quite as fast
 */
Some codeSome codeSome codeSome code
Some codeSome codeSome codeSome code // this line has to be here
Some codeSome codeSome codeSome code

+/

/+ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/

// implementation of support functions

void main(string[] args) {
...
}

[0] https://regex101.com/r/dR7xY1/1

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Sönke Ludwig via Digitalmars-d-announce

Am 08.06.2016 um 16:58 schrieb Steven Schveighoffer:

I agree with Jacob. A comment is a comment.

> There is no reason one needs

to use specifically /+. In fact the only reason for the existence of /+
is to allow nesting of comments -- which doesn't apply here. I'd say you
should support // comments as well.

SDLang supports C and C++ style comments as well, so could in fact apply
here. But probably you'd usually use // style comments in that case.

There's another aspect here, in that most people (even core D
developers) use the /* comment style */. So someone seeing the /+
comment might think this is a specialized dub thing.

Would there be any harm? Looking it up in either DUB's or DMD's
documentation would clarify that.

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 would probably make sense to unify the comment matcher with the one
here, which currently doesn't support /+ +/ comments:
https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/internal/utils.d#L430

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!).

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Jacob Carlborg via Digitalmars-d-announce


On 2016-06-08 16:58, Steven Schveighoffer wrote:


I agree with Jacob. A comment is a comment. There is no reason one needs
to use specifically /+. In fact the only reason for the existence of /+
is to allow nesting of comments -- which doesn't apply here.


And basically the only reason why /+ exists and /* doesn't allow nesting 
is to be compatible with C.


--
/Jacob Carlborg

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Kagamin via Digitalmars-d-announce


On Wednesday, 8 June 2016 at 09:15:09 UTC, Sönke Ludwig wrote:
Two good properties about restricting to /+ +/ is that it's 
still possible to put something else in front of it, and that 
it stands out from the usual /* */ comments.


It stands out because we don't have a recognizable convention for 
such... processing instructions, every tool uses its own. BTW do 
people find nested comments particularly useful?

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Steven Schveighoffer via Digitalmars-d-announce


On 6/8/16 8:21 AM, Jacob Carlborg wrote:

On 2016-06-08 11:15, Sönke Ludwig wrote:


I generally really do appreciate your critique, but without backing
reasons it doesn't really have a constructive effect.

Two good properties about restricting to /+ +/ is that it's still
possible to put something else in front of it, and that it stands out
from the usual /* */ comments. Sure arguments can be made for supporting
all comment types, but it shouldn't be forgotten that in the end this is
a question of absolutely minimal impact.

Just to be clear: If anyone has a good argument for supporting more/all
comment types and there are no equally good arguments against it, please
go ahead and implement it and it will be included. Let's just make this
a quick decision, because changing it later on will mean breakage no
matter how it's done.


It's just that since the language support other styles of comments one
could think that all comments are supported and it will cause confusion
if only one style is supported. Otherwise it might be better to use a
UDA, if possible.

If one reads the documentation and copy pastes and example the user will
most likely get it right. But if you have a conversation saying
something like "it's possible to put the content of dub.json inline in
the source code, just put it in a comment" then someone will for sure
try using a comment style that is not supported.

The documentation needs to be very clear that only one type comments are
supported, if that's the conclusion.



I agree with Jacob. A comment is a comment. There is no reason one needs 
to use specifically /+. In fact the only reason for the existence of /+ 
is to allow nesting of comments -- which doesn't apply here. I'd say you 
should support // comments as well.


There's another aspect here, in that most people (even core D 
developers) use the /* comment style */. So someone seeing the /+ 
comment might think this is a specialized dub thing.


I will finally say this: if such an implementation update existed, what 
would be the reason NOT to pull it? That is, I think literally the only 
reason not to support /* for this purpose is that nobody has done the 
work. If you can give no better reason, it should take away any barriers 
for anyone wishing to create this improvement.


-Steve

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Mike Parker via Digitalmars-d-announce


On Wednesday, 8 June 2016 at 13:27:31 UTC, burjui wrote:
That reason alone is enough. Restricting DUB special comments 
to only /++/ will put users off, because now they know that 
there's a cool feature in DUB, but it only works with certain 
types of comments, that nobody wants to remember (why should 
they?), so they will decide that this feature is either broken 
or unfinished and will hardly use it at all.


We could make users' lives easier, if we allowed them to just 
specify the dependencies in Gradle style on a single line:


#!/usr/bin/env dub
// dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"


I don't understand this argument. There are two options: /++/ and 
/**/. If a user can't remember which one it is, it's a matter of 
a few seconds to find out. With all the things we need to 
remember about a language when programming, I hardly think 
something of this nature is going to put anyone off. And if they 
*are* put off by it, they've got bigger issues than trying to 
remember which comment style to use.

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Sönke Ludwig via Digitalmars-d-announce


Am 08.06.2016 um 15:27 schrieb burjui:

On Wednesday, 8 June 2016 at 12:21:57 UTC, Jacob Carlborg wrote:


It's just that since the language support other styles of comments one
could think that all comments are supported and it will cause
confusion if only one style is supported.


That reason alone is enough. Restricting DUB special comments to only
/++/ will put users off, because now they know that there's a cool
feature in DUB, but it only works with certain types of comments, that
nobody wants to remember (why should they?), so they will decide that
this feature is either broken or unfinished and will hardly use it at all.

We could make users' lives easier, if we allowed them to just specify
the dependencies in Gradle style on a single line:

#!/usr/bin/env dub
// dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"



But the user *will* remember the filename + colon requirement? Or will 
remember yet another format to specify dependencies? What if something 
else, such as compiler flags or link libraries need to be specified?


I'll stay out of this discussion until there is a conclusion now.

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread burjui via Digitalmars-d-announce


On Wednesday, 8 June 2016 at 12:21:57 UTC, Jacob Carlborg wrote:

It's just that since the language support other styles of 
comments one could think that all comments are supported and it 
will cause confusion if only one style is supported.


That reason alone is enough. Restricting DUB special comments to 
only /++/ will put users off, because now they know that there's 
a cool feature in DUB, but it only works with certain types of 
comments, that nobody wants to remember (why should they?), so 
they will decide that this feature is either broken or unfinished 
and will hardly use it at all.


We could make users' lives easier, if we allowed them to just 
specify the dependencies in Gradle style on a single line:


#!/usr/bin/env dub
// dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Jacob Carlborg via Digitalmars-d-announce


On 2016-06-08 11:15, Sönke Ludwig wrote:


I generally really do appreciate your critique, but without backing
reasons it doesn't really have a constructive effect.

Two good properties about restricting to /+ +/ is that it's still
possible to put something else in front of it, and that it stands out
from the usual /* */ comments. Sure arguments can be made for supporting
all comment types, but it shouldn't be forgotten that in the end this is
a question of absolutely minimal impact.

Just to be clear: If anyone has a good argument for supporting more/all
comment types and there are no equally good arguments against it, please
go ahead and implement it and it will be included. Let's just make this
a quick decision, because changing it later on will mean breakage no
matter how it's done.


It's just that since the language support other styles of comments one 
could think that all comments are supported and it will cause confusion 
if only one style is supported. Otherwise it might be better to use a 
UDA, if possible.


If one reads the documentation and copy pastes and example the user will 
most likely get it right. But if you have a conversation saying 
something like "it's possible to put the content of dub.json inline in 
the source code, just put it in a comment" then someone will for sure 
try using a comment style that is not supported.


The documentation needs to be very clear that only one type comments are 
supported, if that's the conclusion.


--
/Jacob Carlborg

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Sönke Ludwig via Digitalmars-d-announce


Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:

On 2016-06-07 20:42, Sönke Ludwig wrote:


No, it has to be the "+" variant (the first /+ +/ comment is evaluated).


That's unfortunate.


I generally really do appreciate your critique, but without backing 
reasons it doesn't really have a constructive effect.


Two good properties about restricting to /+ +/ is that it's still 
possible to put something else in front of it, and that it stands out 
from the usual /* */ comments. Sure arguments can be made for supporting 
all comment types, but it shouldn't be forgotten that in the end this is 
a question of absolutely minimal impact.


Just to be clear: If anyone has a good argument for supporting more/all 
comment types and there are no equally good arguments against it, please 
go ahead and implement it and it will be included. Let's just make this 
a quick decision, because changing it later on will mean breakage no 
matter how it's done.

Re: Beta release DUB 1.0.0-beta.1

2016-06-08 Thread Jacob Carlborg via Digitalmars-d-announce


On 2016-06-07 20:42, Sönke Ludwig wrote:


No, it has to be the "+" variant (the first /+ +/ comment is evaluated).


That's unfortunate.

--
/Jacob Carlborg

Re: Beta release DUB 1.0.0-beta.1

2016-06-07 Thread Sönke Ludwig via Digitalmars-d-announce


Am 07.06.2016 um 15:45 schrieb Jacob Carlborg:

On 2016-06-07 13:22, Sönke Ludwig wrote:


Oh, I typed that by accident, should be /+ dub.sdl: ... +/
BTW, /+ dub.json: ... +/ is also possible, of course.


Does it work with all kind of comments D supports?



No, it has to be the "+" variant (the first /+ +/ comment is evaluated).

Re: Beta release DUB 1.0.0-beta.1

2016-06-07 Thread Rory McGuire via Digitalmars-d-announce

On 07 Jun 2016 11:56, "Sönke Ludwig" 
wrote:
>
> DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support
for single-file packages, which can be used to write shebang-style scripts
on Posix systems:
>
> #!/usr/bin/env dub
> /++ dub.sdl:
> name "colortest"
> dependency "color" version="~>0.0.3"
> +/
>
> void main()
> {
> import std.stdio : writefln;
> import std.experimental.color.conv;
> import std.experimental.color.hsx;
> import std.experimental.color.rgb;
>
> auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
> writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
> }
>
> With "chmod +x" it can then simply be run as ./colortest.d.
>
> Apart from that, the release contains some bug fixes, most notably it
doesn't query the registry for each build any more.
>
> Full change log:
> https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
>
> Download (Latest Preview):
> http://code.dlang.org/download

Awesome! Now we can do quick vibe test snippets without  having to make a
dub project.

Re: Beta release DUB 1.0.0-beta.1

2016-06-07 Thread Jacob Carlborg via Digitalmars-d-announce


On 2016-06-07 13:22, Sönke Ludwig wrote:


Oh, I typed that by accident, should be /+ dub.sdl: ... +/
BTW, /+ dub.json: ... +/ is also possible, of course.


Does it work with all kind of comments D supports?

--
/Jacob Carlborg

Re: Beta release DUB 1.0.0-beta.1

2016-06-07 Thread earthfront via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages


So nice. Thanks so much!

This is great for solutions to project euler problems!

Re: Beta release DUB 1.0.0-beta.1

2016-06-07 Thread meppl via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:


#!/usr/bin/env dub
/++ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/



this is exactly what i could make good use of for my scripting 
stuff. thank you for implementing

Re: Beta release DUB 1.0.0-beta.1

2016-06-07 Thread Sönke Ludwig via Digitalmars-d-announce


Am 07.06.2016 um 13:09 schrieb Marc Schütz:

On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:

DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is
support for single-file packages, which can be used to write
shebang-style scripts on Posix systems:

#!/usr/bin/env dub
/++ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/


Hmm... `/++` is for DDoc. Is this a good idea? Does it matter?


Oh, I typed that by accident, should be /+ dub.sdl: ... +/
BTW, /+ dub.json: ... +/ is also possible, of course.

Re: Beta release DUB 1.0.0-beta.1

2016-06-07 Thread Marc Schütz via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages, which can be used to write 
shebang-style scripts on Posix systems:


#!/usr/bin/env dub
/++ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/


Hmm... `/++` is for DDoc. Is this a good idea? Does it matter?

Re: Beta release DUB 1.0.0-beta.1

2016-06-07 Thread Luis via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages, which can be used to write 
shebang-style scripts on Posix systems:


#!/usr/bin/env dub
/++ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/

void main()
{
import std.stdio : writefln;
import std.experimental.color.conv;
import std.experimental.color.hsx;
import std.experimental.color.rgb;

auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
writefln("Yellow in HSV: %s", 
yellow.convertColor!(HSV!()));

}

With "chmod +x" it can then simply be run as ./colortest.d.

Apart from that, the release contains some bug fixes, most 
notably it doesn't query the registry for each build any more.


Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

Download (Latest Preview):
http://code.dlang.org/download


YES!

Re: Beta release DUB 1.0.0-beta.1

2016-06-07 Thread wobbles via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages, which can be used to write 
shebang-style scripts on Posix systems:


[...]


This is great - very nice feature.
That was one of the things I missed most when moving from rdmd to 
dub - so good to see it back!

Re: Beta release DUB 1.0.0-beta.1

2016-06-07 Thread Edwin van Leeuwen via Digitalmars-d-announce


On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages, which can be used to write 
shebang-style scripts on Posix systems:


#!/usr/bin/env dub
/++ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/



I love that as a feature! Thanks for adding that.

48 matches

Mail list logo