Re: Get pointer or reference of an element in Array(struct)

2017-12-08 Thread anonymous via Digitalmars-d-learn
On Saturday, 9 December 2017 at 06:15:16 UTC, Arun Chandrasekaran 
wrote:
Is there a way to get the pointer or reference of an element in 
Array(T)?

[...]

auto d2 = gallery[0];


auto d2 = [0];


Re: Building DMD on OpenBSD

2017-07-18 Thread Anonymous via Digitalmars-d

On Tuesday, 18 July 2017 at 05:11:30 UTC, Kai Nacke wrote:
In master there is already some OpenBSD support. Some time ago 
I worked on druntime support but I still need to finish this. 
Mostly there is nothing magic here - just translating the 
header files. The only non-obvious work is required for the 
module/shared library stuff (in rt.sections). If there is an 
OpenBSD expert around who can help here it would be nice.


Maybe talk to OpenBSD porters on their mailing list. Ill 
put my stuff on github as soon as I can.




Re: Building DMD on OpenBSD

2017-07-17 Thread Anonymous via Digitalmars-d

On Monday, 17 July 2017 at 17:18:23 UTC, Joakim wrote:
Unfortunately, dmd has not kept porters in mind and hasnt 
kept the C++ version updated, or kept a workflow that enables 
easy bootstrapping:


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

You will have to build druntime and phobos for 2.067 also and 
collect it all in a different location, which you could invoke 
to bootstrap a new dmd.  You may run into issues related to 
D/C++ integration when building the latest dmd, as that 
hasnt been tested on OpenBSD, only FreeBSD.


Why do you want the latest dmd on OpenBSD?  I ask because it 
will likely require some work, though likely not a lot.


Ive already tried building 2.067 druntime by mistake and 
run into problems. Most are resolvable by just adding 
TARGET_OPENBSD next to TARGET_FREEBSD. But yeah, its gonna 
take some work. I want it because Im using OpenBSD as my 
main OS and I have a project that I want to port to D.


Btw I shouldve built the `install` target (got confused by 
the wiki). Now I get:


cp: ../ini/openbsd/bin64/dmd.conf: No such file or directory

which is more understandable.



Re: Building DMD on OpenBSD

2017-07-17 Thread Anonymous via Digitalmars-d

On Monday, 17 July 2017 at 09:58:42 UTC, Joakim wrote:
The last dmd we released that was written in C++ was 2.067, for 
which you can still check out the branch.  Youd have to 
build that bootstrap compiler 2.067 first, then worry about the 
latest dmd.


Since we dont regularly build for OpenBSD, its 
possible that support has slipped behind.  Usually, its 
as easy as adding OpenBSD to a couple more #ifdefs, but 
sometimes you need to adapt the dmd source also for a rarely 
used platform like OpenBSD.


I managed to build the bootstrap dmd without any trouble. Btw the 
wiki page doesnt mention that the dependency is *GNU* Make 
which is typically installed as gmake on BSDs. Then I tried 
building the new dmd and got (in dmd/src):


CC=c++ dmd -of../generated/openbsd/release/64/idgen ddmd/idgen.d
Error: cannot find source code for runtime library file 
object.d
   dmd might not be correctly installed. Run dmd 
-man for installation instructions.

   config file: /etc/dmd.conf
Specify path to file object.d with -I switch
gmake[1]: *** [posix.mak:437: 
../generated/openbsd/release/64/idgen] Error 1


Now Im trying to figure out the /etc/dmd.conf business. I 
found ini/freebsd/bin64/dmd.conf in the 2.067 dmd folder so I 
guess Ill start from there. Thanks for the help so far.




Re: Building DMD on OpenBSD

2017-07-16 Thread Anonymous via Digitalmars-d

On Sunday, 16 July 2017 at 21:37:12 UTC, Seb wrote:

How about simply building the bootstrap binary yourself then?
I think 2.067 is the last version thats still written in 
C++:


https://github.com/dlang/dmd/tree/2.067


Yep, that should work. I believe this should be put somewhere on 
the wiki because otherwise bootstrapping is hard to figure out.



PS: Do you manually insert the HTML codes? They are escaped.


I noticed them added after a redirect to the captcha page 
(Im using tor).




Re: Building DMD on OpenBSD

2017-07-16 Thread Anonymous via Digitalmars-d

On Sunday, 16 July 2017 at 19:47:20 UTC, Seb wrote:
Auto-bootstrapping is __only__ used if no host compiler is 
found on the system.
This should only happen on esoteric platforms (not intended as 
an offense) like yours.


So I should use digger then? I looked through its repo briefly 
and I cant really tell if Im gonna run into the same 
issue or not.
I guess another option is to build GDC and then use it to build 
DMD.



In any case, I submitted a PR to use SSL for AUTO_BOOSTRAP:

https://github.com/dlang/dmd/pull/7000


Thanks.



Building DMD on OpenBSD

2017-07-16 Thread Anonymous via Digitalmars-d
I did some googling (well, duckduckgoing) and found a few posts 
on this forum indicating that this could work. So I gave it a try 
and followed https://wiki.dlang.org/Building_under_Posix
The build failed because src/posix.mak in the dmd repo was trying 
to download 
http://downloads.dlang.org/releases/2.x/2.072.2/dmd.2.072.2.openbsd.tar.xz which doesnt exist. What do I do now?


OTOH its a good thing that the build failed. When I saw 
http:// instead of https:// in the console output I went to check 
what the makefile was doing and - wait for it - it was trying to 
download an executable from the internet and run it. I 
couldnt believe my eyes. I mean, you sure can use an 
unencrypted channel but then you need some kind of cryptographic 
signature to verify the downloaded file. I tried the above with 
2.074.1 (the latest stable) but the trunk version has this too.




Re: Developer positions at Sociomantic Labs

2017-06-14 Thread anonymous via Digitalmars-d-announce
“The best minds of my generation are thinking about how to make 
people click ads.” - Jeffrey Hammerbacher (Cloudera cofounder)




What is this error message telling me?

2017-04-11 Thread Anonymous via Digitalmars-d-learn
I was watching a dconf presentation from last year and wanted to 
try this out: https://github.com/luismarques/parnas72. It doesn't 
compile / run as it is and the problem seems to be in the 
function below.


import std.algorithm;
import std.range;
import std.uni;
/// Performs [["foo", "bar"], ["baz"]] -> ["baz", "foo bar"]
auto alphabetized(Range)(Range range)
{
return range
.map!(line => line.joiner(" "))
.array
.sort!((a, b) => icmp(a, b) < 0);
}

void main()
{
auto a = alphabetized([["foo", "bar"], ["baz"]]);
}


More specifically, icmp doesn't seem to be allowed as the 
predicate for sort:


Here's the error message I get:

C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7082): Error: 
function 'std.algorithm.searching.skipOver!(Result, 
dstring).skipOver' is not nothrow
C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7055): Error: 
nothrow function 'std.uni.fullCasedCmp!(Result).fullCasedCmp' may 
throw
C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7136): Error: 
template instance std.uni.fullCasedCmp!(Result) error 
instantiating

test.d(14):instantiated from here: icmp!(Result, Result)
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(1851):
instantiated from here: __lambda3!(Result, Result)
test.d(14):instantiated from here: sort!((a, b) => 
icmp(a, b) < 0, cast(SwapStrategy)0, Result[])
test.d(19):instantiated from here: 
alphabetized!(string[][])

C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(1863): Error: static 
assert  "Invalid predicate passed to sort: __lambda3"
test.d(14):instantiated from here: sort!((a, b) => 
icmp(a, b) < 0, cast(SwapStrategy)0, Result[])
test.d(19):instantiated from here: 
alphabetized!(string[][])



My question is, how do I begin to understand error messages like 
the above? I looked at the signature for sort and icmp and don't 
get what the problem is.


Thanks.




Re: Project Highlight: The New CTFE Engine

2016-11-19 Thread anonymous via Digitalmars-d-announce

On Friday, 18 November 2016 at 10:59:11 UTC, Mike Parker wrote:
If you've been following Stefan's CTFE Status thread here in 
the forums, you know some of the details of the work he has 
been doing in overhauling the CTFE engine. In a post targeting 
the world at large, he explains why he started the project, 
describes the deficiencies he found with the current 
implementation, and gives a high level overview of his new one.


The blog post: 
https://dlang.org/blog/2016/11/18/project-highlight-the-new-ctfe-engine/


Reddit:
https://www.reddit.com/r/programming/comments/5dltm4/a_look_at_the_overhaul_of_ds_ctfe_engine/


there is a typo after the first quote:  fourms


Re: Release D 2.072.0

2016-11-07 Thread Anonymous via Digitalmars-d-announce

On Monday, 7 November 2016 at 18:26:44 UTC, Anonymous wrote:

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub 
(v1.1.0), comes

with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin


It seems that there was another regression that nobody 
detected, because nobody has build one of the major tool used 
by most of the D enthusiastic:


https://github.com/Hackerpilot/DCD/issues/352
https://issues.dlang.org/show_bug.cgi?id=16663


To be honest, I know that the D world existed before me, and I 
know that it'll still exist if I leave. Between, 2.072 is the 
worst release I've ever seen.


Re: Release D 2.072.0

2016-11-07 Thread Anonymous via Digitalmars-d-announce

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub 
(v1.1.0), comes

with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin


It seems that there was another regression that nobody detected, 
because nobody has build one of the major tool used by most of 
the D enthusiastic:


https://github.com/Hackerpilot/DCD/issues/352
https://issues.dlang.org/show_bug.cgi?id=16663


Re: Weird dmd error?

2016-11-07 Thread Anonymous via Digitalmars-d

On Monday, 7 November 2016 at 12:31:57 UTC, Anonymous wrote:
On Monday, 7 November 2016 at 11:57:48 UTC, Andrea Fontana 
wrote:

On Monday, 7 November 2016 at 10:57:49 UTC, Anonymous wrote:
Exactly the same thing happens. There's already 3 semantic 
passes. To solve this kind of forward references another 
semantic pass would be required. But in this case you 
couldn't determine how many passes would be necessary so 
there would be a  complexity problem in the compiler.


But it's not really the same, error in my case is inside 
druntime.

In your example errors are inside my code.


