On Saturday, 13 February 2016 at 03:16:09 UTC, cym13 wrote:
On Saturday, 13 February 2016 at 02:17:17 UTC, Xinok wrote:
On Friday, 12 February 2016 at 20:43:24 UTC, Taylor Hillegeist
wrote:
So I have this code and I have to add the element
.each!(a => a.each!("a"));
to the end in order for it t
On Saturday, 13 February 2016 at 02:17:17 UTC, Xinok wrote:
On Friday, 12 February 2016 at 20:43:24 UTC, Taylor Hillegeist
wrote:
So I have this code and I have to add the element
.each!(a => a.each!("a"));
to the end in order for it to evaluate the range completely
and act like I expect it too
On Friday, 12 February 2016 at 20:43:24 UTC, Taylor Hillegeist
wrote:
So I have this code and I have to add the element
.each!(a => a.each!("a"));
to the end in order for it to evaluate the range completely and
act like I expect it too. Is there a better thing to put in
the place of
.each!(a
On Saturday, 13 February 2016 at 01:11:53 UTC, Nicholas Wilson
wrote:
...
If you just want the range evaluated use walkLength
It might work in this case, but in general this won't work for
any range which defines .length as a member. In that case,
walkLength will simply return .length of tha
On Friday, 12 February 2016 at 20:43:24 UTC, Taylor Hillegeist
wrote:
So I have this code and I have to add the element
.each!(a => a.each!("a"));
to the end in order for it to evaluate the range completely and
act like I expect it too. Is there a better thing to put in
the place of
.each!(a
On Friday, 12 February 2016 at 20:43:24 UTC, Taylor Hillegeist
wrote:
So I have this code and I have to add the element
.each!(a => a.each!("a"));
to the end in order for it to evaluate the range completely and
act like I expect it too. Is there a better thing to put in
the place of
.each!(a
On Friday, 12 February 2016 at 13:00:30 UTC, Charles wrote:
1. Yes. Example:
https://github.com/rejectedsoftware/vibe.d/tree/master/examples/https_server
2. I'd do this with nginx. Example:
http://serverfault.com/a/337893
3. Yes.
4. Yes. Example:
https://github.com/rejectedsoftware/vibe.d/tree
On Friday, 12 February 2016 at 23:46:09 UTC, Kapps wrote:
You'll encounter this pretty often in Phobos I think. I really
don't think @nogc is ready, and tend to avoid it in my code.
Exceptions are a big reason for it, and lots of functions in
Phobos throw exceptions which prevents them from bei
On Thursday, 11 February 2016 at 12:41:16 UTC, rcorre wrote:
On Thursday, 11 February 2016 at 04:20:13 UTC, tsbockman wrote:
On Thursday, 11 February 2016 at 03:09:51 UTC, rcorre wrote:
I recently tried compiling enumap with GDC, and found that it
disagrees with DMD on whether a function is @no
On 2/12/16 4:08 PM, WhatMeWorry wrote:
I was thinking about fixed length arrays of structures the other day so
I played around with the flowing code:
struct Foo
{
inti;
string str;
void info() { writeln("i = ", i, "str = ", str); }
}
Foo[2] foos
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
I was thinking about fixed length arrays of structures the other
day so I played around with the flowing code:
struct Foo
{
inti;
string str;
void info() { writeln("i = ", i, "str = ", str); }
}
Foo[2] foos;
auto f1 = Foo(1, "6chars"); // this st
So I have this code and I have to add the element
.each!(a => a.each!("a"));
to the end in order for it to evaluate the range completely and
act like I expect it too. Is there a better thing to put in the
place of
.each!(a => a.each!("a"));?
import std.stdio;
import std.path;
import std.file;
On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer
wrote:
but I'm unaware of such an optimization, and it definitely
isn't triggered specifically by 'in'. 'in' is literally
replaced with 'scope const' when it is a storage class.
-Steve
I'd imagine GCC or LLVM may be able to ma
On Friday, 12 February 2016 at 17:29:54 UTC, Matt Elkins wrote:
On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote:
On Friday, 12 February 2016 at 15:12:19 UTC, Steven
Schveighoffer wrote:
On 2/12/16 9:37 AM, Matt Elkins wrote:
[...]
Pass by reference and pass by value means different
On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote:
On Friday, 12 February 2016 at 15:12:19 UTC, Steven
Schveighoffer wrote:
On 2/12/16 9:37 AM, Matt Elkins wrote:
[...]
Pass by reference and pass by value means different treatment
inside the function itself, so it can't differ from ca
On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote:
note that 'in' and 'scope'(other than for delegates) parameter
storage class usage should be avoided.
It really should be a warning.
Add to docs!
On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer
wrote:
It could potentially differ based on the type being passed,
Yes, that's what I meant.
but I'm unaware of such an optimization,
Hm. Unfortunate.
and it definitely isn't triggered specifically by 'in'. 'in' is
literall
On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer
wrote:
On 2/12/16 9:37 AM, Matt Elkins wrote:
[...]
Pass by reference and pass by value means different treatment
inside the function itself, so it can't differ from call to
call. It could potentially differ based on the type
Thanks for your replies, John and Ali. I wasn't sure I was clear.
I'm going to try to see if I can fit Ali concept (totally lazy,
which is what I was looking for) within ndslices, so that I can
also use it in 3D and apply window() function to the result and
mess around with it.
On 2/12/16 9:37 AM, Matt Elkins wrote:
On Friday, 12 February 2016 at 14:03:05 UTC, Steven Schveighoffer wrote:
On 2/10/16 11:51 PM, Matt Elkins wrote:
* The in keyword. This is nice syntactic sugar over having a special
trait in C++ which deduces whether to pass by value or const-reference.
"
On Friday, 12 February 2016 at 14:36:18 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 12 February 2016 at 12:31:57 UTC, Guillaume Piolat
wrote:
Sorry if these questions are a bit basic, the implied subtext
is "and does it work well?".
Just in case you didn't know, browsers now support HTTP/2 (and
On Friday, 12 February 2016 at 14:03:05 UTC, Steven Schveighoffer
wrote:
On 2/10/16 11:51 PM, Matt Elkins wrote:
* The in keyword. This is nice syntactic sugar over having a
special
trait in C++ which deduces whether to pass by value or
const-reference.
"foo(in bar)" is way more readable than
On Friday, 12 February 2016 at 12:31:57 UTC, Guillaume Piolat
wrote:
Sorry if these questions are a bit basic, the implied subtext
is "and does it work well?".
Just in case you didn't know, browsers now support HTTP/2 (and
SPDY)...
https://en.wikipedia.org/wiki/HTTP/2
On 2/10/16 11:51 PM, Matt Elkins wrote:
* The in keyword. This is nice syntactic sugar over having a special
trait in C++ which deduces whether to pass by value or const-reference.
"foo(in bar)" is way more readable than something like
"foo(traits::fast_param bar)"
Hm... in is short for scope
On Friday, 12 February 2016 at 12:31:57 UTC, Guillaume Piolat
wrote:
1. Can vibe.d handle HTTPS connections?
2. Can vibe.d "rewrite" HTTP connections to HTTPS?
3. Can vibe.d be put behind a nginx reverse proxy?
4. Can vibe.d send mails?
1. Yes. Example:
https://github.com/rejectedsoftware
1. Can vibe.d handle HTTPS connections?
2. Can vibe.d "rewrite" HTTP connections to HTTPS?
3. Can vibe.d be put behind a nginx reverse proxy?
4. Can vibe.d send mails?
Sorry if these questions are a bit basic, the implied subtext is
"and does it work well?".
On Wednesday, 10 February 2016 at 20:53:15 UTC, ZombineDev wrote:
On Wednesday, 10 February 2016 at 10:31:34 UTC, Voitech wrote:
Hi, why this is not working ?
class Base{
int a;
}
class BaseTemplate(E):Base{
E value;
this(E value){
this.value=value;
28 matches
Mail list logo