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 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
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: [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
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: Measuring test coverage
On Sunday, 9 August 2015 at 20:24:22 UTC, Alexei Bykov wrote: D has builtin support for coverage analysis but it produces only .lst files. This is a bit inconvenient. Is there any tool which can create something like an html report from .lst files? For now I'm using OpenCppCoverage which is not the best tool and works only on Windows but at least it produces html reports which can be customized (sort of). If your code is hosted at Github or similar, https://github.com/ColdenCullen/doveralls allows you to use coveralls.io for D code. Not made by me, but I've been using it for a while now and it works very well for me.
std.parallelism and multidimensional arrays
I have a code which does a lot of work on 2D/3D arrays, for which
I use the 2.066 multidimensional slicing syntax through a fork of
the Unstandard package [1].
Many times the order of operations doesn't matter and I thought I
would give the parallelism module a try to try and get some easy
speedups (I also use MPI, but that has some additional overhead).
The way I currently have my foreach loops set up, p is a
size_t[2], the payload of the array v is double[9] and the array
is indexed directly with a size_t[2] array and all works fine:
foreach(immutable p, ref v, arr) { double[9] stuff; arr[p] =
stuff; }
If I naively try
foreach(immutable p, ref v, parallel(arr)) { ... }
I first get errors of the type Error: foreach: cannot make v
ref. I do not understand where that particular problem comes
from, but I can possibly live without the ref, so I went for
foreach(immutable p, v, parallel(arr)) { ... }
Which gets me Error: no [] operator overload for type
(complicated templated type of some wrapper struct I have for
arr). I'm guessing it doesn't like that there is no such thing
as a simple one-dimensional slicing operation for a
multidimensional array?
Should I define an opSlice function that takes the usual two
size_t arguments for the upper and lower bounds and doesn't
require a dimension template argument and somehow map this to my
underlying two-dimensional array? Will it need an opIndex
function that takes only takes a single size_t as well?
Or is this just taking the simple parallel(...) too far and
should I try to put something together myself using lower-level
constructs?
Any hints would be appreciated!
[1] http://code.dlang.org/packages/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: Position of unittest attributes
On Sunday, 22 March 2015 at 09:42:44 UTC, Rikki Cattermole wrote:
On 22/03/2015 10:29 p.m., Stefan Frijters wrote:
So I was trying to add some attributes to unittests in my
code, but
apparently they are only allowed *before* the unittest
keyword, which I
think makes it much harder to quickly see the unittests when
scrolling
through the code:
void foo() @safe pure nothrow @nogc { } // Ok - I normally use
this
style, and Phobos does too, I think?
@safe pure nothrow @nogc void bar() { } // Ok
@safe pure nothrow @nogc unittest { foo(); } // Ok
unittest @safe pure nothrow @nogc { bar(); } // Nope
I looked through the D grammar and it does seem to disallow
this, so
it's not a bug as such, but is there a particular reason to
not allow it?
Post attributes to e.g. functions are a relatively new standard
in D. It'll simply be nobody has brought it up as of yet.
File it into the issue tracker.
Thank you.
While filing in the summary field in Bugzilla it actually showed
me an issue already exists
https://issues.dlang.org/show_bug.cgi?id=10925 , so I just bumped
it a bit.
Position of unittest attributes
So I was trying to add some attributes to unittests in my code,
but apparently they are only allowed *before* the unittest
keyword, which I think makes it much harder to quickly see the
unittests when scrolling through the code:
void foo() @safe pure nothrow @nogc { } // Ok - I normally use
this style, and Phobos does too, I think?
@safe pure nothrow @nogc void bar() { } // Ok
@safe pure nothrow @nogc unittest { foo(); } // Ok
unittest @safe pure nothrow @nogc { bar(); } // Nope
I looked through the D grammar and it does seem to disallow this,
so it's not a bug as such, but is there a particular reason to
not allow it?
Strange alias behaviour in template arguments
So this is a strange thing I ran into while trying to streamline
some templates in my code, where fixed-length arrays are passed
as runtime arguments. I started out by trying variant fun2(),
which disappointingly didn't work. fun3() then did its job but I
was suspicious and tried fun4() and fun(5), which also worked but
shouldn't. Is this a bug or am I doing something bad?
struct Connectivity(uint _d, uint _q) {
enum d = _d; // Number of dimensions
enum q = _q;
}
alias d2q9 = Connectivity!(2,9);
// Stores fixed-size array of base type T, and the length of the
array is determined by the connectivity.
struct Field(T, alias c) {
alias conn = c;
T[conn.d] payload;
this(in T[conn.d] stuff) {
payload = stuff;
}
}
// Ok
void fun(T)(T field) {
pragma(msg, T);
pragma(msg, T.conn);
pragma(msg, T.conn.d);
pragma(msg, T.conn.q);
}
// cannot deduce function from argument types
void fun2(T)(T field, double[T.conn.d] foo) {
pragma(msg, T);
pragma(msg, T.conn);
pragma(msg, T.conn.d);
pragma(msg, T.conn.q);
field.payload = foo;
}
// Ok!
void fun3(T, alias d = T.conn.d)(T field, double[d] foo) {
pragma(msg, T);
pragma(msg, T.conn);
pragma(msg, T.conn.d);
pragma(msg, T.conn.q);
pragma(msg, typeof(foo)); // 2, okay
field.payload = foo;
}
// Huh?
void fun4(T, alias d = T.conn.q)(T field, double[d] foo) {
pragma(msg, T);
pragma(msg, T.conn);
pragma(msg, T.conn.d);
pragma(msg, T.conn.q);
pragma(msg, typeof(foo)); // expect 9, get 2
field.payload = foo;
}
// Huh?
void fun5(T, alias d = T.conn)(T field, double[d] foo) {
pragma(msg, T);
pragma(msg, T.conn);
pragma(msg, T.conn.d);
pragma(msg, T.conn.q);
pragma(msg, typeof(foo)); // don't know what to expect, still
get 2
field.payload = foo;
}
void main() {
double[d2q9.d] foo;
auto f = Field!(double, d2q9)(foo);
f.fun(); // Sure, this works
// f.fun2(foo); // Won't work without additional alias
f.fun3(foo); // Works, so are we happy?
f.fun4(foo); // No! This isn't supposed to work...
f.fun5(foo); // Nor this...
}
Any thoughts?
Re: Strange alias behaviour in template arguments
On Tuesday, 3 March 2015 at 14:40:45 UTC, anonymous wrote:
On Tuesday, 3 March 2015 at 13:42:09 UTC, Stefan Frijters wrote:
So this is a strange thing I ran into while trying to
streamline some templates in my code, where fixed-length
arrays are passed as runtime arguments. I started out by
trying variant fun2(), which disappointingly didn't work.
fun3() then did its job but I was suspicious and tried fun4()
and fun(5), which also worked but shouldn't. Is this a bug or
am I doing something bad?
struct Connectivity(uint _d, uint _q) {
enum d = _d; // Number of dimensions
enum q = _q;
}
alias d2q9 = Connectivity!(2,9);
// Stores fixed-size array of base type T, and the length of
the array is determined by the connectivity.
struct Field(T, alias c) {
alias conn = c;
T[conn.d] payload;
this(in T[conn.d] stuff) {
payload = stuff;
}
}
// Ok
void fun(T)(T field) {
pragma(msg, T);
pragma(msg, T.conn);
pragma(msg, T.conn.d);
pragma(msg, T.conn.q);
}
// cannot deduce function from argument types
void fun2(T)(T field, double[T.conn.d] foo) {
pragma(msg, T);
pragma(msg, T.conn);
pragma(msg, T.conn.d);
pragma(msg, T.conn.q);
field.payload = foo;
}
// Ok!
void fun3(T, alias d = T.conn.d)(T field, double[d] foo) {
pragma(msg, T);
pragma(msg, T.conn);
pragma(msg, T.conn.d);
pragma(msg, T.conn.q);
pragma(msg, typeof(foo)); // 2, okay
field.payload = foo;
}
// Huh?
void fun4(T, alias d = T.conn.q)(T field, double[d] foo) {
pragma(msg, T);
pragma(msg, T.conn);
pragma(msg, T.conn.d);
pragma(msg, T.conn.q);
pragma(msg, typeof(foo)); // expect 9, get 2
field.payload = foo;
}
// Huh?
void fun5(T, alias d = T.conn)(T field, double[d] foo) {
pragma(msg, T);
pragma(msg, T.conn);
pragma(msg, T.conn.d);
pragma(msg, T.conn.q);
pragma(msg, typeof(foo)); // don't know what to expect, still
get 2
field.payload = foo;
}
void main() {
double[d2q9.d] foo;
auto f = Field!(double, d2q9)(foo);
f.fun(); // Sure, this works
// f.fun2(foo); // Won't work without additional alias
f.fun3(foo); // Works, so are we happy?
f.fun4(foo); // No! This isn't supposed to work...
f.fun5(foo); // Nor this...
}
Any thoughts?
I don't know if there's a reason why fun2 doesn't work. I don't
see one.
fun4 and fun5 work correctly. They are the same as fun3, just
with other default values for d. Those default values are not
used, because d is inferred from the argument to be 2. If you
pass a double[3], d is inferred to be 3 (and the compiler
complains on `field.payload = foo`).
You can use a static assert or a template constraint to work
around fun2 not working:
void fun6(T, size_t d)(T field, double[d] foo)
{
static assert(d == T.conn.d);
...
}
void fun7(T, size_t d)(T field, double[d] foo) if(d == T.conn.d)
{
...
}
Ah, yes, I was misinterpreting the alias. fun7() would work for
me, although it's a shame fun2() doesn't...
Cheers.
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...
Code coverage during CTFE
Recently I've hooked my code up to coveralls.io using the convenient doveralls[1]. At first, I just did a dub test command before sending the data to coveralls, but my simulation code also has runnable tests in addition to unittests, which reaches many more lines. Today I've added an option to my testing script to merge the .lst files from various runs, basically adding up the number of times each line is hit. This seems to work just fine. However, my code also heavily uses string mixins in a couple of places, and I use functions that return the relevant strings to generate them. These functions are never called at runtime, and as such are shown with the nasty red bars for no coverage. Is it possible to get a -cov dump for code run at compile time? [1] https://github.com/ColdenCullen/doveralls
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: 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.
Dub subPackage buildType and output file name
Currently I'm using dub for the first time and I've run into two problems so far. 1) I have defined buildTypes in dub.json, as well as subPackages. However, I want to always build all subPackages in release mode, regardless of the --build option I'm using to build the main program. I'm not clear if it's possible to do this, and if so, how to specify this. 2) I would like the file name of my final executable to depend on my chosen --build and --config options (i.e. myexecutable-build-config). Is this possible to do? Kind regards, Stefan
Re: multidimensional array
On Sunday, 28 September 2014 at 04:24:25 UTC, Joel wrote:
I'm trying to make a multidimensional array. I feel I've tried
every thing. Is there a good guide explaining it?
struct Spot { bool dot; }
spots = new Spot[][](800,600);
assert(spots[800-1][600-1].dot, Out of bounds);
You could also take a look at unstd.multidimarray (not my work,
but I'm using it extensively at the moment)[1].
[1]
http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html
Foreach/opApply with @nogc
Should this be possible? I admit to not being fully clear on the
way delegates are handled, but maybe someone can shed some light?
As an example I use a snippet Ali uses to demonstrate opApply:
struct NumberRange {
int begin;
int end;
int opApply(int delegate(ref int) @nogc operations) @nogc const
{
int result = 0;
for (int number = begin; number != end; ++number) {
result = operations(number);
if (result) {
break;
}
}
return result;
}
}
void main() {
import std.stdio;
foreach (element; NumberRange(3, 7)) { // line 21
write(element, ' ');
}
}
When I compile this with 2.066.0 I get
opapply.d(21): Error: function opapply.NumberRange.opApply (int
delegate(ref int) @nogc operations) const is not callable using
argument types (int delegate(ref int __applyArg0) @system)
It doesn't actually complain about anything gc, just about the
signature, so I was wondering if there is some restriction inside
the foreach implementation that can be lifted? Thanks in advance
for any hints!
Re: Foreach/opApply with @nogc
On Sunday, 24 August 2014 at 14:34:03 UTC, bearophile wrote: ketmar: but i tend not to fill enhancement requests without corresponding patches, I agree that having a patch ready is much better. But people like me file hundreds of ERs without too much damage done, and many of them get eventually implemented. If you find a D limitation, then putting this information in Bugzilla is better than letting this get forgotten. Bye, bearophile I would also prefer to submit a patch but I do not have the skills to do it at the moment, so I filed an enhancement request: https://issues.dlang.org/show_bug.cgi?id=13370 .
Re: Foreach/opApply with @nogc
On Sunday, 24 August 2014 at 18:55:09 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sun, 24 Aug 2014 11:45:14 -0700
Ali Çehreli via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
Yeah, the only reason why the original code does not work is
the
write() expression in the foreach body.
hm. really. i forgot what is delegate body for opApply. sure,
here we
can't use @nogc delegate. my fault.
Apologies for the misunderstanding. Before I close my enhancement
request I do have a followup question: is it possible somehow to
have both a @nogc and a normal opApply function available? My
code would like to have @nogc in as many places as possible, but
there will be places where I cannot make the foreach body @nogc
(I think; maybe some more Phobos functions can be annotated as
well and the problem would go away).
So I basically want something like this:
void bar() @nogc { }
void foreachBar() @nogc {
foreach (element; NumberRange(3, 7)) { bar(); }
}
void foo() { }
void foreachFoo() {
foreach (element; NumberRange(3, 7)) { foo(); }
}
void main() {
foreachBar();
foreachFoo();
}
Obviously if I have one opApply function one of the two functions
complains
opapply.d(36): Error: @nogc function 'opapply.foreachBar' cannot
call non-@nogc function 'opapply.NumberRange.opApply'
or
opapply.d(44): Error: function opapply.NumberRange.opApply (int
delegate(ref int) @nogc operations) const is not callable using
argument types (int delegate(ref int __applyArg0) @system)
If I add a second opApply function (one with @nogc, the other
without) the compiler cannot distinguish between the two:
opapply.d(36): Error: NumberRange(3, 7).opApply matches more than
one declaration:
opapply.d(5): const @nogc int(int delegate(ref int) @nogc
operations)
and:
opapply.d(18): const int(int delegate(ref int) operations)
opapply.d(36): Error: cannot uniquely infer foreach argument types
opapply.d(44): Error: NumberRange(3, 7).opApply matches more than
one declaration:
opapply.d(5): const @nogc int(int delegate(ref int) @nogc
operations)
and:
opapply.d(18): const int(int delegate(ref int) operations)
opapply.d(44): Error: cannot uniquely infer foreach argument types
Is this maybe something that could be used as an enhancement
request? Or I guess what I want is basically an 'inout' kind of
thing for @nogc...
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: multidimensional indexing/slicing docs?
On Wednesday, 6 August 2014 at 08:48:25 UTC, John Colvin wrote: Is there anywhere that describes what Kenji (it was Kenji wasn't it?) recently implemented for this? Not what you asked for, but maybe useful nonetheless: Denis Shelomovskij has written a multidimensional array implementation using the new syntax[1]. I've been using it in my code for a while now and it's been working great so far. [1] http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html
Re: DDoc and private members / mixins / UDAs
On Thursday, 26 June 2014 at 02:33:43 UTC, Mathias LANG wrote:
On Wednesday, 25 June 2014 at 18:49:27 UTC, Stefan Frijters
wrote:
Let me preface this by admitting that I'm not sure I'm using
the DDoc functionality properly at all, so let me know if my
questions are bogus.
Is it possible to:
- Add private members to documentation?
- Have DDoc do its thing after mixins have been handled?
- Access UDAs?
To expand on the last point: in my code I currently use UDAs
to annotate variables that can be set in an input file; at
compile time I use __traits to find all of them and create a
parser etc. for them. I would really like to be able to create
a minimal documentation, which only includes all such
UDA-annotated variables from all modules, so it can be used as
a short manual for the end user, rather than being developer
documentation. I was thinking of using a LaTeX template and
using the absence or presence of the UDA to somehow insert a
macro that is either just blank or actually adds the
documentation.
Any tips to achieve this in a different fashion are also
appreciated.
Kind regards,
Stefan Frijters
1) You might be interested by ddox [1] which provides more
functionality and a nicer output than DDoc (actually, the
phobos docs are being replacd by it).
As you can see in the example, you can filter what goes in and
what doesn't, as well as the minimum protection level (so you
can chose to put private in it).
Note that if you have a dub-based project, you can just run
dub --build=ddox to get it working.
2) Yes for regular mixin, no for template mixins. Example:
mixin strToSym!(moduleName!moduleName); // Template mixin
mixin(int a = 42;); // regular mixin
Will output (using dmd -Xfdocs.json module.d):
{
name : strToSym!(\std.traits\),
kind : mixin,
line : 62
},
{
name : a,
kind : variable,
protection : private,
file : CppWrapper.d-mixin-63,
line : 63,
deco : i,
init : 42
},
3) Nope. Again, example:
@(ThisIsAFunction)
void foo() {}
Ouputs in the docs.json:
{
name : foo,
kind : function,
protection : private,
file : CppWrapper.d,
line : 66,
deco : FZv,
endline : 66
},
Hope this helps !
[1]: https://github.com/rejectedsoftware/ddox
Thank you! Some comments:
1) I will check it out. It looks like it may be a bit too
HTML-centric for my taste though.
2) Here, I meant if there is a way to have the comment included
as well. It doesn't seem like this is the case (if there are no
hidden switches I don't know about):
/// Comment
int a;
/// Ditto
mixin(int b;);
mixin(///Ditto\nint c;);
{
kind : module,
file : testdoc2.d,
members : [
{
name : a,
kind : variable,
comment : Comment\n,
line : 2,
char : 5,
deco : i
},
{
name : b,
kind : variable,
file : testdoc2.d-mixin-4,
line : 4,
char : 5,
deco : i
},
{
name : c,
kind : variable,
file : testdoc2.d-mixin-5,
line : 6,
char : 5,
deco : i
}
]
},
3) That's a shame. I guess I can work around it by doing a dirty
grep beforehand and using that information to filter the json...
Related question: I found a pull request to add
__traits(documentation, ...)[1] which would also allow me to
solve my problem as a workaround, does anyone know if this is
still moving forward?
[1]: https://github.com/D-Programming-Language/dmd/pull/3531
DDoc and private members / mixins / UDAs
Let me preface this by admitting that I'm not sure I'm using the DDoc functionality properly at all, so let me know if my questions are bogus. Is it possible to: - Add private members to documentation? - Have DDoc do its thing after mixins have been handled? - Access UDAs? To expand on the last point: in my code I currently use UDAs to annotate variables that can be set in an input file; at compile time I use __traits to find all of them and create a parser etc. for them. I would really like to be able to create a minimal documentation, which only includes all such UDA-annotated variables from all modules, so it can be used as a short manual for the end user, rather than being developer documentation. I was thinking of using a LaTeX template and using the absence or presence of the UDA to somehow insert a macro that is either just blank or actually adds the documentation. Any tips to achieve this in a different fashion are also appreciated. Kind regards, Stefan Frijters
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
Scalar + array operations
When working on my current project (writing a numerical
simulation code) I ran into the following issue when trying to
multiply a vector (represented by a fixed-length array) by a
scalar:
import std.stdio;
void main() {
int ifoo = 2;
int[3] ibar = 1;
double dfoo = 2.0;
double[3] dbar = 1.0;
dfoo = ifoo * dfoo; // Scalar int * scalar double -- OK
writeln(dfoo);
dfoo = dfoo * dfoo; // Scalar double * scalar double -- OK
writeln(dfoo);
dbar = dfoo * dbar[];// Scalar double * array of double --
OK
writeln(dbar);
ibar = ifoo * ibar[];// Scalar int * array of int -- OK
writeln(ibar);
dbar = ifoo * dbar[];// Scalar int * array of double -- OK
writeln(dbar);
// dbar = dfoo * ibar[]; // Scalar double * array of int -- FAIL
// writeln(dbar);
}
I would have expected the last case to work as well, but I get
testarr.d(20): Error: incompatible types for ((dfoo) * (ibar[])):
'double' and 'int[]'
Is this by design? It was very surprising to me, especially since
all other combinations do seem to work.
Kind regards,
Stefan Frijters
Re: Scalar + array operations
On Wednesday, 21 May 2014 at 13:52:47 UTC, John Colvin wrote: Please file a bug, there's no reason for that not to work, it just needs to be implemented properly. Ok, thanks for confirming. Filed as https://issues.dlang.org/show_bug.cgi?id=12780 .
Re: Scalar + array operations
On Wednesday, 21 May 2014 at 17:07:27 UTC, Francesco Cattoglio wrote: On Wednesday, 21 May 2014 at 13:52:47 UTC, John Colvin wrote: On Wednesday, 21 May 2014 at 11:45:57 UTC, Stefan Frijters wrote: I would have expected the last case to work as well, but I get testarr.d(20): Error: incompatible types for ((dfoo) * (ibar[])): 'double' and 'int[]' Is this by design? It was very surprising to me, especially since all other combinations do seem to work. Kind regards, Stefan Frijters Please file a bug, there's no reason for that not to work, it just needs to be implemented properly. To me, it just feels reasonable that it is not allowed. What should be the correct type of the result? int[]? I thought double to int conversion was not allowed unless you explicitly asked for it. No, I expected and desired an array of doubles, implicitly converting the array of ints to doubles.
Avoiding __traits(getAttributes, ...) on alias
I've been playing with UDAs a bit and I wanted to find all
variables with a particular attribute in various modules. I
thought I had it cracked, until I added a module that contains an
alias declaration, which makes it choke when trying to execute
__traits(getAttributes, ...). A small example is shown below. Is
there any conditional I can insert between the two foreach lines
to make it detect such an alias declaration, and move on to the
next derived member? Or should getAttributes handle this by just
returning no attributes?
import std.traits;
@(testattr) int foo;
alias char[256] MyChar;
@(testattr) int bar;
void main() {
foreach(e ; __traits(derivedMembers, mixin(__MODULE__))) {
foreach( t; __traits(getAttributes, mixin(e)) ){
pragma(msg, t);
}
}
// testattr
// test.d(9): Error: first argument is not a symbol
// test.d(9): Error: invalid foreach aggregate false
// testattr
}
Any hints would be appreciated!
Kind regards,
Stefan Frijters
Re: Avoiding __traits(getAttributes, ...) on alias
On Friday, 9 May 2014 at 12:19:12 UTC, John Colvin wrote:
On Friday, 9 May 2014 at 11:53:59 UTC, Stefan Frijters wrote:
I've been playing with UDAs a bit and I wanted to find all
variables with a particular attribute in various modules. I
thought I had it cracked, until I added a module that contains
an alias declaration, which makes it choke when trying to
execute __traits(getAttributes, ...). A small example is shown
below. Is there any conditional I can insert between the two
foreach lines to make it detect such an alias declaration, and
move on to the next derived member? Or should getAttributes
handle this by just returning no attributes?
import std.traits;
@(testattr) int foo;
alias char[256] MyChar;
@(testattr) int bar;
void main() {
foreach(e ; __traits(derivedMembers, mixin(__MODULE__))) {
foreach( t; __traits(getAttributes, mixin(e)) ){
pragma(msg, t);
}
}
// testattr
// test.d(9): Error: first argument is not a symbol
// test.d(9): Error: invalid foreach aggregate false
// testattr
}
Any hints would be appreciated!
Kind regards,
Stefan Frijters
You could always do a static if with __traits(compiles,
__traits(getAttributes, mixin(e))
Thank you for the fast reply; this solves my problem. I actually
tried this before, but in my actual code instead of the example,
where I'm deep into backticks and quotes and escaped quotes so I
probably made a mistake there...
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
Re: Starting D with a project in mind.
On Wednesday, 16 October 2013 at 07:52:44 UTC, Andrew wrote: andrew@islay:~/dub$ ./build.sh Generating version file... Running gdmd... /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code /usr/local/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L) line 224 is trying to instantiate a Duration object. Any ideas ? Giving up on dub, I tried niaively to build one of the vibe.d samples directly :- andrew@islay:~/vibe.d/examples/http_server/source$ gdmd -I~/vibe.d/source app.d /data/home/andrew/vibe.d/source/vibe/stream/ssl.d:43: error: module bio is in file 'deimos/openssl/bio.d' which cannot be read Looks like I'm missing some openssl dependencies, where do these come from as they don't appear to be part of phobos ? Thanks As far as I know deimos is a set of official (?) bindings for common C libraries. I don't know dub's build process but I assume that if the build script would have worked for you it would have attempted to clone this repo https://github.com/D-Programming-Deimos/openssl (you can find more bindings if you go up one level). My gdc build hadn't finished yet when I had to leave for work this morning, but I'll try to build dub tonight, to see if I run into the same problems...
Re: Starting D with a project in mind.
On Wednesday, 16 October 2013 at 09:11:16 UTC, Andrew wrote: As far as I know deimos is a set of official (?) bindings for common C libraries. I don't know dub's build process but I assume that if the build script would have worked for you it would have attempted to clone this repo https://github.com/D-Programming-Deimos/openssl (you can find more bindings if you go up one level). My gdc build hadn't finished yet when I had to leave for work this morning, but I'll try to build dub tonight, to see if I run into the same problems... I've been using a Cubieboard A20, it's much better than a RPi as it has 1GB RAM, dual core armv7 and much better IO including on-board SATA for $50. The gcc /gdc build takes around 2 - 3 hours on that. You'll probably run into the same libphobos issues that I had, since there are many places where there are no ARM headers. Ok, I logged onto my Pi during lunch break, and actually the compilation process went fine, and pragma(msg, __VERSION__); now correctly has 2063L as output. So in my recent experience: - GDC master branch doesn't compile properly, because it's missing the ARM-specific code. - GDC-jp91 master branch compiles, but is based on 2.060 and is too old to be useful. - GDC-jp91 arm branch seems to work, although Johannes has warned that there is some codegen bug when compiling with -O2. This is all now a bit confusing, but I expect GDC master branch to compile again for ARM when either frontend version 2.064 is released and merged into GDC (in a few weeks hopefully?), or Johannes' arm fork is merged into GDC (whenever he has time to find and fix his codegen bug). Then everything would be (relatively) easy again... Looking into dub / vibe.d is out of my lunch scope :-P
Re: Starting D with a project in mind.
On Wednesday, 16 October 2013 at 19:18:53 UTC, Andrew wrote: I'm a very happy man ! Everything is built and working including dub and the http_server example from vibe.d. It's slow to build, but it executes quickly and strips down to about 3MB which is heavy but tolerable. Thanks to everybody for the help, now I can start learning D, exploring vibe.d and Pegged and hopefully make some good progress on my MUD. So to recap, to help anybody else building on ARM these are the steps I took :- mkdir gdc cd gdc wget http://gcc.igor.onlinedirect.bg/snapshots/LATEST-4.8/gcc-4.8-20131010.tar.bz2 tar xvf gcc-4.8-20131010.tar.bz2 git clone https://github.com/jpf91/GDC.git arm_gdc cd arm_gdc git checkout arm ./setup-gcc.sh ../gcc-4.8-20131010 cd ../ mkdir build cd build export C_INCLUDE_PATH=/usr/include/$(gcc -print-multiarch) export EXTRA_CONF=-mfloat-abi=hard --with-float=hard ../gcc-4.8-20131010/configure --enable-languages=d --disable-bootstrap --prefix=/usr/local/gdc --disable-multilib --disable-softfloat --with-float=hard make -j2 sudo make install sudo cp ../arm_gdc/libphobos/libdruntime/core/time.d /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core sudo mv /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di.old I don't know why that last step was necessary but dub and a few other things didn't build without it. After that dub built fine once I'd hacked the build file to use gdc. Cool. I was posting in the D.GNU newsgroup about this when I noticed your update, so I included a link to this work around in my post [1]. Maybe Iain or any of the other gurus know of a better way, because the last part looks awfully dirty :-D [1] http://forum.dlang.org/post/wshaxsawkvkwfaefp...@forum.dlang.org
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 14:56:06 UTC, Dicebot wrote: On Tuesday, 15 October 2013 at 14:38:32 UTC, Andrew wrote: Is this something I can update easily ? If rebuilding GDC from sources so that it will catch 2.063.2 frontend version is an option - it may help. Looking at https://github.com/jpf91/GDC/commits/arm , 2.063.2 support is also included in the ARM branch, cf. commit 1aa5755 from June 30, so you should have it already I think. Where did you get the 2.062 info from?
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 19:23:13 UTC, Andrew wrote: 2060L - seems I'm further advanced than everybody else :-) Sorry, I thought it was 2.052, but now I see it's well behind since it should be 2.063. I'm rebuilding again from the master. Aha, oops, I have the same 2060L, but that is presumably because I forgot to 'git checkout arm', and the master branch on Johannes' fork is not up-to-date. The reason why this works while normal GDC doesn't is that this is so old it doesn't include some explicit architecture static ifs that were added later (and for which ARM was not available for some time). I'm going to let this stuff rebuild overnight...
Re: Starting D with a project in mind.
On Monday, 14 October 2013 at 07:36:03 UTC, Andrew wrote: Thanks Stefan, those were the instructions that I tried. With GDC, is it possible to generate portable intermediate C code so that I can compile D sources on the Mac and then just copy the resultant C code to an ARM debian machine and build that there ? That would allow me to work around the problem of not being able to build D directly on the target system. Thanks Hi, I actually managed to build GDC over the weekend, directly on the RPi. It required some small changes to the process as compared to [1]: - Fresh raspbian install (same). - Installed the packages (same). - Set up swap USB HD (same). - I got gcc-4.8.1 release sources, didn't apply the patches (seems they are already in place now), nor did I rerun the autoconf. I then proceeded to clone GDC, run the scripts and build, however I ran into a set of bugs[2]. I tried to get around those with my limited knowledge but got stuck. Luckily Johannes Pfau has been doing some great work as usual and already fixed these problems (mostly) in his fork / ARM branch [3]. So I redid this part of the process, with a fresh GCC source directory, using a clone of his fork, and the compilation ran to completion. A small test program also worked, but Johannes warned that there is some codegen issue in his fork, which is why he hasn't opened a pull request to merge into GDC proper yet[2]. I don't know the details of that but this might be good enough for now for your purposes. I assume that by the time 2.064 comes around and GDC's frontend is update one can go back to the main GDC master branch, as most fixes are already in druntime as well. Cheers, Stefan [1] http://gdcproject.org/wiki/Raspberry%20Pi/build/Raspbian%28Hardfloat%29/GCC-Devel [2] http://bugzilla.gdcproject.org/show_bug.cgi?id=80 [3] https://github.com/jpf91/GDC/tree/arm
Re: Starting D with a project in mind.
On Friday, 11 October 2013 at 07:09:17 UTC, Andrew wrote: As Adam already said D on Pi is adventurous. For MongoDB and web stuff, you should look into Vibe.d [0]. For parsing I would suggest Pegged [1]. Welcome to D and Happy Hacking! :) [0] http://vibed.org/ [1] https://github.com/PhilippeSigaud/Pegged Thanks both. Well after several hours of hacking I have spectacularly failed to build GDC on any arm based debian environment - tried both my RPi and Cubieboard. In both cases it fails with a pile of compilation errors. I'm guessing that D just isn't mainstream enough at the moment to be properly supported on Debian and yet it's too big and complicated to build easily yourself and so it's probably a non-starter for me at the moment. There is a pre-built package on debian gdc-4.4 but it's too old to build vibe or dub from my experimentation. I guess I'll go back to plain old C. Thanks anyway - I'll check back in a few years. Hi, I don't know which instructions you followed, but building GDC for the Pi was slow (overnight job) but in the end relatively pain free for me using these instructions: http://gdcproject.org/wiki/Raspberry%20Pi/build/Raspbian%28Hardfloat%29/GCC-Devel. This was some time ago however (more than a year by now, wow), so I don't know if some change has broken the process since. I don't think I have the SD card with GDC installed anymore so I don't know for sure which version I built at the time. I think it was based on 2.0.59 still. See also http://forum.dlang.org/thread/kpdcgoynlofeosxaj...@forum.dlang.org. When I have some free time I will fire up one of my Pis and give it a try again and report back. Cheers, Stefan
Re: Rectangular multidimensional arrays for D
On Wednesday, 9 October 2013 at 08:30:11 UTC, Denis Shelomovskij wrote: 09.10.2013 7:55, Nick B пишет: On Tuesday, 8 October 2013 at 17:26:46 UTC, Stefan Frijters wrote: andrei wrote: I too are interesteed in this area as well. Dennis do you only plan to focus on multidimensional arrays only, or will you incorporate the above matrices as well ?? What features are you proposing ? I propose stuff for multidimensional arrays only as you noted. And I plan just to revise my existing API [1] without cardinal changes. I.e. all I propose is rectangular multidimensional arrays slicing and iterating. For matrix and math specific tasks see DScience [2] and SciD [3]. The latter started as a fork of DScience but became a separate project and is in development. See its wiki [4]. Also such math oriented libraries have to be partially (and the are) wrapper around LAPACK. Also it will be interest to see features you (Stefan and Nick) need e.g. as examples of code you want to compile with comments if needed. Write down at least basic features for now. [1] http://denis-sh.bitbucket.org/unstandard/unstd.multidimensionalarray.html [2] https://github.com/dscience-developers/dscience [3] https://github.com/kyllingstad/scid [4] https://github.com/kyllingstad/scid/wiki Ok, off the top of my head, here are some of the points that would be great for me to have. I apologize in advance if any of them are trivial / irrelevant or out of scope; I have not had time to get my hands dirty on this subject. Even if they are not to be part of the generic multidimensional array (MDA) module, these are things that I would then like to build my own implementation of without having to work with instead of against the things that will be in Phobos. - Many of my operations involve looping over the array in no particular order, so the first foreach example in your link #1 will be very useful. - Another very common operation is accessing a lattice site and looking at its neighbours to determine the outcome of the operation. Of course this is easy for nested for-loops as I can just nest one deeper and pre-calculate the neighbour offsets in another array, but I don't know if there's a canonical way to do this in terms of a foreach loop, and if this would add requirements to the MDA. As an example, Python's numpy seems to have 'generic_filter' for tasks like this[1]. In my testing it was very slow though. - I will have multiple MDAs, containing information like local densities and velocities. These will affect each other in calculations and thus being able to use zip and friends would be very useful. This would require the MDA to be a range I guess? - My code will use wrapped MPI[2] and HDF5[3] calls for parallelism and parallel IO, respectively, and because of that I will need some control over the memory layout. Nothing fancy, but the usual C-style pointer arithmetic would need to work I think, unless there's a nicer mechanism. I hope these comments can be of some help. Cheers, Stefan [1] http://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.filters.generic_filter.html#scipy.ndimage.filters.generic_filter [2] http://en.wikipedia.org/wiki/Message_Passing_Interface [3] http://www.hdfgroup.org/HDF5/
Re: Rectangular multidimensional arrays for D
On Tuesday, 8 October 2013 at 14:41:47 UTC, Denis Shelomovskij wrote: I accidentally discovered Andrei wrote [1] multidimensional array implementation is needed. If it really is, I will work to revise the API and prepare my implementation [2] for review if nobody is doing it already. Also as Kenji's multidimensional indexing and slicing pull [3] still not merged the only way is to use hacks like this: --- // first two rows and three columns of the second matrix array2d = matrices[1, R[0 .. 2], R[0 .. 3]]; --- [1] http://forum.dlang.org/post/kivkp0$csp$1...@digitalmars.com [2] http://denis-sh.bitbucket.org/unstandard/unstd.multidimensionalarray.html [3] https://github.com/D-Programming-Language/dmd/pull/443 --- Previous related topics --- At least the ones I participated in: * October 09, 2011: Kenji Hara proposes Matrix-type-friendly syntax and more. His dmd pull #443 still isn't merged. http://forum.dlang.org/thread/j6sp68$2a7k$1...@digitalmars.com https://github.com/D-Programming-Language/dmd/pull/443 * October 25, 2011: Original Multidimensional arrays for D post. No response from Phobos developers. http://forum.dlang.org/thread/j864es$2gi0$1...@digitalmars.com * June 17, 2012: A request for template that can simulate a rectangular array. http://forum.dlang.org/thread * June 30, 2012: A request for fixed size multidimensional array at runtime. http://forum.dlang.org/thread/ldjzfqvnjltbbiovq...@forum.dlang.org I don't normally post here a lot (though I'm a regular reader), but I wanted to say I for one would really appreciate an official solution for proper rectangular arrays. A bit of background: I'm a numerical physicist focusing on the lattice Boltzmann method[1], where most physical quantities live on a (3D) lattice. Currently I'm using a Fortran code with is very feature-rich, but has grown organically over a decade or so and the features have come at the cost of maintainability and performance. As I'm very much interested in the D language (though I cannot devote much time to it at the moment) I've had plans of writing my own smaller D code which would contain the features I need. It would be nice to be able to use Phobos for my 3D array needs. Slicing will also be much valued to make it easier to communicate sections of the lattice through MPI. I would aim to undertake this project after I've finished my PhD thesis, in ~2 months. I don't assume an official Phobos version would be available at that time, but even having a good idea of the API that is being aimed for would save me a lot of time I think. Cheers, Stefan [1] http://en.wikipedia.org/wiki/Lattice_Boltzmann_methods
