Re: Can vibe d leverage existing web technologies?
On Tuesday, 13 September 2016 at 23:45:18 UTC, Intersteller wrote: vibe.d does not have much lateral support as the most commons web technologies do. Can vibe.d leverage pre-existing techs such as php, ruby/rails, etc? Starting from scratch and having to build a robust and secure framework is really not the way to go. Sure. Just use res.write(executeShell(["php", "-f", "somephpscript.php"]).output); or something like that. But seriously, you probably don't want to do that. It's like asking if ruby on rails can leverage php. Sure, they can communicate over HTTP or whatever else they support but trying to execute PHP from within Rails or vice versa just isn't really all that beneficial.
zip: why isn't requireSameLength the default?
in zip: why isn't requireSameLength the default? This is the most common case and would fit with the goal of being safe by default.
Can vibe d leverage existing web technologies?
vibe.d does not have much lateral support as the most commons web technologies do. Can vibe.d leverage pre-existing techs such as php, ruby/rails, etc? Starting from scratch and having to build a robust and secure framework is really not the way to go.
Re: Copy a struct and its context
On 9/13/16 5:01 PM, Yuxuan Shui wrote:
For example, a common use case might be I want to capture everything by
value. In stead of adding all the fields by hand and passing them to the
constructor, I want the compiler to do it for me.
i.e. I wish I could (borrowing C++ syntax):
struct A[=] {
...
}
Then the context will be captured by value instead of reference.
This is a valid enhancement. Why not try and ask for it?
I don't know if the specific syntax would work for D, but the feature
seems useful in some respects.
-Steve
Re: Copy a struct and its context
On Tuesday, 13 September 2016 at 20:36:22 UTC, Steven
Schveighoffer wrote:
On 9/13/16 4:11 PM, Yuxuan Shui wrote:
On Tuesday, 13 September 2016 at 20:00:40 UTC, Steven
Schveighoffer wrote:
Not familiar with C++ lambda. You can always "specify" how to
capture
the data by directly declaring it:
auto foo()
{
int x;
static struct S
{
int x;
}
return S(x);
}
It just feels a bit tedious to do something manually while the
compiler
have enough information to do it for me.
Do what for you? How does it know that you don't want to use a
closure and a reference to that instead?
Note that all the internals for this are implementation
defined. Given sufficient conditions, the compiler could
"cheat" and allocate the data inside the struct itself instead.
For example, if all referenced data was immutable.
-Steve
For example, a common use case might be I want to capture
everything by value. In stead of adding all the fields by hand
and passing them to the constructor, I want the compiler to do it
for me.
i.e. I wish I could (borrowing C++ syntax):
struct A[=] {
...
}
Then the context will be captured by value instead of reference.
Re: pure functions
On Tuesday, September 13, 2016 20:08:22 Patrick Schluter via Digitalmars-d-
learn wrote:
> On Tuesday, 13 September 2016 at 06:59:10 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, September 13, 2016 03:33:04 Ivy Encarnacion via
> >
> > Digitalmars-d- learn wrote:
> > A pure function cannot call any function that is not pure [...]
>
> I've read that a lot but it's not true. A pure function can call
> impure function. The restriction is, that the impure function
> called within the pure function does not depend or mutate on
> state existing outside of that function. If the called function
> changes local variable, it has no bearing on outside the scope.
> Here a contrived example in C.
>
> size_t strlen(const char *str); is pure. If I define it this way
> for example:
>
> size_t my_strlen(const char *str)
> {
>char temp[50];
>
>strlcpy(temp, str, sizeof temp); /* strlcpy is not pure as it
> mutates something outside of its "scope" */
>
>return strlen(str);
> }
>
> That function is pure. There is no visible change outside of it.
>
> my_strlen and strlen have exactly the same properties.
That's because you're talking about functional purity and _not_ D's pure. If
you want to talk about D's pure, you pretty much need to forget about
functional purity. While D's pure allows you to get functional purity, it's
actually something different. It would be far more accurate at this point if
it were called something like @noglobal. Actual, functional purity really
only comes into play when a pure function's parameters are immutable or
implicitly convertible to immutable, at which point the compiler can
guarantee that the same arguments to the function will result in the
function returning the same result. Sometimes, pure functions whose
parameters are immutable or implicitly convertible to immutable are referred
to as strongly pure functions, whereas those whose parameters aren't are
called weakly pure. So-called strongly pure functions are what you need if
you want to talk about functional purity, whereas so-called weakly pure
functions are still pure as far as D is concerned, because they don't
violate the functional purity of a strongly pure function if they're called
by it.
Originally, for a function to be pure in D, it _had_ to have parameters
which were immutable or implicitly convertible to immutable, which actually
was functionally pure, but it was too restrictive to be useful, so pure was
expanded to what it is now, which makes it so that it's not really about
functional purity anymore even though it enables functional purity in a way
that the compiler can detect it and optimize for it.
But when a D programmer talks about a function that's imppure, they're
generally not talking about functional purity but about whether it's marked
with pure or inferred as pure by the compiler, and per that definition, the
code that you have above _is_ pure. In a way, what you're trying to prove
about impure in D is both right and wrong, because we're dealing with
conflicting definitions of purity here. When discussing pure in D, if you
want to talk about whether a function is functionally pure in the sense that
one would normally talk about pure functions outside of D, then you need to
clearly state that you're talking about functional purity and not about D's
pure. When simply saying that something is pure or not, folks here are going
to expect you to be talking about D's definition of purity.
By the way, the only ways to get around pure are:
1. use debug blocks (where pure is ignored in order to facilite debugging).
2. use an extern(*) other than extern(D) so that the body of the function
doesn't have to be marked pure like the prototype does (since other types
of linkage don't actually use pure), allowing you to lie to the compiler.
3. use function pointers and cast an impure function pointer to a pure one
and thereby lie to the compiler.
So, there are a couple of ways to fool the compiler, but there's only one
wayt that's sanctioned by it, and it's only intended for debugging purposes.
- Jonathan M Davis
Re: Copy a struct and its context
On 9/13/16 4:11 PM, Yuxuan Shui wrote:
On Tuesday, 13 September 2016 at 20:00:40 UTC, Steven Schveighoffer wrote:
Not familiar with C++ lambda. You can always "specify" how to capture
the data by directly declaring it:
auto foo()
{
int x;
static struct S
{
int x;
}
return S(x);
}
It just feels a bit tedious to do something manually while the compiler
have enough information to do it for me.
Do what for you? How does it know that you don't want to use a closure
and a reference to that instead?
Note that all the internals for this are implementation defined. Given
sufficient conditions, the compiler could "cheat" and allocate the data
inside the struct itself instead. For example, if all referenced data
was immutable.
-Steve
Re: pure functions
On 9/13/16 4:08 PM, Patrick Schluter wrote: On Tuesday, 13 September 2016 at 06:59:10 UTC, Jonathan M Davis wrote: On Tuesday, September 13, 2016 03:33:04 Ivy Encarnacion via Digitalmars-d- learn wrote: A pure function cannot call any function that is not pure [...] I've read that a lot but it's not true. A pure function can call impure function. The restriction is, that the impure function called within the pure function does not depend or mutate on state existing outside of that function. If the called function changes local variable, it has no bearing on outside the scope. D defines pure differently. You are allowed to declare a function is pure if it takes (and possibly changes) mutable references. It can be called by pure functions, but will not be optimized in the same way one would expect traditional pure functions to be optimized. We call it "weak-pure". In D, an "impure" function is defined exactly as one that accesses mutable global state. Everything else can be declared pure. The one exception is memory allocation. -Steve
Re: Discarding all forum drafts at once
On Tuesday, 13 September 2016 at 18:15:56 UTC, Nordlöw wrote: I have lots of unsent drafts I would like to discard all at once. Is this possible somehow? Delete the cookies.
Re: Copy a struct and its context
On Tuesday, 13 September 2016 at 20:00:40 UTC, Steven
Schveighoffer wrote:
On 9/13/16 3:42 PM, Yuxuan Shui wrote:
[...]
There's nothing in the language to prevent this optimization.
[...]
Again, could be clearer. But the fact that both the function
and the struct affect the same data kind of dictates it needs
to be a reference.
[...]
Not familiar with C++ lambda. You can always "specify" how to
capture the data by directly declaring it:
auto foo()
{
int x;
static struct S
{
int x;
}
return S(x);
}
It just feels a bit tedious to do something manually while the
compiler have enough information to do it for me.
In D, if you have a closure, it's going to be heap allocated.
Just the way it is. If you don't want that, you have to avoid
them.
-Steve
Re: pure functions
On Tuesday, 13 September 2016 at 06:59:10 UTC, Jonathan M Davis
wrote:
On Tuesday, September 13, 2016 03:33:04 Ivy Encarnacion via
Digitalmars-d- learn wrote:
A pure function cannot call any function that is not pure [...]
I've read that a lot but it's not true. A pure function can call
impure function. The restriction is, that the impure function
called within the pure function does not depend or mutate on
state existing outside of that function. If the called function
changes local variable, it has no bearing on outside the scope.
Here a contrived example in C.
size_t strlen(const char *str); is pure. If I define it this way
for example:
size_t my_strlen(const char *str)
{
char temp[50];
strlcpy(temp, str, sizeof temp); /* strlcpy is not pure as it
mutates something outside of its "scope" */
return strlen(str);
}
That function is pure. There is no visible change outside of it.
my_strlen and strlen have exactly the same properties.
Re: Copy a struct and its context
On Tuesday, 13 September 2016 at 01:32:19 UTC, Steven Schveighoffer wrote: On 9/12/16 4:11 PM, Ali Çehreli wrote: On 09/10/2016 10:44 PM, Yuxuan Shui wrote: I recently noticed nested struct capture its context by reference (which, BTW, is not mentioned at all here: https://dlang.org/spec/struct.html#nested). He wants to deep-copy the struct, meaning copy the context pointer data. Meaning if you change 'i' in s, then s_copy's foo still returns 42. I don't think it is or should be doable. -Steve with stack stomp no way that any hack could work, if any.
Re: Copy a struct and its context
On 9/13/16 3:42 PM, Yuxuan Shui wrote:
On Tuesday, 13 September 2016 at 01:32:19 UTC, Steven Schveighoffer wrote:
On 9/12/16 4:11 PM, Ali Çehreli wrote:
On 09/10/2016 10:44 PM, Yuxuan Shui wrote:
I recently noticed nested struct capture its context by reference
(which, BTW, is not mentioned at all here:
https://dlang.org/spec/struct.html#nested).
" It has access to the context of its enclosing scope (via an added
hidden field)."
It needs to be a reference. Otherwise, you store the entire stack
frame in the struct? That wouldn't be a "field". It also has write
access to the context:
Why not just capture the variables that are actually been referenced?
There's nothing in the language to prevent this optimization.
Also being a field doesn't put limits on the size of the "field".
Again, could be clearer. But the fact that both the function and the
struct affect the same data kind of dictates it needs to be a reference.
I like how C++ lambda lets you choose what variables to capture, and how
are they captured. I'm little disappointed that D doesn't let me do the
same.
Not familiar with C++ lambda. You can always "specify" how to capture
the data by directly declaring it:
auto foo()
{
int x;
static struct S
{
int x;
}
return S(x);
}
In D, if you have a closure, it's going to be heap allocated. Just the
way it is. If you don't want that, you have to avoid them.
-Steve
Re: Copy a struct and its context
On Tuesday, 13 September 2016 at 01:32:19 UTC, Steven Schveighoffer wrote: On 9/12/16 4:11 PM, Ali Çehreli wrote: On 09/10/2016 10:44 PM, Yuxuan Shui wrote: I recently noticed nested struct capture its context by reference (which, BTW, is not mentioned at all here: https://dlang.org/spec/struct.html#nested). " It has access to the context of its enclosing scope (via an added hidden field)." It needs to be a reference. Otherwise, you store the entire stack frame in the struct? That wouldn't be a "field". It also has write access to the context: Why not just capture the variables that are actually been referenced? Also being a field doesn't put limits on the size of the "field". I like how C++ lambda lets you choose what variables to capture, and how are they captured. I'm little disappointed that D doesn't let me do the same.
Discarding all forum drafts at once
I have lots of unsent drafts I would like to discard all at once. Is this possible somehow?
Re: How to check member function for being @disable?
On Tuesday, September 13, 2016 17:59:09 Adam D. Ruppe via Digitalmars-d-learn wrote: > On Tuesday, 13 September 2016 at 17:52:48 UTC, Jonathan M Davis > > wrote: > > It's really intended for disabling features that would normally > > be there. I don't know why it would ever make sense to @disable > > a normal function. > > Consider the case of `alias this` or a mixin template. You might > make a wrapper type that disables a particular operation by > writing `@disable void opBinary(op)` so it won't forward to the > underlying thing. Ah. That makes sense. Thanks for pointing out that use case. And actually, I think that that use case further supports the idea that what code should be testing for is whether an operation works and not whether it's @disabled. In the general case, you don't even have any guarantee that the type being aliased has an operation that would need to be @disabled. And from the caller's perspective, it shouldn't matter whether the + operator doesn't work because it wasn't declared or because it was @disabled. - Jonathan M Davis
Re: How to check member function for being @disable?
On Tuesday, 13 September 2016 at 17:52:48 UTC, Jonathan M Davis wrote: It's really intended for disabling features that would normally be there. I don't know why it would ever make sense to @disable a normal function. Consider the case of `alias this` or a mixin template. You might make a wrapper type that disables a particular operation by writing `@disable void opBinary(op)` so it won't forward to the underlying thing.
Re: How to check member function for being @disable?
On Tuesday, September 13, 2016 17:29:26 Uranuz via Digitalmars-d-learn wrote: > OK. Seems that there is nothing that I could do more about my > example code.. So the best way to be sure if something is > assignable property is to try assign to it and test whether it > compiles. The question was because utill this moment I somehow > was living without __traits(compiles..). Seems that my use cases > just was not enough complicated... Thanks for the answers. > > It could be good idea to have __traits( isDisable ... ) or > something for it. I admit that not only '@disabled this();' > regular methods could me marked @disable too.. The main places that I can think of at the moment where @disable makes sense is for disabling default initialization - @disable this(); - and disabling copying - @disable this(this);. It's really intended for disabling features that would normally be there. I don't know why it would ever make sense to @disable a normal function. Why would it even exist if it were @disabled? So, for the compiler to allow @disable on normal functions sounds like a bug to me - or at least an oversight in the design and implementation of @disable - but maybe there's a legitimate reason that I'm not thinking of at the moment. Regardless, testing for it is as simple as testing whether it can be called or not, and you have to worry about that in a number of cases anyway, because the access level of the function may be such that you can't call it (e.g. it's private, and the code in question is not in the module trying to call it). So, I don't really see what testing for @disable specifically would buy you. - Jonathan M Davis
Re: How to check member function for being @disable?
On Tuesday, 13 September 2016 at 15:32:57 UTC, Jonathan M Davis wrote: On Tuesday, September 13, 2016 08:28:10 Jonathan M Davis via Digitalmars-d- learn wrote: On Tuesday, September 13, 2016 04:58:38 Uranuz via Digitalmars-d-learn wrote: > In my code I iterate in CT over class methods marked as > @property and I have a probleme that one of methods is > @disable. So I just want to skip @disable members. I found > possible solution, but it's interesting to we if we have > more clear and obvious way to test for @disable without > using __traits( compile ) for it? @disable "looks" like > attribute but seems that I cant't get it through __traits( > getAttributes ) or __traits( getFunctionAttributes ). Maybe > we could add something to test for @disable if it's not > already exists? I really don't think that it's going to scale properly to check whether something is marked with @disable. The problem is that it propagates. For instance, if a struct has a member variable that has default initialization disabled via @disable this(); then that struct effectively has @disable this(); too even though it doesn't have it explicitly. So, ultimately what needs to be tested for is the behavior and not the presence of @disable, and that means testing with __traits(compiles, ...). And I would point out that most traits test via __traits(compiles, ...) or is(typeof(...)) rather than checking for something like an attribute. So, if don't like using __traits(compiles, ...) in metaprogramming, your going to get frustrated quickly. A large portion of the time, it's exactly the solution to the problem. What would make sense would be creating a trait to test for the @disabled functionality in queston - e.g. there could be an eponymous template named something like hasDefaultInitializer (though that name is a bit long) which indicated whether a type had @disabled this(); or not. Then you can use that trait in your code rather than using __traits(compiles, ...) all over the place. - Jonthan M Davis OK. Seems that there is nothing that I could do more about my example code.. So the best way to be sure if something is assignable property is to try assign to it and test whether it compiles. The question was because utill this moment I somehow was living without __traits(compiles..). Seems that my use cases just was not enough complicated... Thanks for the answers. It could be good idea to have __traits( isDisable ... ) or something for it. I admit that not only '@disabled this();' regular methods could me marked @disable too..
Re: Confusion over what types have value vs reference semantics
On Tuesday, September 13, 2016 15:27:07 Neurone via Digitalmars-d-learn wrote:
> On Sunday, 11 September 2016 at 16:14:59 UTC, Mike Parker wrote:
> > On Sunday, 11 September 2016 at 16:10:04 UTC, Mike Parker wrote:
> >> And here, no memory is allocated. barSlice.ptr is the same as
> >> bar.ptr and barSlice.length is the same as bar.length.
> >> However, if you append a new element:
> >>
> >> barSlice ~= 10;
> >>
> >> The GC will allocate memory for a new array and barSlice will
> >> no longer point to bar. It will now have four elements.
> >
> > I should clarify that this holds true for all slices, not just
> > slices of static arrays. The key point is that appending to a
> > slice will only allocate if the the .capacity property of the
> > slice is 0. Slices of static arrays will always have a capacity
> > of 0. Slices of slices might not, i.e. there may be room in the
> > memory block for more elements.
>
> Thanks for the detailed answer. I still don't get the advantage
> of passing slices into functions by value allowing modification
> to elements of the original array. Is there an way to specify
> that a true independent copy of an array should be passed into
> the function? E.g, in c++ func(Vector v) causes a copy of
> the argument to be passed in.
Slices are a huge performance boost (e.g. the fact that we have slicing like
this for strings makes parsing code _way_ more efficient by default than
would ever be the case for something like std::string). If you're worried
about a function mutating the elements of an array that it's given, then you
can always mark them with const. e.g.
auto foo(const(int)[] arr) {...}
But there is no way to force a naked dynamic array to do a deeper copy when
passed. If you're worried about it, you can explicitly call dup to create a
copy of the array rather than slice it - e.g. foo(arr.dup) - but the
function itself can't enforce that behavior. The closest that it could do
would be to explicitly dup the parameter itself - though if you were going
to do that, you'd want to make it clear in the documentation, since that's
not a typical thing to do, and if someone wanted to ensure that an array
that they were passing to the function didn't get mutated, they'd dup it
themselves, which would result in two dups if your function did the dup.
If you want a dynamic array to be duped every time it's passed to a function
or otherwise copied, you'd need to create a wrapper struct with a postblit
constructor that called dup. That would generally make for unnecessarily
inefficient code though. The few containers in std.container are all
reference types for the same reason - containers which copy by default make
it way too easy to accidentally copy them and are arguably a bad default
(though obviously, there are cases where that would be the best behavior).
So, the typical thing to do with dynamic arrays is to use const or immutable
elements when you want to ensure that they don't get mutated when passing
them around and duping or iduping a dynamic array when you want to ensure
that you have a copy of the array rather than a slice.
- Jonathan M Davis
Re: How to check member function for being @disable?
On Tuesday, September 13, 2016 08:28:10 Jonathan M Davis via Digitalmars-d- learn wrote: > On Tuesday, September 13, 2016 04:58:38 Uranuz via Digitalmars-d-learn wrote: > > In my code I iterate in CT over class methods marked as @property > > and I have a probleme that one of methods is @disable. So I just > > want to skip @disable members. I found possible solution, but > > it's interesting to we if we have more clear and obvious way to > > test for @disable without using __traits( compile ) for it? > > @disable "looks" like attribute but seems that I cant't get it > > through __traits( getAttributes ) or __traits( > > getFunctionAttributes ). Maybe we could add something to test for > > @disable if it's not already exists? > > I really don't think that it's going to scale properly to check whether > something is marked with @disable. The problem is that it propagates. For > instance, if a struct has a member variable that has default initialization > disabled via @disable this(); then that struct effectively has @disable > this(); too even though it doesn't have it explicitly. So, ultimately what > needs to be tested for is the behavior and not the presence of @disable, and > that means testing with __traits(compiles, ...). And I would point out that > most traits test via __traits(compiles, ...) or is(typeof(...)) rather than > checking for something like an attribute. So, if don't like using > __traits(compiles, ...) in metaprogramming, your going to get frustrated > quickly. A large portion of the time, it's exactly the solution to the > problem. What would make sense would be creating a trait to test for the @disabled functionality in queston - e.g. there could be an eponymous template named something like hasDefaultInitializer (though that name is a bit long) which indicated whether a type had @disabled this(); or not. Then you can use that trait in your code rather than using __traits(compiles, ...) all over the place. - Jonthan M Davis
Re: Confusion over what types have value vs reference semantics
On Sunday, 11 September 2016 at 16:14:59 UTC, Mike Parker wrote: On Sunday, 11 September 2016 at 16:10:04 UTC, Mike Parker wrote: And here, no memory is allocated. barSlice.ptr is the same as bar.ptr and barSlice.length is the same as bar.length. However, if you append a new element: barSlice ~= 10; The GC will allocate memory for a new array and barSlice will no longer point to bar. It will now have four elements. I should clarify that this holds true for all slices, not just slices of static arrays. The key point is that appending to a slice will only allocate if the the .capacity property of the slice is 0. Slices of static arrays will always have a capacity of 0. Slices of slices might not, i.e. there may be room in the memory block for more elements. Thanks for the detailed answer. I still don't get the advantage of passing slices into functions by value allowing modification to elements of the original array. Is there an way to specify that a true independent copy of an array should be passed into the function? E.g, in c++ func(Vector v) causes a copy of the argument to be passed in.
Re: How to check member function for being @disable?
On Tuesday, September 13, 2016 04:58:38 Uranuz via Digitalmars-d-learn wrote: > In my code I iterate in CT over class methods marked as @property > and I have a probleme that one of methods is @disable. So I just > want to skip @disable members. I found possible solution, but > it's interesting to we if we have more clear and obvious way to > test for @disable without using __traits( compile ) for it? > @disable "looks" like attribute but seems that I cant't get it > through __traits( getAttributes ) or __traits( > getFunctionAttributes ). Maybe we could add something to test for > @disable if it's not already exists? I really don't think that it's going to scale properly to check whether something is marked with @disable. The problem is that it propagates. For instance, if a struct has a member variable that has default initialization disabled via @disable this(); then that struct effectively has @disable this(); too even though it doesn't have it explicitly. So, ultimately what needs to be tested for is the behavior and not the presence of @disable, and that means testing with __traits(compiles, ...). And I would point out that most traits test via __traits(compiles, ...) or is(typeof(...)) rather than checking for something like an attribute. So, if don't like using __traits(compiles, ...) in metaprogramming, your going to get frustrated quickly. A large portion of the time, it's exactly the solution to the problem. - Jonathan M Davis
Re: Fiber Concurrency Showcase
On Tuesday, 13 September 2016 at 10:02:28 UTC, Andrea Fontana wrote: Check this: http://ddili.org/ders/d.en/fibers.html Further, are we forced to use the GC for Fiber allocation or can a sub-class of Fiber implement its own allocation strategy?
Re: Fiber Concurrency Showcase
On Tuesday, 13 September 2016 at 10:02:28 UTC, Andrea Fontana wrote: Check this: http://ddili.org/ders/d.en/fibers.html Thanks! I would like to make use of message passing between Fibers aswell. Any code example for this? Specifically: Should the call to `new Fiber()` take all the TId's of its communication neighbourds be passed as argument to the `Fiber` constructor?
Re: Fiber Concurrency Showcase
On Tuesday, 13 September 2016 at 10:02:28 UTC, Andrea Fontana wrote: On Tuesday, 13 September 2016 at 09:46:46 UTC, Nordlöw wrote: I would like to experiment with Fibers/Coroutines in D/vibe.d. I'm missing a code example in std.concurrency that highlights an example of using Fibers for massive concurrency. Could anybody show me such a code example or link to a more descriptive tutorial? Check this: http://ddili.org/ders/d.en/fibers.html Andrea Ha! Should have refreshed the page before replying :-P
Re: Fiber Concurrency Showcase
On Tuesday, 13 September 2016 at 09:46:46 UTC, Nordlöw wrote: I would like to experiment with Fibers/Coroutines in D/vibe.d. I'm missing a code example in std.concurrency that highlights an example of using Fibers for massive concurrency. Could anybody show me such a code example or link to a more descriptive tutorial? Ali has an asynchronous I/O example in the Fibers chapter of his book: http://ddili.org/ders/d.en/fibers.html
Re: Fiber Concurrency Showcase
On Tuesday, 13 September 2016 at 09:46:46 UTC, Nordlöw wrote: I would like to experiment with Fibers/Coroutines in D/vibe.d. I'm missing a code example in std.concurrency that highlights an example of using Fibers for massive concurrency. Could anybody show me such a code example or link to a more descriptive tutorial? Check this: http://ddili.org/ders/d.en/fibers.html Andrea
Fiber Concurrency Showcase
I would like to experiment with Fibers/Coroutines in D/vibe.d. I'm missing a code example in std.concurrency that highlights an example of using Fibers for massive concurrency. Could anybody show me such a code example or link to a more descriptive tutorial?
Re: Binary heap: obtain a _reference_ to the front of the heap
On Tuesday, 13 September 2016 at 08:19:04 UTC, Johan Engelen
wrote:
In the binary heap documentation, I read that
`BinaryHeap.front()` "Returns a copy of the front of the heap".
[1]
Is there no function to access the front of the heap without a
copy? (micro-optimization)
Thanks,
Johan
[1]
https://dlang.org/phobos/std_container_binaryheap.html#.BinaryHeap.front
What does
foreach(ref e; bh)
{
//...
}
do?
Binary heap: obtain a _reference_ to the front of the heap
In the binary heap documentation, I read that `BinaryHeap.front()` "Returns a copy of the front of the heap". [1] Is there no function to access the front of the heap without a copy? (micro-optimization) Thanks, Johan [1] https://dlang.org/phobos/std_container_binaryheap.html#.BinaryHeap.front
Re: pure functions
On Tuesday, September 13, 2016 03:33:04 Ivy Encarnacion via Digitalmars-d- learn wrote: > Can pure functions throw exceptions on its arguments? Also, how > can it perform impure operations? Yes, as long as the exception's constructor is pure, a pure function can throw an exception. However, whether a pure function can do impure operations depends on what you mean by that. A pure function cannot call any function that is not pure (except in debug blocks, which circumvent pure purely for debug purposes and should not be used in normal code). That's part of being pure. But "pure" in the D sense really doesn't have anything to do with functional purity except insofar as it helps enable functional purity, so if when you're talking about a pure function doing an impure operation, you mean doing something that isn't functionally pure, then it can so long as the function's that it's calling are all pure. _All_ that pure means in D is that the function cannot access any mutable, global state or call any functions that aren't pure. At this point, it would be far more accurate for it to be called @noglobal than pure, but it's pure because when it was introduced, it was much closer to functionally pure (but far less useful). Originally, pure functions had to have parameters which were immutable or implicitly convertible to immutable so that the function could be functionally pure. That requirement no longer exists, but when a pure function does meet those requirements, there are optimizations that the compiler can do based on functional purity. For instance, a pure function which is functionally pure (i.e. if given the same arguments, it will always result in the same return value) will only be called once with a given set of arguments within an expression even if it's called multiple times. e.g. auto result = pureFunc(a) * pureFunc(a); would result in only one call to pureFunc if pureFunc's parameters are immutable or implicitly convertible to immutable, and the result will be reused. But if the paramaters are not immutable or implicitly convertible to immutable, then it's not functionally pure, and the calls cannot be optimized. Most pure functions can't be optimized like that. On the whole, pure is just a way to guarantee that a function is only using what it's given via its arguments and not doing stuff like saving state in static or global variables. Being able to optimize based on pure when it's actually functionally pure is a just a nice bonus that pops up occasionally. For a more in-depth look at D's purity, you should read http://klickverbot.at/blog/2012/05/purity-in-d/ - Jonathan M Davis