i'm on a 2071.2 frontend now, my comments are based on this.
are you on 2072 ?


oh no yet another 2.072 regression !


Re: Weird dmd error?

2016-11-07 Thread Anonymous via Digitalmars-d

On Monday, 7 November 2016 at 11:57:48 UTC, Andrea Fontana wrote:

On Monday, 7 November 2016 at 10:57:49 UTC, Anonymous wrote:
Exactly the same thing happens. There's already 3 semantic 
passes. To solve this kind of forward references another 
semantic pass would be required. But in this case you couldn't 
determine how many passes would be necessary so there would be 
a  complexity problem in the compiler.


But it's not really the same, error in my case is inside 
druntime.

In your example errors are inside my code.


i'm on a 2071.2 frontend now, my comments are based on this.
are you on 2072 ?


Re: Weird dmd error?

2016-11-07 Thread Anonymous via Digitalmars-d

On Monday, 7 November 2016 at 09:58:08 UTC, Anonymous wrote:
On Monday, 7 November 2016 at 08:34:55 UTC, Andrea Fontana 
wrote:


--- test.d
void* test (ssize_t );
import core.sys.posix.unistd;
---

Try to run:
dmd test.d

It says:
/usr/include/dmd/druntime/import/core/sys/posix/sys/types.d(100): Error: 
undefined identifier 'c_long'


It looks normal but it's not documented. It's just that the 
import is not yet known in the scope.


To be clearer, the problem is the same with:

void main()
{
foo;
void foo(){}
}

Exactly the same thing happens. There's already 3 semantic 
passes. To solve this kind of forward references another semantic 
pass would be required. But in this case you couldn't determine 
how many passes would be necessary so there would be a  
complexity problem in the compiler.


Re: Weird dmd error?

2016-11-07 Thread Anonymous via Digitalmars-d

On Monday, 7 November 2016 at 08:34:55 UTC, Andrea Fontana wrote:


--- test.d
void* test (ssize_t );
import core.sys.posix.unistd;
---

Try to run:
dmd test.d

It says:
/usr/include/dmd/druntime/import/core/sys/posix/sys/types.d(100): Error: 
undefined identifier 'c_long'


It looks normal but it's not documented. It's just that the 
import is not yet known in the scope. It 's like:


void main(string[] args)
{
writeln();
import std.stdio;
}

But

void main(string[] args)
{
writeln();
}
import std.stdio;

works because the symbol lookup succeeds in the parent scope.

For your example to work, another semantic pass would necessary.


Re: Release D 2.072.0

2016-11-02 Thread anonymous via Digitalmars-d-announce

On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote:
On Wednesday, 2 November 2016 at 12:36:45 UTC, Johan Engelen 
wrote:

LDC built with DMD 2.072.0 gives the following error when run:
object.Error@src/rt/minfo.d(356): Cyclic dependency between 
module ddmd.traits and ddmd.cond

ddmd.traits* ->
ddmd.attrib ->
ddmd.cond* ->
ddmd.expression ->
ddmd.traits*

Pretty much all of LDC's D code is DDMD front-end code, master 
is at front-end version 2.071.2. I hope someone can try to 
build DMD 2.071.2 using 2.072.0 and see if a similar issue is 
found.


I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but 
boot since master straping works there's probably something 
that's been fixed in one or two of these ddmd modules, likely a 
static ctor...


Maybe after this:

https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368

ddmd.attribs was removed

https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15

and it was also part of the cycle.


Re: Release D 2.072.0

2016-11-02 Thread anonymous via Digitalmars-d-announce
On Wednesday, 2 November 2016 at 12:36:45 UTC, Johan Engelen 
wrote:

LDC built with DMD 2.072.0 gives the following error when run:
object.Error@src/rt/minfo.d(356): Cyclic dependency between 
module ddmd.traits and ddmd.cond

ddmd.traits* ->
ddmd.attrib ->
ddmd.cond* ->
ddmd.expression ->
ddmd.traits*

Pretty much all of LDC's D code is DDMD front-end code, master 
is at front-end version 2.071.2. I hope someone can try to 
build DMD 2.071.2 using 2.072.0 and see if a similar issue is 
found.


I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but 
boot since master straping works there's probably something 
that's been fixed in one or two of these ddmd modules, likely a 
static ctor...


Re: RC buffer

2016-11-02 Thread anonymous via Digitalmars-d
On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei 
Alexandrescu wrote:
I've eliminated all UTF nonsense from 
https://github.com/dlang/phobos/pull/4878 resulting in a bare 
reference counted buffer of (qualified) ubyte.



Andrei


BTW about this PR: why RCString an not more generally RCArray ?


Re: how to mark an extern function @nogc?

2016-07-12 Thread anonymous via Digitalmars-d-learn

On Tuesday, 12 July 2016 at 14:04:55 UTC, Seb wrote:
D is entirely driven by highly motivated volunteers. (this will 
change soon with the new D foundation)


With the fundation, volunteers wont be highly motivated anymore. 
Fundations are real motivation-killers.






Re: Linker error

2016-06-05 Thread Anonymous via Digitalmars-d-learn

On Monday, 6 June 2016 at 02:21:03 UTC, docandrew wrote:

On Sunday, 5 June 2016 at 21:26:56 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
<digitalmars-d-learn@puremagic.com> wrote:

[...]


You can report it here: https://issues.dlang.org


[...]


null is simpler from a reader's perspective. :)


[...]


Interesting that they would use such code in the book. Which 
chapter is it?


Thanks. I agree it's simpler and switched to `null`.

The example is in chapter 3.


That it works on OSX but not on Windows makes me think it 
should definitely be reported as a bug.


-Jon


https://issues.dlang.org/show_bug.cgi?id=16129


Re: Linker error

2016-06-05 Thread Anonymous via Digitalmars-d-learn

On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
<digitalmars-d-learn@puremagic.com> wrote:
Should I report this as a dmd bug then? Not sure where / how 
to do that.


You can report it here: https://issues.dlang.org

I think I'll just let it go; I was able to work passed it 
anyway using "static Note[] empty;", and `null` works too. Is 
either one better?


null is simpler from a reader's perspective. :)

By the way, this is from an example I found in "D Web 
Development" by Kai Nacke.


Interesting that they would use such code in the book. Which 
chapter is it?


Thanks. I agree it's simpler and switched to `null`.

The example is in chapter 3.


Re: Linker error

2016-06-05 Thread Anonymous via Digitalmars-d-learn

On Sunday, 5 June 2016 at 20:16:54 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
<digitalmars-d-learn@puremagic.com> wrote:

static Note[0] empty;

Note[] getNotes(string id)
{
return (id in store) ? store[id] : empty;
}


It's likely an accepts-invalid bug, meaning it should be a 
compiler error instead. I don't think it makes sense that the 
compiler tries to slice a fixed-length array of length zero.. 
tho perhaps it should just equate that to returning null.


In any case you can return `null` instead of "empty". 
Fixed-length arrays of length zero aren't really all that 
well-defined. Some would say they make no sense, but there is a 
weird benefit to them when used with the built-in hashmaps (a 
void[0] value type wouldn't allocate memory, AFAIR and if that 
is still true).


Should I report this as a dmd bug then? Not sure where / how to 
do that.


I think I'll just let it go; I was able to work passed it anyway 
using "static Note[] empty;", and `null` works too. Is either one 
better?


By the way, this is from an example I found in "D Web 
Development" by Kai Nacke.


Re: Linker error

2016-06-05 Thread Anonymous via Digitalmars-d-learn

On Sunday, 5 June 2016 at 18:45:36 UTC, docandrew wrote:

On Sunday, 5 June 2016 at 18:36:13 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 18:30:25 UTC, Anonymous wrote:

[...]


Should have included:

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
ns.obj(ns)  Offset 0BA0AH Record Type 009D
 Error 16: Index Range
--- errorlevel 1


Hmm, on OSX w/ dmd v2.071.0 I'm unable to duplicate. Can you 
try upgrading to v2.071 and see if that works?


-Jon


I upgraded, but I still get the same error:

dmd ns.d

 OPTLINK (R) for Win32  Release 8.00.17
 Copyright (C) Digital Mars 1989-2013  All rights reserved.
 http://www.digitalmars.com/ctg/optlink.html
 ns.obj(ns)  Offset 00678H Record Type 009D
  Error 16: Index Range
 --- errorlevel 1

dmd --version
DMD32 D Compiler v2.071.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright


Re: Linker error

2016-06-05 Thread Anonymous via Digitalmars-d-learn

On Sunday, 5 June 2016 at 18:30:25 UTC, Anonymous wrote:

Why does the following give a linker error?

If I change static Note[0] empty; to static Note[] empty;, all 
is well.
Or if I leave it as Note[0] empty; and don't use it in 
getNotes, all is well.


struct Note
{
string topic;
string content;
}

class NoteStore
{   

Note[][string] store;

static Note[0] empty;

Note[] getNotes(string id)
{
return (id in store) ? store[id] : empty;
}   
}

void main() {}

dmd --version
DMD32 D Compiler v2.070.0
Windows 10


Should have included:

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
ns.obj(ns)  Offset 0BA0AH Record Type 009D
 Error 16: Index Range
--- errorlevel 1


Linker error

2016-06-05 Thread Anonymous via Digitalmars-d-learn

Why does the following give a linker error?

If I change static Note[0] empty; to static Note[] empty;, all is 
well.
Or if I leave it as Note[0] empty; and don't use it in getNotes, 
all is well.


struct Note
{
string topic;
string content;
}

class NoteStore
{   

Note[][string] store;

static Note[0] empty;

Note[] getNotes(string id)
{
return (id in store) ? store[id] : empty;
}   
}

void main() {}

dmd --version
DMD32 D Compiler v2.070.0
Windows 10


Re: Windows vs UTF-8 (issue 15845)

2016-04-03 Thread anonymous via Digitalmars-d

On Sunday, 3 April 2016 at 22:48:21 UTC, Adam D. Ruppe wrote:
What happens if you give it a 4 char buffer? I imagine it would 
work fine then in all cases. It seems to for me.


Doesn't seem to work for me.

The exact code I tested:

import std.stdio;
import std.exception: enforce;
import core.sys.windows.windows;

