Re: Recursive SymbolNames solved.

[Stefan Koch via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote:

Hi, I solved the issue.
PR is coming shortly.


Solution is as follows:

Keep a list of already visited symbols in the mangler.
And information where we store the mangle.
meaning the position in the mangle string.
If a symbol is encountered for the second time store a 
backrefernce rather then the symbol name again.

Re: LDC 1.0.0 has been released!

[Kai Nacke via Digitalmars-d-announce]

On Monday, 6 June 2016 at 10:45:39 UTC, Guillaume Piolat wrote:

On Monday, 6 June 2016 at 07:25:49 UTC, tester wrote:

On Monday, 6 June 2016 at 07:00:56 UTC, Kai Nacke wrote:

Hi everyone,

It is a great pleasure to announce that version 1.0.0 of LDC, 
the LLVM-based D compiler, is now available for download!


The release is based on the 2.070.2 frontend and standard 
library and supports LLVM 3.5-3.8. We provide binaries for 
Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf). :-)


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

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

Regards,
Kai



very nice!
how about a howto for windows/VS users?


Hi,

Here is what I've learned:

- use VS 2015 preferably,
- since a while the stock LDC package work as is, nothing to 
configure,
- use PATH and --compiler=ldc2 or 
--compiler=path/to/compiler.exe to tell dub where LDC is 
(separate packages for 32-bit and 64-bit),
- to avoid a dependency on the VS 2015 runtime, add the 
following linker flags:


"lflags-windows-ldc": [
"libcmt.lib",
"/nodefaultlib:msvcrt.lib",
"/nodefaultlib:vcruntime.lib"
],

- executables made with LDC are not supported on XP and Vista, 
but seem to work regardless :)


Thanks!

See https://github.com/ldc-developers/ldc-scripts/pull/1

Regards,
Kai

Re: Beta release DUB 1.0.0-beta.1

