Re: LockingTextWriter not an output range?
On Wednesday, 18 April 2018 at 06:40:15 UTC, rikki cattermole wrote: On 18/04/2018 6:28 PM, kookman wrote: The below static assert fails. Is this expected? Not the way I read the docs. static assert (isOutputRange(typeof(stdout.lockingTextWriter), char)); static assert (isOutputRange!(typeof(stdout.lockingTextWriter()), char)); Ah - thank you! (slapping my forehead for wasted 2 hours)
Re: making a struct an inputRange with free functions
On Wednesday, April 18, 2018 20:39:46 jmh530 via Digitalmars-d-learn wrote:
> On Monday, 16 April 2018 at 19:27:28 UTC, Jonathan M Davis wrote:
> > [snip]
>
> It really would be nice if it worked with free functions...
>
> I was trying to get the example working with Atila's concepts
> library [1]. I tried re-writing the checkInputRange function so
> that UFCS is only used when hasMember passes, but that didn't
> seem to help things. The big issue is when the free functions are
> in another module that checkInputRange does not know about. The
> only solution I can think of is a template mixin (below). Then to
> use, you import InputRange; mixin InputRange; . However, I have
> no idea how well this will work more generally.
>
>
>
> mixin template InputRange()
> {
> void checkInputRange(R)(inout int = 0) {
> R r = R.init; // can define a range object
> if (r.empty) {} // can test for empty
> r.popFront; // can invoke popFront()
> auto h = r.front; // can get the front of the range
> }
> enum isInputRange(R) = is(typeof(checkInputRange!R));
> }
>
> [1] https://github.com/atilaneves/concepts
Occasionally, that aspect of importing and UFCS can be annoying, but on the
whole, I don't really see why it matters much, particularly when actually
having the free functions available would be an enormous change to how
imports work and could cause a ton of other problems. It would mean that
code would be affected by which code imported it rather than just the code
that it imports, and at that point, you effectively lose control over what's
going on. It would mean that just like C/C++ #includes, you couldn't rely on
the module being the same every time you imported it. Even if the effect
were limited to templated code, it would mean that two supposedly identical
instantiations of a template would not necessarily be identical anymore, and
they'd have to be recompiled in every module that used them. It would be a
disaster in the making. mixins are the closest that we get to that, but in
that case, the programmer is specifically stating that they want to reuse
that code directly in their own module as if it were declared there rather
than using stuff from other modules. Occasionally, that might be limiting,
but without those restrictions, you basically don't have a module system
anymore. And with mixins, you have control over what affects your module,
whereas having the code that imports a module affect it would be more like
mixing in code from the outside.
And in any case, IMHO, the range API functions aren't really functions that
make much sense as free functions anyway. They're not generic, and they're
very much tied to the type that they go with - just like opEquals, opAssign,
or toString are tied to the type. They're inherently pretty much the
opposite of generic. And even if the import rules somehow let you have them
as free functions without it causing problems, what would it buy you? The
only situation I can think of where it might be useful is if you're dealing
with a type that you can't control and thus can't add the member functions
to. But in that case, you can always just wrap that type in another type
that does declare the range API. So, I don't think that much is lost by not
being able to use UFCS to make something a range.
- Jonathan M Davis
Re: making a struct an inputRange with free functions
On Monday, 16 April 2018 at 19:27:28 UTC, Jonathan M Davis wrote:
[snip]
It really would be nice if it worked with free functions...
I was trying to get the example working with Atila's concepts
library [1]. I tried re-writing the checkInputRange function so
that UFCS is only used when hasMember passes, but that didn't
seem to help things. The big issue is when the free functions are
in another module that checkInputRange does not know about. The
only solution I can think of is a template mixin (below). Then to
use, you import InputRange; mixin InputRange; . However, I have
no idea how well this will work more generally.
mixin template InputRange()
{
void checkInputRange(R)(inout int = 0) {
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront; // can invoke popFront()
auto h = r.front; // can get the front of the range
}
enum isInputRange(R) = is(typeof(checkInputRange!R));
}
[1] https://github.com/atilaneves/concepts
Re: Error calling geqrs function from lubeck package.
On Tuesday, 17 April 2018 at 03:30:45 UTC, Jamie wrote: On Tuesday, 17 April 2018 at 03:26:25 UTC, Jamie wrote: Sorry it's really an error calling geqrs function from mir-lapack package. If you don't get an answer here, you can always file an issue at mir-lapack with a simple example.
Re: The case of -debug -O and: is breaking pure/@nogc/nothrow/@safe UB under -debug?
On Wednesday, 18 April 2018 at 13:47:35 UTC, Jonathan M Davis wrote: Thanks for both your answers, Jonathan and Nicholas. To the extent that I'd like to explain this in a d-idioms post, here is a tentative synthesis of your answers (Jonathan M Davis and Nicholas Wilson): - breaking pure with -debug is UB - breaking @nogc with -debug is definately not UB - breaking @safe wit -debug is potentially UB, like an incorrect @trusted clause would be (I'm assuming adverse conditions here) - there is disagreement between you w.r.t whether breaking nothrow with -debug is UB or not Note that I'm using the "undefined behaviour" term even though the behaviour is quite more constrained than that, because readers have a notion of what "undefined behaviour" is. For the purpose of brevity and simplicity I'll have to unify(!) this complicated situation in "breaking pure/@nogc/nothrow/@safe is Undefined Behaviour though in most cases it will work just fine".
Re: The case of -debug -O and: is breaking pure/@nogc/nothrow/@safe UB under -debug?
On Wednesday, April 18, 2018 13:15:08 Guillaume Piolat via Digitalmars-d- learn wrote: > The D specification says: > > "A ConditionalStatement that has a DebugCondition is called a > DebugStatement. DebugStatements have relaxed semantic checks in > that pure, @nogc, nothrow and @safe checks are not done. Neither > do DebugStatements influence the inference of pure, @nogc, > nothrow and @safe attributes." > > > So it seems under a debug clause you don't have to conform to > pure/@nogc/nothrow/@safe. > > The immediate question that follow is: > > "Is breaking pure/@nogc/nothrow/@safe Undefined Behaviour (UB) in > a DebugStatement?" > > Would the optimizer -O breaks code that breaks such by virtue of > being -debug? > > If no (not UB), doesn't this guarantees that no optimizations > will ever be performed thanks to pure/@nogc/nothrow/@safe? It wouldn't surprise me if Walter were the only person who could really answer that, though maybe one of the other compiler devs could. However, I'm quite sure that if you have strongly pure function, and you've turned on optimizations, extra calls to it will be elided regardless of the function internals, because that decision is made based on the function signature. The same will go for any optimization that is done based on the function signature. nothrow, for instance, would cause problems. If the function is nothrow, the compiler will have omitted all of the exception handling code around the function call, so if an exception is somehow thrown from a nothrow function, it's likely to cause some unpleasant problems. I expect that it will work on some level, since you can throw Errors from nothrow functions, but in the case of Errors, it's not guaranteed that any clean-up code is run (e.g. destructors and scope statements may or may not run and almost certainly won't if the function being called was nothrow, since that's the kind of thing that gets removed from around calls to nothrow functions when optimizing code). So, an Exception being thrown from a nothrow function would be very similar to an Error being thrown from a nothrow function. Either way, you don't want it to happen if it's not then going to kill your program, and while an Error is virtually guaranteed to bubble to the top and result in your program dying, in the case of an Exception, you might have something catching Exceptions which will end up catching it, in which case the program will be an invalid state, but it won't actually be killed. So, that could be very bad. I don't think that @nogc matters much one way or the other unless you haven't linked in the GC (e.g. if you're using -betterC). AFAIK, _all_ @nogc does is provide a way for the programmer to know for sure that a function doesn't allocate using the GC, and I don't think that it does any optimizations of any kind (I honestly don't know of any way that that information could even theoretically be used for optimizations). So, that probably doesn't matter in practice, though it wouldn't surprise me if at some point, someone figures out something clever that can be assumed based on @nogc, and you end up with problems if you violate it. All that violating @safe is going to do is essentially mean that you've marked a section of code as @trusted. If the code in question is actually @safe but just couldn't be verified as such by the compiler, then you're fine, but if it's actually doing something that isn't @safe, then you could have memory corruption problems. But that's the same with anything that's marked @trusted. What I can't say for sure is what happens inside the function when it's compiled. What I expect would happen would be that inside the debug statement, any errors related to stuff like pure would be ignored but that the compiler would otherwise treat that code like any other code in the function. - Jonathan M Davis
Re: The case of -debug -O and: is breaking pure/@nogc/nothrow/@safe UB under -debug?
On Wednesday, 18 April 2018 at 13:15:08 UTC, Guillaume Piolat wrote: The D specification says: "A ConditionalStatement that has a DebugCondition is called a DebugStatement. DebugStatements have relaxed semantic checks in that pure, @nogc, nothrow and @safe checks are not done. Neither do DebugStatements influence the inference of pure, @nogc, nothrow and @safe attributes." So it seems under a debug clause you don't have to conform to pure/@nogc/nothrow/@safe. Correct. Good luck trying to debug a pure function if you can't print intermediates. The immediate question that follow is: "Is breaking pure/@nogc/nothrow/@safe Undefined Behaviour (UB) in a DebugStatement?" Pure: definitely no, debug escaping pure is pretty much the whole point. @nogc/nothrow/@safe I'm not so sure about. I think it is allowed because logging functions may not necessarily be @nogc/nothrow/@safe and not being able to call them defeats the purpose of debug. Would the optimizer -O breaks code that breaks such by virtue of being -debug? I don't think so: pure: optimisations are about eliding calls with identical arguments. You shouldn't be relying on any variations due to optimisation @nogc: no optimisation are performed based on this knowledge. nothrow: optimisations are about eliding unwinding tables, I don't think this would have an effect on the soundness of the function. @safe: debug is effectively @trusted, the usual rules apply.
The case of -debug -O and: is breaking pure/@nogc/nothrow/@safe UB under -debug?
The D specification says: "A ConditionalStatement that has a DebugCondition is called a DebugStatement. DebugStatements have relaxed semantic checks in that pure, @nogc, nothrow and @safe checks are not done. Neither do DebugStatements influence the inference of pure, @nogc, nothrow and @safe attributes." So it seems under a debug clause you don't have to conform to pure/@nogc/nothrow/@safe. The immediate question that follow is: "Is breaking pure/@nogc/nothrow/@safe Undefined Behaviour (UB) in a DebugStatement?" Would the optimizer -O breaks code that breaks such by virtue of being -debug? If no (not UB), doesn't this guarantees that no optimizations will ever be performed thanks to pure/@nogc/nothrow/@safe?
Status of dstddb
What is the status of dstddb( https://code.dlang.org/packages/database )?Is it usable? What about entity( https://code.dlang.org/packages/entity )?
Re: Rotate array in writefln?
On Wednesday, 18 April 2018 at 06:54:29 UTC, Chris Katko wrote:
I need to rotate an array by 90 degrees, or have writefln
figure that out.
I need, say:
0 4 5 6
0 0 0 0
0 0 0 0
0 0 0 0
But it's outputting:
0 0 0 0
4 0 0 0
5 0 0 0
6 0 0 0
int [4][4] data;
file.writeln(format("%(%-(%d %)\n%)", data));
Generally, the solution would be std.range.transposed. However,
since you're using a int[4][4], that's not a range-of-ranges, and
transposed don't work out of the box. This helper function should
help:
T[][] ror(T, size_t N1, size_t N2)(ref T[N1][N2] arr)
{
T[][] result = new T[][N2];
foreach (i, e; arr) {
result[i] = e.dup;
}
return result;
}
unittest
{
import std.stdio;
import std.range;
int [4][4] data;
data[2][3] = 4;
writefln("%(%-(%d %)\n%)", data);
writefln("%(%-(%d %)\n%)", data.ror.transposed);
}
--
Simen
Re: Rotate array in writefln?
On Wednesday, 18 April 2018 at 06:54:29 UTC, Chris Katko wrote:
I need to rotate an array by 90 degrees, or have writefln
figure that out.
I need, say:
0 4 5 6
0 0 0 0
0 0 0 0
0 0 0 0
But it's outputting:
0 0 0 0
4 0 0 0
5 0 0 0
6 0 0 0
int [4][4] data;
file.writeln(format("%(%-(%d %)\n%)", data));
You can transpose the matrix :)
