Re: Formal Review of std.range.ndslice
On Sunday, 13 December 2015 at 22:32:43 UTC, Ilya Yaroshenko
wrote:
Since it's a segfault in the compiler, should I put it on
Bugzilla too?
Yes
1. Please note in Bugzilla report that program code is
incorrect (see example of correct above).
2. More reduced code can be used for report:
void main() {
Slice!(3, double*) force = new double[60].sliced(3, 4, 5);
// Wrong foreach params. dmd failed with exit code -11.
foreach(p, e; force)
{
}
}
Reported as https://issues.dlang.org/show_bug.cgi?id=15441 .
Will look into my other non-bug problems when I can, have to run
now...
Re: Formal Review of std.range.ndslice
On Sunday, 13 December 2015 at 15:59:19 UTC, Ilya Yaroshenko
wrote:
Could you please post reduced code example that caused dmd to
segfault?
Took dustmite about 6 hours to reduce, and then I went at it
manually for a bit, so this is the smallest I could get it:
import std.experimental.ndslice;
int main() {
Field force;
foreach(p, e; force) e;
}
struct Field {
alias arr this;
Slice!(3, double*) arr;
}
Compiled with dmd 2.069.1 via dub build:
{
"name": "dlbc",
"sourcePaths": ["src"],
"dependencies": {
"dip80-ndslice": "~>0.8.3",
},
}
dip80-ndslice 0.8.3: target for configuration "library" is up to
date.
dlbc ~master: building configuration "application"...
Segmentation fault
dmd failed with exit code 139.
Since it's a segfault in the compiler, should I put it on
Bugzilla too?
2D way: &slice[0, 0] or &(slice.front.front());
ND way: &(slice.byElement.front())
Note: Comparing with unstandard there is no guarantee that the
first element in a ndarray is the first element in memory.
`reversed` and `allReversed` should not be used to preserve
strides positive.
Hm, I assumed the underlying array would be a single block of
data and then a bunch of pointers would be used to keep track of
any slices. I'll try to figure out how to give the data to C then
(for MPI and HDF5, to be exact).
Re: Formal Review of std.range.ndslice
On Friday, 11 December 2015 at 22:56:15 UTC, Ilya wrote:
On Friday, 11 December 2015 at 19:31:14 UTC, Stefan Frijters
wrote:
[...]
Slice!(N, T*) arr;
[...]
// compute length
// more flexible construtors would be added after
// allocatrs support for ndslice
size_t len = 1;
foreach(l; lengths)
len *= l;
arr = new T[len].sliced(lengths);
[...]
std.experimental.ndslice.selection: indexSlice, byElement;
foreach(p; someField.shape.indexSlice.byElement) {
someField[p] = foo(someOtherField[bar(p)]);
...
}
[...]
See also updated docs:
http://dtest.thecybershadow.net/artifact/website-13cbdcf17d84fc31328c3f517a56bea783c418d6-d9c63e815273f0906309088334e7dfb1/web/phobos-prerelease/std_experimental_ndslice.html
Ilya
Thank you for your help. I'm trying to convert my code again at
the moment, but ran into a new problem: I need to pass a pointer
to the data into a C function. It seems that the .ptr property is
not available, and using & caused dmd to segfault (currently
running a Dustmite reduction for that). Is there any clean way to
get a pointer to the underlying data?
Re: Formal Review of std.range.ndslice
Today I've made an abortive attempt at replacing my code's [1]
dependence on unstd.multidimarray [2] with ndslice.
I'm guessing it's just me being stupid, but could anyone supply
with some hints on how to do the conversion with a minimum of
fuss?
Basically I have an N-dimensional array (N is known at compile
time) of type T wrapped in a struct to carry some additional
information.
I then address it using size_t[N] fixed-size arrays, and loop
over it a lot with foreach, which also uses size_t[N] as index.
So it looks something like this:
struct Field(T, uint N) {
alias arr this;
MultidimArray!(T, N) arr; // is there any way to supply the
correct type here with ndslice? I cannot use auto, right?
this (in size_t[N] lengths) {
arr = multidimArray!T(lengths);
}
}
and then things like
foreach(immutable p, ref pop; someField) {
pop = foo(someOtherField[bar(p)]);
...
}
where p is of type size_t[N].
I tried using ndarray in conjunction with the
std.experimental.allocator, but I don't particularly care about
memory management;
these are large arrays that are allocated once and kept around
for the duration of the program.
Any help would be appreciated.
[1] https://github.com/SFrijters/DLBC
[2] https://bitbucket.org/SFrijters/unstandard
Re: Request for testers: GDC-5.1 Release Candidate branched
On Sunday, 19 April 2015 at 07:13:16 UTC, Iain Buclaw wrote: Hi, GCC-5.1 has hit RC, and so it's all rush again to get bug fixes in quick before the window closes. Packages are up on Debian: https://packages.debian.org/experimental/gdc-5 Latest changes however are on github: https://github.com/D-Programming-GDC/GDC/tree/gdc-5 Updates/Fixes from gdc-4.9 include: - Front-end updated from 2.065.0 to 2.066.1 - Added "goto" support for GDC Extended Inline Assembler - Added -fbounds-check=safe compiler option - Added Runtime support for EMUTLS targets - Added new gcc.attributes "section", "weak" and "alias" - Partially fixed thunk support for externally referenced methods (only variadic methods now don't work) - Improved Closure/Frame chaining, all tests now passing in the testsuite[1] - Improved NRVO support to take advantage of Return Slot Optimisation (RSO), all tests now passing in the testsuite[2] Last feature I am working on getting in is runtime exception chaining support. If anyone has any grand ideas, they'd be more than welcome. [1]: https://github.com/D-Programming-GDC/GDC/commit/84e77850a4e9184526d9b571fb8bdfda4dc103a1#diff-cbd05be6883e1f976bc2eee00b1e6bcaL2442 [2]: https://github.com/D-Programming-GDC/GDC/commit/b9bbf568c20d806bc8570c8cefe41bf57c729bb1#diff-2a4fd18a3f136c982c89e12064e0b6baL551 Regards Iain. I don't have too much to report (which is a good thing in this case): I did a fresh install from source, following [1], and I didn't encounter any problems. I was already compiling my code with an earlier GDC version that used the 2.066.1 front-end (which is required for my code) because it gives me a 2.5x speed increase for my code execution (in my Linux VM at least), so I love the new release already :-D Cheers, Stefan [1] http://wiki.dlang.org/GDC/Installation/Generic
Re: Dutch D Meetup
On Monday, 23 February 2015 at 22:20:50 UTC, Arjan wrote: On Monday, 23 February 2015 at 21:07:04 UTC, George Sapkin wrote: Seems like there are some local meetups starting across the globe, but no Dutch one so far. Are there any D users from the Netherlands that would want to meetup and share their D stories? Cheers. I would surely come. Though have not really anything to share yet. I might be interested in something like this, but I also don't have any exciting stories to share to be honest...
Re: Zero-length static array spec
On Sunday, 1 February 2015 at 14:54:37 UTC, ketmar wrote: On Sun, 01 Feb 2015 14:42:31 +, Stefan Frijters wrote: It does not seem to say whether a zero-length array should have a valid address or not. i believe that zero-length array should not be `null`, as it's "infinitely small", yet not "non-existent". at least this is what my logic tells me. Fwiw, I would also like this to be the case, as to not have to handle any special cases when using int[N] templates and such.
Zero-length static array spec
So recently I ran into this discrepancy between the behaviour of
dmd (and gdc) and ldc2:
void test(int[] data)
in { assert(data, "data must be non-null."); }
body { }
void main() {
import std.stdio;
int[1] data1;
writeln(data1); // [0]
test(data1); // Passes
assert(data1.ptr !is null);
int[0] data0;
writeln(data0); // []
test(data0); // Passes with dmd and gdc, fails with ldc2
(2.066.1)
assert(data0.ptr !is null); // Passes with dmd and gdc, fails
with ldc2
}
I reported this as an issue at
https://github.com/ldc-developers/ldc/issues/831 and was asked to
check for a more definite answer. So, in light of recent
developments of trying to tighten up the D spec, does anyone have
any insight what the correct behaviour should be, and can it be
locked down in the spec?
Currently the D spec says [1]:
---
Static Arrays
int[3] s;
These are analogous to C arrays. Static arrays are distinguished
by having a length fixed at compile time.
The total size of a static array cannot exceed 16Mb. A dynamic
array should be used instead for such large arrays.
A static array with a dimension of 0 is allowed, but no space is
allocated for it. It's useful as the last member of a variable
length struct, or as the degenerate case of a template expansion.
Static arrays are value types. Unlike in C and D version 1,
static arrays are passed to functions by value. Static arrays can
also be returned by functions.
---
It does not seem to say whether a zero-length array should have a
valid address or not.
Thoughts?
[1] http://dlang.org/arrays.html
Re: Simplified signatures in generated documentation
The simplified signatures would be show for the main signatures, i.e. the ones with a light blue background, and the full signatures would be added at the end of the documentation for each symbol. I like it. Some of my code also features a lot of free functions with template constraints and it does get a bit much. Related remark on the other side of things (more text!): documentation is currently lacking UDA annotations [1] and I would love it if that were to be added at some point. [1] https://issues.dlang.org/show_bug.cgi?id=12995
Re: Finally full multidimensional arrays support in D
On Tuesday, 10 June 2014 at 19:04:18 UTC, Stefan Frijters wrote:
I've been using the multidimensional arrays for a while now,
but recently I've run into a problem w.r.t. optimization:
import std.stdio;
import unstd.multidimarray;
void main() {
MultidimArray!(double, 3) arr;
arr = multidimArray!double([1,2,42]);
writeln(arr.lengths);
}
If I compile with 'dmd multidimtest.d unstd/multidimarray.d', I
get [1,2,42], as expected, but when I compile in release mode
'dmd multidimtest.d unstd/multidimarray.d -release' I get
[0,0,0]. Any ideas what might cause this?
I've looked into this and it seems there is required code inside
a contract 'in', which is omitted with -release.
I've gone ahead and opened a pull request to fix this:
https://bitbucket.org/denis-sh/unstandard/pull-request/2/bugfixes-for-multidimarrayd
Stefan
Re: Finally full multidimensional arrays support in D
I've been using the multidimensional arrays for a while now, but
recently I've run into a problem w.r.t. optimization:
import std.stdio;
import unstd.multidimarray;
void main() {
MultidimArray!(double, 3) arr;
arr = multidimArray!double([1,2,42]);
writeln(arr.lengths);
}
If I compile with 'dmd multidimtest.d unstd/multidimarray.d', I
get [1,2,42], as expected, but when I compile in release mode
'dmd multidimtest.d unstd/multidimarray.d -release' I get
[0,0,0]. Any ideas what might cause this?
Also, when I compile with -w (which I normally prefer) I get a
list of errors of the type
unstd/multidimarray.d(101): Warning: calling
unstd.multidimarray.MultidimArray!(double,
3LU).MultidimArray.this without side effects discards return
value of type inout(MultidimArray!(double, 3LU)), prepend a
cast(void) if intentional
I've acted on these errors in the version I use for my HPC test
code, and I have not noticed any deleterious effects; would you
accept a pull request to fix these?
Kind regards,
Stefan Frijters
Re: Finally full multidimensional arrays support in D
On Monday, 17 March 2014 at 17:39:41 UTC, Denis Shelomovskij wrote: Multidimensional arrays indexing and slicing syntax is finally added [1] (thanks to Kenji Hara). So it was a good cause to update my multidimensional arrays library implementation and add support for the new syntax. So here we are: [2]. Also should we add it to the standard library? [1] https://github.com/D-Programming-Language/dmd/pull/443 [2] http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html First of all, thank you very much for making such nice additions to D available for general use. I finally got around to giving this a spin. I'm using it for a proof-of-context HPC simuation code written in D (currently mostly experimenting with D's features), and as such I'm interfacing with the C MPI library to communicate between processes. The basis of the simulation is a 3D lattice, so I was eagerly awaiting a nice solution in D. So far I've run into two things while using your library. The first is that I need to provide void pointers to the data to the MPI functions, so I currently hacked your code to make the _data storage array publicly accessible and that seems to work. To give an idea, I currently have code like this (just a snippet): arr = multidimArray!T(nxH, nyH, nzH); // [...] fill the array with data // Prepare a buffer to receive a slice from another process. rbuffer = multidimArray!T(haloSize, nyH, nzH); // Prepare a buffer to send a slice to another process. sbuffer = arr[$-2*haloSize-1..$ - haloSize-1, 0..$, 0..$].dup; // Here I now use the pointer of the storage arrays to send the buffer around. MPI_Sendrecv(sbuffer._data.ptr, nyH * nzH, MPI_INT, M.nbx[1], 0, rbuffer._data.ptr, nyH * nzH, mpiType, M.nbx[0], 0, M.comm, &mpiStatus); // Put the buffer in the correct spot in the main array. arr[0..haloSize, 0..$, 0..$] = rbuffer; Am I missing a nicer way to accomplish this? I like the compactness of the code (compared to what I'm currently used to with our F90 simulation code). Secondly, the property that returns the dimensions of the array is called 'dimentions' (with a t), this should be fixed. Regards, Stefan
