Re: mir: How to change iterator?

2020-04-18 Thread 9il via Digitalmars-d-learn

On Sunday, 19 April 2020 at 02:56:30 UTC, 9il wrote:

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)));


or mir.algorithm.iteration: each that can work with nd-ranges.


EDIT:

 or mir.algorithm.iteration: equal that can work with nd-ranges.



Re: mir: How to change iterator?

2020-04-18 Thread 9il via Digitalmars-d-learn

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)));


or mir.algorithm.iteration: each that can work with nd-ranges.


Re: Checked!({short, ushort, byte, ubyte}, Throw): compilation fails

2020-04-18 Thread tsbockman via Digitalmars-d-learn

On Saturday, 18 April 2020 at 15:20:42 UTC, kdevel wrote:

On Saturday, 18 April 2020 at 08:39:52 UTC, tsbockman wrote:

https://code.dlang.org/packages/checkedint


Hm.

$ dub test
Generating test runner configuration 'checkedint-test-library' 
for 'library' (library).
Excluding package.d file from test due to 
https://issues.dlang.org/show_bug.cgi?id=11847
Performing "unittest" build using [...]/linux/bin64/dmd for 
x86_64.
checkedint ~master: building configuration 
"checkedint-test-library"...

Linking...
Running ./checkedint-test-library
source/checkedint/package.d(672): [unittest] unittest failure
core.exception.AssertError@source/checkedint/package.d(672): 
unittest failure


This should be fixed now.

(It actually appears there was a bug in two of my unit tests 
*and* in *old* versions of the compiler, where the compiler bug 
allowed my bad unit tests to wrongly pass. Weird...)


Re: Checked!({short, ushort, byte, ubyte}, Throw): compilation fails

2020-04-18 Thread tsbockman via Digitalmars-d-learn

On Saturday, 18 April 2020 at 15:20:42 UTC, kdevel wrote:

On Saturday, 18 April 2020 at 08:39:52 UTC, tsbockman wrote:

https://code.dlang.org/packages/checkedint


Hm.

$ dub test
Generating test runner configuration 'checkedint-test-library' 
for 'library' (library).
Excluding package.d file from test due to 
https://issues.dlang.org/show_bug.cgi?id=11847
Performing "unittest" build using [...]/linux/bin64/dmd for 
x86_64.
checkedint ~master: building configuration 
"checkedint-test-library"...

Linking...
Running ./checkedint-test-library
source/checkedint/package.d(672): [unittest] unittest failure
core.exception.AssertError@source/checkedint/package.d(672): 
unittest failure


I think that's a compiler bug, not a bug in my checkedint 
package, as the unit tests pass on earlier D compiler versions 
(including GDC 2.075). Regardless, I'll try to track it down and 
either fix it or file a compiler bug report for it today.


Re: How convert String to Hex?

2020-04-18 Thread Simen Kjærås via Digitalmars-d-learn

On Saturday, 18 April 2020 at 15:47:38 UTC, Marcone wrote:

How convert String to Hex?

Example:

string text = "Hello World"; // Converted to Hex = 
48656c6c6f20576f726c64


import std.format : format;

string hex = format("%(%2x%)", "Hello World");

import std.stdio : writeln;
writeln(hex);

A bit of explanation: %(  %) is a range formatting specifier, and 
basically means "format each element of the range with the format 
specifier between these two symbols". In other words, it's the 
equivalent of "Hello World".map!(c => format("%2x", c)).joiner.


--
  Simen


How convert String to Hex?

2020-04-18 Thread Marcone via Digitalmars-d-learn

How convert String to Hex?

Example:

string text = "Hello World"; // Converted to Hex = 
48656c6c6f20576f726c64


Re: Checked!({short, ushort, byte, ubyte}, Throw): compilation fails

2020-04-18 Thread kdevel via Digitalmars-d-learn

On Saturday, 18 April 2020 at 08:39:52 UTC, tsbockman wrote:

[...]

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?


The deprecation message is a consequence of a (very annoying) 
language change made after std.experimental.checkedint was 
written. It's not really a bug, although someone should 
probably fix it anyway.


The message suggests using -preview=intpromote. But it produces 
another error:


```minusminus.d
void foo ()
{
   import std.experimental.checkedint;
   Checked!(short) b;
   --b;
}
```

$ dmd -preview=intpromote minusminus.d
[...]/linux/bin64/../../src/phobos/std/experimental/checkedint.d(727): Error: 
cannot implicitly convert expression onOverflow(this.payload) of type int to 
short
minusminus.d(5): Error: template instance 
std.experimental.checkedint.Checked!(short, 
Abort).Checked.opUnary!"--" error instantiating


Anyway, you might want to give my checkedint package on DUB a 
try, instead:


https://code.dlang.org/packages/checkedint


Hm.

$ dub test
Generating test runner configuration 'checkedint-test-library' 
for 'library' (library).
Excluding package.d file from test due to 
https://issues.dlang.org/show_bug.cgi?id=11847
Performing "unittest" build using [...]/linux/bin64/dmd for 
x86_64.
checkedint ~master: building configuration 
"checkedint-test-library"...