void main()
{
SetConsoleCP(65001);
SetConsoleOutputCP(65001);

uint readBytes;
ubyte[4] c;
ReadFile(GetStdHandle(STD_INPUT_HANDLE), c.ptr, c.length,
, null).enforce();
writeln(readBytes, " ", c[]);
}


When I enter "a", it prints "3 [97, 13, 10, 0]".
When I enter "ä", it prints "0 [0, 0, 0, 0]".

I've also tried even larger buffers. Same result.


Re: How to return a const handle (view) to a mutable member of an agregate

2016-03-13 Thread anonymous via Digitalmars-d-learn

On Sunday, 13 March 2016 at 22:34:54 UTC, Chris Wright wrote:
In theory, it can't be modified. As a practical matter, unions 
and casts will allow people to modify it.


Saying that it *can't* be modified is slightly besides the point, 
yeah. It *must* not be modified. Casting away const and then 
mutating will probably just work as expected much of the time. 
But it's not allowed by the language. One must not do it.


I think it's important not to give the impression that it's ok in 
practice to cast away const and then mutate.


By the way, I don't think unions are in the exact same boat as 
casts here. With a union of const and mutable types, I'd say it's 
perfectly fine to mutate the data through the mutable one. Such a 
union is similar to having const and mutable pointers to the same 
data. Unions of immutable and mutable types are weird, though.


Decorating your code with @safe is intended to prevent these 
holes (and other types of unsafe code).


But even in non-@safe code, the compiler doesn't just accept 
mutating through a const reference. It requires a cast, which is 
an explicit signal to just do what the programmer says. There's a 
similar signal for ignoring @safe: @trusted.


Re: How to return a const handle (view) to a mutable member of an agregate

2016-03-13 Thread anonymous via Digitalmars-d-learn

On Sunday, 13 March 2016 at 20:10:57 UTC, Basile B. wrote:

ref const(Array!Type) view(){}

Unless the result is explicitly cast later it can't me modified.


No, it can't be modified, period. Casting away const and then 
mutating is not allowed, it has undefined behavior.


Re: Can I get more opinions on increasing the logo size on the site please

2016-02-25 Thread anonymous via Digitalmars-d

On Wednesday, 17 February 2016 at 20:11:10 UTC, anonymous wrote:

On 10.02.2016 22:31, anonymous wrote:

I've shot him an email.


No response for a week. Trying a GitHub @-mention now:
https://github.com/D-Programming-Language/dlang.org/pull/1212#issuecomment-185381136


No response to that either. I've also tried emailing two other 
addresses and Twitter. Nothing. What now?


Re: template mixins vs alias

2016-02-22 Thread anonymous via Digitalmars-d-learn

On Monday, 22 February 2016 at 13:35:10 UTC, Andrea Fontana wrote:

Check this code:
http://dpaste.dzfl.pl/fcf876acbbdc

Structs A and B do the same things, in different way.

Is there any difference/limitation between those?

Andrea


The mixin variant generates a method. That means, you can 
reference members of the struct in the function.


Silly example:

mixin template Test(T)
{
auto returnX() { return x; }
}
struct A
{
int x;
mixin Test!int;
}


With the alias variant you get an alias to a free function, not a 
method. So you couldn't reference x like above.


