Re: construct range from tuple?
On Sunday, 18 September 2016 at 09:36:13 UTC, e-y-e wrote:
On Sunday, 18 September 2016 at 08:06:54 UTC, Lutger wrote:
[...]
Use std.range's 'only' function [1], it takes variadic
arguments of the same type and constructs a range consisting of
them.
Example:
import std.meta : AliasSeq;
import std.range : only;
import std.algorithm.comparison : equal;
alias names = AliasSeq!("Alice", "Bob");
auto range = only(names, "Chuck");
assert(range.equal(["Alice", "Bob", "Chuck"]));
That's *exactly* what I was looking for, thanx!
Re: Can vibe d leverage existing web technologies?
On Thursday, 15 September 2016 at 20:56:19 UTC, Intersteller wrote: On Thursday, 15 September 2016 at 14:31:28 UTC, Martin Tschierschke wrote: 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. A good way to mix different technologies is to use a Apache or nginx proxy on the same server, so you can start using vibe.d for some parts and keep the rest at its place. Regards mt. How is this done? How can it be done smoothly? I'm not sure how to partition the work load. While, say, some pages might be served from php, and others from vibe2, etc, it seems like it would be nightmare to maintain consistency and interactivity. True. It is easier to maintain if you do a 'vertical split'. So each subsystem maintains a strict boundary. You have to be clear about the dependencies between subsystems and any data exchange should happen via an explicit api. So there is no shared database between the D part and the php part for example. Communication with json over http is common and well supported by vibe.d. See: http://martinfowler.com/articles/microservices.html This a more coarse grained approach which reduces coupling between the different parts. For example, you could write a small api with vibe.d which does image processing, or collects and manipulates data from third party apis, or whatever. The rails app handles authentication and ui, making use of the services that your vibe.d api provides. Another example: if you have a reasonably standalone part of a webapplication such as administrative pages or whatever, you could program that in vibe.d and let an nginx server route everything /admin/* to that part. The rails app exposes an api to modify its data which the admin app build in vibe.d makes use of.
construct range from tuple?
I have a tuple of strings generated at compile time, for example:
alias names = AliasSeq!("Alice", "Bob");
How is it possible to construct a range of strings from this, in
order to use it at runtime with other range algorithms?
For example, this
chain(names, ["Chuck"])
doesn't work as intended because it expands to
chain("Alice", "Bob", ["Chuck"])
I want some function makeRange that works like this:
assert(chain(makeRange(names), ["Chuck"]).fold!( (x,y) => x ~ " "
~ y) ==
"Alice Bob Chuck");
What would be a good way to do that?
Equivalent of FirstOrDefault with ranges
I was looking for something like FirstOrDefault* from .NET in
phobos. For example, I have this piece of code:
string findBobOrReturnNull(string[] names)
{
auto r = names.find("bob");
if(r.empty) return null;
return r.front;
}
assert(findBobOrReturnNull(["alice", "bob"]) == "bob");
assert(findBobOrReturnNull(["alice"]) is null);
How can I turn that into something like this, or is there another
idiomatic way to write it as a single expression?
string findBobOrReturnNull(string[] names)
{
return names.find("bob").firstOrDefault;
}
*
https://msdn.microsoft.com/en-us/library/bb340482%28v=vs.110%29.aspx
Re: documented unit tests as examples
On Friday, 13 May 2016 at 21:00:04 UTC, Steven Schveighoffer wrote: On 5/13/16 4:55 PM, Meta wrote: When I was new to D and I first saw the `assert(...)` idiom in an example in the documentation, it confused me for a minute or two, but if you know what `assert` does you can quickly wrap your head around the fact that it's both a test and an example. This would benefit users that are completely new to programming in general, however. Given the fact that asserts aren't always run, it's never comforting to me to run a program that tests something and have it give NO feedback. In fact, I frequently find myself triggering the assert to make sure it's actually being run (and I've caught the build not actually running it many times). This has a negative affect on anyone actually looking to see how a D function works. I can write a program that does nothing easily enough, why such a complicated example? -Steve This is a flaw of the simplistic test runner, not of the idea of unittests itself. Every other unittest system I worked with, including for example unit-threaded in D, reports a summary of the amount of tests that are ran. Very simple and just enough information that the test you just added has indeed been executed. One line is enough. Honestly I think keeping asserts in examples is better than the assert/writeln hybrid approach, because 1) asserts give the reader exact information about the expected behavior and contracts of a function (this information is lost to the reader when the asserts are reduced to print statements) and 2) having unittests compile to something very differently depending on context sounds like adding too much accidental complexity. Ideally there would be a way to print the values of all arguments given to an assert, that would be the most informative. And zooming out just a one liner with the number of tests or asserts ran and the number succeeded. I think this should be the domain of an external tool or library though, not the compiler itself. It is certainly possible to create such a tool and have phobos use it, no reason to add more complexity to the language itself.
