Re: Just because it's a slow Thursday on this forum
On 2/11/16 4:38 PM, H. S. Teoh via Digitalmars-d wrote: (Next thing you know, newbies will be asking why there's both `print` and `write` that do the same thing except different.) That sounds unlikely to me. What would be a few examples/precedents? -- Andrei
Re: Just because it's a slow Thursday on this forum
On Friday, 12 February 2016 at 03:18:47 UTC, Nick Sabalausky
wrote:
I'd be perfectly happy to have it, particularly if it had a
less confusing name, but can definitely see it being debatable
whether it really is Phobos-worthy.
Andrei has previously expressed a desire for a big standard
library and it is a very good introduction to the language for
newbies to be able to use print. It's simple and does what they
expect, writefln("%s %s %s %s", a, b, c, d) is anything but
simple and contains multiple pitfalls for a new user. This is
likely the second most commonly used function (or thing someone
wants a function to do) after main.
Why is the resistance to convenience functions so high in this
community? If you want people to use D it will need to be both
powerful and feel light and easy to use. It would seem to be
better for D to allow convenience functions in Phobos more
broadly where the use case is common.
There are already many print and write functions, it's not a
thing that has only one way to do it that will be greatly muddied
by the addition of another function, can you cite threads from
other languages where people are confused by a function called
print that prints?
Re: Just because it's a slow Thursday on this forum
On 02/11/2016 04:44 PM, John Colvin wrote: On Thursday, 11 February 2016 at 21:38:42 UTC, H. S. Teoh wrote: On Thu, Feb 11, 2016 at 03:38:42PM -0500, Nick Sabalausky via Digitalmars-d wrote: On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote: >[...] My understanding is that's the whole point of the "dump" function being discussed. Unless I misunderstood? IMO `dump` is worthwhile but `print` seems little more than an alias for `writefln`. I can't find enough justification to warrant `print`. (Next thing you know, newbies will be asking why there's both `print` and `write` that do the same thing except different.) T yeah, dump is really useful, print is a bit marginal. Ahh, I missed the "print" stuff. I do agree it's not as useful as "dump", plus the name seems to suggest a connection with printf, which strikes me as confusing. I do think the "print" function discussed (ie, like writeln, but auto-inserts spaces between the args) is occasionally nice for script-like programs. In fact, I think I have a function like that in Scriptlike specifically because of that...unless it's back in my older utility library instead... I'd be perfectly happy to have it, particularly if it had a less confusing name, but can definitely see it being debatable whether it really is Phobos-worthy.
Re: Just because it's a slow Thursday on this forum
On Thursday, 11 February 2016 at 21:38:42 UTC, H. S. Teoh wrote: On Thu, Feb 11, 2016 at 03:38:42PM -0500, Nick Sabalausky via Digitalmars-d wrote: On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote: >[...] My understanding is that's the whole point of the "dump" function being discussed. Unless I misunderstood? IMO `dump` is worthwhile but `print` seems little more than an alias for `writefln`. I can't find enough justification to warrant `print`. (Next thing you know, newbies will be asking why there's both `print` and `write` that do the same thing except different.) T yeah, dump is really useful, print is a bit marginal.
Re: Just because it's a slow Thursday on this forum
On Thu, Feb 11, 2016 at 03:38:42PM -0500, Nick Sabalausky via Digitalmars-d wrote: > On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote: > > > >Fair enough. > > > >Personally, though, I find a bunch of comma-separated values very > >unhelpful. It would be much better if they were labelled, e.g., if: > > > > int x, y, z; > > dump(x,y,z); > > > >outputs: > > > > x=1, y=2, z=3 > > > >it would be much better than just: > > > > 1, 2, 3 > > > >which is unclear which values belongs to which variable. Trivial to > >figure out in this case, but it's not as obvious when interspersed > >between other program output & debug messages. But maybe that's just > >a matter of habit, and difference in personal debugging style. > > > > My understanding is that's the whole point of the "dump" function > being discussed. Unless I misunderstood? IMO `dump` is worthwhile but `print` seems little more than an alias for `writefln`. I can't find enough justification to warrant `print`. (Next thing you know, newbies will be asking why there's both `print` and `write` that do the same thing except different.) T -- In order to understand recursion you must first understand recursion.
Re: Just because it's a slow Thursday on this forum
On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote: Fair enough. Personally, though, I find a bunch of comma-separated values very unhelpful. It would be much better if they were labelled, e.g., if: int x, y, z; dump(x,y,z); outputs: x=1, y=2, z=3 it would be much better than just: 1, 2, 3 which is unclear which values belongs to which variable. Trivial to figure out in this case, but it's not as obvious when interspersed between other program output & debug messages. But maybe that's just a matter of habit, and difference in personal debugging style. My understanding is that's the whole point of the "dump" function being discussed. Unless I misunderstood?
Re: Just because it's a slow Thursday on this forum
On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote: Personally, though, I find a bunch of comma-separated values very unhelpful. It would be much better if they were labelled So wasn't this dump() as opposed to print()? Two different functions doing different things. -- Andrei
Re: Just because it's a slow Thursday on this forum
On Thu, Feb 11, 2016 at 09:55:49AM -0500, Nick Sabalausky via Digitalmars-d
wrote:
> On 02/10/2016 02:47 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via
> >Digitalmars-d wrote:
> >>On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
> >>>I see no non-trivial cost.
> >>
> >>I, to, am not getting the cost story. H.S. Teoh, could you please
> >>substantiate? -- Andrei
> >
> >Sorry, I meant technical debt. My point was that this function needs
> >to provide more value than what's effectively just an alias for
> >writefln("%s, %s, %s", x, y, z).
> >
>
> Having used an equivalent to the proposed "dump" for many years (and
> an inferior equivalent at that), I can attest that it definitely
> provides sufficient value over write* functions. With write*, there's
> always either excess verbosity that just gets in the way of my "flow",
> or I can opt the succinct route and wind up looking at a dump of
> numbers finding it difficult to know what number is what variable. Any
> homemade wrapper/alias only creates even MORE work when trying to use
> it. Anyone may be skeptical of the reasons, but it doesn't matter
> because again, this is all direct personal experience, not
> hypothetical theorizing.
>
> In short: Yes. Yes it does provide sufficient value. And the
> "technical debt" is still vastly less than the time, effort and bother
> of having to defend yet another clear improvement on the D perpetual
> debate forums.
Fair enough.
Personally, though, I find a bunch of comma-separated values very
unhelpful. It would be much better if they were labelled, e.g., if:
int x, y, z;
dump(x,y,z);
outputs:
x=1, y=2, z=3
it would be much better than just:
1, 2, 3
which is unclear which values belongs to which variable. Trivial to
figure out in this case, but it's not as obvious when interspersed
between other program output & debug messages. But maybe that's just a
matter of habit, and difference in personal debugging style.
T
--
Making non-nullable pointers is just plugging one hole in a cheese
grater. -- Walter Bright
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 02:47 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
I see no non-trivial cost.
I, to, am not getting the cost story. H.S. Teoh, could you please
substantiate? -- Andrei
Sorry, I meant technical debt. My point was that this function needs to
provide more value than what's effectively just an alias for
writefln("%s, %s, %s", x, y, z).
Having used an equivalent to the proposed "dump" for many years (and an
inferior equivalent at that), I can attest that it definitely provides
sufficient value over write* functions. With write*, there's always
either excess verbosity that just gets in the way of my "flow", or I can
opt the succinct route and wind up looking at a dump of numbers finding
it difficult to know what number is what variable. Any homemade
wrapper/alias only creates even MORE work when trying to use it. Anyone
may be skeptical of the reasons, but it doesn't matter because again,
this is all direct personal experience, not hypothetical theorizing.
In short: Yes. Yes it does provide sufficient value. And the "technical
debt" is still vastly less than the time, effort and bother of having to
defend yet another clear improvement on the D perpetual debate forums.
Re: Just because it's a slow Thursday on this forum
On Wednesday, 10 February 2016 at 19:30:26 UTC, Andrei Alexandrescu wrote: On 02/10/2016 01:51 PM, w0rp wrote: I wonder if the addition of another function for printing will confuse some new users. In my experience: * two names for the same exact thing => annoyance (not only in D, e.g. dual use of "class" and "typename" in C++) * two different names that do the same thing in slightly different without a distinction, interchangeable ways => confusion and annoyance (e.g. "class" vs "struct" in C++) * two names that do the same thing, one poorly and one better => confusion (e.g. "stringstream" vs. "strstream", vector vs vector_bool in C++) * two names that do two similar, but distinct things => "oh ok" (e.g. "map" vs. "multimap"). So I think we're safe. Andrei Yeah, that makes sense. Fair enough.
Re: Just because it's a slow Thursday on this forum
On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
> >I see no non-trivial cost.
>
> I, to, am not getting the cost story. H.S. Teoh, could you please
> substantiate? -- Andrei
Sorry, I meant technical debt. My point was that this function needs to
provide more value than what's effectively just an alias for
writefln("%s, %s, %s", x, y, z).
T
--
Never ascribe to malice that which is adequately explained by incompetence. --
Napoleon Bonaparte
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 02:25 PM, Nick Sabalausky wrote: I see no non-trivial cost. I, to, am not getting the cost story. H.S. Teoh, could you please substantiate? -- Andrei
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 02:08 PM, H. S. Teoh via Digitalmars-d wrote: 1) It's clear that it's only intended for debugging (i.e., the name should make it clear it isn't for general output, so `dump` rather than `print` would be preferable); Those would be two different functions. -- Andrei
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 01:51 PM, w0rp wrote: I wonder if the addition of another function for printing will confuse some new users. In my experience: * two names for the same exact thing => annoyance (not only in D, e.g. dual use of "class" and "typename" in C++) * two different names that do the same thing in slightly different without a distinction, interchangeable ways => confusion and annoyance (e.g. "class" vs "struct" in C++) * two names that do the same thing, one poorly and one better => confusion (e.g. "stringstream" vs. "strstream", vector vs vector_bool in C++) * two names that do two similar, but distinct things => "oh ok" (e.g. "map" vs. "multimap"). So I think we're safe. Andrei
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 02:08 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Feb 10, 2016 at 06:51:21PM +, w0rp via Digitalmars-d wrote: I wonder if the addition of another function for printing will confuse some new users. I can't imagine it would in any significant way. Certainly not if it's named "dump", anyway. Currently I don't see much value in it to justify the costs. BUT, there might be a case for it if: [...] I see no non-trivial cost. I've been using a homemade equivalent of it for years, and I can speak from experience that it's definitely a big help. Not only that, but the only two reasons I've ever had for NOT using it are fixed by this proposal: - Can now be done without bulky "mixin(...)" at the usage site. - Built into Phobos so never a need, in any project, to [temporarily or otherwise] tie in a new dependency just for a temporary debugging aid. I'm hugely in favor of this. Me want.
Re: Just because it's a slow Thursday on this forum
On Wednesday, 10 February 2016 at 18:51:21 UTC, w0rp wrote: I wonder if the addition of another function for printing will confuse some new users. I'm a relatively new D user. For the most part, all I use is writeln because that's what was used in the Hello World examples. I only bother looking for other printing functions when I need them. Nevertheless, I struggle with some of the documentation in std.stdio. A few functions, like byChunk, are documented in a high-quality way. For others, the situation is not so good. Look at stdout, just says standard output stream. There's no definition of stream anywhere in there, or a link to maybe the wikipedia page on streams. When I google output stream it brings up Java documentation. I happen to know what it means and someone with other programming experience will too, but not a new programmer. Many other functions are documented in a similarly terse fashion. So no, I don't think adding another function to std.stdio will be confusing ipso facto. Instead, if you think new users will find std.stdio confusing, may I suggest improving the documentation (of both old and new functionality).
Re: Just because it's a slow Thursday on this forum
On Wed, Feb 10, 2016 at 06:51:21PM +, w0rp via Digitalmars-d wrote: > I wonder if the addition of another function for printing will confuse > some new users. Currently I don't see much value in it to justify the costs. BUT, there might be a case for it if: 1) It's clear that it's only intended for debugging (i.e., the name should make it clear it isn't for general output, so `dump` rather than `print` would be preferable); 2) It's actually useful for debugging, meaning: a) It will use introspection to recursively output aggregate members (preferably with field members labelled); b) Arrays and AA likewise should be output in the expected format; c) Attributes, and perhaps the full type, should be included in the output, especially if function pointers and delegates are involved, e.g.: const(char)[] data = ...; int delegate(float) @safe dg; dump(data, dg); should output something like: (const(char)[])"Some string data", (int delegate(float) @safe)0x12345678 (Why the full type? because it's useful for debugging `auto` variables in range-based code and other such code. And also to make it absolutely clear that this isn't meant for anything other than debugging output.) d) It will, optionally, walk recursive data structures and output each node in some sensible way. 3) The output format should be standard, readable by default, and should not need (nor allow) customization. (Otherwise, we might as well go back to writefln & friends.) T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy
Re: Just because it's a slow Thursday on this forum
I wonder if the addition of another function for printing will confuse some new users.
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 09:22 AM, Daniel Kozak via Digitalmars-d wrote: It is something else. Same as php has echo and var_dump. writeln just output value of some variable, but dump will print names and values of variables, so you can see structure of your data. Oh btw one nice thing about dump would be to display strings in "dson" format, i.e. the same way they'd appear in a D declaration. Example: s = "This is\na\tstring." writeln(s) would output: This is astring. whereas dump!(s) would write: s = "This is\na\tstring." Andrei
Re: Just because it's a slow Thursday on this forum
On Wednesday, 10 February 2016 at 14:06:02 UTC, Suliman wrote: Sorry, but where dump! function can be helpful? What's wrong with writeln? Formatting complex data automatically makes it a lot easier to see what you're getting. Makes debugging so much easier when your data is actually readable. Long strings, complex structs, byte arrays, json or xml, these all really need more formatting to read than writeln does.
Re: Just because it's a slow Thursday on this forum
Dne 10.2.2016 v 15:06 Suliman via Digitalmars-d napsal(a): On Tuesday, 9 February 2016 at 18:02:50 UTC, Andrei Alexandrescu wrote: On 02/09/2016 10:34 AM, ixid wrote: On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote: I'm not a fan of non-trivial string mixins except in extenuating circumstances. This is something Steven Schveighoffer commented on in these discussions as well. As this is a fundamental D feature and it's currently rather clunky and hard to use it would suggest this needs improvement. What should be done with it if anything and with what methods? An alternate solution is liable to be too clever for its own good. Everybody and their cat understands string concatenation. What we need here is better tactical tools, e.g. a simple string template/interpolation engine. -- Andrei Sorry, but where dump! function can be helpful? What's wrong with writeln? It is something else. Same as php has echo and var_dump. writeln just output value of some variable, but dump will print names and values of variables, so you can see structure of your data.
Re: Just because it's a slow Thursday on this forum
On Tuesday, 9 February 2016 at 18:02:50 UTC, Andrei Alexandrescu wrote: On 02/09/2016 10:34 AM, ixid wrote: On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote: I'm not a fan of non-trivial string mixins except in extenuating circumstances. This is something Steven Schveighoffer commented on in these discussions as well. As this is a fundamental D feature and it's currently rather clunky and hard to use it would suggest this needs improvement. What should be done with it if anything and with what methods? An alternate solution is liable to be too clever for its own good. Everybody and their cat understands string concatenation. What we need here is better tactical tools, e.g. a simple string template/interpolation engine. -- Andrei Sorry, but where dump! function can be helpful? What's wrong with writeln?
Re: Just because it's a slow Thursday on this forum
On Tuesday, 9 February 2016 at 18:02:50 UTC, Andrei Alexandrescu wrote: On 02/09/2016 10:34 AM, ixid wrote: An alternate solution is liable to be too clever for its own good. Everybody and their cat understands string concatenation. What we need here is better tactical tools, e.g. a simple string template/interpolation engine. -- Andrei I wasn't suggesting throwing the baby out with the bathwater. Library and IDE support to what's there would be great.
Re: Just because it's a slow Thursday on this forum
On 02/09/2016 10:34 AM, ixid wrote: On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote: I'm not a fan of non-trivial string mixins except in extenuating circumstances. This is something Steven Schveighoffer commented on in these discussions as well. As this is a fundamental D feature and it's currently rather clunky and hard to use it would suggest this needs improvement. What should be done with it if anything and with what methods? An alternate solution is liable to be too clever for its own good. Everybody and their cat understands string concatenation. What we need here is better tactical tools, e.g. a simple string template/interpolation engine. -- Andrei
Re: Just because it's a slow Thursday on this forum
On 02/08/2016 02:15 PM, Nick Sabalausky wrote: I'd wanted to do a non-mixin version, but that hasn't been possible. Well, wasn't possible at the time, anyway.
Re: Just because it's a slow Thursday on this forum
On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote: I'm not a fan of non-trivial string mixins except in extenuating circumstances. This is something Steven Schveighoffer commented on in these discussions as well. As this is a fundamental D feature and it's currently rather clunky and hard to use it would suggest this needs improvement. What should be done with it if anything and with what methods?
Re: Just because it's a slow Thursday on this forum
On Tuesday, 9 February 2016 at 14:38:23 UTC, Andrei Alexandrescu
wrote:
On 02/09/2016 07:46 AM, Jakob Ovrum wrote:
void main()
{
import std.stdio : stdout;
int a = 42;
string b = "foo";
float c = 3.14;
dump!(a, b, c)(); // a = 42, b = foo, c = 3.14
stdout.dump!(a, b, c)(" | "); // a = 42 | b = foo | c =
3.14
}
I think this is good stuff and should go in Phobos. Where
particularly? -- Andrei
I can't really see the applications beyond a role as a simple
lowtech debugging aid, but since it uses std.stdio I guess that's
an OK place to put it.
Re: Just because it's a slow Thursday on this forum
On 02/09/2016 07:46 AM, Jakob Ovrum wrote:
void main()
{
import std.stdio : stdout;
int a = 42;
string b = "foo";
float c = 3.14;
dump!(a, b, c)(); // a = 42, b = foo, c = 3.14
stdout.dump!(a, b, c)(" | "); // a = 42 | b = foo | c = 3.14
}
I think this is good stuff and should go in Phobos. Where particularly?
-- Andrei
Re: Just because it's a slow Thursday on this forum
On 02/09/2016 06:25 AM, Marc Schütz wrote: On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu wrote: On 2/7/16 7:11 PM, John Colvin wrote: alias dump = dumpTo!stdout; alias errDump = dumpTo!stderr; I'm hoping for something with a simpler syntax, a la dump!(stdout, "x") where stdout is optional. -- Andrei Why would `stdout` need to be a template argument? It needn't! -- Andrei
Re: Just because it's a slow Thursday on this forum
On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu
wrote:
On 2/7/16 7:11 PM, John Colvin wrote:
alias dump = dumpTo!stdout;
alias errDump = dumpTo!stderr;
I'm hoping for something with a simpler syntax, a la
dump!(stdout, "x") where stdout is optional. -- Andrei
This works:
---
import std.stdio : File;
static import std.ascii;
template dump(symbols...)
{
import std.stdio : File;
void dump(Separator, Terminator)(
File file,
Separator separator = ", ",
Terminator terminator = std.ascii.newline)
{
foreach(i, symbol; symbols[0 .. $ - 1])
file.write(__traits(identifier, symbols[i]), " = ", symbol,
separator);
file.write(__traits(identifier, symbols[$ - 1]), " = ",
symbols[$ - 1], terminator);
}
void dump(Separator, Terminator)(
Separator separator = ", ",
Terminator terminator = std.ascii.newline)
if (!is(Separator == File))
{
import std.stdio : stdout;
.dump!symbols(stdout, separator, terminator);
}
}
void main()
{
import std.stdio : stdout;
int a = 42;
string b = "foo";
float c = 3.14;
dump!(a, b, c)(); // a = 42, b = foo, c = 3.14
stdout.dump!(a, b, c)(" | "); // a = 42 | b = foo | c = 3.14
}
---
I'm not a fan of non-trivial string mixins except in extenuating
circumstances. I tried compressing it to a single call to `write`
like your `print` except using staticMap, but like I often do I
ran into "template instance foo cannot use local 'bar' as
parameter to non-global template baz" errors.
Re: Just because it's a slow Thursday on this forum
On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu wrote: On 2/7/16 7:11 PM, John Colvin wrote: alias dump = dumpTo!stdout; alias errDump = dumpTo!stderr; I'm hoping for something with a simpler syntax, a la dump!(stdout, "x") where stdout is optional. -- Andrei Why would `stdout` need to be a template argument?
Re: Just because it's a slow Thursday on this forum
On Sunday, 7 February 2016 at 23:26:05 UTC, Andrei Alexandrescu
wrote:
On 02/04/2016 09:46 PM, Tofu Ninja wrote:
On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei
Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/3971 --
Andrei
People one github were asking for a dump function so they
could do
int a = 5;
dump!("a"); // prints "a = 5"
Here's a working version if anyone wants it but you have to
use it like
mixin dump!("a");
//
mixin template dump(Names ... )
{
auto _unused_dump = {
import std.stdio : writeln, write;
foreach(i,name; Names)
{
write(name, " = ", mixin(name),
(i
"\n");
}
return false;
}();
}
unittest{
int x = 5;
int y = 3;
int z = 15;
mixin dump!("x", "y"); // x = 5, y = 3
mixin dump!("z"); // z = 15
mixin dump!("x+y");// x+y = 8
mixin dump!("x+y < z");// x+y < z = true
}
This is useful and we should include it. How would you improve
the code to allow dumping to a different File than stdout (e.g.
most often stderr)? -- Andrei
FWIW, That functionality's been in the "semitwist d tools" util
lib for years. (Although granted, much of the lib has bitrotted
by this point.) See "traceVal".
I'd wanted to do a non-mixin version, but that hasn't been
possible. That was a major motivator for my suggestion ages ago
of "string mixins without the mixin keyword by marking a ctfe
func as mixin" but that was rejected in favor of only allowing it
for template mixins, not string mixins.
Re: Just because it's a slow Thursday on this forum
On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu
wrote:
On 2/7/16 7:11 PM, John Colvin wrote:
alias dump = dumpTo!stdout;
alias errDump = dumpTo!stderr;
I'm hoping for something with a simpler syntax, a la
dump!(stdout, "x") where stdout is optional. -- Andrei
How about this, which allows you to specify variables as alias
parameters (i.e. without strings) as well. It could be a lot
neater if a static assert is used in the body instead of using
template constraints, but obviously that has its downsides.
import std.stdio : File;
import std.traits : isSomeString;
import std.meta : allSatisfy;
private template isAlias(a ...)
if (a.length == 1)
{
enum isAlias = __traits(compiles, { alias b = a[0]; })
&& is(typeof(a[0]));
}
private template isStringValue(a ...)
if (a.length == 1)
{
enum isStringValue = isSomeString!(typeof(a[0]));
}
private template isStringOrAlias(a ...)
if (a.length == 1)
{
/* can't use templateOr in the dump template constraints
* because `Error: template instance F!(a) cannot use local
'a'
* as parameter to non-global template templateOr(T...)` */
* enum isStringOrAlias = isAlias!a || isStringValue!a;
}
mixin template dump(alias file, Args ...)
if (is(typeof(file) == File) && Args.length > 0
&& allSatisfy!(isStringOrAlias, Args))
{
auto _unused_dump = {
import std.traits : Select;
// can put expressions directly in Select with
//
https://github.com/D-Programming-Language/phobos/pull/3978
enum sep = ", ";
enum term = "\n";
foreach (i, arg; Args)
{
static if (isSomeString!(typeof(arg)))
file.write(arg, " = ", mixin(arg),
Select!(i < Args.length - 1, sep, term));
else
file.write(__traits(identifier, Args[i]), " = ",
arg,
Select!(i < Args.length - 1, sep, term));
}
return false;
}();
}
mixin template dump(Args ...)
if (Args.length > 0
&& allSatisfy!(isStringOrAlias, Args))
{
import std.stdio : stdout;
mixin .dump!(stdout, Args);
}
unittest
{
import std.stdio;
int a = 3, b = 4;
mixin dump!q{ a + b };
mixin dump!(stderr, "a - b");
mixin dump!a;
mixin dump!(stderr, a, b);
}
Re: Just because it's a slow Thursday on this forum
On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu wrote: On 2/7/16 7:11 PM, John Colvin wrote: alias dump = dumpTo!stdout; alias errDump = dumpTo!stderr; I'm hoping for something with a simpler syntax, a la dump!(stdout, "x") where stdout is optional. -- Andrei dump and fdump, just like printf and fprintf?
Re: Just because it's a slow Thursday on this forum
On 2/7/16 7:11 PM, John Colvin wrote: alias dump = dumpTo!stdout; alias errDump = dumpTo!stderr; I'm hoping for something with a simpler syntax, a la dump!(stdout, "x") where stdout is optional. -- Andrei
Re: Just because it's a slow Thursday on this forum
On Sunday, 7 February 2016 at 23:26:05 UTC, Andrei Alexandrescu
wrote:
On 02/04/2016 09:46 PM, Tofu Ninja wrote:
On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei
Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/3971 --
Andrei
People one github were asking for a dump function so they
could do
int a = 5;
dump!("a"); // prints "a = 5"
Here's a working version if anyone wants it but you have to
use it like
mixin dump!("a");
//
mixin template dump(Names ... )
{
auto _unused_dump = {
import std.stdio : writeln, write;
foreach(i,name; Names)
{
write(name, " = ", mixin(name),
(i
"\n");
}
return false;
}();
}
unittest{
int x = 5;
int y = 3;
int z = 15;
mixin dump!("x", "y"); // x = 5, y = 3
mixin dump!("z"); // z = 15
mixin dump!("x+y");// x+y = 8
mixin dump!("x+y < z");// x+y < z = true
}
This is useful and we should include it. How would you improve
the code to allow dumping to a different File than stdout (e.g.
most often stderr)? -- Andrei
Something like this?
import std.stdio : File, stderr, stdout;
template dumpTo(alias output)
if (isInstanceOf!(File, output))
{
mixin template dumpTo(Names ... )
{
auto _unused_dump = {
import std.traits : Select;
foreach (i, name; Names)
{
output.write(name, " = ", mixin(name),
Select!(i < Names.length - 1, ", ", '\n'));
}
return false;
}();
}
}
alias dump = dumpTo!stdout;
alias errDump = dumpTo!stderr;
Re: Just because it's a slow Thursday on this forum
On 02/04/2016 09:46 PM, Tofu Ninja wrote:
On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/3971 -- Andrei
People one github were asking for a dump function so they could do
int a = 5;
dump!("a"); // prints "a = 5"
Here's a working version if anyone wants it but you have to use it like
mixin dump!("a");
//
mixin template dump(Names ... )
{
auto _unused_dump = {
import std.stdio : writeln, write;
foreach(i,name; Names)
{
write(name, " = ", mixin(name), (i
This is useful and we should include it. How would you improve the code
to allow dumping to a different File than stdout (e.g. most often
stderr)? -- Andrei
Re: Just because it's a slow Thursday on this forum
On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei Alexandrescu
wrote:
https://github.com/D-Programming-Language/phobos/pull/3971 --
Andrei
People one github were asking for a dump function so they could do
int a = 5;
dump!("a"); // prints "a = 5"
Here's a working version if anyone wants it but you have to use
it like
mixin dump!("a");
//
mixin template dump(Names ... )
{
auto _unused_dump = {
import std.stdio : writeln, write;
foreach(i,name; Names)
{
write(name, " = ", mixin(name), (i
Re: Just because it's a slow Thursday on this forum
On Friday, 5 February 2016 at 02:46:01 UTC, Tofu Ninja wrote: ... It's kinda neat cus it supports arbitrary expressions. Mixins are pretty powerful.