What's nicer about the alias version is that you see what symbol 
is being generated. It's obvious that `alias returnInit = 
returnInitImpl!int;` creates a symbol "returnInit". In the mixin 
variant, you have to read the template's source to see that.


Re: compilation issues (dmd, rdmd, ldc2)

2016-02-21 Thread anonymous via Digitalmars-d-learn

On 21.02.2016 22:51, kraxli wrote:

On Sunday, 21 February 2016 at 21:35:55 UTC, anonymous wrote:

[...]

a) do it the linker way: `dmd -L-L~/.dub/packages/consoled-1.0.0/
-L-lconsoled ...`, or
b) do it the dmd way: `dmd
~/.dub/packages/consoled-1.0.0/libconsoled.a ...`.


b) works! :-) Many thanks!!
a) doesn't work, I need to search for more information on linking as I
would like to understand these kind of basics in D :-). The books I
consulted so far (Learn D and D cookbook) did not help me to understand
the linking so far ...


I investigated a bit on option a. The tilde (~) is the problem. Tilde 
expansion is only done when it's the first character of a word. So you 
either have to replace the tilde with "/home/foo", or somehow make it 
the first character of a word for the shell. Since you can't just put a 
space there, you would have to hack around a bit. For example:


dmd -L-L`echo ~`/.dub/packages/consoled-1.0.0/ ...

Regarding learning about linking: dmd's -L flag just forwards its 
argument to the linker. The linker isn't D-specific. To learn about 
linking in D you can learn about compiling/linking in general (what's a 
compiler, what's a linker, what's an object file, etc.), and you can 
learn about the command line interface of the specific linker that dmd 
invokes.


On Ubuntu, dmd calls gcc for linking, which in turn calls ld. So if you 
want to know what to put into those -L arguments, you have to learn the 
gcc/ld command lines.


Re: compilation issues (dmd, rdmd, ldc2)

2016-02-21 Thread anonymous via Digitalmars-d-learn

On Sunday, 21 February 2016 at 21:21:30 UTC, kraxli wrote:
Thanks for coming back on that! The problem is the 
consoled-package which has the library:

~/.dub/packages/consoled-1.0.0/libconsoled.a

So I link it (or aim to do it ;-) ) but dmd cannot find it:

$ dmd -I~/.dub/packages/consoled-1.0.0/source  
-L-l~/.dub/packages/consoled-1.0.0/libconsoled  appX.d
/usr/bin/ld: cannot find 
-l~/.dub/packages/consoled-1.0.0/libconsoled

collect2: error: ld returned 1 exit status
--- errorlevel 1


I don't think it works like that. If I remember correctly, you 
can either
a) do it the linker way: `dmd -L-L~/.dub/packages/consoled-1.0.0/ 
-L-lconsoled ...`, or
b) do it the dmd way: `dmd 
~/.dub/packages/consoled-1.0.0/libconsoled.a ...`.


I don't know what's going on there, but there shouldn't be a 
std/range.d with recent versions of phobos. It's a package 
since 2.067.0. Maybe a leftover from a previous installation?


I just reinstalled it and it seems as it would have installed 
in the directory mentioned by ldc2:

-- Installing: /usr/local/include/d/std/range
-- Installing: /usr/local/include/d/std/range/primitives.d
-- Installing: /usr/local/include/d/std/range/package.d
-- Installing: /usr/local/include/d/std/range/interfaces.d


But is there a file /usr/local/include/d/std/range.d? If so, 
that's apparently not from your latest install, and it may 
confuse ldc. If there is no such file, then I can't make any 
sense of the error messages.


Re: compilation issues (dmd, rdmd, ldc2)

2016-02-21 Thread anonymous via Digitalmars-d-learn

On Sunday, 21 February 2016 at 20:04:34 UTC, kraxli wrote:
What is going on here and what is the difference between dmd 
and rdmd?


dmd compiles the modules that you specify on the command line. By 
default, it then links an executable from the generated object 
files. The linking can only work when you give dmd all the code, 
either in source form or in compiled object form. When something 
is missing, you get "undefined reference" errors.


That means, when your program has multiple source files 
(including libraries), you must put them all on the dmd command 
line. Or you can compile modules individually (without linking, 
-c flag), and then put the generated object files on the command 
line when linking.


rdmd is a wrapper around dmd (or another, compatible compiler). 
It reads the dependency tree of the modules, and runs dmd on all 
of the source files at once. That means, you only need to put the 
root module on the command line for rdmd. rdmd reads the imports 
and generates a full list of source files for dmd.


Moreover, ldc2 has conflicts with modules which is probably due 
to installation, linking and scope issues. How can I shrink the 
scope for ldc2 such that it only looks at the "right place" for 
modules (and where is that?) ?


$ ldc2 -I~/.dub/packages/consoled-1.0.0/source/  appX.d
/usr/local/include/d/std/range.d(287): Error: module std.range 
from file /usr/local/include/d/std/range.d conflicts with 
package name range


I don't know what's going on there, but there shouldn't be a 
std/range.d with recent versions of phobos. It's a package since 
2.067.0. Maybe a leftover from a previous installation?


Re: Official compiler

2016-02-18 Thread anonymous via Digitalmars-d

On 18.02.2016 21:24, David Nadlinger wrote:

But please don't make up argument trying to rationalize whatever
personal decision somebody else made. You could literally copy LLVM
source code into your application and sell it as a closed-source product
without risking any copyright problems (if you comply with the very
modest attribution clause of the license).


LLVM's license isn't the supposed problem. DMD's license is. You cannot 
copy DMD backend code to LLVM. By not contributing to other compilers, 
Walter stays in the clear in that regard. At least, that's how I 
understand the argument.


Re: Can I get more opinions on increasing the logo size on the site please

2016-02-17 Thread anonymous via Digitalmars-d

On 10.02.2016 22:31, anonymous wrote:

I've shot him an email.


No response for a week. Trying a GitHub @-mention now:
https://github.com/D-Programming-Language/dlang.org/pull/1212#issuecomment-185381136


Re: Confusion regarding struct lifecycle

2016-02-17 Thread anonymous via Digitalmars-d-learn

On 17.02.2016 17:36, Matt Elkins wrote:

I tried this, and got the same issue. Actually, I was still able to
reproduce the original reported issue as well, which leads me to believe
either the bug was not actually fixed or (and this is more likely) I
screwed something up with my install. Do I need to do anything special
to install a nightly build (I'm on Windows)?


For reference, link to the issue:
https://issues.dlang.org/show_bug.cgi?id=15661

As you can see on the bugzilla page, the fix was pushed to the 'stable' 
branch. But nightlies are probably built from 'master'. So the fix isn't 
in the nightlies until 'stable' gets merged into 'master'. At the 
latest, that should happen again with the 2.071 release.


You can build a 'stable' dmd from git. I just did that and I can say 
that the test code for issue 15661 now prints



HERE1a
HERE1b
HERE2


which seems to be the correct output, indicating that the issue got fixed.

However, the code from this thread still prints


Before 8
Before 1
Foo being destroyed: 0
Before 2
Foo being destroyed: 0
Before 3
Foo being destroyed: 0
After Foo construction
About to lose scope
Foo being destroyed: 0
Foo being destroyed: 3
Foo being destroyed: 2
Foo being destroyed: 1 


Foo being destroyed: 8


So, different issue?


[dlang.org] Getting the ddox pages out of limbo

2016-02-12 Thread anonymous via Digitalmars-d
We currently have two differently generated versions of the library 
documentation on dlang.org:


1) dlang.org/phobos/* (and dlang.org/phobos-prerelease/*) is generated 
by dmd's Ddoc functionality. These are the official docs, part of the 
"Documentation" section.


2) dlang.org/library/* (and dlang.org/library-prerelease/*) is generated 
by ddox (). Once upon a time, 
these docs were supposed to become official, replacing the other ones. 
Currently, they're in an unfortunate state of beta-forever.


ddox has a number of issues that make it currently not feasible to just 
switch over:


* Macro for "path to base of docs"?
https://github.com/rejectedsoftware/ddox/issues/87

* macros from parent scopes are not known in child scopes
https://github.com/rejectedsoftware/ddox/issues/116

* treating of underscore not consistent with dmd
https://github.com/rejectedsoftware/ddox/issues/117

There may be more.

Now, is the plan still to make the switch to ddox for the official 
documentation? Is anyone actually working towards that goal?


If not, maybe we should get rid of the ddox pages, at least for the time 
being. Currently, I think they do more harm than good: They confuse 
people who find them through google, and they drain maintenance resources.


Regarding google, hiding them via robots.txt could be a milder 
alternative to outright deleting them.


And then there's Adam D. Ruppe's . No idea how 
that plays into the whole mess we're in.


Re: static array of structs clarification questions

2016-02-12 Thread anonymous via Digitalmars-d-learn

On 12.02.2016 22:08, WhatMeWorry wrote:

question #1: The static array must contain the fat pointers to str
variables. But where is the string data itself actually held: the stack?
the heap? somewhere else? (does it vary depending on location or scope)


Depends on how the string was created. You can create dynamic arrays 
over any memory. (Remember: string is an alias of immutable(char)[], 
i.e. a dynamic array.)


I'm not sure where strings from literals are located. Could be some 
static data section in the executable, or some such. That's beyond me.



question #2: If the above struct was to contain the same struct and the
second one contains a third, how would the lower structs be allocated?
Is it "turtles all the way down?


Struct data is put right where the variable is. Unlike classes and 
arrays, structs are not references to some other location.


When a struct has a struct member, then the data of the member is put 
right next to the parent's data. The size of the member is added to the 
parent's size.


One consequence of this is that you can't have trees with just structs: 
`struct Node {Node left; Node right;}` - not gonna fly.



question #2: Of what use is the nulls in the array elements? When I took
out the member function: void info(), the nulls went away.


My guess is that you declared the struct in a function (e.g. main), and 
the null is the context pointer. Put the struct declaration at module 
scope, or make it `static`, and the null thing should go away.


A context pointer is needed when the struct references data from the 
surrounding function scope. You don't do that here, but the compiler is 
apparently not smart enough to figure that out.


Re: Can I get more opinions on increasing the logo size on the site please

2016-02-10 Thread anonymous via Digitalmars-d

On 10.02.2016 17:49, Ola Fosheim Grøstad wrote:

If you guys are going to create a
new logo based on the old one, you probably should clear it with the
original creator. On his website he has give us use rights for
non-commercial use, but not rights to create derivative works...


The new logo is not part of the pull request. It's already on the site. 
If there's a legal problem, we should probably revert that.


The exact text on the site of the original author [1] is

COPYRIGHT © SUKIMASHITA 2006
ALL FREE TO USE. ONLY SELLING THESE IMAGES IS PROHIBITED.

I'd understand that to allow derivative works, but disallow selling 
them. I'm not a lawyer, though.


If those terms don't allow us to mess with the logo, what kind of 
statement or license do we need from the author?



[1] http://media.sukimashita.com/d/


Re: Can I get more opinions on increasing the logo size on the site please

2016-02-10 Thread anonymous via Digitalmars-d

On 10.02.2016 22:37, CraigDillabaugh wrote:

I know I can take the logo from the website and blow it up, but it is
pretty small and enlarging it so much will result in a pretty awful
looking image.


It's an SVG file, so enlarging should work beautifully. If you're having 
trouble with it, I can upload a larger SVG or PNG version.


Is 256x256 the ideal format? Does it need to be square? The logo on the 
site is more wide than high. Do you want it cropped or centered?


Re: Can I get more opinions on increasing the logo size on the site please

2016-02-10 Thread anonymous via Digitalmars-d

On 10.02.2016 21:38, Ola Fosheim Grøstad wrote:

Ask for a Creative Commons license?


I've shot him an email.


Re: why mkdir can't create tree of dirs?

2016-02-09 Thread anonymous via Digitalmars-d-learn

On Tuesday, 9 February 2016 at 20:20:59 UTC, Suliman wrote:
It's look like that I can only create one nesting level sub 
folder, for example there is exists dir: D:\foo

I can't create dir D:\foo\bar\baz I can only create D:\foo\bar


http://dlang.org/phobos/std_file.html#.mkdirRecurse


td.windows.syserror.WindowsException@C:\D\dmd2\windows\bin\..\..\src\phobos\stdfile.d(2048):
 F:\foo\imgs_projected\jma_vis\1602\123: ╨б╨╕╤Б╤В╨╡╨╝╨╡ ╨╜╨╡ ╤Г╨┤╨╨╡╤В╤Б╤П 
╨╜╨░╨╣╤В╨╕ ╤Г╨║╨░╨╖╨░╨╜╨╜╤Л╨╣ ╨┐╤Г╤В╤М. (error 3)


What's up with that garbled text?


Re: UFCS on Enum in Member Function

2016-02-09 Thread anonymous via Digitalmars-d-learn

On Tuesday, 9 February 2016 at 21:05:50 UTC, jmh530 wrote:
For instance, in the code below, I could use Baz but not Caz. 
It seems to work when I use the alternate version of Caz 
calling a non-member function.


Bug?


No bug; works as intended. UFCS can only be used with free 
functions, not with methods.


Re: Safe cast away from immutable

2016-02-08 Thread anonymous via Digitalmars-d

On 08.02.2016 22:14, Iakh wrote:

Is all prams being const(but not immutable) not enough for
function to be Pure?


The hidden `this` parameter must be const, too. And mutable indirections 
in the return type must be considered.


This article explains it in detail:
http://klickverbot.at/blog/2012/05/purity-in-d/


Re: Odd Destructor Behavior

2016-02-07 Thread anonymous via Digitalmars-d-learn

On 07.02.2016 22:49, Matt Elkins wrote:

 From this non-reduced situation, does anything jump out? Am I missing
something about struct lifetimes? This is the only place I instantiate a
TileView.


Looks weird. I presume this doesn't happen with simpler constructor 
parameters/arguments, like int instead of Texture.Handle? I don't see 
how the parameter types would make a destructor call appear. Might be a bug.


Can you post the code for Texture, makeInputStream, etc, so that we have 
a full, reproducible test case?


Re: Odd Destructor Behavior

2016-02-07 Thread anonymous via Digitalmars-d-learn

On 07.02.2016 23:07, Márcio Martins wrote:

The destructor you are seeing is from the assignment:

m_tileView = TileView(...);

This creates a temporary TileView, copies it to m_tileView, and then
destroys it. I suppose you want to move it instead. You need to copy the
handles from the temporary into the destination, and then clear them out
from the temporary to prevent them from being released.


I think you're mistaken here. The result of a struct literal is usually 
moved implicitly.


Code:

import std.stdio;

struct S
{
~this() {writeln("dtor");}
}

void main()
{
auto s = S();
writeln("end of main");
}


Output:

end of main
dtor


If there was a copy that's destroyed after the assignment, there should 
be another "dtor" before "end of main".


Re: Odd Destructor Behavior

2016-02-07 Thread anonymous via Digitalmars-d-learn

On 07.02.2016 23:49, Matt Elkins wrote:

Oi. Yes, I can, but it is quite a lot of code even if you don't count
that it is dependent on OpenGL, GLFW, and gl3n to run to this point.
This is why I was disappointed that simpler reproducing cases weren't
appearing. I should probably spend more time trying to reduce the case
some...


Minimal test cases are great, but if you're not able to get it down in 
size, or not willing to, then a larger test case is ok, too. The problem 
is clear, and I'd expect reducing it to be relatively straight-foward 
(but possibly time-consuming). Just don't forget about it completely, 
that would be bad.


Also be aware of DustMite, a tool for automatic reduction:

https://github.com/CyberShadow/DustMite


Re: foreach seems to work with opIndex()

2016-02-06 Thread anonymous via Digitalmars-d-learn

On 06.02.2016 15:43, Tofu Ninja wrote:

Foreach seems to work if there is an opIndex() with no arguments that
returns a range interface, is this documented? I can't seem to find
anything that say this is supposed to happen. I am not really
complaining, its nice, but I just didnt really expect it because I feel
like I remember this being an error some time ago.


https://issues.dlang.org/show_bug.cgi?id=14619


Re: Type safety could prevent nuclear war

2016-02-04 Thread anonymous via Digitalmars-d

On 05.02.2016 00:47, tsbockman wrote:

You can do the same thing in D if you try, but it's not natural at all
to use `extern(C)` for *internal* linkage of an all-D program like that.

Any competent reviewer would certainly question why you were using
`extern(C)`; this scores much lower in "underhanded-ness" than the
original C program.


We do have a lot of bindings to C libraries, though. When there's a 
wrong alias in one of them, you have the same scenario.



Even so, I think that qualifies as a compiler bug or a hole in the D spec.


Can anything be done about it? The compiler simply has no way to verify 
declarations, has it?


Re: Type safety could prevent nuclear war

2016-02-04 Thread anonymous via Digitalmars-d

On 04.02.2016 23:57, tsbockman wrote:

http://www.underhanded-c.org/#winner

Actually, I'm surprised that this works even in C - I would have
expected at least a compiler (or linker?) warning; this seems like it
should be easy to detect automatically.


You can do the same thing in D, using extern(C) to get no mangling:

main.d:

alias float_t = double;
extern(C) float_t deref(float_t* a);
void main()
{
import std.stdio: writeln;
float_t d = 1.23;
writeln(deref()); /* prints "1.01856e-314" */
}


deref.d:

alias float_t = float;
extern(C) float_t deref(float_t* a) {return *a;}


Command to build and run:

dmd main.d deref.d && ./main




Re: DMD OSX / Segfault 11

2016-02-03 Thread anonymous via Digitalmars-d-learn

On 03.02.2016 14:16, Robert M. Münch wrote:

Well, it should of course be:

BaseOperator: Value {
}


Still missing "class". I know I'm being pedantic, but if you're being 
sloppy here, how do I know that you're not being sloppy where it matters?



Casting between class types that have an inheritance relation, like
Value and BaseOperator, does make sense (upcat/downcast).


Yes, that's what I need.


Do that then. Cast between class types. Pointers don't by you anything here.


If anything, you should be casting between Value* and BaseOperator*
(both pointer types) if you want to do something with pointers.


I tried this, but that doesn't work either.


Yeah, you can't check if the downcast succeeded this way. Casts between 
pointers always succeed (and then fail horribly at run-time).



But you very seldom need pointers to class references. Just return
Value from get, and cast to BaseOperator.


But am I not getting a copy then? I want to avoid copying objects as
much as possible.


No, you're not getting a copy. Classes are reference types. That means, 
variables of class types are references already. They're pointers in 
disguise.


Re: How do you get a hexstring from a base10 string -or- from a number?

2016-02-03 Thread anonymous via Digitalmars-d-learn

On 04.02.2016 00:45, Enjoys Math wrote:

On Wednesday, 3 February 2016 at 23:43:45 UTC, Enjoys Math wrote:
body { // is currently:
   return to!string(this.toHash());
}

and is returning a base10 string, so how would I return a hex string so
I can compare numbers displayed to the debugger addresses in visual D?


to!string has an optional radix (aka base) parameter:

  return to!string(this.toHash(), 16);


Re: Why this code can't take advantage from CTFE?

2016-02-03 Thread anonymous via Digitalmars-d-learn

On 03.02.2016 16:34, Andrea Fontana wrote:

void main()
{
 enum first = very_very_long_function(10);
 writeln("First is ", first);

 auto second = very_very_long_function(12);
 writeln("Second is ", second);

 auto third = first;
 third += 1;
 writeln("Third is ", third);
}

Why second init doesn't work with CTFE? It could be something like
third, but with one less copy. What am I missing?


The compiler doesn't try to apply CTFE everywhere, because it could take 
forever. So CTFE is only done when the programmer requests it by using a 
function in a static context.


The compiler is still free to precompute the value at compile time, if 
it thinks that's a good idea, but that's just an optimization. And while 
it's evaluation of a function at compile time, it's not CTFE in the 
sense of __ctfe.


Re: Interested in D, spec confuses me.

2016-02-02 Thread anonymous via Digitalmars-d

On 02.02.2016 20:50, Bambi wrote:

Making the return value immutable is a very different thing from making
every value of the object immutable to the method alone.


Sure it's a different thing, but the meaning of "immutable" is the same.

By the way, it's not that the object's fields are made immutable for the 
method, but the method can only be called on immutable objects.



These are
different meanings. It reads like a redundancy but has different
meanings. This isn't good in my eyes.


I don't see how it reads like a redundancy. Surely, you don't expect a 
redundancy in this:


void f(immutable int[] a, immutable int[] b);

The other signature is no different. Two occurrences of "immutable", 
applying to two different things.


I agree that it can be unclear to newbies what exactly is immutable when 
a method is marked immutable, but the meaning of the keyword is the same 
as elsewhere. Using another word there would be more confusing.


Re: const and immutable member variables in classes

2016-02-02 Thread anonymous via Digitalmars-d-learn

On 02.02.2016 23:48, Ali Çehreli wrote:

struct S {
 const int c;// Makes S non-assignable
 immutable int i;// Makes S non-assignable
}

void main() {
 auto a = S();
 auto b = S();
 a = b;  // Compilation ERROR
}

(That is the same issue in C++.)

That's why I've been avoiding them altogether. However, considering that
there is no default-assignment for classes, there is no problem with
using const or immutable members with classes, right?


I'm not sure what you mean by "default assignment". I'd say it works 
more simply with classes, because they're reference types. It's the same 
as using pointers to structs:


auto a = new S();
auto b = new S();
a = b; /* no problem */


Re: DMD OSX / Segfault 11

2016-02-02 Thread anonymous via Digitalmars-d-learn

On 02.02.2016 19:06, Robert M. Münch wrote:

I have a very strange effect, I'm not sure what it is about:

Value: {}

WordV: Value {
 Value* get() {}
}

BaseOperator: Value : {
}


This isn't valid D code at all, which makes it unnecessarily hard to 
understand what you mean.



Now comes the code using this:

auto op = cast(BaseOperator)(Word.get());
if (op !is null) {...


If get() returns "Value*" it segfaults, if I change it to "Value" it
works. How can this be?


A Value* is a pointer to a class reference. Unless you're doing 
something really funky with the pointer, casting it to a class type 
doesn't make sense.


Casting between class types that have an inheritance relation, like 
Value and BaseOperator, does make sense (upcat/downcast).


If anything, you should be casting between Value* and BaseOperator* 
(both pointer types) if you want to do something with pointers.


But you very seldom need pointers to class references. Just return Value 
from get, and cast to BaseOperator.


Re: Switch with dynamic case

2016-02-02 Thread anonymous via Digitalmars-d-learn

On 02.02.2016 15:07, Daniel Kozak wrote:

import std.stdio;
import std.typetuple : TypeTuple;

alias cs = TypeTuple!(0, 1, 2, 3);

void main(string[] argv)
{
 switch(argv.length)
 {
 default: writeln("Uknown number of args"); break;
 foreach(c; cs)
 {
 case c: writefln("%s args", c);
 break;
 }
 }
}

This works, but I dont know why or how, is there some documentation
about this feature?


The key thing to understand is that the foreach is a "static" one. A 
static foreach is unrolled at compile-time.


So that switch code is replaced at compile time with this, almost:


switch(argv.length)
{
default: writeln("Uknown number of args"); break;

case 0: writefln("%s args", 0);
break;

case 1: writefln("%s args", 1);
break;

case 2: writefln("%s args", 0);
break;
}


"But", I hear you ask, "it breaks when I put the default at the bottom. 
What's up with that?". Yeah, that's a bit weird/buggy.


The problem is with the break statement. It applies to the foreach, not 
to the switch. And while the foreach is unrolled at compile-time, the 
break is evaluated at run-time. The generated code really looks more 
like this:



switch(argv.length)
{
default: writeln("Uknown number of args"); break;

/* start of unrolled foreach */
case 0: writefln("%s args", 0);
goto behind_foreach;

case 1: writefln("%s args", 1);
goto behind_foreach;

case 2: writefln("%s args", 0);
goto behind_foreach;
/* end of unrolled foreach */
behind_foreach:
}


So, the breaks skip past the other cases that were created by the 
foreach, but they don't actually break out of the switch.


There are at least two open issues related to this:

https://issues.dlang.org/show_bug.cgi?id=14887
https://issues.dlang.org/show_bug.cgi?id=7835

Everything works fine when breaking the switch with a label:


sw: switch(argv.length)
{
foreach(c; cs)
{
case c: writefln("%s args", c);
break sw;
}
default: writeln("Uknown number of args"); break;
}


Unfortunately, the spec is rather quiet about static foreach. And you 
won't actually find the term "static foreach". The only thing I could 
find is a little "Foreach over Tuples" section on 
, which doesn't tell a lot.


Re: Interested in D, spec confuses me.

2016-02-02 Thread anonymous via Digitalmars-d

On 02.02.2016 15:36, Bambi wrote:

The example snippet ' immutable(int[]) bar() immutable {} ' brings back
bad memories of redundant declarations of the style ' Object object =
new Object(); '. And homonyms in programming languages seem like a bad
idea in general.


"immutable" is not a homonym here. It means the same thing ("cannot ever 
change"). And it's not redundant either, as the two instances apply to 
different targets. It's clear what the first "immutable" ties to: It 
qualifies the return type. The second one is less clear: It qualifies 
the type of the object, meaning the method can only be called on an 
immutable object.


Leaving either of them out changes the meaning of the signature:
`int[] bar() immutable {}` - Return type is mutable now.
`immutable(int[]) bar() {}` - Object type is mutable now. I.e., this 
method can be called on a mutable object, and it cannot be called on an 
immutable object.


Re: CTFE thoughts & functional approach

2016-02-02 Thread anonymous via Digitalmars-d

On 02.02.2016 09:27, Robert M. Münch wrote:


==> BEGIN

[...]

enum A {afoo, bfoo, cfoo};


(Aside: In D no semicolon is needed here.)


string generateEnums(T...)(string type){
string code = "enum " ~ type ~ " {";

// this is a static foreach (compile time)
foreach(m; T){
  debug pragma(msg, m ~ ","); // check what code we get at compile time
  code ~= m ~ ",";
}

return(code ~ "}");


(Aside: Those parentheses are misleading. return is not a function.)


}

int main(){

[...]

mixin(generateEnums!members1("B"));
B switch_var_b = chomp(user_input).to!B; // get rid of terminating
chars


[...]

}

<== END


I'm not saying that everything is perfect as it is, but that code can be 
made nicer with what we have right now:



template generateEnums(string[] members)
{
// 'join' variant:
import std.array: join;
mixin("enum generateEnums {" ~ members.join(",") ~ "}");

// 'format' variant:
// import std.format;
// mixin(format(q{ enum generateEnums {%-(%s, %)} }, members));
}

void main()
{
alias B = generateEnums!([members1]);
B switch_var_b = chomp(readln()).to!B;
/* ... */
}



How about being able to write something like "ensure_final_switch B;"
and have this call a CTF that generates the necessary code and has
access to tool for building D structured code, AST etc.? And has a
compile-time state I can later access in a upcoming CTF.


So you're asking for AST macros, I suppose. There are two DIPs for them:

http://wiki.dlang.org/DIP50 - AST Macros
http://wiki.dlang.org/DIP78 - AST Macros Lite

I don't know where they stand, as I'm not really interested in the whole 
thing, but maybe one of those matches your vision.


If that's not what you have in mind, please be more concrete about what 
you think of. Maybe show some pseudo code showing how you'd like to be 
able to solve the example of generating enums.


Re: Declaring rvalue function arguments

2016-01-31 Thread anonymous via Digitalmars-d-learn

On 31.01.2016 18:21, Matt Elkins wrote:

I know I can mark an argument ref to require lvalues, so I'm wondering
whether there is an equivalent for rvalues; that is, is there a way to
specify that an argument to a function MUST be an rvalue?

For example, in C++ I can do this:
[code]
void foo(int && x) {...}

foo(5); // Works fine
int y = 5;
foo(y); // Compile error; y is not an rvalue
[/code]

This functionality turns out to be really useful when dealing with
transferring ownership of resources.


I don't know if this works in all cases, but it passes that simple test:


@disable void foo(ref int x);
void foo(int x) {}

void main()
{
foo(5); /* works */
int y = 5;
foo(y); /* error */
}



Re: Problem when calling toJSON()

2016-01-31 Thread anonymous via Digitalmars-d-learn

On 01.02.2016 01:29, Alex Herrmann wrote:

This problem is solved! Sorry for not updating the question.

It was actually a problem with me not iduping it, and the memory being
reclaimed or something similar. I did also change to stdx.data.json
(std_data_json on dub).


You don't seem to be clear on what exactly went wrong. So here's an 
explanation:


On 31.01.2016 23:52, Alex Herrmann wrote:
>  auto outmd5 = JSONValue(cast(string) toHexString(md5_hash));

That cast is bad. You're casting a fixed-size char array to string, 
effectively slicing it. The data will get corrupted when the fixed-size 
array goes out of scope. Which happens immediately here, as you don't 
store the result of the toHexString call anywhere.


As you mentioned, .idup instead of cast is the proper way to do this. 
std.conv.to!string is another option.


Generally, casts should be avoided. It's easy to mess up with them in 
subtle ways.


Re: CTFE thoughts & functional approach

2016-01-31 Thread anonymous via Digitalmars-d

On Sunday, 31 January 2016 at 13:59:06 UTC, Robert M. Münch wrote:

I like CTFE and the meta programming idea for languages like D.

However, I'm wondering why most (everyone?) is trying to do 
meta-programming using the same language as the one getting 
compiled. IMO the use-cases a pretty different and doing CTFE, 
code-generation etc. needs some other approach. If you look at 
all the strange template syntax, strange hacks etc. it's all 
far from being obvious.


You're conflating CTFE with the other meta programming tools 
here. CTFE is the same language as run-time D, but it doesn't 
have strange template syntax. Templates, static if, __traits, 
etc. have strange syntax, but they're sort of a different 
language already.


Are you maybe wishing for a nicer alternative to templates, etc?

Why not have a CTL (compile-time-language) that has access to 
some compiler internals, that follows a more functional 
concept? We are evaluating sequences of things to generate 
code, include / exclude code etc.


From my experience with the different approaches, functional 
thinking is much better suited and simpler to use for CTFE 
goals.


IMO that would really be a big step ahead. Because you know a 
hammer, not everything is a nail...


I think this is too vague to lead anywhere. At least you should 
identify specific problems with D's toolset. And if you have 
concrete ideas for improvements, you should desribe them in more 
detail, spelling out how they improve upon the status quo.


If you want to have an entirely different meta programming 
system, then you should show how it would look like, and how it 
would be better than the status quo. I don't think anyone can 
make much of "make it more functional". Also, when it's 
fundamentally different from what we have now, then I don't see 
it getting into D at the moment. The language is not in a phase 
of designing fundamentals.


Re: How do you initialize a class instance which has static storage within another class?

2016-01-30 Thread anonymous via Digitalmars-d-learn

On 30.01.2016 22:52, Enjoys Math wrote:


class A { static B b; } class B {}

doing b = new B() does NOT work.

Nor could I create a this() {} at module level


It works when you make b const/immutable:

class A {static immutable B b = new B;} class B {}

If you want/need b to be mutable, you can use a static constructor 
(`static this`), either in the class or the module:


class A {static B b; static this() {b = new B;}} class B {}
class A {static B b;} static this() {A.b = new B;} class B {}

You could also set it in `main` or another function that runs before b 
is used, of course.


Re: Error using templates: "cannot use template to add field to aggregate ''"

2016-01-25 Thread anonymous via Digitalmars-d-learn

On 25.01.2016 15:51, pineapple wrote:

class unitvalue{
 double coefficient;
 int[unit] exponents;

 unitvalue copy(){
 unitvalue value = new unitvalue();
 value.coefficient = this.coefficient;
 value.exponents = this.exponents.dup;
 return value;
 }

 template opmethod(string methoddef, string methodcall){
 const char[] methodtemplate =


Can't have variables like that in templates. Make it a "manifest 
constant" with  enum. Also, if you want opmethod!("foo", "bar") to 
evaluate to the code, then methodtemplate needs to be renamed to 
"opmethod". I.e., make this line:


enum opmethod =


Also, opmethod doesn't need to be template. A function would work as well:

static string opmethod(string methoddef, string methodcall)
{
return
"unitvalue " ~ methoddef ~ "{
unitvalue copy = this.copy();
copy." ~ methodcall ~ ";
return copy;
}"
;
}

mixin(unitvalue.opmethod(
"sum(in unitvalue value)", "add(value)"
));



 "unitvalue " ~ methoddef ~ "{
 unitvalue copy = this.copy();
 copy." ~ methodcall ~ ";
 return copy;
 }"
 ;
 }

 mixin(unitvalue.opmethod!(
 "sum(in unitvalue value)", "add(value)"
 ));
 void add(in unitvalue value){
 if(!this.samedimensions(value)){
 throw new Exception("Cannot add values of differing
dimensions.");
 }else{
 this.coefficient += value.coefficient;
 }
 }

 bool samedimensions(in unitvalue value){
 return this.exponents == value.exponents;


This gives me an error, too: "Error: incompatible types for 
((this.exponents) == (value.exponents)): 'int[int]' and 'const(int[int])'"


(I've aliased unit to int.)

As far as I can tell, this should work. There's a bugzilla issue for it:
https://issues.dlang.org/show_bug.cgi?id=13622

You can work around the bogus error message by using a const temporary 
for this.exponent:


const this_exponents = this.exponents;
return this_exponents == value.exponents;



 }
}





Re: Templates, templates, templates...

2016-01-24 Thread anonymous via Digitalmars-d-learn

On 24.01.2016 10:02, Voitech wrote:

I added base class for Rule -> BaseRule. But this class is just a shell
without implementation.
Is there any way to avoid this ?


What's the problem with BaseRule not having any implementation? When the 
different Rule instantiations don't have any common operations that can 
be put there, then BaseRule's purpose is only to be a common supertype.


Re: [dlang.org] Let's talk about the logo

2016-01-24 Thread anonymous via Digitalmars-d

On 22.01.2016 00:46, anonymous wrote:

http://i.imgur.com/eJaKFtx.png

[...]

For dlang.org, I'd choose the version with the wide background arc. I
think it looks nice on the menu bar, and it puts a little more emphasis
there than just the core shape. But just the core shape looks fine, too.


I made a pull request for the wide one (the third one from the top):

https://github.com/D-Programming-Language/dlang.org/pull/1212


Re: core.thread.Thread.start is marked as "nothrow" but documentation says it throws

2016-01-23 Thread anonymous via Digitalmars-d-learn

On 23.01.2016 12:44, tcak wrote:

https://dlang.org/phobos/core_thread.html#.Thread

final nothrow Thread.start()

Looking at the code, no "throw new ..." is seen, but the function
"onThreadError" is called
which has "throw" in it.

Most weird thing is that "onThreadError" function is marked as "nothrow"
but it still throws.

I would think that yes, maybe the compiler might not be able to see it
because throw is found
in another function, but how come "onThreadError" throws with nothrow.


onThreadError [1] throws a ThreadError [2] which derives from Error, as 
the name suggests. nothrow functions may throw Errors, because Errors 
are considered a way of force-exiting the program. Errors are not 
supposed to be caught.


So onThreadError is fine. And if Thread.start can actually only throw 
ThreadError, and not ThreadException, then that one is ok too, but the 
documentation is wrong and should be fixed.



[1] 
https://github.com/D-Programming-Language/druntime/blob/33f1962747801be35a48f4875c909e16747fdcce/src/core/thread.d#L2972
[2] 
https://github.com/D-Programming-Language/druntime/blob/33f1962747801be35a48f4875c909e16747fdcce/src/core/thread.d#L88


Re: Templates, templates, templates...

2016-01-23 Thread anonymous via Digitalmars-d-learn

On 23.01.2016 12:30, Voitech wrote:

Ok so i want to hold different types in LogicRule maybe Algebraic
implementation would do?

private alias ControllTemplate(T) =Rule!(T,ControllFlag);
private alias SymbolRule =ControllTemplate!(SymbolType);
private alias StringRule =ControllTemplate!(SymbolRule[]);
private alias LogicTemplate(T...)
=Rule!(Algebraic!(ControllTemplate(T))[],LogicFlag); <--error


You're missing an exclamation mark there, and you've got the order of 
Algebraic and ControllTemplate wrong. This compiles:


private alias LogicTemplate(T...) = 
Rule!(ControllTemplate!(Algebraic!T)[],LogicFlag);



private alias AlgebraicLogicRule = LogicTemplate!(SymbolRule,StringRule);

error:
Error: cannot pass type (Rule!(SymbolType, ControllFlag),
Rule!(Rule!(SymbolType, ControllFlag)[], ControllFlag)) as a function
argument

[...]

Is there any nicer way to handle this case ?


Instead of Algebraic you could use a common base class, or interface, 
for the Rule instantiations:


abstract class RuleBase
{
... whatever common functionality rules have ...
}
class Rule(V,F) : RuleBase { ...}

But I have to say that I'm having trouble making sense of all that class 
and template complexity, and how it helps in actually validating user input.


Since this is a parsing thing, you may want to look into writing parsers 
an/or using a parse generator. I think Pegged is the most popular one 
for D. http://code.dlang.org/packages/pegged


Re: [dlang.org] Let's talk about the logo

2016-01-22 Thread anonymous via Digitalmars-d

On 22.01.2016 20:53, ronaldmc wrote:

I don't want to start a war, but this isn't community? I mean aren't we
trying to make things better, because the way you said it seems like a
dictatorship.


It's dictatorship insofar as Walter and Andrei have veto power. If they 
don't want something in, it doesn't go in. I don't think this is a 
problem in practice. If it was, the community could always fork the 
project and then play by their own rules.


And of all things, the logo wouldn't be a good reason to divide over, in 
my opinion.


Re: D ASM. Program fails

2016-01-22 Thread anonymous via Digitalmars-d-learn

On 22.01.2016 21:34, Iakh wrote:

This code returns 0 for any input v


It seems to return 5 here: http://dpaste.dzfl.pl/85fb8e5c4b6b


Re: [dlang.org] Let's talk about the logo

2016-01-22 Thread anonymous via Digitalmars-d

On 22.01.2016 16:48, WebFreak001 wrote:

(First I have fixed these weird curves on the D's bottom left and top
left corner.)


What's weird about them? As far as I see, you made the corners more 
pointed, though it's hard to tell at that size. I'm not sure if that's 
an improvement.


Re: [dlang.org] Let's talk about the logo

2016-01-22 Thread anonymous via Digitalmars-d

On 22.01.2016 20:08, WebFreak001 wrote:

Original: https://i.imgur.com/6M1Eoy2.png

Fixed: https://i.imgur.com/uLuUgJY.png


:D

Yeah, uhm, that's totally an improvement, of course.


Re: D ASM. Program fails

2016-01-22 Thread anonymous via Digitalmars-d-learn

On 22.01.2016 06:59, Iakh wrote:

import std.stdio;
import core.simd;

int pmovmskb(inout byte16 v)
{
 asm
 {
 movdqa XMM0, v;
 pmovmskb EAX, XMM0;
 ret;
 }
}
void main()
{
 byte16 a = [-1, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0];
 auto i = pmovmskb(a);
}


I don't know much about these things, but it seems to be the `ret;`.

This doesn't segfault:

int pmovmskb(byte16 v)
{
int r;
asm
{
movdqa XMM0, v;
pmovmskb EAX, XMM0;
mov r, EAX;
}
return r;
}


Removed the `inout` because it doesn't make sense. You may be looking 
for `ref`.


Re: `static` symbol needs to be `immutable` for compile-time access?

2016-01-22 Thread anonymous via Digitalmars-d-learn

On 22.01.2016 10:56, Shriramana Sharma wrote:

Do all values which need to
be readable at compile time need to be declared `immutable`?


Yes, `static immutable` or `enum`.


In C/C++ the `static` here is used to avoid the array being created every
time the function is entered; in D too it does the same thing, no?


Yes, it's the same in D.

But without `immutable` you could make `func` return a different value 
per call, i.e. `func` would not be pure. Impure compile time 
calculations are not allowed. One reason for that is that it would 
require specifying an order in which they're done, which would be weird, 
especially with separate compilation of modules.



So if I
have an array of constants in a function that I need to be accessible to a
template at compile time, and I (for obvious reasons) don't want to be
initialized at every function call, do I have to declare it `static
immutable`?


Yes, without `immutable` they're not constants to the compiler.


Re: [dlang.org] Let's talk about the logo

2016-01-22 Thread anonymous via Digitalmars-d

On 22.01.2016 20:08, WebFreak001 wrote:

Original: https://i.imgur.com/6M1Eoy2.png

Fixed: https://i.imgur.com/uLuUgJY.png


Can you post the fixed SVG code, so that I can update my stuff?


Re: [dlang.org] Let's talk about the logo

2016-01-22 Thread anonymous via Digitalmars-d

On 22.01.2016 15:44, WebFreak001 wrote:

However I dont have an SVG for that and I basically just used the logo
from the imgur screenshot, cut of a rounded rectangle (5px border
radius) and added a simple box shadow (0px 1px 3px rgba(0,0,0,0.3))


Here's the SVG. Go crazy.

https://gist.github.com/anonymous/421e80748f1c885f7620


Re: `static` symbol needs to be `immutable` for compile-time access?

2016-01-22 Thread anonymous via Digitalmars-d-learn

On 22.01.2016 15:33, Shriramana Sharma wrote:

It would seem that in the case of arrays, the former is preferable to the
latter, as per the para above this header:

http://ddili.org/ders/d.en/const_and_immutable.html#ix_const_and_immutable.variable,
%20immutable


The link doesn't work for me, but yes, `static immutable` is usually 
better for arrays than `enum`.



But a further question, if I don't declare them as `static immutable` but
just as `immutable`, would that mean that those arrays are necessarily
created (meaning memory allocation) every time the function is run?


I guess compilers may reuse the same array for all calls, seeing that 
the value is a constant, but I don't think they're required to do so.


[dlang.org] Let's talk about the logo

2016-01-21 Thread anonymous via Digitalmars-d
The logo is repeatedly being called out as a weak spot of the D brand. 
But so far Walter has been adamant about keeping it the way it is.


I agree with him that changing it to a completely different one would 
probably not be a good move, losing whatever brand recognition we have. 
But I think we should adapt the logo to the needs at hand.


It's obvious to me that the D and the moons (the two circles to the 
upper right of the D) make the recognizable core of the logo. I know 
that others see it the same way. That means, the D and the moons should 
be kept intact. Their shapes and positions should not change.


However, I believe we can take away a lot of the decorations of the 
current logo, and it will still be recognized immediately as the same brand.


Here's a little progression of simplifications, in the context of dlang.org:

http://i.imgur.com/eJaKFtx.png

The first one is the current logo. The last one shows just the core 
shape (D + moons), of course.


I'm not nearly the first one to do this, but I'd like to propose 
adopting the core shape as the official logo. Then specify some specific 
shade of red as the official brand color. (We're using #B03931 on 
dlang.org.)


We could provide multiple variants of the logo for different use cases, 
and with varying levels of decoration:


* Core shape in different color combinations (black one white, red on 
white, white on red).
* Versions that include the background arc (I'm interpreting that as 
Mars), possibly in different colors.
* The full version with border and shadow. I.e. the current logo with 
adjusted colors, and maybe some details changed, like number of borders 
or amount of shininess.


For dlang.org, I'd choose the version with the wide background arc. I 
think it looks nice on the menu bar, and it puts a little more emphasis 
there than just the core shape. But just the core shape looks fine, too.


Re: writeln wipes contents of variables ?

2016-01-21 Thread anonymous via Digitalmars-d-learn

On 22.01.2016 01:49, W.J. wrote:

How can I identify those ranges, or, how can I tell if any particular
range has value semantics ? I didn't read any of this in the manual -
not that I could remember anyways.


Generally you shouldn't. If you care about it either way, use .save or 
std.range.refRange.


If you don't want some range r to be consumed by some operation, pass 
r.save instead of plain r. If you want r to be consumed, pass 
refRange(). Only if you don't care if r is consumed or not, should you 
pass simply r.


If you know for a fact that copying r is the same as r.save, then you 
can just pass (and copy) r, of course. We know it's that way with 
dynamic arrays, because of their nature as pointer+length structures. 
But there's nothing wrong with calling .save on an array anyway.


Also, when a function takes a range via a ref parameter, then you don't 
need refRange, of course. The ref parameter ensures that no copy is made 
and that the original range is affected by the function.


Re: Do D need a popular framework? like ruby's rails? or java 's ssh?

2016-01-19 Thread anonymous via Digitalmars-d-announce

On 19.01.2016 14:22, beck wrote:

Do D need a popular framework?
in china ,a little peopel use dlang.
i just  use it do some simple work for myself. yet,i have learn d for a
week ..
i ask so many friends ,they don't use D at all.we use golang more than
dlang.


Please don't post questions or suggestions like this to the Announce 
group. The announce group is for software releases, book publications, 
stuff like that. The General group would have been the right place for this.


Re: Unions and Structs

2016-01-18 Thread anonymous via Digitalmars-d-learn

On 18.01.2016 18:10, Russel Winder via Digitalmars-d-learn wrote:

So this is an error?

union flob {
ulong data;
struct thingy {
uint data;
uint bits;
}
thingy burble;
};

because you cannot have a union field with a name that is also the name
of a struct field defined within the union.


I don't see the problem. You have to access the thingy's 'data' through 
the 'burble' member, so there is no ambiguity, is there?


This would be different, and dmd rejects it accordingly:

union flob {
ulong data;
struct {
		uint data; /* test.d(4): Error: variable test.flob.data conflicts with 
variable test.flob.data at test.d(2) */

uint bits;
}
}




Re: [dlang.org] new forum design

2016-01-18 Thread anonymous via Digitalmars-d

On 18.01.2016 19:59, Andrej Mitrovic via Digitalmars-d wrote:

Btw, drop-down menus which do not drop-down on hover are really
strange. I've never seen a drop-down menu on a modern website which
required you to click to open and click to close.


Microsoft does this.


Re: [dlang.org] new forum design

2016-01-18 Thread anonymous via Digitalmars-d

On 18.01.2016 20:35, Andrej Mitrovic via Digitalmars-d wrote:

On 1/18/16, anonymous via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

[...]

Microsoft does this.



And techcrunch apparently too..


Another one: stackoverflow


Re: [dlang.org] new forum design

2016-01-18 Thread anonymous via Digitalmars-d

On 18.01.2016 21:32, wobbles wrote:

On the reddit thread, a bug in safari was posted:
"
I found a bug on Safari 7.1.3: each time I click the "Edit" button for
the code editor, the gray panel with the code it in gets longer, and
pushes the rest of the content in the site down. Here's an album with
the before/after screenshots. http://imgur.com/a/TIylc
"
https://www.reddit.com/r/programming/comments/41j1nm/check_out_ds_new_site/cz32v1v


We may already have a ticket for this:
https://issues.dlang.org/show_bug.cgi?id=15548

I have no idea what's going on here, and I don't have a Mac. So if 
anyone with access to Safari could have a look at this, that would be 
great :)


I've tried using browserstack.com to make sense of this. But you only 
get 30 minutes free trial time, and after 16 minutes all I know is that 
removing `editor.refresh()` from the edit button action [1] seems to 
help. But the "Reset" button still messes things up. Also, since this 
apparently wasn't an issue with the old design, and the JS code hasn't 
been touched, this should be fixable in CSS.



[1] 
https://github.com/D-Programming-Language/dlang.org/blob/818d38b19cfa357e79d991c55fd3a63d7fd9a39f/js/run.js#L492


Re: Logo for D

2016-01-17 Thread anonymous via Digitalmars-d-announce

On 17.01.2016 18:55, Karabuta wrote:

Ohh! A great design is better seen by a designer. "Iron with steal,
steel with gold, gold with diamond". Always room for improvement.


I don't understand.


copying directories recursively

2016-01-17 Thread anonymous via Digitalmars-d-learn

TL;DR: Is there a simple way to copy directories recursively?

My goal is to copy the directories ./src/dlang.org/{css,images,js} and 
their contents to ./ddo/{css,images,js}.


Naively I tried this:


void main()
{
import file = std.file;
auto outputPath = "./ddo/";
foreach (dir; ["css", "images", "js"])
{
file.copy("./src/dlang.org/" ~ dir, outputPath ~ dir);
}
}


But that fails with "std.file.FileException@std/file.d(3154): 
src/dlang.org/css: Is a directory".


`copy` doesn't have a parameter to enable copying directories, and I 
can't find any `copyDir` or `copyRecurse` or some such.


As it looks I'll end up implementing my own `copyRecurse`:


void copyRecurse(string from, string to)
{
import std.file: copy, dirEntries, isDir, isFile, mkdirRecurse, 
SpanMode;

import std.path: buildNormalizedPath, buildPath;

from = buildNormalizedPath(from);
to = buildNormalizedPath(to);

if (isDir(from))
{
mkdirRecurse(to);

auto entries = dirEntries(from, SpanMode.breadth);
foreach (entry; entries)
{
auto dst = buildPath(to, entry.name[from.length + 1 .. $]);
// + 1 for the directory separator
if (isFile(entry.name)) copy(entry.name, dst);
else mkdirRecurse(dst);
}
}
else copy(from, to);
}


Is there a simpler way to do this?


Re: [dlang.org] new forum design - preview

2016-01-16 Thread anonymous via Digitalmars-d

On 16.01.2016 14:18, Jacob Carlborg wrote:

I think it's too small to be useful. I always read in landscape mode
because I think the font size is too small. It would be even better if
the reader view worked (iPhone).


Looks like I had accidentally made it a bit smaller. Fixed it.


Re: Logo for D

2016-01-16 Thread anonymous via Digitalmars-d-announce

On 16.01.2016 18:55, karabuta wrote:

How do you see it?

http://amazingws.0fees.us/wp-content/uploads/2016/01/dlang2.png

Many variants are on the way.


Do you intend to propose this for the official logo?

If so, be aware that the logo is a delicate matter. There have been 
various proposals to change it from the current one, and all have been 
rejected. It's Walter himself who is rather strictly against any changes.


I have been pushing for this variant:

https://gist.github.com/aG0aep6G/0803ec5ae49f6afb0196

You see it's very, very similar to the current one. To the point that 
you could say it's really the same logo. Yet, it was the one part of the 
red-top-bar redesign that didn't fly with the powers that be. I haven't 
given up yet, though.


By the way, I'm not sure if this is announcement material. If you're 
looking for feedback, I think the General group would have been a better 
fit.


Re: Rust's website is really good

2016-01-16 Thread anonymous via Digitalmars-d

On 16.01.2016 16:53, karabuta wrote:

OK. How do I contribute to the design? I will run away if I have to go
through a long process b4 i can do that:)


In the end someone will have to make a successful pull request against 
the dlang.org git repository. That means cloning the repository, 
applying your changes, and pushing through review. When the changes are 
non-trivial, it means being/getting familiar with Ddoc and the other 
stuff that's used in the dlang.org code.


There's a wiki page about all that:
http://wiki.dlang.org/Contributing_to_dlang.org

You can very meaningfully contribute without doing all that yourself, 
though. An HTML+CSS mockup goes a long way. It can be discussed, 
approved/rejected, and if you're not willing/able to do the actual 
dlang.org code, maybe someone else takes it on. That's exactly how the 
current push for the red-top-bar redesign came about.


Re: Logo for D

2016-01-16 Thread anonymous via Digitalmars-d-announce

On Saturday, 16 January 2016 at 18:56:36 UTC, karabuta wrote:

Nope. Just playing around. Why did they reject yours by the way?


It's not been rejected outright. More like put on ice. Or maybe 
I'm just not getting the hints :)


Andrei said: "Can we defer any changes to the logo so we don't 
get sidetracked in this? Just scale the existing logo to fit and 
defer any changes to it to later."

-- http://forum.dlang.org/post/n591ec$aqv$1...@digitalmars.com


Re: Functions that return type

2016-01-16 Thread anonymous via Digitalmars-d-learn
On Saturday, 16 January 2016 at 21:22:15 UTC, data pulverizer 
wrote:
Is it possible to create a function that returns Type like 
typeof() does? Something such as:


Type returnInt(){
return int;
}


No. A function cannot return a type. A template can evaluate to a 
type, though:



template returnInt(){
alias returnInt = int;
}



More to the point what is the Type of a type such as int?


Types don't have types. You can check if something is a type with 
an IsExpression: `is(T)` is true if T is a type.


Re: [dlang.org] new forum design - preview

2016-01-15 Thread anonymous via Digitalmars-d

On 14.01.2016 23:03, tsbockman wrote:

On Thursday, 14 January 2016 at 19:46:33 UTC, anonymous wrote:

Would a border help? http://i.imgur.com/XoPddxr.png

Or how about making the whole area gray? http://i.imgur.com/AXrmKU4.png


Either of those would be an improvement.


I went with the border. It's easier to implement and less likely to be 
controversial. http://beta.forum.dlang.org does not show it yet. I guess 
Vladimir needs to push a button for that.


Re: [dlang.org] new forum design - preview

2016-01-15 Thread anonymous via Digitalmars-d

On 14.01.2016 22:58, ddd wrote:

Cant you do a max-width on the container holding the main page? I agree
it should


I guess there should be a "not" in here?


be an entire 2k display but my laptop the sidebar could easily
push the edge of the window.


The container has a max-width. There's still a padding to the left of 
the subnav so that the grey box is aligned with the D logo above.


Re: [dlang.org] new forum design - preview

2016-01-15 Thread anonymous via Digitalmars-d

On 13.01.2016 18:13, Saurabh Das wrote:

+1 for Sans-serif fonts! I find them much easier to read too :)
(anonymous has assured me that this font will grow on me though).


I only said it grew on me :)


The page is too white. The style looks good on the main website, but on
the forum makes it difficult to read.


Does that mean it's bad for reading longer text? We shouldn't use white 
background for large parts of the main site either then.


Re: Index a parameter tuple with a run-time index

2016-01-15 Thread anonymous via Digitalmars-d-learn

On 15.01.2016 21:42, Nordlöw wrote:

How do I index a function parameter tuple with a run-time index?


With a switch and a static foreach:


void f(A...)(size_t i, A a)
{
import std.stdio: writeln;
switch_: switch (i)
{
foreach (iT, T; A)
{
case iT: writeln(T.stringof); break switch_;
}
default: writeln("??"); break;
}
}

void main()
{
f(0, "foo", 42); /* string */
f(1, "foo", 42); /* int */
f(2, "foo", 42); /* ?? */
}



Re: local import hijacking

2016-01-14 Thread anonymous via Digitalmars-d

On 14.01.2016 15:25, Byron Heads wrote:

I got burned by this yesterday, this code should not compile

import std.experimental.logger : trace;


void foo() {
 import std.net.curl : trace;
 trace("hello");
}


void main() {
 foo();
}


I don't see a problem with that specific code. You're explicitly 
importing `trace` from std.net.curl, so it can't be surprising that it's 
called.


But change one little detail and this qualifies as hijacking, I think:


void foo() {
import std.net.curl; /* not mentioning trace */
trace("hello");
}


Imagine that std.net.curl didn't have a `trace` function when the code 
was written. std.experimental.logger.trace would have been called then. 
When a `trace` function is then added to std.net.curl, the code suddenly 
calls a different `trace`, without any warning. Hijacking.


Re: [dlang.org] new forum design - preview

2016-01-14 Thread anonymous via Digitalmars-d

On 14.01.2016 16:29, tn wrote:

I don't use my browser in full screen mode, but the useless white
margins are still there. With the horizontal-split mode the line length
of the message is less than 60 characters. Compared to that, I would be
happy with 80 or 90 you suggest.


This is an issue with the horizontal split mode, right? In the other 
modes you should get more than 80 characters on a line.


I agree that horizontal split looks quite cramped right now, unless you 
hide the navigation.



Besides, especially the margin that is on the left side of the
navigation bar looks ugly, like it was rendered improperly.


Would a border help? http://i.imgur.com/XoPddxr.png

Or how about making the whole area gray? http://i.imgur.com/AXrmKU4.png


Re: [dlang.org] getting the redesign wrapped up

2016-01-12 Thread anonymous via Digitalmars-d

On 12.01.2016 08:24, Vladimir Panteleev wrote:
> Nice. Is it responsive?

As responsive as the main site. I just updated the dlang.org submodule 
and fixed what got broken.


I'm mostly done now. Pull request is over here:
https://github.com/CyberShadow/DFeed/pull/51


Re: How to declare an alias to a function literal type

2016-01-12 Thread anonymous via Digitalmars-d-learn

On 12.01.2016 16:41, ParticlePeter wrote:

// alias MF = void function( int i );  // not working
// alias void function( int i ) MF;  // not working


These are both fine. The first one is the preferred style.



MF myFunc;
myFunc = MF { myCode };


This line doesn't work. Function literals don't take a type before the 
curly braces. They have their own syntax. See 
http://dlang.org/spec/expression.html (search for "Function Literals").


Since most of the stuff in function literals can be inferred from the 
context, something as simple as this works:

myFunc = (i) { myCode };


  1   2   3   4   5   6   7   8   9   >