[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 D 2.071.1-b2

[Jack Stouffer via Digitalmars-d-announce]

On Sunday, 29 May 2016 at 21:53:23 UTC, Martin Nowak wrote:

Second beta for the 2.071.1 release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.071.1.html


Please report any bugs at https://issues.dlang.org

-Martin


2.072 is getting rather long in the tooth: 
https://github.com/dlang/phobos/blob/master/changelog.dd. I think 
that's the largest change log for Phobos I have seen.


When are you planning on branching master?

Re: Beta release DUB 1.0.0-beta.1

[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: Recursive SymbolNames solved.

[FlatBareRunner via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 19:41:49 UTC, deadalnix wrote:

On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote:

Hi, I solved the issue.
PR is coming shortly.


Dude come on, that isn't an announce. There is No PR, there is 
no description of the solution, there is nothing.


Hey guys, I cured cancer and solved world hunger. PR coming 
soon.


Lol ! My turn:

I'm a genious but I haven't done anything genial yet...

Re: Recursive SymbolNames solved.

[FlatBareRunner via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 18:02:41 UTC, Jerry wrote:

On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote:

Hi, I solved the issue.
PR is coming shortly.


How was they getting recursive?


Think to the fibo templatized example, it generates a very long 
mangle with basically always the same symbol.

Re: Beta release DUB 1.0.0-beta.1

[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

[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

[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.


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.



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.



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.


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


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: Recursive SymbolNames solved.

[Jerry via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote:

Hi, I solved the issue.
PR is coming shortly.


How was they getting recursive?

Re: The Official D Blog is Live

[Seb via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 16:44:35 UTC, Mike Parker wrote:

On Wednesday, 8 June 2016 at 14:45:07 UTC, bachmeier wrote:
Is it possible to announce the new This Week In D from the 
blog when it comes out?


That sort of post doesn't really fit within the goals of the 
blog. I mean, TWID is put out every Sunday. That would mean I'd 
make a two or three line blurb of the nature, "There's a new 
TWID out" every Sunday. That's what the Announce forum is for, 
and even Adam doesn't announce the new TWID every week.


+1

I do intend to contact Adam about a TWID-related post, though 
(I've already got some others lined up for some interesting 
content). That's much more valuable, IMO, and fits better with 
the goals of the blog. And, of course, any time I can fit it in 
to the context of a given post, I'll certainly remind people to 
check TWID out. Every post should have value on its own other 
than being a simple announcement with a link.


And now that you've brought this up, I've just realized there 
are no links to TWID in the dlang.org menus. I'll have to add 
one to the side bar of the blog.


It has even a better spot - the "News" section of the front page.
Speaking of which: now that we have have an official D Blog, 
maybe we can put the latest headline of the official blog to the 
news section?

Re: The Official D Blog is Live

[Mike Parker via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 14:45:07 UTC, bachmeier wrote:
Is it possible to announce the new This Week In D from the blog 
when it comes out?


That sort of post doesn't really fit within the goals of the 
blog. I mean, TWID is put out every Sunday. That would mean I'd 
make a two or three line blurb of the nature, "There's a new TWID 
out" every Sunday. That's what the Announce forum is for, and 
even Adam doesn't announce the new TWID every week.


I do intend to contact Adam about a TWID-related post, though 
(I've already got some others lined up for some interesting 
content). That's much more valuable, IMO, and fits better with 
the goals of the blog. And, of course, any time I can fit it in 
to the context of a given post, I'll certainly remind people to 
check TWID out. Every post should have value on its own other 
than being a simple announcement with a link.


And now that you've brought this up, I've just realized there are 
no links to TWID in the dlang.org menus. I'll have to add one to 
the side bar of the blog.

Re: Beta release DUB 1.0.0-beta.1

[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

Berlin D Meetup June 2016

[Ben Palmer via Digitalmars-d-announce]

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.

Re: Web page listing all D compilers (and DMDFE version!) on travis-ci

[Nick Sabalausky via Digitalmars-d-announce]

On 06/07/2016 12:05 PM, FreeSlave wrote:

On Tuesday, 26 April 2016 at 06:42:11 UTC, Nick Sabalausky wrote:

https://semitwist.com/travis-d-compilers

That's an auto-generated listing of all versions of DMD, GDC and LDC
available on travis-ci.

[...]


Looks like semitwist.com is down.


Oops. It's back up now.


How about duplicating this list to
github pages?


Not a bad idea.

https://github.com/Abscissa/travis-dc-detect-master/issues/4

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

[Johan Engelen via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 10:06:00 UTC, Oleg Nykytenko wrote:

On Wednesday, 8 June 2016 at 08:43:59 UTC, Joakim wrote:
Have you run the standard library's tests?  There was a thread 
last summer about this:


http://forum.dlang.org/thread/zhcduibirwprgbzqk...@forum.dlang.org


We haven't run library's tests.
What right way to run this tests?

But:
We ported our sufficiently big server application from Linux to 
SmartOS x64.
All application tests is OK. Application working now on testing 
server in production like regime under full load.
And it's working fine. We're planning to use it in production 
in future.


Are you interested in running a buildbot for LDC on your platform 
to detect issues early?
See: 
http://forum.dlang.org/thread/hikcbbqqnpvvyirxg...@forum.dlang.org


Thanks,
  Johan

Re: Nested comments

[ketmar via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 15:21:08 UTC, John Colvin wrote:

On Wednesday, 8 June 2016 at 15:04:28 UTC, Kagamin wrote:

BTW do people find nested comments particularly useful?


Yes for:

A) commenting out a block of code without having to care about 
syntactic correctness (otherwise version(none)) or whether it 
contains comments (otherwise /* */)


B) code examples inside comments


same two points for me too.

Nested comments

[John Colvin via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 15:04:28 UTC, Kagamin wrote:

BTW do people find nested comments particularly useful?


Yes for:

A) commenting out a block of code without having to care about 
syntactic correctness (otherwise version(none)) or whether it 
contains comments (otherwise /* */)


B) code examples inside comments

Re: Beta release DUB 1.0.0-beta.1

[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

[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: The Official D Blog is Live

[bachmeier via Digitalmars-d-announce]

Is it possible to announce the new This Week In D from the blog 
when it comes out?

Re: Beta release DUB 1.0.0-beta.1

[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: The Official D Blog is Live

[Mike Parker via Digitalmars-d-announce]

On Tuesday, 7 June 2016 at 22:18:57 UTC, Ali Çehreli wrote:

On 06/07/2016 12:19 PM, Mike Parker wrote:

On Tuesday, 7 June 2016 at 18:50:47 UTC, Jesse Phillips wrote:


I think each post should have an author displayed. While this 
likely
will be the same person, I think it is good to have it called 
out
repeatedly so one doesn't have to find the first post to see 
who is

posting.

It will also make it very clear when there is a guest poster.


The author name is displayed at the bottom of each post then 
single post
page (i.e. when you click the post title on the main page). I 
didn't
notice it wasn't showing on the main page. I'll see about 
adding it.


Both the author and the date of a blog post is important. I 
would like to see botthat information right under the title.


Ok, now the author and the date is at the top of every post, 
front page and single post page. Looks better. Thanks, guys!

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

[flamencofantasy via Digitalmars-d-announce]

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!

Re: Beta release DUB 1.0.0-beta.1

[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 vibe.d 0.7.29-beta.2

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

Am 08.06.2016 um 13:53 schrieb akaDemik:

On Wednesday, 8 June 2016 at 11:30:07 UTC, akaDemik wrote:

On Thursday, 2 June 2016 at 08:27:03 UTC, Sönke Ludwig wrote:

The release candidate is planned for the 6th, so please take a moment
to test this release.


There are two problems after the upgrade.

1. subConfiguration "vibe-d" "win32" not applied to "vibe-d:core"
https://github.com/rejectedsoftware/vibe.d/issues/1513

2. vibe-d/examples/http_server asserts when using win32
subconfiguration. https://github.com/rejectedsoftware/vibe.d/pull/1514

The previous build used "vibe-d": "0.7.26".


Oh sorry. #1513 only for "vibe-d": "0.7.28". It works fine in version
0.7.29-beta.2`.
#1514 -- still open.


Pulled #1514 into the 0.7.29 branch, will be in 0.7.29-rc.1. Thanks for 
doing the PR!

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

[Alexandr Basko via Digitalmars-d-announce]

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

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

[Alexandr Basko via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 11:30:50 UTC, Joakim wrote:

On Wednesday, 8 June 2016 at 10:06:00 UTC, Oleg Nykytenko wrote:

On Wednesday, 8 June 2016 at 08:43:59 UTC, Joakim wrote:

[...]


We haven't run library's tests.
What right way to run this tests?

But:
We ported our sufficiently big server application from Linux 
to SmartOS x64.
All application tests is OK. Application working now on 
testing server in production like regime under full load.
And it's working fine. We're planning to use it in production 
in future.


Vibe.d simple http/https/web test applications work fine too.


That's great to hear. :) If I were you though, I'd at least 
double-check by running the ldc tests, as I don't think others 
are using that platform.  With ldc, I believe it's just "make 
test".


Ok. I try to run these tests on server. Tomorrow i will post 
results, then i came back to working place

Recursive SymbolNames solved.

[Stefan Koch via Digitalmars-d-announce]

Hi, I solved the issue.
PR is coming shortly.

Re: Beta release DUB 1.0.0-beta.1

[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

[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: LDC+Dub+Vibe.d work on SmartOS 64bit now

[flamencofantasy via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 08:00:03 UTC, Alexandr Basko wrote:
At first, we have build ldc-lts-master on OmniOS(32bit arch). 
We did some corrections in AddLLVM.cmake file for build 
llvm_3.8. And soon we have received working "Hello world" on 
Dlang.
But when we try to build vibe.d it fall down. We should had do 
some corrections in vide.d source. After this vibe.d began 
working on OmniOS and SmartOS 32bit.
But in SmartOS 64 bit not only vibe.d not compiling, even 
"Hello world" not working. Many hours of analyzing and 
correcting errors during build bring success. Vibe.d works fine 
with libevent configuration in OmniOS, SmartOS 32bit and 
SmartOS 64bit.
All corrections are commited to druntime, phobos and vibe.d by 
Nykytenko Oleg.


PS. If anybody need more details, we will be happy to help and 
write completely "HOWTO"


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

Re: Beta release vibe.d 0.7.29-beta.2

[akaDemik via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 11:30:07 UTC, akaDemik wrote:

On Thursday, 2 June 2016 at 08:27:03 UTC, Sönke Ludwig wrote:
The release candidate is planned for the 6th, so please take a 
moment to test this release.


There are two problems after the upgrade.

1. subConfiguration "vibe-d" "win32" not applied to 
"vibe-d:core" 
https://github.com/rejectedsoftware/vibe.d/issues/1513


2. vibe-d/examples/http_server asserts when using win32 
subconfiguration. 
https://github.com/rejectedsoftware/vibe.d/pull/1514


The previous build used "vibe-d": "0.7.26".


Oh sorry. #1513 only for "vibe-d": "0.7.28". It works fine in 
version 0.7.29-beta.2`.

#1514 -- still open.

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

[Joakim via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 10:06:00 UTC, Oleg Nykytenko wrote:

On Wednesday, 8 June 2016 at 08:43:59 UTC, Joakim wrote:
Have you run the standard library's tests?  There was a thread 
last summer about this:


http://forum.dlang.org/thread/zhcduibirwprgbzqk...@forum.dlang.org


We haven't run library's tests.
What right way to run this tests?

But:
We ported our sufficiently big server application from Linux to 
SmartOS x64.
All application tests is OK. Application working now on testing 
server in production like regime under full load.
And it's working fine. We're planning to use it in production 
in future.


Vibe.d simple http/https/web test applications work fine too.


That's great to hear. :) If I were you though, I'd at least 
double-check by running the ldc tests, as I don't think others 
are using that platform.  With ldc, I believe it's just "make 
test".

Re: Beta release vibe.d 0.7.29-beta.2

[akaDemik via Digitalmars-d-announce]

On Thursday, 2 June 2016 at 08:27:03 UTC, Sönke Ludwig wrote:
The release candidate is planned for the 6th, so please take a 
moment to test this release.


There are two problems after the upgrade.

1. subConfiguration "vibe-d" "win32" not applied to "vibe-d:core" 
https://github.com/rejectedsoftware/vibe.d/issues/1513


2. vibe-d/examples/http_server asserts when using win32 
subconfiguration. 
https://github.com/rejectedsoftware/vibe.d/pull/1514


The previous build used "vibe-d": "0.7.26".

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

[Oleg Nykytenko via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 08:43:59 UTC, Joakim wrote:
Have you run the standard library's tests?  There was a thread 
last summer about this:


http://forum.dlang.org/thread/zhcduibirwprgbzqk...@forum.dlang.org


We haven't run library's tests.
What right way to run this tests?

But:
We ported our sufficiently big server application from Linux to 
SmartOS x64.
All application tests is OK. Application working now on testing 
server in production like regime under full load.
And it's working fine. We're planning to use it in production in 
future.


Vibe.d simple http/https/web test applications work fine too.

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

[John via Digitalmars-d-announce]

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.

  T init(T, Args...)() {
import std.traits : FunctionTypeOf;

static struct DummyType {}
static if (is(T == class)) T r = new T;
else T r;

foreach (arg; Args) {
  alias fun = arg!DummyType;
  static if (is(FunctionTypeOf!fun PT == __parameters)) {
enum name = __traits(identifier, PT);
foreach (m; __traits(allMembers, T)) {
  static if (name == m) __traits(getMember, r, m) = 
fun(DummyType.init);

}
  }
}
return r;
  }

  struct Point {
int x, y;
  }

  void main() {
auto pt = init!(Point, x => 123, y => 456);
assert(pt.x == 123 && pt.y == 456);
  }

Re: Beta release DUB 1.0.0-beta.1

[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: LDC+Dub+Vibe.d work on SmartOS 64bit now

[Joakim via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 08:00:03 UTC, Alexandr Basko wrote:
At first, we have build ldc-lts-master on OmniOS(32bit arch). 
We did some corrections in AddLLVM.cmake file for build 
llvm_3.8. And soon we have received working "Hello world" on 
Dlang.
But when we try to build vibe.d it fall down. We should had do 
some corrections in vide.d source. After this vibe.d began 
working on OmniOS and SmartOS 32bit.
But in SmartOS 64 bit not only vibe.d not compiling, even 
"Hello world" not working. Many hours of analyzing and 
correcting errors during build bring success. Vibe.d works fine 
with libevent configuration in OmniOS, SmartOS 32bit and 
SmartOS 64bit.
All corrections are commited to druntime, phobos and vibe.d by 
Nykytenko Oleg.


PS. If anybody need more details, we will be happy to help and 
write completely "HOWTO"


Have you run the standard library's tests?  There was a thread 
last summer about this:


http://forum.dlang.org/thread/zhcduibirwprgbzqk...@forum.dlang.org

Re: LDC 1.0.0 has been released!

[Dicebot via Digitalmars-d-announce]

Was there anything changed regarding -od / -op / -oq behaviour? I 
am getting DCD build errors with new LDC because object files are 
emitted to a different place it expects.

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

[Alexandr Basko via Digitalmars-d-announce]

At first, we have build ldc-lts-master on OmniOS(32bit arch). We 
did some corrections in AddLLVM.cmake file for build llvm_3.8. 
And soon we have received working "Hello world" on Dlang.
But when we try to build vibe.d it fall down. We should had do 
some corrections in vide.d source. After this vibe.d began 
working on OmniOS and SmartOS 32bit.
But in SmartOS 64 bit not only vibe.d not compiling, even "Hello 
world" not working. Many hours of analyzing and correcting errors 
during build bring success. Vibe.d works fine with libevent 
configuration in OmniOS, SmartOS 32bit and SmartOS 64bit.
All corrections are commited to druntime, phobos and vibe.d by 
Nykytenko Oleg.


PS. If anybody need more details, we will be happy to help and 
write completely "HOWTO"

Re: Beta release DUB 1.0.0-beta.1

[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