Re: ubyte + ubyte = int
On Thursday, 27 October 2022 at 01:57:15 UTC, Salih Dincer wrote:
You should help the compiler with return type:
I love D, enjoys it when I code...:)
I played a little on the code, and the following is possible and
beautiful:
```d
// If you type auto instead of ubyte as return type, the return
will be char.
ubyte toHexDigit(bool capital = false)(ubyte decimal)
{
static if(capital) enum start = 'A';
else enum start = 'a';
if(decimal < 10)
return cast(char)(decimal + ubyte('0'));
if(decimal < 16)
return cast(char)(decimal - ubyte(10)
+ ubyte(start));
return '\xFF';
}
unittest
{
assert(is(typeof(toHexDigit(9)) == ubyte));
assert(toHexDigit(9) == 57); // '9'
assert(toHexDigit(10) == 97); // 'a'
assert(toHexDigit!true(10) == 65); // 'A'
}
```
SDB@79
Re: ubyte + ubyte = int
On Wednesday, 26 October 2022 at 21:10:54 UTC, 0xEAB wrote:
I know this is advanced stuff, but the compiler *could* even
prove that the calculation(s) won’t go beyond `ubyte.max`.
```d
//... => char?
return (decimal - ubyte(10) + ubyte('A'));
return '\xFF';
}
```
You should help the compiler with return type:
```d
char toHexDigit(ubyte decimal) pure nothrow @nogc
{
if (decimal < 10)
return cast(char) (decimal + ubyte('0'));
if (decimal < 16)
return cast(char) (decimal - ubyte(10) + ubyte('A'));
return '\xFF';
}
void main()
{
import std.stdio : writeln;
foreach(ubyte n; 0..256)
{
const c = n.toHexDigit();
if(n < 16)
{
c.writeln(": ", n);
} else assert(c == char.init);
}
} /*
0: 0
1: 1
2: 2
3: 3
4: 4
5: 5
6: 6
7: 7
8: 8
9: 9
A: 10
B: 11
C: 12
D: 13
E: 14
F: 15
Process finished.
*/
```
SDB@79
Re: Importing modules under DUB on Windows
On Wednesday, 26 October 2022 at 22:51:53 UTC, DLearner wrote:
On Wednesday, 26 October 2022 at 18:53:58 UTC, Hipreme wrote:
On Wednesday, 26 October 2022 at 18:37:00 UTC, DLearner wrote:
On Wednesday, 26 October 2022 at 16:58:08 UTC, H. S. Teoh
wrote:
On Wed, Oct 26, 2022 at 04:20:01PM +, DLearner via
Digitalmars-d-learn wrote:
[...]
Maybe try instead:
"importPaths": [ "C:\\Users\\..." ]
since the error message indicates that it expects an array,
not a string.
T
Thanks for this.
Following your suggestion, seems that DUB found the module
(as it got through to the linking step without complaint),
but then the linker failed to resolve the function name.
However, when I moved the module to the project `'source'`
directory (and took out the `importPaths` JSON entry),
everything worked.
But I don't really want to do this - the module is my
collection of utilities, used in a variety of projects, so
doesn't really belong within one specific project.
Best regards
The linker failed to resolve because it didn't include the
symbols you imported.
Think of import a way to the compiler resolve the compilation.
Think of source a way to both the compiler and the linker to
resolve compilation and linking.
If you give only the import path, you will need a library.
What you actually want is to put your new importPath to the
JSON array `sourcePaths`
Added `"sourcePaths": [ "C\\Users\\..." ]`
Unfortunately failed with
`core.exception.AssertError@source\dub\internal\vibecompat\inet\path.d(222): Trying to append absolute path.`
I tried to construct a relative path to the module directory
from the project directory, that didn't work either.
Okay. So this error is very strange, the other thing I can give
you advice is:
If your other thing is another dub project, you can add it as a
dependency by putting in your dub.json
```json
"dependencies" : {
"your_project_name" : {"path" : "your/path/here"}
}
```
AFAIK, there is no problem in putting an absolute path
dependency, in fact, I'm using things from another drive letter.
Re: Importing modules under DUB on Windows
On Wednesday, 26 October 2022 at 18:53:58 UTC, Hipreme wrote: On Wednesday, 26 October 2022 at 18:37:00 UTC, DLearner wrote: On Wednesday, 26 October 2022 at 16:58:08 UTC, H. S. Teoh wrote: On Wed, Oct 26, 2022 at 04:20:01PM +, DLearner via Digitalmars-d-learn wrote: [...] Maybe try instead: "importPaths": [ "C:\\Users\\..." ] since the error message indicates that it expects an array, not a string. T Thanks for this. Following your suggestion, seems that DUB found the module (as it got through to the linking step without complaint), but then the linker failed to resolve the function name. However, when I moved the module to the project `'source'` directory (and took out the `importPaths` JSON entry), everything worked. But I don't really want to do this - the module is my collection of utilities, used in a variety of projects, so doesn't really belong within one specific project. Best regards The linker failed to resolve because it didn't include the symbols you imported. Think of import a way to the compiler resolve the compilation. Think of source a way to both the compiler and the linker to resolve compilation and linking. If you give only the import path, you will need a library. What you actually want is to put your new importPath to the JSON array `sourcePaths` Added `"sourcePaths": [ "C\\Users\\..." ]` Unfortunately failed with `core.exception.AssertError@source\dub\internal\vibecompat\inet\path.d(222): Trying to append absolute path.` I tried to construct a relative path to the module directory from the project directory, that didn't work either.
Re: ubyte + ubyte = int
On 10/26/22 14:19, Ali Çehreli wrote:
>https://dlang.org/spec/type.html#integer-promotions
Reading "Value Range Propagation" further down that link, I learned that
e.g. masking 'decimal' with 0xf makes the code compile:
return ((decimal & 0xf) + ubyte('0'));
return ((decimal & 0xf) - ubyte(10) + ubyte('A'));
Ali
Re: ubyte + ubyte = int
On 10/26/22 14:10, 0xEAB wrote: > I guess, this fancy behavior is inherited from C. Yes. It is called integer promotions: https://dlang.org/spec/type.html#integer-promotions (The next section is related as well.) > I know this is advanced stuff, but the compiler *could* even prove that > the calculation(s) won’t go beyond `ubyte.max`. Apparently it does not go that far but there is Value Range Propagation: https://www.digitalmars.com/articles/b62.html That article links to this forum post: https://www.digitalmars.com/d/archives/digitalmars/D/Value_Preservation_and_Polysemy_80224.html#N80293 Ali
ubyte + ubyte = int
```d
@safe:
void main()
{
import std.stdio : writeln;
writeln(ubyte(4).toHexDigit);
}
ubyte toHexDigit(ubyte decimal) pure nothrow @nogc
{
if (decimal < 10)
return (decimal + ubyte('0'));
if (decimal < 16)
return (decimal - ubyte(10) + ubyte('A'));
return '\xFF';
}
```
```
onlineapp.d(12): Error: cannot implicitly convert expression
`cast(int)decimal + 48` of type `int` to `ubyte`
onlineapp.d(15): Error: cannot implicitly convert expression
`cast(int)decimal - 10 + 65` of type `int` to `ubyte`
```
I guess, this fancy behavior is inherited from C.
I know this is advanced stuff, but the compiler *could* even
prove that the calculation(s) won’t go beyond `ubyte.max`.
Re: library to solve the system of linear equations
The workaround is to compile without --release mode, but using the "O3" ldc flag instead does the job - the binary is fast, yet the try - catch block executes properly. On Wednesday, 26 October 2022 at 20:13:37 UTC, Yura wrote: OK, got the problem solved by adding the following lines in my dub.sdl file: lflags "-lopenblas" "-lgfortran" dflags "--static" However, one problem still remains. Apparently, when compiled with dub --release mode I got segfault in my try - catch block. Any solution to this? On Wednesday, 26 October 2022 at 12:24:47 UTC, Yura wrote: I am now trying to compile the code statically using the dub manager via the following command line: dub build --force --build=release --compiler=path_to_ldc2/ldc2 and having these lines in my dub.sdl file: dependency "mir" version="~>3.2.3" dependency "lubeck" version="~>1.5.1" dflags "-static" For some reasons it does not work: (.text+0x2f2): undefined reference to `_gfortran_concat_string' /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libopenblas.a(dormlq.o):(.text+0x784): more undefined references to `_gfortran_concat_string' follow collect2: error: ld returned 1 exit status Error: /usr/bin/cc failed with status: 1 Any idea of what I am doing wrong? Should I also specify something in my dub.sdl via lflags? Thank you in advance! On Tuesday, 18 October 2022 at 17:01:53 UTC, Yura wrote: Yes, did the same and it worked. The amazing thing is that the system solver turned out to be natively parallel and runs smoothly! On Tuesday, 18 October 2022 at 15:22:02 UTC, mw wrote: On Tuesday, 18 October 2022 at 09:56:09 UTC, Siarhei Siamashka wrote: On Monday, 17 October 2022 at 20:05:24 UTC, mw wrote: On Monday, 17 October 2022 at 19:54:12 UTC, Yura wrote: it is possible to install the most recent ldc and gdc compilers on Ubuntu 18.04? Yes, I used LDC on the same system. What's the recommended way to have up to date D compilers in Ubuntu? I just download the official prebuilt binary from the ldc github repo.
Re: library to solve the system of linear equations
OK, got the problem solved by adding the following lines in my dub.sdl file: lflags "-lopenblas" "-lgfortran" dflags "--static" However, one problem still remains. Apparently, when compiled with dub --release mode I got segfault in my try - catch block. Any solution to this? On Wednesday, 26 October 2022 at 12:24:47 UTC, Yura wrote: I am now trying to compile the code statically using the dub manager via the following command line: dub build --force --build=release --compiler=path_to_ldc2/ldc2 and having these lines in my dub.sdl file: dependency "mir" version="~>3.2.3" dependency "lubeck" version="~>1.5.1" dflags "-static" For some reasons it does not work: (.text+0x2f2): undefined reference to `_gfortran_concat_string' /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libopenblas.a(dormlq.o):(.text+0x784): more undefined references to `_gfortran_concat_string' follow collect2: error: ld returned 1 exit status Error: /usr/bin/cc failed with status: 1 Any idea of what I am doing wrong? Should I also specify something in my dub.sdl via lflags? Thank you in advance! On Tuesday, 18 October 2022 at 17:01:53 UTC, Yura wrote: Yes, did the same and it worked. The amazing thing is that the system solver turned out to be natively parallel and runs smoothly! On Tuesday, 18 October 2022 at 15:22:02 UTC, mw wrote: On Tuesday, 18 October 2022 at 09:56:09 UTC, Siarhei Siamashka wrote: On Monday, 17 October 2022 at 20:05:24 UTC, mw wrote: On Monday, 17 October 2022 at 19:54:12 UTC, Yura wrote: it is possible to install the most recent ldc and gdc compilers on Ubuntu 18.04? Yes, I used LDC on the same system. What's the recommended way to have up to date D compilers in Ubuntu? I just download the official prebuilt binary from the ldc github repo.
Re: Importing modules under DUB on Windows
On Wednesday, 26 October 2022 at 18:37:00 UTC, DLearner wrote: On Wednesday, 26 October 2022 at 16:58:08 UTC, H. S. Teoh wrote: On Wed, Oct 26, 2022 at 04:20:01PM +, DLearner via Digitalmars-d-learn wrote: Hi Never used DUB before. Wanted to use a function stored in a module outside the main source. Main source has `import ;` Put a line into the JSON: `"importPaths": "C:\\Users\\..."` pointing to the directory holding the module. `dub run` failed with `Expected JSON array, got string`. Maybe try instead: "importPaths": [ "C:\\Users\\..." ] since the error message indicates that it expects an array, not a string. T Thanks for this. Following your suggestion, seems that DUB found the module (as it got through to the linking step without complaint), but then the linker failed to resolve the function name. However, when I moved the module to the project `'source'` directory (and took out the `importPaths` JSON entry), everything worked. But I don't really want to do this - the module is my collection of utilities, used in a variety of projects, so doesn't really belong within one specific project. Best regards The linker failed to resolve because it didn't include the symbols you imported. Think of import a way to the compiler resolve the compilation. Think of source a way to both the compiler and the linker to resolve compilation and linking. If you give only the import path, you will need a library. What you actually want is to put your new importPath to the JSON array `sourcePaths`
Re: Importing modules under DUB on Windows
On Wednesday, 26 October 2022 at 16:58:08 UTC, H. S. Teoh wrote: On Wed, Oct 26, 2022 at 04:20:01PM +, DLearner via Digitalmars-d-learn wrote: Hi Never used DUB before. Wanted to use a function stored in a module outside the main source. Main source has `import ;` Put a line into the JSON: `"importPaths": "C:\\Users\\..."` pointing to the directory holding the module. `dub run` failed with `Expected JSON array, got string`. Maybe try instead: "importPaths": [ "C:\\Users\\..." ] since the error message indicates that it expects an array, not a string. T Thanks for this. Following your suggestion, seems that DUB found the module (as it got through to the linking step without complaint), but then the linker failed to resolve the function name. However, when I moved the module to the project `'source'` directory (and took out the `importPaths` JSON entry), everything worked. But I don't really want to do this - the module is my collection of utilities, used in a variety of projects, so doesn't really belong within one specific project. Best regards
Re: Importing modules under DUB on Windows
On Wed, Oct 26, 2022 at 04:20:01PM +, DLearner via Digitalmars-d-learn wrote: > Hi > > Never used DUB before. > Wanted to use a function stored in a module outside the main source. > > Main source has `import ;` > > Put a line into the JSON: `"importPaths": "C:\\Users\\..."` pointing > to the directory holding the module. > > `dub run` failed with `Expected JSON array, got string`. Maybe try instead: "importPaths": [ "C:\\Users\\..." ] since the error message indicates that it expects an array, not a string. T -- It said to install Windows 2000 or better, so I installed Linux instead.
Re: Hipreme's #2 Tip of the day - Reducing .di files dependency
On Tuesday, 25 October 2022 at 12:29:50 UTC, Andrey Zherikov wrote: On Sunday, 23 October 2022 at 20:12:46 UTC, Hipreme wrote: This will greatly reduce the number of import and dependencies you need if you ever need to distribute a library. Could you elaborate more on the benefit? Does it reduce compilation time for dependency? If so then how much? The main problem of that is when you actually get an import the user does not need to know. This is especially useful for dub projects, which if you import an internal dependency of the project, think of a renderer. I have the HipremeRenderer which uses OpenGL and DirectX-D. What if I show that I'm importing directx-d which is so huge? What if I'm just showing my .di files and the library file? The user would not be able to use the library without getting directx-d. And even worse, if I already guarantee that my renderer is self contained, why would I make someone need to import another library just to use mine? This is how it helps, the compilation times depends on how much code your dependency have, if it was std.regex, it could save you 2 to 3 seconds.
Re: Is "auto t=T();" not the same as "T t;"?
Looks like explicitly initialized variable in this case allocates array literal. Uninitialized variable is initialized with init pattern. This may be correct as uninitialized variable isn't guaranteed to hold a value most useful for you, it's only guaranteed to hold a defined value.
Re: library to solve the system of linear equations
I am now trying to compile the code statically using the dub manager via the following command line: dub build --force --build=release --compiler=path_to_ldc2/ldc2 and having these lines in my dub.sdl file: dependency "mir" version="~>3.2.3" dependency "lubeck" version="~>1.5.1" dflags "-static" For some reasons it does not work: (.text+0x2f2): undefined reference to `_gfortran_concat_string' /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libopenblas.a(dormlq.o):(.text+0x784): more undefined references to `_gfortran_concat_string' follow collect2: error: ld returned 1 exit status Error: /usr/bin/cc failed with status: 1 Any idea of what I am doing wrong? Should I also specify something in my dub.sdl via lflags? Thank you in advance! On Tuesday, 18 October 2022 at 17:01:53 UTC, Yura wrote: Yes, did the same and it worked. The amazing thing is that the system solver turned out to be natively parallel and runs smoothly! On Tuesday, 18 October 2022 at 15:22:02 UTC, mw wrote: On Tuesday, 18 October 2022 at 09:56:09 UTC, Siarhei Siamashka wrote: On Monday, 17 October 2022 at 20:05:24 UTC, mw wrote: On Monday, 17 October 2022 at 19:54:12 UTC, Yura wrote: it is possible to install the most recent ldc and gdc compilers on Ubuntu 18.04? Yes, I used LDC on the same system. What's the recommended way to have up to date D compilers in Ubuntu? I just download the official prebuilt binary from the ldc github repo.
Re: Is "auto t=T();" not the same as "T t;"?
On Wednesday, 26 October 2022 at 04:40:17 UTC, Salih Dincer wrote: On Tuesday, 25 October 2022 at 13:51:30 UTC, Andrey Zherikov wrote: Does the second piece of code shows a bug or my expectation is not correct (and why if so)? As a result, if this is a bug, Andrey has the right to report it. Bug tracking system doesn't work with gmail emails so I'm not able to report.
