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;
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 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:
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 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
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
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 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 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
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
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 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
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
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
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]
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
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
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
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:
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 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
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 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
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
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
28 matches
Mail list logo