Linking...
Running ./checkedint-test-library
source/checkedint/package.d(672): [unittest] unittest failure
core.exception.AssertError@source/checkedint/package.d(672): 
unittest failure


??:? _d_unittestp [0x4c07b5]
source/checkedint/package.d:672 void 
checkedint.__unittest_L654_C5() [0x49959c]

??:? void checkedint.__modtest() [0x4bc4b2]
??:? int 
core.runtime.runModuleUnitTests().__foreachbody2(object.ModuleInfo*) [0x4da1ec]
??:? int object.ModuleInfo.opApply(scope int 
delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) [0x4bedb7]
??:? int rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref 
rt.sections_elf_shared.DSO) [0x4c581f]
??:? int rt.sections_elf_shared.DSO.opApply(scope int 
delegate(ref rt.sections_elf_shared.DSO)) [0x4c5d8c]
??:? int rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*))) [0x4c57ad]
??:? int object.ModuleInfo.opApply(scope int 
delegate(object.ModuleInfo*)) [0x4bed89]

??:? runModuleUnitTests [0x4da029]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int 
function(char[][])*).runAll() [0x4c226c]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) [0x4c21f8]

??:? _d_run_main2 [0x4c2161]
??:? _d_run_main [0x4c1f1d]
[...]/linux/bin64/../../src/druntime/import/core/internal/entrypoint.d:34 main 
[0x48c241]
??:? __libc_start_main [0x7700e585]
1/3 unittests FAILED
Program exited with code 1




Re: Extracting user defined attributes on function parameters

2020-04-18 Thread Simen Kjærås via Digitalmars-d-learn

On Saturday, 18 April 2020 at 09:19:48 UTC, Simen Kjærås wrote:
On Wednesday, Friday, 17 Apr 2020 17:45:47 UTC, H. S. Teoh 
wrote:


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.


Not unlikely. Importing the module defining S in the module 
defining ParameterDefaults does indeed make things compile. 
Hiding S by making it private makes the error return.


It's not about private. Or even if it is, there's other issues. 
Proof:


struct A {
struct S {}
void f(@S int = 3);
pragma(msg, Issue20744!f);
}

template Issue20744(func...) {
static if (is(typeof(func[0]) PT == __parameters)) {
alias Issue20744 = (PT args) {};
}
}

--
  Simen


Re: Extracting user defined attributes on function parameters

2020-04-18 Thread Simen Kjærås via Digitalmars-d-learn

On Wednesday, Friday, 17 Apr 2020 17:45:47 UTC, H. S. Teoh wrote:

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.


Not unlikely. Importing the module defining S in the module 
defining ParameterDefaults does indeed make things compile. 
Hiding S by making it private makes the error return.


(for whatever reason your message isn't visible in the web 
interface)


--
  Simen


Re: Checked!({short, ushort, byte, ubyte}, Throw): compilation fails

2020-04-18 Thread tsbockman via Digitalmars-d-learn

On Friday, 17 April 2020 at 21:25:34 UTC, kdevel wrote:

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 author of std.experimental.checkedint hasn't (yet) written 
the opCast overload required to make that code work. It's just a 
feature missing from the code for that specific module in the 
standard library, not a language issue.


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?


The deprecation message is a consequence of a (very annoying) 
language change made after std.experimental.checkedint was 
written. It's not really a bug, although someone should probably 
fix it anyway.


Anyway, you might want to give my checkedint package on DUB a 
try, instead:


https://code.dlang.org/packages/checkedint

(It's the original candidate for std.experimental.checkedint. 
Alexandrescu didn't like it, so he rejected it and wrote his own. 
But, I still think mine has a better API, especially if you use 
the SmartInt types.)


Re: Checked!({short, ushort, byte, ubyte}, Throw): compilation fails

2020-04-18 Thread tsbockman via Digitalmars-d-learn

On Friday, 17 April 2020 at 21:25:34 UTC, kdevel wrote:

On Friday, 17 April 2020 at 12:59:20 UTC, Simen Kjærås wrote:
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 author of std.experimental.checkedint hasn't implemented the 
overload of opCast required to make your code work. It's just a 
missing feature.


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?


The warning is caused by some (very annoying, but intentional) 
changes made to the compiler after std.experimental.checkedint 
was written. That module needs to be updated accordingly, but no 
one has done it yet.


Anyway, you might want to take a look at my checkedint package on 
Dub:


https://code.dlang.org/packages/checkedint

In my opinion, the API is better - especially if you use 
SmartInt. (I submitted it for inclusion in the standard library 
originally, but Alexandrescu did not agree with my approach and 
so wrote his own version, which became 
std.experimental.checkedint.)


Re: Working with cmd

2020-04-18 Thread user1234 via Digitalmars-d-learn

On Friday, 17 April 2020 at 21:38:23 UTC, Quantium wrote:

Are there any libs which can be used to access cmd commands?


You can pipe cmd.exe:

---
import std.process : pipeProcess, ProcessPipes;
ProcessPipes pp = pipeProcess(["cmd.exe"]);
pp.stdin.writeln("echo foobar");
pp.stdin.close;
assert(pp.stdout.readln() == "foobar\n");
---

there are other ways depending on what you really want to do.