Working with cmd
Are there any libs which can be used to access cmd commands?
Re: Checked!({short, ushort, byte, ubyte}, Throw): compilation fails
On Friday, 17 April 2020 at 12:59:20 UTC, Simen Kjærås wrote:
[Deleted text makes sense]
And assigning from an int to a short may discard data, so it's
statically disallowed by Checked.
This is a deliberate design choice, and the appropriate way to
handle it is with a cast:
unittest {
import std.experimental.checkedint;
Checked!(int, Throw) a = 65535;
Checked!(short, Throw) b = cast(short)a;
}
A curiosity. Usually you cast into the type on the left. But
Checked!(short, Throw) b = cast (Checked!(short, Throw)) a;
does not compile:
Error: template std.experimental.checkedint.Checked!(int,
Throw).Checked.opCast cannot deduce function from argument
types
!(Checked!(short, Throw))(), candidates are: [...]
One has to go over the underlying type?
The above code will throw when casting (before the assignment),
because 65535 can't fit in a short.
It's remarkable that the cast to the /underlying type/ throws. I
would have expected that
cast(short) a
is equivalent to what actually must be written as
cast(short) a.get
You also get a deprecation message, about an integral promotion
not being performed. I believe the result is correct and the
warning can be ignored.
So the warning is a bug?
void foo (T) ()
{
import std.experimental.checkedint;
alias CT = Checked!(T, Throw);
CT c = CT.min;
CT b;
--b;
c /= b;
}
Re: Extracting user defined attributes on function parameters
On Friday, 17 April 2020 at 18:05:39 UTC, Jean-Louis Leroy wrote: Interesting example, but all hope is not lost. `a` could (should?) be passed as an alias in __parameters. Well, __parameters itself actually kinda works. The compiler knows it is an expression and can stringify it or evaluate it on demand for you... but how to express that in D code is pretty weird and idk how to library that. Using in-site for various things can be done but putting it in a lib is idk.
Re: Extracting user defined attributes on function parameters
On Friday, 17 April 2020 at 18:05:39 UTC, Jean-Louis Leroy wrote: Interesting example, but all hope is not lost. `a` could (should?) be passed as an alias in __parameters. Okay I take this back...
Re: Extracting user defined attributes on function parameters
On Friday, 17 April 2020 at 17:48:06 UTC, Adam D. Ruppe wrote:
On Friday, 17 April 2020 at 17:31:32 UTC, Jean-Louis Leroy
wrote:
Well, can't do. I need this purely at compile time, and
cross-module.
And the CTFE engine gets weird with it too dmd will have to
fix this.
But default parameters might not be possible in general at CT
anyway... it is actually possible to define it to a variable.
Observe:
int a;
void f(int arg = a) { // default arg is to use the global...
import std.stdio; writeln(arg);
}
void main() {
f(); // 0 this time
a = 4; // and it can be changed at runtime!
f(); // will now say 4
}
Interesting example, but all hope is not lost. `a` could
(should?) be passed as an alias in __parameters.
Re: Integration tests
On Friday, 17 April 2020 at 16:56:57 UTC, Russel Winder wrote: Hi, Thinking of trying to do the next project in D rather than Rust, but… Rust has built in unit testing on a module basis. D has this so no problem. Rust allows for integration tests in the tests directory of a project. These are automatically build and run along with all unit tests as part of "cargo test". Does D have any integrated support for integration tests in the way Rust does? Automated testing is important, perhaps you describe further what's needed? I haven't worked with Rust test frameworks, but I took a look at the description of the integration tests and unit tests. It wasn't immediately obvious what can be done with the Rust integration test framework that cannot be done with D's unittest framework. An important concept described was testing a module as an external caller. That would seem very be doable using D's unittest framework. For example, one could create a set of tests against Phobos, put them in a separate location (e.g. a separate file), and arrange to have the unittests run as part of a CI process run along with a build. My look was very superficial, perhaps you could explain more.
Re: Extracting user defined attributes on function parameters
On Friday, 17 April 2020 at 17:31:32 UTC, Jean-Louis Leroy wrote:
Well, can't do. I need this purely at compile time, and
cross-module.
And the CTFE engine gets weird with it too dmd will have to
fix this.
But default parameters might not be possible in general at CT
anyway... it is actually possible to define it to a variable.
Observe:
int a;
void f(int arg = a) { // default arg is to use the global...
import std.stdio; writeln(arg);
}
void main() {
f(); // 0 this time
a = 4; // and it can be changed at runtime!
f(); // will now say 4
}
Re: Extracting user defined attributes on function parameters
On Fri, Apr 17, 2020 at 05:33:23PM +, Simen Kjærås via Digitalmars-d-learn wrote: > On Friday, 17 April 2020 at 16:54:42 UTC, Adam D. Ruppe wrote: [...] > > So pragma(msg) is doing something really weird, the bug doesn't > > appear to be in Phobos per se, I think it is the compiler doing the > > wrong thing, it seems to me it works inside a function scope but not > > at module scope.. > > It's even more fascinating - the issue doesn't occur if > ParameterDefaults is defined in the same module that it's used in, and > it works if there's a type with the same name as the UDA. Reducing the > code as much as I can, I get this: [...] > The above code works, and prints "3". If you move ParameterDefaults to > a different module, something like this: [...] > Then you get an error message about 'undefined identifier S'. Add some > kind of S to bar, and you get an error message about S not being > readable at compile-time or things just work if it is readable. It > seems the UDA is being looked up in the wrong context. This is reminiscient of a bug I found recently, the ultimate cause of which is accessing a private symbol across modules, which is verboten, but it manifested itself in a way that appeared completely unrelated -- it turned an attribute-inferred function into @system where one expected @safe, which percolated up the call stack and ended up as a template mismatch error, which then shunted the template resolution into another overload which finally generated a totally unrelated compile error (very unhelpful!). I wonder if the ultimate cause of the above case is ultimately caused by the change to import semantics that hid private symbols from outside the module. Perhaps something, somewhere, is triggering an illegal access of a private symbol, which percolates up the call/instantiation stack and causing what appears to be a strange compiler discrepancy. Or perhaps it's a compiler bug. :-D T -- It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton
Re: Extracting user defined attributes on function parameters
On Friday, 17 April 2020 at 16:54:42 UTC, Adam D. Ruppe wrote:
void main() {
import std.stdio;
writeln(ParameterDefaults!f.stringof);
}
and it is fine.
Well, can't do. I need this purely at compile time, and
cross-module. That's for supporting UDAs and default parameter
values in openmethods. If you want a peek at what I am up to, see
here:
https://github.com/jll63/openmethods.d/blob/bolts-reflection/source/bolts/reflection/metafunction.d
Re: Extracting user defined attributes on function parameters
On Friday, 17 April 2020 at 16:54:42 UTC, Adam D. Ruppe wrote:
This part seems fine...
pragma(msg, ParameterDefaults!f.stringof);
It is this, specifically, that causes the problem. Replace it
with:
void main() {
import std.stdio;
writeln(ParameterDefaults!f.stringof);
}
and it is fine.
So pragma(msg) is doing something really weird, the bug doesn't
appear to be in Phobos per se, I think it is the compiler doing
the wrong thing, it seems to me it works inside a function
scope but not at module scope..
It's even more fascinating - the issue doesn't occur if
ParameterDefaults is defined in the same module that it's used
in, and it works if there's a type with the same name as the UDA.
Reducing the code as much as I can, I get this:
struct S {}
void f(@S int = 3);
pragma(msg, ParameterDefaults!f.stringof);
template ParameterDefaults(func...) {
import std.traits : FunctionTypeOf;
static if (is(FunctionTypeOf!(func[0]) PT == __parameters)) {
enum ParameterDefaults = (PT[0..1] args) @trusted {
return *&(args[0]);
}();
}
}
The above code works, and prints "3". If you move
ParameterDefaults to a different module, something like this:
-
import bar;
struct S {}
void f(@S int = 3);
pragma(msg, ParameterDefaults!f.stringof);
-
module bar;
template ParameterDefaults(func...) {
static if (is(typeof(func[0]) PT == __parameters)) {
enum ParameterDefaults = (PT[0..1] args) @trusted {
return *&(args[0]);
}();
}
}
-
Then you get an error message about 'undefined identifier S'. Add
some kind of S to bar, and you get an error message about S not
being readable at compile-time or things just work if it is
readable. It seems the UDA is being looked up in the wrong
context.
--
Simen
Integration tests
Hi, Thinking of trying to do the next project in D rather than Rust, but… Rust has built in unit testing on a module basis. D has this so no problem. Rust allows for integration tests in the tests directory of a project. These are automatically build and run along with all unit tests as part of "cargo test". Does D have any integrated support for integration tests in the way Rust does? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Extracting user defined attributes on function parameters
On Friday, 17 April 2020 at 16:40:15 UTC, Jean-Louis Leroy wrote:
Alas the presence of parameter UDAs breaks
std.traits.ParameterDefaults:
import std.traits;
struct attr;
void f(@attr int);
This part seems fine...
pragma(msg, ParameterDefaults!f.stringof);
It is this, specifically, that causes the problem. Replace it
with:
void main() {
import std.stdio;
writeln(ParameterDefaults!f.stringof);
}
and it is fine.
So pragma(msg) is doing something really weird, the bug doesn't
appear to be in Phobos per se, I think it is the compiler doing
the wrong thing, it seems to me it works inside a function scope
but not at module scope..
I'd like to understand why taking a slice of __parameters vs
fetching the first element matters. What is the (meta?) type of
__parameters[0..1]?
The first element alone becomes a type. The slice maintains the
magic data inside the compiler; it contains stuff the rest of the
language cannot express by itself except in parameter lists.
It is weird.
collapses into a string. Makes me think of wave functions in
quantum mechanics ;-)
well it is dependent on when the compiler observes it so lol
Re: Extracting user defined attributes on function parameters
Alas the presence of parameter UDAs breaks std.traits.ParameterDefaults: import std.traits; struct attr; void f(@attr int); pragma(msg, ParameterDefaults!f.stringof); Error: dmd -c bug.d bug.d(4): Error: undefined identifier `attr`, did you mean variable `ptr`? /home/jll/dlang/dmd-2.090.1/linux/bin64/../../src/phobos/std/traits.d(1526): Error: template instance `std.traits.ParameterDefaults!(f).Get!0LU` error instantiating /home/jll/dlang/dmd-2.090.1/linux/bin64/../../src/phobos/std/traits.d(1529): instantiated from here: `Impl!0LU` bug.d(6):instantiated from here: `ParameterDefaults!(f)` bug.d(6):while evaluating `pragma(msg, ParameterDefaults!(f).stringof)` I filed a bug report (20744). And examined the code of ParameterDefaults. I think I understand how it works, for the most part, but I haven't been able to find a fix yet. I'd like to understand why taking a slice of __parameters vs fetching the first element matters. What is the (meta?) type of __parameters[0..1]? I think I'd need to make a copy of it, minus the UDAs tucked at the beginning. But I haven't found a way of splitting it into smaller components. I tried using indexation and variadic template parameters, but it always collapses into a string. Makes me think of wave functions in quantum mechanics ;-)
Re: Checked!({short, ushort, byte, ubyte}, Throw): compilation fails
On Friday, 17 April 2020 at 08:59:19 UTC, kdevel wrote:
On Friday, 17 April 2020 at 04:29:06 UTC, Meta wrote:
Unlike C/C++, char is not a numeric type in D; It's a UTF-8
code point:
Thanks, it's a code /unit/. main reads now:
void main ()
{
bar!ubyte;
bar!byte;
bar!ushort;
bar!short;
bar!uint;
bar!int;
bar!ulong;
bar!long;
}
and dmd complains:
The problem is, short/short gives an int answer:
unittest {
import std.experimental.checkedint;
Checked!(short, Throw) a;
pragma(msg, typeof(a/a));
}
So, in your code you get this situation:
unittest {
import std.experimental.checkedint;
Checked!(int, Throw) a;
Checked!(short, Throw) b = a;
}
And assigning from an int to a short may discard data, so it's
statically disallowed by Checked. This is a deliberate design
choice, and the appropriate way to handle it is with a cast:
unittest {
import std.experimental.checkedint;
Checked!(int, Throw) a = 65535;
Checked!(short, Throw) b = cast(short)a;
}
The above code will throw when casting (before the assignment),
because 65535 can't fit in a short.
You also get a deprecation message, about an integral promotion
not being performed. I believe the result is correct and the
warning can be ignored.
--
Simen
Re: make dub use my version of dmd
On 4/17/20 4:37 AM, WebFreak001 wrote: On Thursday, 16 April 2020 at 19:56:44 UTC, Adam D. Ruppe wrote: For future reference, newer dubs (v 1.17 + i think) allow --compiler=dmd-version for example. You need to put the exe in your PATH and rename it yourself, but it recognizes *dmd-* (or *ldc2-* or *gdc-*) all the same so you can specifiy them. I was doing that in early versions of my android thing, i made a program "android-ldc" and then did "dub build --compiler=android-ldc" and it all worked. S o you can do that with versions too. Sure, it does all that. But if you have a broken symlink in the same directory as the dub executable it tries to use that first. Also you can use `dub --compiler=/path/to/dmd` (or ldc, or gdc) and it magically know the compiler type, though maybe it knows because of the filename. Yes, I think that is what was happening. I had a broken symlink in ~/bin/dmd, and it complained about not being able to get the version from it. I mistakenly thought it couldn't find a dmd in that directory, and it wasn't willing to use my path DMD. Then I tried the same dub binary on a different machine and it successfully found the dmd in my path. Which is when I realized something was different between the two installations. But one thing I DID learn, is that if you have your path set to one compiler's dmd, and specifically call another compiler's dub, it will use the dmd in that dub's directory rather than your path. So you do have to copy it elsewhere (or use the --compiler option). -Steve
Re: __init unresolved external when using C library structs converted with dstep
On 2020-04-17 09:06:44 +, Dominikus Dittes Scherkl said: On Friday, 17 April 2020 at 08:59:41 UTC, Robert M. Münch wrote: How would that look like? myStruct ms = void; // ??? Exactly. Cool... never saw this / thought about it... will remember it, hopefully. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: __init unresolved external when using C library structs converted with dstep
On Friday, 17 April 2020 at 08:59:41 UTC, Robert M. Münch wrote: How would that look like? myStruct ms = void; // ??? Exactly.
Re: __init unresolved external when using C library structs converted with dstep
On 2020-04-16 18:33:51 +, Basile B. said: On Tuesday, 14 April 2020 at 17:51:58 UTC, Robert M. Münch wrote: I use a C libary and created D imports with dstep. It translates the C structs to D structs. When I now use them, everything compiles fine but I get an unresolved external error: WindowsApp1.obj : error LNK2019: unresolved external symbol "myCstruct.__init" (_D7myCStruct6__initZ) referenced in function _Dmain Any idea what this is about and how to fix it? I'm wondering why D tries to find the __init function in the C library and not compile it from the import. One way to prevent the problem is to do void initialization each time you declare a variable of this type. How would that look like? myStruct ms = void; // ??? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Checked!({short, ushort, byte, ubyte}, Throw): compilation fails
On Friday, 17 April 2020 at 04:29:06 UTC, Meta wrote:
Unlike C/C++, char is not a numeric type in D; It's a UTF-8
code point:
Thanks, it's a code /unit/. main reads now:
void main ()
{
bar!ubyte;
bar!byte;
bar!ushort;
bar!short;
bar!uint;
bar!int;
bar!ulong;
bar!long;
}
and dmd complains:
[...]linux/bin64/../../src/phobos/std/experimental/checkedint.d(1410):
Deprecation: integral promotion not done for `~cast(ubyte)0u`, use
'-preview=intpromote' switch or `~cast(int)(cast(ubyte)0u)`
x.d(9): Error: template
`std.experimental.checkedint.Checked!(ubyte,
Throw).Checked.__ctor` cannot deduce function from argument types
`!()(Checked!(int, Throw))`, candidates are:
[...]linux/bin64/../../src/phobos/std/experimental/checkedint.d(331):
`__ctor(U)(U rhs)`
x.d(15): Error: template instance `x.foo!ubyte` error
instantiating
x.d(22):instantiated from here: `bar!ubyte`
[...]linux/bin64/../../src/phobos/std/experimental/checkedint.d(1410):
Deprecation: integral promotion not done for `~cast(byte)0`, use
'-preview=intpromote' switch or `~cast(int)(cast(byte)0)`
x.d(9): Error: template
`std.experimental.checkedint.Checked!(byte,
Throw).Checked.__ctor` cannot deduce function from argument types
`!()(Checked!(int, Throw))`, candidates are:
[...]linux/bin64/../../src/phobos/std/experimental/checkedint.d(331):
`__ctor(U)(U rhs)`
x.d(15): Error: template instance `x.foo!byte` error instantiating
x.d(23):instantiated from here: `bar!byte`
[...]linux/bin64/../../src/phobos/std/experimental/checkedint.d(1410):
Deprecation: integral promotion not done for `~cast(ushort)0u`, use
'-preview=intpromote' switch or `~cast(int)(cast(ushort)0u)`
x.d(9): Error: template
`std.experimental.checkedint.Checked!(ushort,
Throw).Checked.__ctor` cannot deduce function from argument types
`!()(Checked!(int, Throw))`, candidates are:
[...]linux/bin64/../../src/phobos/std/experimental/checkedint.d(331):
`__ctor(U)(U rhs)`
x.d(15): Error: template instance `x.foo!ushort` error
instantiating
x.d(24):instantiated from here: `bar!ushort`
[...]linux/bin64/../../src/phobos/std/experimental/checkedint.d(1410):
Deprecation: integral promotion not done for `~cast(short)0`, use
'-preview=intpromote' switch or `~cast(int)(cast(short)0)`
x.d(9): Error: template
`std.experimental.checkedint.Checked!(short,
Throw).Checked.__ctor` cannot deduce function from argument types
`!()(Checked!(int, Throw))`, candidates are:
[...]linux/bin64/../../src/phobos/std/experimental/checkedint.d(331):
`__ctor(U)(U rhs)`
x.d(15): Error: template instance `x.foo!short` error
instantiating
x.d(25):instantiated from here: `bar!short`
I tested some DMD versions down to 2.075 none of which compiled
successfully.
Re: mir: How to change iterator?
On Friday, 17 April 2020 at 08:40:36 UTC, WebFreak001 wrote: On Tuesday, 14 April 2020 at 20:24:05 UTC, jmh530 wrote: [...] Use std.algorithm:equal for range compare with approxEqual for your comparator: assert(equal!approxEqual(y, [2.5, 2.5].sliced(2))); simplified: assert(equal!approxEqual(y, [2.5, 2.5]));
Re: mir: How to change iterator?
On Tuesday, 14 April 2020 at 20:24:05 UTC, jmh530 wrote:
In the code below, I multiply some slice by 5 and then check
whether it equals another slice. This fails for mir's
approxEqual because the two are not the same types (yes, I know
that isClose in std.math works). I was trying to convert the y
variable below to have the same double* iterator as the term on
the right, but without much success. I tried std.conv.to and
the as, slice, and sliced functions in mir.
I figure I am missing something basic, but I can't quite figure
it out...
/+dub.sdl:
dependency "mir-algorithm" version="~>3.7.28"
+/
import mir.math.common: approxEqual;
import mir.ndslice.slice : sliced;
void main() {
auto x = [0.5, 0.5].sliced(2);
auto y = x * 5.0;
assert(approxEqual(y, [2.5, 2.5].sliced(2)));
}
Use std.algorithm:equal for range compare with approxEqual for
your comparator:
assert(equal!approxEqual(y, [2.5, 2.5].sliced(2)));
Re: make dub use my version of dmd
On Thursday, 16 April 2020 at 19:56:44 UTC, Adam D. Ruppe wrote: For future reference, newer dubs (v 1.17 + i think) allow --compiler=dmd-version for example. You need to put the exe in your PATH and rename it yourself, but it recognizes *dmd-* (or *ldc2-* or *gdc-*) all the same so you can specifiy them. I was doing that in early versions of my android thing, i made a program "android-ldc" and then did "dub build --compiler=android-ldc" and it all worked. S o you can do that with versions too. Also you can use `dub --compiler=/path/to/dmd` (or ldc, or gdc) and it magically know the compiler type, though maybe it knows because of the filename.
