Re: template instantiation problems
On Friday, 10 January 2020 at 18:31:59 UTC, ag0aep6g wrote: import m1 = foo.baz; import m2 = foo; alias p = __traits(parent, m1); pragma(msg, m1.stringof); /* "module baz", ok */ pragma(msg, m2.stringof); /* "module foo", ok */ pragma(msg, p.stringof); /* "package foo", ok */ enum e(alias thing) = thing.stringof; pragma(msg, e!m1); /* "module baz", ok */ pragma(msg, e!m2); /* "module foo", ok */ pragma(msg, e!p); /* "module foo", wat?? */ Thanks for your test case. https://github.com/dlang/dmd/pull/10724
Re: range algorithms on container class
On Thursday, 9 January 2020 at 10:26:07 UTC, Jonathan M Davis wrote: On Wednesday, January 8, 2020 10:56:20 PM MST rikki cattermole via Digitalmars-d-learn wrote: Slicing via the opSlice operator overload is a convention, not a requirement. It's not a requirement, but it's more than a convention. If you use the container with foreach, the compiler will call opSlice on the container to get a range. So, there's no need to implement opApply to iterate over a container with foreach. You could choose to implement a container with opApply and use a function other than opSlice for getting a range, but the compiler understands enough to try to slice the container for you automatically when using it with foreach. - Jonathan M Davis Implementing opApply allowed me to use foreach on the container. I would expect that returning a slice would not be logically possible for many container types. A slice cannot be a range either, otherwise you would need to call the array algorithm to assign a slice of an array to another array. So the compiler must be creating a forward iterating range to pass into the range algorithms in these cases. That foreach, and range algorithms can work on a native array but only foreach can work on custom container type looks like a gap in the language.
Re: Filling an associated array of associated arrays
On Tuesday, 14 January 2020 at 23:59:59 UTC, mipri wrote: On Tuesday, 14 January 2020 at 23:23:51 UTC, Jamie wrote: c.f. https://issues.dlang.org/show_bug.cgi?id=17607 I found that by searching the forums for your error. That has fixed my issue. I had searched the forums for relevant topics, but not the error itself. A lesson for me. Cheers
So, you want to be a programmer? Here is the way to go.
Hi everyone. I've received so many people asking me about how to learn programming, or complaining about how difficult it is, that I wrote a small text teaching the way to go for those who want to learn programming. I tried to write it in a funny and straight forward way. Here it is: https://themindofmurilomiranda.blogspot.com/2020/01/the-path-of-programmer.html
Re: Filling an associated array of associated arrays
On Tuesday, 14 January 2020 at 23:23:51 UTC, Jamie wrote:
I'm trying to initialise an associated array of associated
arrays with values, taking the same approach I would for an
associated array:
This works:
import std.stdio;
void main() {
string[string][string] table = ([
"info" : [
"equation" : "H2 + I2 <=> 2HI",
"type" : "elementary",
],
"frc" : [
"A" : "1.2e9",
"n" : "1.2e9",
"C" : "1.2e9",
],
]);
writeln(table);
}
c.f. https://issues.dlang.org/show_bug.cgi?id=17607
I found that by searching the forums for your error.
Filling an associated array of associated arrays
I'm trying to initialise an associated array of associated arrays with values, taking the same approach I would for an associated array: string[string][string] table = [ "info" : [ "equation" : "H2 + I2 <=> 2HI", "type" : "elementary", ], "frc" : [ "A" : "1.2e9", "n" : "1.2e9", "C" : "1.2e9", ], ]; But I'm getting the error `Not an associative array initializer'. Is there a way to do this in the fashion that I'm trying? I can declare it like string[string][string] table; table["info"]["equation"] = "H2 + I2 <=> 2HI"; table["info"]["type"] = "elementary"; But don't see why the first way wouldn't work.
Re: How to create meson.build with external libs?
On Tuesday, 14 January 2020 at 20:14:30 UTC, p.shkadzko wrote:
On Tuesday, 14 January 2020 at 15:15:09 UTC, Rasmus Thomsen
wrote:
On Tuesday, 14 January 2020 at 09:54:18 UTC, p.shkadzko wrote:
On Monday, 13 January 2020 at 21:15:51 UTC, p.shkadzko wrote:
On Monday, 13 January 2020 at 20:53:43 UTC, p.shkadzko wrote:
[...]
It's very odd to me that Manjaros pkg-config doesn't include
that pkg-config path by default and also doesn't include that
library path by default, every distro I've so far used did
that.
I added /usr/local/include/d/cblas/cblas to $PATH but that
didn't help :(
Can you show us your meson.build? You need to set
`dependencies:` properly to include all dependencies so ninja
includes the right dirs and links the required libraries. You
can look at other projects using D for that, e.g. I do it like
this:
https://github.com/Cogitri/corecollector/blob/master/source/corectl/meson.build
Here is my meson.build file
---
project('demo_proj', 'd',
version : '0.1',
default_options : ['warning_level=3']
)
mir_alg = dependency('mir-algorithm', method: 'pkg-config')
lubeck = dependency('lubeck', method: 'pkg-config')
required_deps = [mir_alg, lubeck]
ed = executable('demo_proj', 'app.d', dependencies:
required_deps, install : true)
As I mentioned earlier cblas.d is installed in
/usr/local/include/d/cblas/cblas/cblas.d
If I replace lubeck with mir-lapack (which I also installed into
/usr/local/lib), repeat "meson build && cd build && ninja" and
call ./demo_proj, I get this:
-
./demo_proj: error while loading shared libraries:
subprojects/mir-algorithm/libmir-algorithm.so.3.4.0:ject file: No
such file or directory
But libmir-algorithm.so.3.4.0 is installed in /usr/local/lib and
it is in $PATH :(
Re: How to create meson.build with external libs?
On Tuesday, 14 January 2020 at 15:15:09 UTC, Rasmus Thomsen wrote:
On Tuesday, 14 January 2020 at 09:54:18 UTC, p.shkadzko wrote:
On Monday, 13 January 2020 at 21:15:51 UTC, p.shkadzko wrote:
On Monday, 13 January 2020 at 20:53:43 UTC, p.shkadzko wrote:
On Monday, 13 January 2020 at 19:56:35 UTC, p.shkadzko wrote:
On Monday, 13 January 2020 at 17:14:29 UTC, p.shkadzko
wrote:
[...]
I had to set PKG_CONFIG_PATH to "/usr/local/lib/pkgconfig".
For some reason Manjaro distro doesn't have it set by
default. After setting the pkgconfig path, lubeck is
getting found and everything works.
It's very odd to me that Manjaros pkg-config doesn't include
that pkg-config path by default and also doesn't include that
library path by default, every distro I've so far used did that.
I added /usr/local/include/d/cblas/cblas to $PATH but that
didn't help :(
Can you show us your meson.build? You need to set
`dependencies:` properly to include all dependencies so ninja
includes the right dirs and links the required libraries. You
can look at other projects using D for that, e.g. I do it like
this:
https://github.com/Cogitri/corecollector/blob/master/source/corectl/meson.build
Here is my meson.build file
---
project('demo_proj', 'd',
version : '0.1',
default_options : ['warning_level=3']
)
mir_alg = dependency('mir-algorithm', method: 'pkg-config')
lubeck = dependency('lubeck', method: 'pkg-config')
required_deps = [mir_alg, lubeck]
ed = executable('demo_proj', 'app.d', dependencies:
required_deps, install : true)
As I mentioned earlier cblas.d is installed in
/usr/local/include/d/cblas/cblas/cblas.d
Re: How to create meson.build with external libs?
On Tuesday, 14 January 2020 at 11:26:30 UTC, Andre Pany wrote: On Tuesday, 14 January 2020 at 09:54:18 UTC, p.shkadzko wrote: [...] May I ask, whether you have tried to use Dub, or is s.th. blocking you from using Dub? Kind regards André I tested dub and it fetched and compiled mir.ndslice and lubeck without issues. Then somebody mentioned meson and that it gives you more control and speed over the build. I also saw that mir library uses meson so decided to give it a try.
Re: Reading a file of words line by line
On Tuesday, 14 January 2020 at 16:39:16 UTC, mark wrote:
I can't help feeling that the foreach loop's block is rather
more verbose than it could be?
WordSet words;
auto rx = ctRegex!(r"^[a-z]+", "i");
auto file = File(filename);
foreach (line; file.byLine) {
auto match = matchFirst(line, rx);
if (!match.empty()) {
auto word = match.hit().to!string; // I hope this assumes
UTF-8?
if (word.length == wordsize) {
words[word.toUpper] = 0;
}
}
}
return words;
}
One thing I picked up during Advent of Code last year was
std.file.slurp, which was great for reading 90% of the input
files from that contest. With that, I'd do this more like
int[string] words;
slurp!string("input.txt", "%s").each!(w => words[w] = 0);
Where "%s" is what slurp() expects to find on each line, and
'string' is the type it returns from that. With just a list of
words this isn't very interesting. Some of my uses from the
contest are:
auto input = slurp!(int, int, int)(args[1], "z=%d>")
.map!(p => Moon([p[0], p[1], p[2]])).array;
Tuple!(string, string)[] input =
slurp!(string, string)("input.txt", "%s)%s");
Of course if you want to validate the input as you're reading
it, you still have to do extra work, but it could be in a
.filter!
Re: Reading a file of words line by line
Should I have closed the file, i.e.,: auto file = File(filename); scope(exit) file.close(); // Add this?
Reading a file of words line by line
As part of learning D I want to read a file that contains one
word per line (plus optional junk after the word) and creates a
set of all the unique words of a particular length (uppercased).
D doesn't appear to have a set type so I'm faking using an
associative array whose values are always 0.
I can't help feeling that the foreach loop's block is rather more
verbose than it could be?
#!/usr/bin/env rdmd
import std.stdio;
immutable WORDFILE = "/usr/share/hunspell/en_GB.dic";
immutable WORDSIZE = 4; // Should be even
alias WordSet = int[string]; // key = word; value = 0
void main() {
import core.time;
auto start = MonoTime.currTime;
auto words = getWords(WORDFILE, WORDSIZE);
// TODO
writeln(words.length, " words");
writeln(MonoTime.currTime - start);
}
WordSet getWords(string filename, int wordsize) {
import std.conv;
import std.regex;
import std.uni;
WordSet words;
auto rx = ctRegex!(r"^[a-z]+", "i");
auto file = File(filename);
foreach (line; file.byLine) {
auto match = matchFirst(line, rx);
if (!match.empty()) {
auto word = match.hit().to!string; // I hope this assumes
UTF-8?
if (word.length == wordsize) {
words[word.toUpper] = 0;
}
}
}
return words;
}
PS I'm using ldc on Linux and think that rdmd is excellent. For
lots of small Python programs I have I'm wondering how many would
be faster using D and rdmd (which I think caches binaries). Also
I've now got Mike Parker's "Learning D" on order.
Re: Invalid memory operation during allocation with `new`
On 1/13/20 6:06 PM, Per Nordlöw wrote: On Monday, 13 January 2020 at 20:30:33 UTC, Adam D. Ruppe wrote: Reading symbols from pain... (gdb) break onInvalidMemoryOperationError Breakpoint 1 at 0x4614f8 (gdb) r Starting program: /home/me/test/pain [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Thanks a lot. Unfortunately that didn't tell me the cause of the problem but only the stack trace of the failing call to `new` which is not called inside a destructor. can you post the stack trace? -Steve
Re: How to create meson.build with external libs?
On Tuesday, 14 January 2020 at 09:54:18 UTC, p.shkadzko wrote: On Monday, 13 January 2020 at 21:15:51 UTC, p.shkadzko wrote: On Monday, 13 January 2020 at 20:53:43 UTC, p.shkadzko wrote: On Monday, 13 January 2020 at 19:56:35 UTC, p.shkadzko wrote: On Monday, 13 January 2020 at 17:14:29 UTC, p.shkadzko wrote: [...] I had to set PKG_CONFIG_PATH to "/usr/local/lib/pkgconfig". For some reason Manjaro distro doesn't have it set by default. After setting the pkgconfig path, lubeck is getting found and everything works. It's very odd to me that Manjaros pkg-config doesn't include that pkg-config path by default and also doesn't include that library path by default, every distro I've so far used did that. I added /usr/local/include/d/cblas/cblas to $PATH but that didn't help :( Can you show us your meson.build? You need to set `dependencies:` properly to include all dependencies so ninja includes the right dirs and links the required libraries. You can look at other projects using D for that, e.g. I do it like this: https://github.com/Cogitri/corecollector/blob/master/source/corectl/meson.build
Re: Is it safe in D to cast pointers to structures like this?
On Tuesday, 14 January 2020 at 12:05:01 UTC, John Burton wrote: After years of C++ I have become paranoid about any casting of pointers being undefined behavior due to aliasing so want to see if :- FWIW, this is safe and portable in C++20: https://en.cppreference.com/w/cpp/numeric/bit_cast 1) This is safe to do in D. 2) If not is there anything I can do to make it safe. 3) If not, what is the best approach? What is legal in C, should in theory be legal in D unless the documentation states otherwise as the goal for D is to make porting C code to D easy. Hence, type punning through union should be ok. I am not sure what the various D compilers do with aliasing, but allowing type punning through pointers can inhibit some optimizations.
Is it safe in D to cast pointers to structures like this?
After years of C++ I have become paranoid about any casting of
pointers being undefined behavior due to aliasing so want to see
if :-
1) This is safe to do in D.
2) If not is there anything I can do to make it safe.
3) If not, what is the best approach?
I have a void* pointing to a block of allocated memory. In that
memory I have a header struct at the start, and some of the
members of that struct are offsets into the memory of other
structs.
Can I do this? It appears to compile and "work" in dmd 64 bit but
I need to make sure it's valid and reliable code. (This is a
minimal example without any error checking etc)
import std.stdio;
//
// getMemory is just an example to make this compile...
//
void* getMemory()
{
static byte[100] someData;
// Something fills in the data here
}
struct Header
{
ulong data1;
ulong data2;
}
struct Data1
{
int a;
}
struct Data2
{
int b;
float[10] d;
}
void main()
{
void* memory = getMemory();
auto header = cast(Header*)memory;
auto data1 = cast(Data1*)(memory + header.data1);
auto data2 = cast(Data2*)(memory + header.data2);
writeln(data1.a, " ", data2.b);
}
Re: How to create meson.build with external libs?
On Tuesday, 14 January 2020 at 09:54:18 UTC, p.shkadzko wrote: [...] May I ask, whether you have tried to use Dub, or is s.th. blocking you from using Dub? Kind regards André
Blog Post #0098: More HeaderBar Stuff
Wanna know how to rearrange the contents of your HeaderBar? Or add extra widgets to that same HeaderBar? Then come on over to the GtkD Coding Blog and have a read: https://gtkdcoding.com/2020/01/14/0098-headerbar-more.html
Re: How to create meson.build with external libs?
On Monday, 13 January 2020 at 21:15:51 UTC, p.shkadzko wrote: On Monday, 13 January 2020 at 20:53:43 UTC, p.shkadzko wrote: On Monday, 13 January 2020 at 19:56:35 UTC, p.shkadzko wrote: On Monday, 13 January 2020 at 17:14:29 UTC, p.shkadzko wrote: [...] I had to set PKG_CONFIG_PATH to "/usr/local/lib/pkgconfig". For some reason Manjaro distro doesn't have it set by default. After setting the pkgconfig path, lubeck is getting found and everything works. After I ran "meson build" I got the following output: --- The Meson build system Version: 0.52.1 Source dir: /home/tastyminerals/dev/test_proj Build dir: /home/tastyminerals/dev/test_proj/build Build type: native build Project name: demo_proj Project version: 0.1 D compiler for the host machine: ldc2 (llvm 1.18.0 "LDC - the LLVM D compiler (1.18.0):") D linker for the host machine: GNU ld.gold 2.33.1 Host machine cpu family: x86_64 Host machine cpu: x86_64 Found pkg-config: /usr/bin/pkg-config (1.6.3) Run-time dependency mir-algorithm found: YES 3.4.0 Run-time dependency lubeck found: YES 1.0.0 Build targets in project: 1 Found ninja-1.9.0 at /usr/bin/ninja I then cd to build/ dir and run "ninja" [2/2] Linking target test_proj.tart@exe/app.d.o'. But when I try to run compiled app.d file as demo_run, I get: ./demo_run: error while loading shared libraries: libmir-algorithm.so: cannot open shared object file: No such file or directory I thought that if meson builds and finds the external libs successfully and ninja links everything, all should be fine. I don't understand. Why the compiled file cannot find the external library? $LD_LIBRARY_PATH was not set to "/usr/local/lib" where libmir-algorithm.so is located. I had to set it explicitly and recompile the project but then I get another error message: ./demo_proj: error while loading shared libraries: subprojects/mir-algorithm/libmir-algorithm.so.3.4.0: cannot open shared object file: No such file or directory (ಠ_ಠ) My test app.d didn't have any imports for mir.ndslice and lubeck. After I imported them, ninja threw the following error. --- [1/2] Compiling D object 'demo_proj@exe/app.d.o'. FAILED: demo_proj@exe/app.d.o ldc2 -I=demo_proj@exe -I=. -I=.. -I/usr/local/include/d/lubeck -I/usr/local/include/d/mir-algorithm -I/usr/local/include/d/mir-core -I/usr/local/include/d/mir-blas -I/usr/local/include/d/mir-lapack -I/usr/local/include/d/mir-random -enable-color -wi -dw -g -d-debug -of='demo_proj@exe/app.d.o' -c ../app.d /usr/local/include/d/lubeck/lubeck.d(8): Error: module cblas is in file 'cblas.d' which cannot be read import path[0] = demo_proj@exe import path[1] = . import path[2] = .. import path[3] = /usr/local/include/d/lubeck import path[4] = /usr/local/include/d/mir-algorithm import path[5] = /usr/local/include/d/mir-core import path[6] = /usr/local/include/d/mir-blas import path[7] = /usr/local/include/d/mir-lapack import path[8] = /usr/local/include/d/mir-random import path[9] = /usr/include/dlang/ldc ninja: build stopped: subcommand failed. cblas.d is located in /usr/local/include/d/cblas/cblas/cblas.d I added /usr/local/include/d/cblas/cblas to $PATH but that didn't help :(
