Re: Algebraic template instance holder
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;
}
}
class Concrete:BaseTemplate!int{
this(int value){
super(value);
}
}
unittest{
Algebraic!(Concrete) holder;
Concrete a=new Concrete(4);
holder =Algebraic!Concrete(a);
}
This is a bug. I filled it as:
https://issues.dlang.org/show_bug.cgi?id=15670
I will see if I can fix it tomorrow.
Hi @ZombineDev have you by chance looked at this bug ?
Questions about vibe.d
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?".
Re: Questions about vibe.d
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/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/master/examples/sendmail Sorry if these questions are a bit basic, the implied subtext is "and does it work well?". Yes, also Sönke actively works one Vibe almost (if not) every single day, so it's also exceptionally well maintained.
Re: Questions about vibe.d
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
Re: Things that keep D from evolving?
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 something like "foo(traits::fast_param bar)" Hm... in is short for scope const. It is not pass by reference. Perhaps you meant auto ref? Right...maybe I've been operating under false pretenses, but I was under the impression that the compiler was allowed to interpret scope const as either "pass by value" or "pass by const reference" freely so long as there was no custom post-blit defined? For the purposes of optimization, I mean, to avoid needless copying.
Re: Questions about vibe.d
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 SPDY)... https://en.wikipedia.org/wiki/HTTP/2 Vibe.d doesn't though. There's a branch for it here: https://github.com/rejectedsoftware/vibe.d/tree/http2-botan-cleanup, but it still has a good bit of work.
Re: Things that keep D from evolving?
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. "foo(in bar)" is way more readable than something like "foo(traits::fast_param bar)" Hm... in is short for scope const. It is not pass by reference. Perhaps you meant auto ref? Right...maybe I've been operating under false pretenses, but I was under the impression that the compiler was allowed to interpret scope const as either "pass by value" or "pass by const reference" freely so long as there was no custom post-blit defined? For the purposes of optimization, I mean, to avoid needless copying. 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 being passed, 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
Re: Things that keep D from evolving?
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 const. It is not pass by reference. Perhaps you meant auto ref? * @property. This little feature has been invaluable in porting my C++ code, letting me shave off tons of accessors and mutators that existed only for the sake of possibly being needed in the future. I didn't even need to use @property for this; its simple existence did the work for me! Well, interestingly, D still allows property syntax without the @property notation. I'm in the habit now of never documenting accessors with @property. Mutators, I still would like to see D require @property to access that syntax. Note that the only good reason to defensively add accessors and mutators for public fields is to keep a consistent binary API. In other words, if have a shared library. D is not quite there yet for shared library support, however. -Steve
Re: Things that keep D from evolving?
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 call to call. It could potentially differ based on the type being passed, 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 note that 'in' and 'scope'(other than for delegates) parameter storage class usage should be avoided. It really should be a warning. Why is that?
Re: Things that keep D from evolving?
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!
Re: Things that keep D from evolving?
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 literally replaced with 'scope const' when it is a storage class. Yeah, I didn't mean 'in' definitely triggered it. I meant that 'in' (or rather, as you say, 'scope const') provides the conditions by which a compiler could make such an optimization, since it can know that the parameter will be unaffected by the function. It seems like that would mean it could, in theory, choose to pass small objects by value and large objects by reference under the hood, to avoid the large object copy (assuming no custom post-blit...and I guess it would have to check for taking the address?). To achieve that in C++ I use a special trait which deduces whether pass-by-value or pass-by-const-reference makes more sense for the type...but maybe I should be doing the same thing in D, if that optimization isn't actually present? It does seem like the compiler could probably perform that optimization even if 'in' (or 'scope const') wasn't used, if it was smart enough... This sort of micro-optimization generally doesn't matter at the application level unless one has actually profiled it. But it comes up a lot for me when writing generic libraries which can't know whether it will be used in a situation someday where those optimizations do actually matter.
Re: Things that keep D from evolving?
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 being passed, 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 note that 'in' and 'scope'(other than for delegates) parameter storage class usage should be avoided. It really should be a warning.
Re: Procedural drawing using ndslice
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.
Re: Things that keep D from evolving?
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 make use of such (type) information for optimizations — moreso probably LLVM due to all the functional languages that use it nowadays.
Re: Things that keep D from evolving?
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 treatment inside the function itself, so it can't differ from call to call. It could potentially differ based on the type being passed, 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 note that 'in' and 'scope'(other than for delegates) parameter storage class usage should be avoided. It really should be a warning. Why is that? Unless it has changed, 'scope' is a noop for everything but delegates. Code that works now will break when(if...) it gets implemented.
static array of structs clarification questions
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 string is 6 chars long
auto f2 = Foo(2, "ThisVeryVeryVeryLongStringHas36Chars");
foos[0] = f1;
foos[1] = f2;
writeln("f1 = ", foos[0]);
writeln("f2 = ", foos[1]);
writeln("array foos size in bytes is ", foos.arrayByteSize);
writeln("array foos has ", foos.length, " elements");
writeln("foos array consists of ", foos);
The output was
f1 = Foo(1, "6chars", null)
f2 = Foo(2, "ThisVeryVeryVeryLongStringHas36Chars", null)
array foos size in bytes is 32
array foos has 2 elements
foos array consists of [Foo(1, "6chars", null), Foo(2,
"ThisVeryVeryVeryLongStri
ngHas36Chars", null)]
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)
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?
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.
Thanks.
Re: static array of structs clarification questions
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;
auto f1 = Foo(1, "6chars"); // this string is 6 chars long
auto f2 = Foo(2, "ThisVeryVeryVeryLongStringHas36Chars");
foos[0] = f1;
foos[1] = f2;
writeln("f1 = ", foos[0]);
writeln("f2 = ", foos[1]);
writeln("array foos size in bytes is ", foos.arrayByteSize);
writeln("array foos has ", foos.length, " elements");
writeln("foos array consists of ", foos);
The output was
f1 = Foo(1, "6chars", null)
f2 = Foo(2, "ThisVeryVeryVeryLongStringHas36Chars", null)
array foos size in bytes is 32
array foos has 2 elements
foos array consists of [Foo(1, "6chars", null), Foo(2,
"ThisVeryVeryVeryLongStri
ngHas36Chars", null)]
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)
It's stored in the static data segment. Basically, directly in the
executable.
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?
The only way to compose a struct with itself is to use pointers. You
can't place a Foo inside a Foo, because it would be infinite in size
(the compiler will complain)
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.
That's odd. I think anonymous probably has the answer (they are context
pointers), but I'm also surprised they are null, they shouldn't be.
-Steve
How to force evaluation of range?
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;
import std.uni;
import std.range;
import std.conv;
import std.algorithm;
void main(string[] Args){
assert(Args.length>1,"Need a path to source files");
assert(Args[1].isValidPath,"Path given is not Valid!");
dirEntries(Args[1], SpanMode.depth)
.filter!(f => f.name.endsWith(".c",".h"))
.tee!(a => writeln("\n",a,"\n\t","=".repeat(80).join))
.map!(a => a
.File("r")
.byLine
.enumerate
.filter!( l => l.value.byGrapheme.walkLength > 80)
.tee!(a => writeln("Line: ",a.index,"\t",a.value))
).each!(a => a.each!("a")); //Force evaluation of every
item
}
Re: static array of structs clarification questions
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: Is this nogc? dmd and gdc disagree
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 being used in @nogc (barring ugly hacks). I don't want to discourage you before you try it, but I feel like @nogc is not yet worth using until something is done about issues such as exceptions, allowing Phobos to properly be able to handle @nogc. On the other hand... Realistically, the only way that Phobos will reach usability with @nogc, is if people keep trying and complaining when something doesn't work that should. I guess the problem is that a lot of this stuff requires RC exceptions to be realistically fixable. (Not this case though.)
Re: Questions about vibe.d
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/master/examples/sendmail Sorry if these questions are a bit basic, the implied subtext is "and does it work well?". Yes, also Sönke actively works one Vibe almost (if not) every single day, so it's also exceptionally well maintained. Thanks for your feedback.
Re: How to force evaluation of range?
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 => a.each!("a"));?
...
The following combination might work:
.joiner.each;
http://dlang.org/phobos/std_algorithm_iteration.html#.joiner
http://dlang.org/phobos/std_algorithm_iteration.html#.each
Re: Is this nogc? dmd and gdc disagree
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 @nogc. Here's a
semi-reduced test-case:
Here's an @nogc version of `byKeyValue()`:
@nogc auto byKeyValue() const {
static immutable keys = [EnumMembers!K];
return zip(keys[], _store[]);
}
Using zip and slices guarantees that the structure returned
will be only 5*size_t.sizeof bytes, regardless of the types of
K and V.
I'm on the DMD 2.070 release, so maybe its fixed in master.
Either way, thanks for the suggestion!
Somehow I didn't realize what I was doing was an
over-complicated zip :)
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 being used in
@nogc (barring ugly hacks). I don't want to discourage you before
you try it, but I feel like @nogc is not yet worth using until
something is done about issues such as exceptions, allowing
Phobos to properly be able to handle @nogc.
Re: How to force evaluation of range?
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 => a.each!("a"));?
[...]
dirEntries(Args[1], SpanMode.depth)
.filter!(f => f.name.endsWith(".c",".h"))
.tee!(a => writeln("\n",a,"\n\t","=".repeat(80).join))
.map!(a => a
.File("r")
.byLine
.enumerate
.filter!( l => l.value.byGrapheme.walkLength > 80)
.tee!(a => writeln("Line: ",a.index,"\t",a.value))
).each!(a => a.each!("a")); //Force evaluation of
every item
}
Have you tried .array? I *think* it's the commonly used way to
flatten a lazy range.
Re: How to force evaluation of range?
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 => a.each!("a"));?
[...]
If you need the value that a range returns (i.e. the range
performs "computation") then use .array
If you just want the range evaluated use walkLength
Re: How to force evaluation of range?
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 that range.
Re: How to force evaluation of range?
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. Is there a better thing to put
in the place of
.each!(a => a.each!("a"));?
...
The following combination might work:
.joiner.each;
http://dlang.org/phobos/std_algorithm_iteration.html#.joiner
http://dlang.org/phobos/std_algorithm_iteration.html#.each
Why not just .each; ?
Re: How to force evaluation of range?
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 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"));?
...
The following combination might work:
.joiner.each;
http://dlang.org/phobos/std_algorithm_iteration.html#.joiner
http://dlang.org/phobos/std_algorithm_iteration.html#.each
Why not just .each; ?
The thing he's trying to iterate over is a range of ranges. A
single .each will only iterate over the outermost range so you
need .joiner first to "flatten" the range, then you can use .each
on that result.
