Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On 2014-06-22 08:25, ed wrote: But there's no 64 bit support for DWT, or am I mistaken? Yes, correct. Why do you need 64bit? All 64bit Windows computers can run 32bit applications. -- /Jacob Carlborg
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Monday, 23 June 2014 at 08:10:49 UTC, Jacob Carlborg wrote: On 2014-06-22 08:25, ed wrote: But there's no 64 bit support for DWT, or am I mistaken? Yes, correct. Why do you need 64bit? All 64bit Windows computers can run 32bit applications. customer require it - program and all components 64bit.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Friday, 20 June 2014 at 18:04:20 UTC, Nick Sabalausky wrote: While it's been awhile since I've used visual GUI designers much, I seem to remember them (at least the better ones anyway) being perfectly capable of doing resizable layouts. Any limitations seemed to have more to do with the widgets and GUI libs themselves rather than any inherent drawback to GUI designers in general. I seem to recall doing some resizable layouts even as far back as VB3. Anchors work, because they are simple and pixel-oriented. GTK boxes have too many settings to put them into a visual designer. Specialized non-pixel-oriented layouts do work with visual designers as they don't require configuration.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Monday, 23 June 2014 at 08:10:49 UTC, Jacob Carlborg wrote: Yes, correct. Why do you need 64bit? All 64bit Windows computers can run 32bit applications. High memory requirements :( If you have performance problems with a (big) database, a possible solution is to cache data on the client.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Monday, 23 June 2014 at 08:10:49 UTC, Jacob Carlborg wrote: Yes, correct. Why do you need 64bit? All 64bit Windows computers can run 32bit applications. Also big grids; hundreds of thousands items.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Monday, 23 June 2014 at 08:10:49 UTC, Jacob Carlborg wrote: On 2014-06-22 08:25, ed wrote: But there's no 64 bit support for DWT, or am I mistaken? Yes, correct. Why do you need 64bit? All 64bit Windows computers can run 32bit applications. Memory is the main reason. I have started working on a 64 bit DWT port. If anything comes of it I'll submit a PR for review. Cheers, ed
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On 2014-06-23 12:21, ed wrote: Memory is the main reason. Fair enough. I have started working on a 64 bit DWT port. If anything comes of it I'll submit a PR for review. Awesome, looking forward to it. How is it going, does it require a lot of changes? -- /Jacob Carlborg
LDC 0.13.0 has been released!
Hi everyone, LDC 0.13.0, the LLVM-based D compiler, is available for download! This is the first stable release based on the 2.064.2 frontend and standard library and supports LLVM 3.1-3.4.2 (OS X: 3.2/3.4.x only). As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/yefpjkfouykvwkjil...@forum.dlang.org Regards, Kai
Re: shorter alternative of constructor with parameter
On 06/22/2014 09:58 PM, Kapps wrote:
On Sunday, 22 June 2014 at 11:50:31 UTC, Shammah Chancellor wrote:
I can't support this proposal. Adds more syntax to a language that
is already becoming cramped. I also don't see the purpose of having
simple constructors like this? Are you going to add (n choose k)
simple constructors to a class? I could get behind field initializer
syntax ala C# with modeling the syntax we have for structures.
new Person() {name: Bob};
-Shammah
In theory, 'with' could be used for that if it returned the expression
passed in:
auto a = with(new Person()) {
Name = Bob;
Age = 27;
}
I had to test that syntax. I got it working with these versions:
C c; with(c = new C()) {
i = 10;
}
C d = new C(); with(d) {
i = 20;
}
I really like the C# object initializer syntax, so your version would be
much appreciated. Or if with could create objects in outer scope like this
with(auto c = new C()) {
i = 30;
}
Re: Optimizing Java using D
On Sunday, 22 June 2014 at 17:34:15 UTC, Nick Sabalausky wrote: On 6/21/2014 1:40 AM, Tofu Ninja wrote: On another note, if someArray.sort() calls the built in sort even when std.algorithm is imported, then most definitely built in sort needs to go, I can see plenty of times where people would not even realize they were calling the wrong sort or even that there was an error in their code. If there's any lingering reasons why built-in sort might still need to exist (I wouldn't know), then maybe it could get moved into object.d (perhaps by internally being renamed ex. __sort, with a sort wrapper in object.d?). That way it should at least trigger a conflict with std.algorithm.sort instead of shadowing it. But then it wouldn't be callable with UFCS, no?
Re: RFC: Value range propagation for if-else
On Sunday, 22 June 2014 at 21:10:31 UTC, bearophile wrote:
Nordlöw:
auto pow(T)(T arg, uint n)
{
enum vr = __traits(valueRange, arg);
static if (vr.min == vr.max) // if arg is constant
I think that unfortunately this currently can't work, you can't
tell the range of the input value like that. I have explained
why in one of my posts in this thread. Please try to explain me
why I'm wrong.
Don't know what you're referring to, but I guess you mean that -
because of separate compilation - the code generated for `pow`
needs to be generic? This is not really a problem, because the
compiler can generate _additional_ specialized functions for it.
But then, a normal `if` would also do, because dead code
elimination can remove the unused parts in these specializations.
Re: nothrow function callbacks in extern(C) code - solution
On Sunday, 22 June 2014 at 08:43:20 UTC, Rainer Schuetze wrote: On 22.06.2014 02:23, Andrei Alexandrescu wrote: Callbacks passed into OS/clib functions are never supposed to throw so we must annotate them all with nothrow. C functions are never designed under the assumption callbacks may throw. -- Andrei For nothrow that restriction makes sense, though there are functions in the Windows C API that actually may throw, e.g. HeapAlloc [1] and MmProbeAndLockPages [2]. No callbacks are involved in these examples, though. Under unix, signal handlers that throw exceptions seem to be used, though this might be non-standard. We even have one in druntime [3]. The SEGV handles throws Errors, not Exceptions, it's ok to be nothrow.
readln for tango with d2?
Doese tango come with a readline fucntion for d2? from this site, i was unable to find anything in my search : http://siegelord.github.io/Tango-D2/
Re: Article on overzealous compiler optimizations
On 2014-06-22 19:32:45 +, Jonathan M Davis via Digitalmars-d said: On Friday, June 20, 2014 15:20:17 Walter Bright via Digitalmars-d wrote: http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-ca n-open-security-holes-in-your-code This is an opportunity for D to define the spec in such away as to preclude the bad optimizations while keeping the good ones. Any ideas? I applaud the sentiment, but I fear that I don't know enough about compiler optimizations to have much in the way of good ideas. It seems like every time the subject comes up, it turns out that compilers do all kinds of crazy things that make it so that half of what you think is guaranteed isn't guaranteed. If you had some way to mark code such that it restricts what the compiler can optimize, then that could help, but you'd have to know that you needed that restriction in the first place, and usually, the problem is that you don't even know what the compiler might optimize out, and not even checking the generated assembly helps in the general case, because what one compiler might leave in, another might optimize out. It's a thorny problem. - Jonathan M Davis Sounds like the oracle query optimizer. 95% of the time it does the right thing, but convincing it to behave the other 5% of the time is a real trick. -Shammah
Re: RFC: Value range propagation for if-else
I think that unfortunately this currently can't work, you can't tell the range of the input value like that. I have explained why in one of my posts in this thread. Please try to explain me why I'm wrong. I'm currently merely talking about possibilities in this case, so I cannot currently prove you wronge ;) To me it seem like an unneccessary limitation that valueRanges aren't propagated to function call arguments provided that the function source is known at compile time. And it doesn't sound to me like enabling this in DMD would be such a great task either.
Re: readln for tango with d2?
On Monday, 23 June 2014 at 10:52:32 UTC, seany wrote: Doese tango come with a readline fucntion for d2? from this site, i was unable to find anything in my search : http://siegelord.github.io/Tango-D2/ tango.io.Console, maybe?
Re: Value range propagation for if-else
Nordlöw wrote in message news:jctlkqtiztnbnctld...@forum.dlang.org... I'm currently merely talking about possibilities in this case, so I cannot currently prove you wronge ;) To me it seem like an unneccessary limitation that valueRanges aren't propagated to function call arguments provided that the function source is known at compile time. And it doesn't sound to me like enabling this in DMD would be such a great task either. What happens when a function is called from different places with values with different ranges? What about when it's called from another compilation unit? Generally the argument ranges can only be known when the function is inlined, and by then it's much too late to expose them via __traits.
Re: Value range propagation for if-else
Daniel Murphy: What happens when a function is called from different places with values with different ranges? What about when it's called from another compilation unit? One solution is to ignore such cases, so that feature gives useful results only when the source is compiled in the same compilation unit. An alternative solution is to handle the functions that use those features like templates, and keep the source available across different compilation units. This is perhaps acceptable because I think that kind of features is going to be used mostly for library code and not for most user functions. Bye, bearophile
Re: Value range propagation for if-else
On Monday, 23 June 2014 at 12:51:58 UTC, Daniel Murphy wrote: What happens when a function is called from different places with values with different ranges? What about when it's called from another compilation unit? Generally the argument ranges can only be known when the function is inlined, and by then it's much too late to expose them via __traits. Ok. That indeed makes things more complicated than I first thought :|
Re: Value range propagation for if-else
On Monday, 23 June 2014 at 13:13:38 UTC, bearophile wrote: One solution is to ignore such cases, so that feature gives useful results only when the source is compiled in the same compilation unit. An alternative solution is to handle the functions that use those features like templates, and keep the source available across different compilation units. This is perhaps acceptable because I think that kind of features is going to be used mostly for library code and not for most user functions. That is certainly a good idea.
Re: Optimizing Java using D
On Sun, 22 Jun 2014 13:33:55 -0400, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On 6/21/2014 1:40 AM, Tofu Ninja wrote: On another note, if someArray.sort() calls the built in sort even when std.algorithm is imported, then most definitely built in sort needs to go, I can see plenty of times where people would not even realize they were calling the wrong sort or even that there was an error in their code. If there's any lingering reasons why built-in sort might still need to exist (I wouldn't know), then maybe it could get moved into object.d (perhaps by internally being renamed ex. __sort, with a sort wrapper in object.d?). That way it should at least trigger a conflict with std.algorithm.sort instead of shadowing it. The only thing I can think of that won't work is sorting an array of char or wchar, which std.algorithm.sort will not do (right?). -Steve
Re: Optimizing Java using D
On Sat, 21 Jun 2014 07:50:29 -0400, Marc Schütz schue...@gmx.net wrote: On Saturday, 21 June 2014 at 05:40:32 UTC, Tofu Ninja wrote: On Saturday, 21 June 2014 at 03:52:54 UTC, logicchains wrote: Blog author here, I've added a note that D's sort matches the speed of C++'s when the stable sort is used instead of the default unstable. I don't think there's anything wrong with D's unstable sort however, as the C++ version also performs worse when using std::sort (unstable) instead of std::stable_sort. Awesome! Glad to see D shown in a good light :) Great article btw. On another note, if someArray.sort() calls the built in sort even when std.algorithm is imported, then most definitely built in sort needs to go, I can see plenty of times where people would not even realize they were calling the wrong sort or even that there was an error in their code. It's a bit more subtle: `someArray.sort()` calls std.algorithm's sort, while `someArray.sort` (without parens) calls the built-in sort. But yes, the latter needs to go. Indeed. It's like a rotten easter egg. Needs to be killed with fire. -Steve
Re: Optimizing Java using D
On Fri, 20 Jun 2014 23:52:52 -0400, logicchains jonathan.t.barn...@gmail.com wrote: Blog author here, I've added a note that D's sort matches the speed of C++'s when the stable sort is used instead of the default unstable. I don't think there's anything wrong with D's unstable sort however, as the C++ version also performs worse when using std::sort (unstable) instead of std::stable_sort. Is it just me, or does this seem unintuitive? I would think a stable sort requires extra care, i.e. extra time, to ensure stability. Do we need an unstable sort then? Or is this a corner case? I am fully ignorant on these advanced sorting routines and how they work. The Quicksort-based sort routines are like black magic to me, my knowledge stops at merge sort :) -Steve
Re: Optimizing Java using D
Steven Schveighoffer: The only thing I can think of that won't work is sorting an array of char or wchar, which std.algorithm.sort will not do (right?). The solution I have suggested is: myString.representation.sort().release.unrepresentation (Where unrepresentation is not yet present in Phobos). Bye, bearophile
Re: Optimizing Java using D
Steven Schveighoffer: Do we need an unstable sort then? Or is this a corner case? Probably is a corner case. And the current stable sort is good. Bye, bearophile
Re: shorter alternative of constructor with parameter
On Sat, 21 Jun 2014 15:47:03 -0400, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, 21 Jun 2014 18:50:21 +
Xinok via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Saturday, 21 June 2014 at 17:17:57 UTC, Suliman wrote:
Dart and few others modern languages support short declaration
constructor with parameter:
class Person {
String name;
Person(String name) {
this.name = name;
}
}
// Shorter alternative
class Person {
String name;
// parameters prefixed by 'this.' will assign to
// instance variables automatically
Person(this.name);
}
it's there any DIP for adding this future to D?
I'd prefer that we didn't crowd the language with minor shortcuts
like these, and save syntactic sugar for more useful features.
Plus, it would be easy enough to make a string mixin which
generates such boilerplate code.
Agreed. This would just add more stuff to the language that people would
have
to understand, and it really doesn't add much benefit. It's just a
slightly
terser syntax - and one that doesn't fit in with any other kind of
function
declarations in D to boot.
Yeah, I don't think we save much with this. A mixin should be able to
assign all the names given in the parameters that you name the same way.
In fact, I bet one can write a boiler-plate string that works for ANY
class, using __traits(allMembers), as long as your parameter names match
the member names. Then you just mixin that string as the first thing in
the ctor.
-Steve
Re: Optimizing Java using D
On Monday, 23 June 2014 at 15:19:15 UTC, Steven Schveighoffer wrote: Is it just me, or does this seem unintuitive? I would think a stable sort requires extra care, i.e. extra time, to ensure stability. Do we need an unstable sort then? Or is this a corner case? I am fully ignorant on these advanced sorting routines and how they work. The Quicksort-based sort routines are like black magic to me, my knowledge stops at merge sort :) -Steve Technically, you can prove that there exists some unstable sort that is always faster than a stable sort. Andrei showed me this once: [2,2,2,2,1] With unstable sort, the 1 and first 2 could be swapped, but with stable sort, the 1 must swap with each 2 until it settles into the 0th position. That said, I've never seen the unstable sort that's always faster than any stable sort and since it doesn't appear in any of the languages I know of, I've got to guess that no one else has discovered it either. That said, I've seen some cases where the unstable sort is faster (particularly in cases where the ordering of the elements is nearly completely random), so it's not as if unstable sort is currently always worse. It's just in many real-world scenarios it ends up being worse. Furthermore, our stable sort (an implementation of Timsort) is impossible to really use incorrectly ... even using it very stupidly (as an example, append an element on the end of a sorted array and insert it by calling stable sort) will result in reasonable runtimes and do what the programmer expects of it. It makes writing simple quick scripts and prototypes absurdly easy and still very efficient. Plus maintaining the current order of the elements is really nice in general. Personally, I'm still in the camp of suggesting that our default should be stable sort and if you're certain your use case will benefit from the extra speed of unstable sort, you should specify it. But I don't think that's going to change.
Re: Optimizing Java using D
How can this be proven? Is it valid only for swap-based sorting algorithms? For example, radix sort is stable and its complexity is O(kn). Is there a faster unstable sort? On Monday, 23 June 2014 at 15:38:25 UTC, Chris Cain wrote: Technically, you can prove that there exists some unstable sort that is always faster than a stable sort. Andrei showed me this once:
Re: Optimizing Java using D
Whoops, comparison based On Monday, 23 June 2014 at 15:57:12 UTC, Andrea Fontana wrote: How can this be proven? Is it valid only for swap-based sorting algorithms? For example, radix sort is stable and its complexity is O(kn). Is there a faster unstable sort? On Monday, 23 June 2014 at 15:38:25 UTC, Chris Cain wrote: Technically, you can prove that there exists some unstable sort that is always faster than a stable sort. Andrei showed me this once:
Re: Optimizing Java using D
On Mon, 23 Jun 2014 11:38:24 -0400, Chris Cain zsh...@gmail.com wrote: On Monday, 23 June 2014 at 15:19:15 UTC, Steven Schveighoffer wrote: Is it just me, or does this seem unintuitive? I would think a stable sort requires extra care, i.e. extra time, to ensure stability. Do we need an unstable sort then? Or is this a corner case? I am fully ignorant on these advanced sorting routines and how they work. The Quicksort-based sort routines are like black magic to me, my knowledge stops at merge sort :) Technically, you can prove that there exists some unstable sort that is always faster than a stable sort. Andrei showed me this once: [2,2,2,2,1] With unstable sort, the 1 and first 2 could be swapped, but with stable sort, the 1 must swap with each 2 until it settles into the 0th position. That said, I've never seen the unstable sort that's always faster than any stable sort and since it doesn't appear in any of the languages I know of, I've got to guess that no one else has discovered it either. Right. It's all dependent on whether the unstable sort can make the right decisions. In my mind, ensuring stability seems like an extra task. In other words, (and I know it's not true) for every stable sort, there exists an equivalent unstable sort that does not have to do extra work to preserve ordering. But some sorts are stable by nature. It's probably a factor of the two sorts using different algorithms that happen to work better on some data sets. That said, I've seen some cases where the unstable sort is faster (particularly in cases where the ordering of the elements is nearly completely random), so it's not as if unstable sort is currently always worse. It's just in many real-world scenarios it ends up being worse. Furthermore, our stable sort (an implementation of Timsort) is impossible to really use incorrectly ... even using it very stupidly (as an example, append an element on the end of a sorted array and insert it by calling stable sort) will result in reasonable runtimes and do what the programmer expects of it. It makes writing simple quick scripts and prototypes absurdly easy and still very efficient. Plus maintaining the current order of the elements is really nice in general. Personally, I'm still in the camp of suggesting that our default should be stable sort and if you're certain your use case will benefit from the extra speed of unstable sort, you should specify it. But I don't think that's going to change. This seems like sound advice. An interesting feature may be to try and predict which sorts are working better for some process. In other words, choose a proportion of sorts to perform using stable, and some to use unstable. Then compare the speed per element, and adjust the proportion to favor the faster sort (obviously only when the sort method is not specified). I wonder how well this might perform for tasks that frequently sort. You could wrap the sorting routine with another function which does this. -Steve
Re: readln for tango with d2?
On 2014-06-23 12:52, seany wrote: Doese tango come with a readline fucntion for d2? from this site, i was unable to find anything in my search : http://siegelord.github.io/Tango-D2/ The documentation for Tango and D1 can be used: http://dsource.org/projects/tango/wiki/ChapterIoConsole -- /Jacob Carlborg
Re: Optimizing Java using D
On Monday, 23 June 2014 at 15:57:12 UTC, Andrea Fontana wrote: How can this be proven? Is it valid only for swap-based sorting algorithms? For example, radix sort is stable and its complexity is O(kn). Is there a faster unstable sort? It's not really about the time complexity but the absolute time it must take. But I showed the example that shows that the fact that any stable sort must do extra work: [2,2,2,2,1] An unstable sort may swap the first 2 and the 1 whereas a stable sort must, by definition, maintain the relative positioning of the 2s, which means it must move all of the 2s upwards. Think of a magical sort that knows exactly the perfect swaps to do in order to sort (that is, magical sort's complexity is O(n)). In the case above, magical unstable sort does 1 swap and magical stable sort must do 4 (if it doesn't, it's not stable). This shows that stable sorts must strictly be equal to or slower than unstable sort (and an unstable sort could sometimes do better than a stable sort). Or, to look at it another way, all stable sorts satisfy the qualities needed by an unstable sort, but not all unstable sorts satisfy the qualities of a stable sort. The minimum number of swaps/operations to create a sorted array won't necessarily maintain the stability property of the elements.
Re: shorter alternative of constructor with parameter
On Mon, Jun 23, 2014 at 11:30:22AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
On Sat, 21 Jun 2014 15:47:03 -0400, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, 21 Jun 2014 18:50:21 +
Xinok via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Saturday, 21 June 2014 at 17:17:57 UTC, Suliman wrote:
Dart and few others modern languages support short declaration
constructor with parameter:
class Person {
String name;
Person(String name) {
this.name = name;
}
}
// Shorter alternative
class Person {
String name;
// parameters prefixed by 'this.' will assign to
// instance variables automatically
Person(this.name);
}
it's there any DIP for adding this future to D?
I'd prefer that we didn't crowd the language with minor shortcuts
like these, and save syntactic sugar for more useful features.
Plus, it would be easy enough to make a string mixin which generates
such boilerplate code.
Agreed. This would just add more stuff to the language that people
would have to understand, and it really doesn't add much benefit.
It's just a slightly terser syntax - and one that doesn't fit in with
any other kind of function declarations in D to boot.
Yeah, I don't think we save much with this. A mixin should be able to
assign all the names given in the parameters that you name the same
way.
In fact, I bet one can write a boiler-plate string that works for ANY
class, using __traits(allMembers), as long as your parameter names
match the member names. Then you just mixin that string as the first
thing in the ctor.
[...]
Here's a first stab at a working mixin that does this (uncomment the
pragma(msg,...) lines to see the generated code):
string defaultCtor(T)()
if (is(T == class))
{
enum isDataMember(T, string memb) =
is(typeof(typeof(__traits(getMember, T, memb)).init));
// Generate function signature
string params, ctorBody;
string delim = ;
foreach (memb; __traits(derivedMembers, T))
{
static if (isDataMember!(T, memb))
{
alias argtype = typeof(__traits(getMember, T,
memb));
auto argname = _ ~ memb;
params ~= delim ~ argtype.stringof ~ ~
argname;
delim = , ;
ctorBody ~= ~ memb ~ = ~ argname ~
;\n;
}
}
return this( ~ params ~ )\n{\n ~ ctorBody ~ };
}
class C {
string name;
int age;
bool registered;
mixin(defaultCtor!(typeof(this)));
//pragma(msg, defaultCtor!(typeof(this)));
void myMethod() {}
}
class D {
int x, y;
string label;
mixin(defaultCtor!(typeof(this)));
//pragma(msg, defaultCtor!(typeof(this)));
}
void main() {
auto c = new C(John Doe, 30, true); // oh yeah
auto d = new D(10, 20, Node 1); // rock on! ;-)
}
Currently, this mixin doesn't handle inheritance very well, but it
should be trivial to extend it to collect all superclass data members
and package them off into a super(...) call inside the generated ctor.
D rawckz.
T
--
Making non-nullable pointers is just plugging one hole in a cheese grater. --
Walter Bright
Designing a matrix library for D
I'd like a matrix library for D, able to handle sparse matrices
too. But first I'd like to discuss its API and general design a
bit.
---
I think a starting point for the design is visible in this paper,
Optimizing Array Accesses in High Productivity Languages by
Mackale Joyner et al.:
http://www.cs.rice.edu/~vs3/PDF/hpcc07-176.pdf
The paper is about optimization, but what's interesting for me is
that it also shows the API and usage of the matrices of the X10
language, that was designed for heavy numerical computations.
Those collections of X10 are based on points and regions.
A Point is a vector of N keys, that are indexes of a vector (like
the row,col for a matrix, or the key for an associative array).
If N is a compile-time constant we lose some flexibility but we
gain efficiency. In theory we want both.
A Region defines part of a collection. In the simpler case it's a
slice of a 1D array, or it can be a 2D rectangular region of a 2D
array, or more. So it's an array of M points. Usually you want M
to be a compile-time constant, but in some cases you want more
flexibility. In some cases you want to intersect regions, or you
want non-convex regions, so the situation gets a little more
complex.
The paper lists some Region operations, that I think can be
implemented with no changes to the D language:
R.rank ::= # dimensions in region;
R.size() ::= # points in region
R.contains(P) ::= predicate if region R contains point P
R.contains(S) ::= predicate if region R contains region S
R.equal(S) ::= true if region R and S contain same set of points
R.rank(i) ::= projection of region R on dimension i (a
one-dimensional region)
R.rank(i).low() ::= lower bound of i-th dimension of region R
R.rank(i).high() ::= upper bound of i-th dimension of region R
R.ordinal(P) ::= ordinal value of point P in region R
R.coord(N) ::= point in region R with ordinal value = N
R1 R2 ::= region intersection (will be rectangular if R1 and
R2 are rectangular)
R1 || R2 ::= union of regions R1 and R2 (may or may not be
rectangular,compact)
R1 - R2 ::= region difference (may or may not be
rectangular,compact)
The paper also shows some ideas for array operations:
A.rank ::= # dimensions in array
A.region ::= index region (domain) of array
A.distribution ::= distribution of array A
A[P] ::= element at point P, where P belongs to A.region
A | R ::= restriction of array onto region R (returns copy of
subarray)
A.sum(), A.max() ::= sum/max of elements in array
A1 op A2 ::= returns result of applying a point-wise op on
array elements,
when A1.region = A2. region
(op can include +, -, *, and / )
A1 || A2 ::= disjoint union of arrays A1 and A2
(A1.region and A2.region must be disjoint)
A1.overlay(A2) ::= array with region, A1.region || A2.region,
with element value A2[P] for all points P in A2.region
and A1[P] otherwise.
---
I've found a second source of ideas in this page:
http://dis.um.es/~alberto/hmatrix/static.html
It's a Haskell matrix library named hmatrix. It's meant to be
safe because it performs automatic inference and compile-time
checking of dimensions in matrix and vector operations.. This
means that in many cases arrays and matrices have a size known at
compile-time (so it's part of the type) and the library verifies
statically that they match:
(matrix
[ 2.0, 0.0, -1.0
, 1.0, 1.0, 7.0
, 5.0, 3.0, 1.0
, 2.0, 8.0, 0.0 ] :: L 4 3)
But:
The size of the result of certain computations can only be known
at run time. For instance, the dimension of the nullspace of
matrix depends on its rank, which is a nontrivial property of
its elements:
The library solves this problem using a GHC compiler language
extension:
By hiding the unknown dimension in an existential type we can
still compute safely with a strongly typed nullspace.
Docs about Haskell existential types:
http://www.haskell.org/haskellwiki/Existential_type
This is a normal Haskell record with specified types:
data Worker b x y = Worker {buffer :: b, input :: x, output :: y}
That is similar to this D code:
class Worker(B, X, Y) {
B buffer;
X input;
Y output;
}
Existential types can be used to hide a type on the left:
data Worker x y = forall b. Buffer b = Worker {buffer :: b,
input :: x, output :: y}
This allows to hide the size of an array where its length is
not known at compile-time. I am not an Haskell expert, but I
think this is a kind of type erasure (where here the type is the
size of the array).
With this strategy in most cases the compiler is able to enforce
the arrays are of right types at compile-time, and allows
run-time sizes for the few remaining cases.
In D this idea should avoid template bloat caused by all the
different array dimensions, but allow optimizations based on the
compile-time knowledge of sizes in the points where the
programmer asks for more efficiency (like unrolling on request in
certain zones if the size is just 4).
Is all this possible
Re: Optimizing Java using D
Corollary: the default sorting algorithm in std will always be unstable, even if for certain data types and inputs it will produce stable sorting. -- Andrei
Time to rename D to @D !?
The @ symbols used on all those attributes like @nogc @nothrow @pure @safe make the D code look ugly. If possible, please get rid of those @ symbols. The attributes look good without the @ symbols.
Re: Adding the ?. null verification
On 6/21/14, 4:32 PM, deadalnix wrote: On Saturday, 21 June 2014 at 22:40:32 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 6/19/14, 1:29 PM, Etienne wrote: writeln(currAssignment.safeDeref.typeInfo.ident.or(meh)); or is really nice and terse. I think we should add that to std. safeDeref isn't the best choice of name. [...] What's your suggestion? T maybe is fine. Last time I checked, it isn't only a monad in haskell, but also vastly used by these peoples who speak english. I like maybe too. nullSafe might also be a reasonable bikeshed color.
Re: Designing a matrix library for D
On Mon, Jun 23, 2014 at 04:45:27PM +, bearophile via Digitalmars-d wrote: I'd like a matrix library for D, able to handle sparse matrices too. But first I'd like to discuss its API and general design a bit. When it comes to libraries that need to handle diverse concrete types (e.g. compact matrices vs. sparse matrices), my take is always to write the matrix algorithms in a way that's independent of the concrete matrix type(s), and to provide concrete types as a separate submodule (or logically distinct section of the API). [...] Those collections of X10 are based on points and regions. A Point is a vector of N keys, that are indexes of a vector (like the row,col for a matrix, or the key for an associative array). If N is a compile-time constant we lose some flexibility but we gain efficiency. In theory we want both. A Region defines part of a collection. In the simpler case it's a slice of a 1D array, or it can be a 2D rectangular region of a 2D array, or more. So it's an array of M points. Usually you want M to be a compile-time constant, but in some cases you want more flexibility. In some cases you want to intersect regions, or you want non-convex regions, so the situation gets a little more complex. I think supporting non-convex (or non-rectangular) regions is a bit too ambitious. Basic support should focus on rectangular/cuboidal/etc. regions, which have the advantage that they are closed under intersections (the intersection of two rectangular regions is always another rectangular region). Non-rectangular regions would destroy a lot of simplifying assumptions that can be made to streamline the design, and yet most applications I can think of need only rectangular regions. I don't think it's worth the price to support such unusual usages. (Besides, if we design the API correctly, they should still be supportable via wrapped matrix types -- this is why matric algorithms should not depend on concrete types, so that for special needs the user can simply define a wrapper that remaps points in such a way as to achieve the desired non-convex regions.) The paper lists some Region operations, that I think can be implemented with no changes to the D language: R.rank ::= # dimensions in region; R.size() ::= # points in region R.contains(P) ::= predicate if region R contains point P R.contains(S) ::= predicate if region R contains region S R.equal(S) ::= true if region R and S contain same set of points R.rank(i) ::= projection of region R on dimension i (a one-dimensional region) R.rank(i).low() ::= lower bound of i-th dimension of region R R.rank(i).high() ::= upper bound of i-th dimension of region R R.ordinal(P) ::= ordinal value of point P in region R R.coord(N) ::= point in region R with ordinal value = N R1 R2 ::= region intersection (will be rectangular if R1 and R2 are rectangular) R1 || R2 ::= union of regions R1 and R2 (may or may not be rectangular,compact) R1 - R2 ::= region difference (may or may not be rectangular,compact) My current thoughts on this, is that concrete matrix/array types should only support array element access and size measurements. Operations like intersections, subarrays, etc., should be done via wrapper types that remap element access and size measurements, but forward element accesses to the underlying concrete type. This way, we avoid excessive copying, which get very expensive with large or high-dimensional arrays. The paper also shows some ideas for array operations: A.rank ::= # dimensions in array A.region ::= index region (domain) of array A.distribution ::= distribution of array A What's a distribution? A[P] ::= element at point P, where P belongs to A.region A | R ::= restriction of array onto region R (returns copy of subarray) IMO, we should avoid all implicit copying. Let the user explicitly ask for a copy if a copy is desired. Implicit copying is the mortal enemy of high performance. A.sum(), A.max() ::= sum/max of elements in array A1 op A2 ::= returns result of applying a point-wise op on array elements, when A1.region = A2. region (op can include +, -, *, and / ) A1 || A2 ::= disjoint union of arrays A1 and A2 (A1.region and A2.region must be disjoint) A1.overlay(A2) ::= array with region, A1.region || A2.region, with element value A2[P] for all points P in A2.region and A1[P] otherwise. All of these should be generic functions / wrappers, I think. [...] I've found a second source of ideas in this page: http://dis.um.es/~alberto/hmatrix/static.html [...] The size of the result of certain computations can only be known at run time. For instance, the dimension of the nullspace of matrix depends on its rank, which is a nontrivial property of its elements: The library solves this problem using a GHC compiler language extension: By hiding the unknown dimension in an existential type we can still compute safely with a strongly typed nullspace. [...] With this
Re: Optimizing Java using D
On Monday, 23 June 2014 at 17:25:13 UTC, Andrei Alexandrescu wrote: Second, there are known reasons and setups where Timsort and derivatives fare better than classic quicksort-based implementations, and generalizing them into some magic stable sort is just better umbrella argument is just odd. Timsort works well on data with large continuous sorted runs, and that's an important case but one that a quicksort-based approach could and should avail itself of as well. Note that unstable version of timsort can perform better on some input, as you can use descendant runs (when only strictly descendent are usable in the stable version).
Re: Time to rename D to @D !?
On Monday, 23 June 2014 at 17:30:19 UTC, John wrote: The @ symbols used on all those attributes like @nogc @nothrow @pure @safe make the D code look ugly. If possible, please get rid of those @ symbols. The attributes look good without the @ symbols. I agree that it looks ugly and is a lot of visual noise, similar to all the angle brackets that some complain about with C++ templates. However, I'm not sure it can be remedied this late in the game.
Re: Optimizing Java using D
Sent: Monday, June 23, 2014 at 10:26 AM From: Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com To: digitalmars-d@puremagic.com Subject: Re: Optimizing Java using D Corollary: the default sorting algorithm in std will always be unstable, even if for certain data types and inputs it will produce stable sorting. -- Andrei Essentially, the sorting order of unstable sort is undefined, so it _can_ produce stable sorting, but it's not guaranteed to. It would be kind of silly to try and make it so that unstable sort was _guaranteed_ to not produce unstable sorting. We _technically_ could write an algorithm that was always stable but named unstableSort without violating what unstable sort is. It would just be silly. - Jonathan M Davis
Druntime DMD/LDC/GDC architecture
Hello all! very simple code: -- double[] a, c; ... c[] += a[]; -- The DMD version I can find in _arraySliceSliceAddass_d, https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraydouble.d . What about LDC and GDC? The _arraySliceSliceAddass_d is the same, no any version(LDC). When I compile code into assembler I found other code then in asm scope. So I suppose LDC has it's own architecture. Is it right? Where I can find it for understanding what optimization can be done by LLVM optimizer? Have GDC it's own architecture too? Best Regards, Ilya
Re: shorter alternative of constructor with parameter
On Saturday, 21 June 2014 at 18:50:23 UTC, Xinok wrote: I'd prefer that we didn't crowd the language with minor shortcuts like these, and save syntactic sugar for more useful features. Plus, it would be easy enough to make a string mixin which generates such boilerplate code. I agree please don't add shortcuts like this that really don't add anything other than more complexity. Please keep D simple and clean to read and have to always guess what shortcuts are being used. As another dev said a template or mixin can be used for this.
Re: Time to rename D to @D !?
On Monday, 23 June 2014 at 17:50:10 UTC, Joakim wrote: The @ symbols used on all those attributes like @nogc @nothrow @pure @safe make the D code look ugly. If we want this change we probably have to make them deprecated a couple of DMD versions before we active the new keywords which may break existing code.
Re: shorter alternative of constructor with parameter
Gary Willoughby: As another dev said a template or mixin can be used for this. I don't think a template/mixin can replace that sufficiently well, because you also often want to put some code inside the constructor. Bye, bearophile
Re: shorter alternative of constructor with parameter
On Mon, 23 Jun 2014 14:20:32 -0400, bearophile bearophileh...@lycos.com
wrote:
Gary Willoughby:
As another dev said a template or mixin can be used for this.
I don't think a template/mixin can replace that sufficiently well,
because you also often want to put some code inside the constructor.
The mixin does not have to generate a whole function, it can just generate
the assigns inside a ctor.
I'm envisioning something like this:
class C
{
int a;
int b;
int c;
this(int a, int b, int c)
{
mixin(ctorAssigns); // this.a = a; this.b = b; this.c = c;
// other code
}
}
-Steve
Re: Druntime DMD/LDC/GDC architecture
On Monday, 23 June 2014 at 18:09:46 UTC, Ilya Yaroshenko wrote: Hello all! very simple code: -- double[] a, c; ... c[] += a[]; -- The DMD version I can find in _arraySliceSliceAddass_d, https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraydouble.d . What about LDC and GDC? The _arraySliceSliceAddass_d is the same, no any version(LDC). When I compile code into assembler I found other code then in asm scope. So I suppose LDC has it's own architecture. Is it right? Where I can find it for understanding what optimization can be done by LLVM optimizer? Have GDC it's own architecture too? Best Regards, Ilya If you look at the bottom of those _array functions you will find a regular loop doing the cleanup for anything missed by the inline asm. If I remember correctly, for gdc it is this loop doing the whole operation as the asm is versioned out.
Re: Designing a matrix library for D
H. S. Teoh: Operations like intersections, subarrays, etc., should be done via wrapper types A Region is not an array of data, it's more like a [(x1,x2),(y1,y2)]. You can allocate an array given a Region, you can iterate a Region, etc. A.distribution ::= distribution of array A What's a distribution? It's a concept of higher level compared to Regions. It's less efficient than Regions, but it's more flexible. It allows to decouple the Point from the location of the data memory. So you can have a distribution that maps Points to various different concrete arrays. http://x10.sourceforge.net/x10doc/2.2.1/x10/array/DistArray.html http://x10.sourceforge.net/x10doc/2.2.1/x10/array/Dist.html I have not fully understood what a Distribution is. Bye, bearophile
Re: Time to rename D to @D !?
Plaese no.
Re: Druntime DMD/LDC/GDC architecture
If you look at the bottom of those _array functions you will find a regular loop doing the cleanup for anything missed by the inline asm. If I remember correctly, for gdc it is this loop doing the whole operation as the asm is versioned out. I think it is something different. LDC has standard D inline asm.
Re: Time to rename D to @D !?
Funny enough two of the attributes you mentioned (pure and nothrow) don't have an @ on them. Maybe I'm strange, but I don't see any problem with the @, and would actually like to see some of the other attributes (including pure and nothrow) adopt them, for consistancy and to free up names. Surely you don't think safe should be a keyword? Or trusted or system?
Re: Designing a matrix library for D
On Monday, 23 June 2014 at 16:45:28 UTC, bearophile wrote: I'd like a matrix library for D, able to handle sparse matrices too. But first I'd like to discuss its API and general design a bit. This all reminds me, I was thinking I'd like to try adding some array language features to D at some point. Things APL's monadics and dyadics, and generic lifting of functions and operators as described here: http://www.ccs.neu.edu/home/pete/pub/esop-2014.pdf It's been pretty low on my priority list, but it sounds similar to some of what you're laying out here. -Wyatt
Re: Time to rename D to @D !?
On Monday, 23 June 2014 at 19:37:49 UTC, Chris Nicholson-Sauls wrote: Funny enough two of the attributes you mentioned (pure and nothrow) don't have an @ on them. Maybe I'm strange, but I don't see any problem with the @, and would actually like to see some of the other attributes (including pure and nothrow) adopt them, for consistancy and to free up names. Surely you don't think safe should be a keyword? Or trusted or system? All are having the @ added: http://wiki.dlang.org/DIP64
Re: Time to rename D to @D !?
On Monday, 23 June 2014 at 20:08:41 UTC, Gary Willoughby wrote: All are having the @ added: http://wiki.dlang.org/DIP64 This hasn't been decided on. It's just a proposal right now.
Is void* compatible with function pointers?
In C and C++, void* is for data pointers but it works (by accident?) for function pointers on all popular platforms. Does D have anything to say about this topic? Ali
Re: Time to rename D to @D !?
On Monday, June 23, 2014 17:30:18 John via Digitalmars-d wrote: The @ symbols used on all those attributes like @nogc @nothrow @pure @safe make the D code look ugly. If possible, please get rid of those @ symbols. The attributes look good without the @ symbols. It would be very cool if we could remove @ from all of the built-in attributes, but the whole reason that they have them in the first place is because it was decided that we didn't want to add new keywords - and that was several years ago when D had a smaller user base. So, I really don't see it changing at this point. If anything, we might go the _other_ way and add @ onto the attributes that don't have it in order to make them more consistent (though I hope that we don't do that, because it's ugly and more verbose). I sympathize with you, but I think that we're stuck at this point. - Jonathan M Davis
Re: Is void* compatible with function pointers?
On Mon, 23 Jun 2014 16:30:41 -0400, Ali Çehreli acehr...@yahoo.com wrote: In C and C++, void* is for data pointers but it works (by accident?) for function pointers on all popular platforms. Doing a bit of research, it seems that it is architecture dependent. For instance, a memory model may use pointers that are larger for function addresses than for object pointers. In this case, casting to and from void * would lose data. But most platforms have the same pointer width for both data and functions. So it works, not by accident, but because that's what the architecture dictates. I think it's important to state that the conversion from function pointer to void pointer is not specified as undefined, but actually just not specified at all. I would say it's architecture-defined. Does D have anything to say about this topic? Since most architectures use same-size words for function addresses and object addresses, D would be fine to say it's defined and valid. I think the extreme outliers are architectures that are not equal, and D will not be harmed too badly by making this distinction. Any D flavor that would be ported to such an architecture may have to be a derived language. -Steve
Re: Is void* compatible with function pointers?
On Mon, Jun 23, 2014 at 04:49:27PM -0400, Steven Schveighoffer via Digitalmars-d wrote: On Mon, 23 Jun 2014 16:30:41 -0400, Ali Çehreli acehr...@yahoo.com wrote: In C and C++, void* is for data pointers but it works (by accident?) for function pointers on all popular platforms. AFAIK, in C++ casting a function pointer to void* is undefined behaviour, and while it does work for the most common platforms, there are systems for which it would fail catastrophically. This is a particularly nasty sticking point for Posix C++ implementations (you can find discussions on this topic if you google for it), because according to the spec, dlsym() should never work for function symbols in the loaded library, though in practice, all Posix platforms (that I know of) don't actually have any problem with it. [...] Does D have anything to say about this topic? Since most architectures use same-size words for function addresses and object addresses, D would be fine to say it's defined and valid. I think the extreme outliers are architectures that are not equal, and D will not be harmed too badly by making this distinction. Any D flavor that would be ported to such an architecture may have to be a derived language. [...] We *could* technically define D's void* to be the same size as the largest pointer type on that particular platform, and it would avoid the problem. The issue in C++ arises because void* is assumed to point to *data* as opposed to code, so it may be smaller than necessary to be a function pointer. But again, in practice I think it's safe to say that the platforms affected by this issue are few in number and not commonly-used, so we should be safe. T -- Study gravitation, it's a field with a lot of potential.
Re: Designing a matrix library for D
H. S. Teoh: The key to success, then, lies in how we design the generic matrix API. If we do it right, then it should be easy to implement features like compile-time size verifications, etc.. Otherwise it can be very painful. One point of my post was to see if it could be useful to extend and improve the current D type system. Apparently you are saying this is not needed for efficiency reasons (but perhaps some type system improvements could be useful to reduce template bloat with the usage of this matrix library. The idea is to perform the compile-time tests of the sizes, and then remove such types in most cases, avoiding the template bloat. There are manual ways to do this, but here it's better to receive help from the type system). Bye, bearophile
Re: Designing a matrix library for D
On Monday, 23 June 2014 at 16:45:28 UTC, bearophile wrote: I'm glad to hear there's interest in this! I've actually been working on a generic multidimensional array library myself (on and off) for the past few months (I'm hoping to have a well-documented dub package by the end of the summer). It's a bit of a hybrid between Julia's `AbstractArray`, NumPy's `ndarray`, Numba, and std.range, and I think it has a very D feel. It is, however, designed for processing sampled signals (rather than matrix algebra), which may be more or less in line with different people's interests. Concepts: InputGrid: anything with a size (size_t[n]) and n-dimensional opIndex. OutputGrid: anything with a size (size_t[n]) and n-dimensional opIndexAssign. Functionality: - Lazy `map` and `reduce`. - Lazy `zip` with built-in broadcasting. - Lazy n-dimensional convolution and cross-correlation. - Lazy sampling and interpolation. - `collect` to force evaluation. - Element-wise operators and and fancy indexing via mixins*. - Everyone's favorite MATLAB-style constructors (`zeros`, `identity`, `meshGrid`, etc.) - Audio/Video and JSON I/O, via GStreamer (though this probably ought to be a separate package). *Because D doesn't allow UFCS for operators, which is silly, but that's the way it is. Other features: - Compatibility with an automatic binding generator I've been working on. - Testing, because I've been using this at work :) If people want to use this, it might make sense to add linear algebra to this package rather than building a separate, incompatible algebra library (see this thread: http://comments.gmane.org/gmane.comp.lang.julia.devel/14533). I did a lot of thinking about the level of abstraction that would be the most useful, and I settled on something like Julia's `AbstractArray` because it fits into D nicely (like ranges, but different!) and easily maps onto something that can be passed to other languages (a block of memory with size/strides metadata). As in Julia, I decided to make rank (`nDim!grid`) a compile-time entity since 1) Writing rank-branching code for NumPy is cumbersome and error prone; rank should be part of overload resolution. 2) It speeds up component-programming-style operations without requiring leaky abstractions (having to specialize on concrete grid types). It's a busy week so I probably won't be able to follow this thread, but I wanted to let you know I was working on this to avoid duplicated efforts, etc. Cheers, Mason
Re: Is void* compatible with function pointers?
On Monday, 23 June 2014 at 20:49:27 UTC, Steven Schveighoffer wrote: Since most architectures use same-size words for function addresses and object addresses, D would be fine to say it's defined and valid. I think the extreme outliers are architectures that are not equal, and D will not be harmed too badly by making this distinction. Any D flavor that would be ported to such an architecture may have to be a derived language. -Steve While it might be fine, I would be concerned that people wouldn't understand the difference between a function and a delegate. They would figure that if you can store a function reference in a void* then you should be able to fit a delegate in as well, and proceed to lose data. I would make it something where the compiler forces you to make an explicit cast. Before that, it should warn you about the potential loss of data.
Re: Time to rename D to @D !?
On Monday, 23 June 2014 at 20:34:59 UTC, Jonathan M Davis via Digitalmars-d wrote: It would be very cool if we could remove @ from all of the built-in attributes, but the whole reason that they have them in the first place is because it was decided that we didn't want to add new keywords - and that was several years ago when D had a smaller user base. So, I really don't see it changing at this point. If anything, we might go the _other_ way and add @ onto the attributes that don't have it in order to make them more consistent (though I hope that we don't do that, because it's ugly and more verbose). People (I've talked to) seem to like Python decorators and Java annotations, and they have mandatory @ characters. I like the @ because it helps me (and my editor) distinguish between words that *define* a computation (return type, parameters, etc.) and words that *describe* a computation (attributes).
Re: Designing a matrix library for D
On Mon, Jun 23, 2014 at 09:08:02PM +, Mason McGill via Digitalmars-d wrote: On Monday, 23 June 2014 at 16:45:28 UTC, bearophile wrote: I'm glad to hear there's interest in this! I've actually been working on a generic multidimensional array library myself (on and off) for the past few months (I'm hoping to have a well-documented dub package by the end of the summer). It's a bit of a hybrid between Julia's `AbstractArray`, NumPy's `ndarray`, Numba, and std.range, and I think it has a very D feel. You are far from the first one to write a multidimensional array library in D. Denis has already done this some time ago, and I have, too. It's clear that we need to get our heads together and knock up something Phobos-worthy. It is, however, designed for processing sampled signals (rather than matrix algebra), which may be more or less in line with different people's interests. I've thought about this a lot, and my conclusion is that matrix algebra is best left to a matrix-specific library wrapper that endows matrix algebra properties on top of a generic multidimensional array type. The main reason is that matrix algebra is rather peculiar to matrices specifically, particularly the non-commutative matrix product, and does not have very many useful usages outside of matrix algebra itself; yet multidimensional arrays in general are useful in a wider scope. So in my mind, there are several components that are needed here: - A generic multidimensional array, as a data container. This can be a set of diverse concrete types, e.g. to represent sparse matrices, etc.. No domain-specific operations are specified for these containers; they are purely for storage and access only. - Specialized array types, like matrices which add matrix algebra semantics to the underlying multidimensional array storage container (e.g., matrix product), or tensor wrappers (endows tensor product semantics on the underlying container). - Algorithms: these take any multidimensional array, or specialized matrix type (depending on the purpose of each algorithm), and operate on them using a common multidimensional array API. They should be as generic as they can be, but no more, e.g., LU decomposition algorithms would take a matrix type rather than the general multidimensional array type, because it is specific to matrices, whereas per-element summation would take any general multidimensional array type, since it doesn't need matrix-specific properties. Similarly, subarray operations should be able to work with any multidimensional array type, since it simply provides a restricted view on the underlying storage container, but doesn't depend on the implementational specifics of the container itself. [...] I did a lot of thinking about the level of abstraction that would be the most useful, and I settled on something like Julia's `AbstractArray` because it fits into D nicely (like ranges, but different!) and easily maps onto something that can be passed to other languages (a block of memory with size/strides metadata). As in Julia, I decided to make rank (`nDim!grid`) a compile-time entity since 1) Writing rank-branching code for NumPy is cumbersome and error prone; rank should be part of overload resolution. 2) It speeds up component-programming-style operations without requiring leaky abstractions (having to specialize on concrete grid types). It's a busy week so I probably won't be able to follow this thread, but I wanted to let you know I was working on this to avoid duplicated efforts, etc. [...] I think the best solution would be a generic multidimensional concept (analogous to the input range concept) that will fit all of our multidimensional array implementations. Algorithms that can work with diverse ranks shouldn't care if the rank of a particular concrete type is compile-time or runtime, for example. Let the algorithms be adaptable (up to practicality, of course -- if an algo can't work or works very poorly with dynamic rank, then just add a sig constraint that requires static rank, for example), and the user can choose which concrete type(s) best suits his needs. The concrete types can then be provided by a separate module, and if we do it right, should be interoperable with each other. T -- How are you doing? Doing what?
Re: Designing a matrix library for D
On Mon, Jun 23, 2014 at 09:09:03PM +, bearophile via Digitalmars-d wrote: H. S. Teoh: The key to success, then, lies in how we design the generic matrix API. If we do it right, then it should be easy to implement features like compile-time size verifications, etc.. Otherwise it can be very painful. One point of my post was to see if it could be useful to extend and improve the current D type system. Apparently you are saying this is not needed for efficiency reasons (but perhaps some type system improvements could be useful to reduce template bloat with the usage of this matrix library. The idea is to perform the compile-time tests of the sizes, and then remove such types in most cases, avoiding the template bloat. There are manual ways to do this, but here it's better to receive help from the type system). [...] I'm not against using / extending the type system to improve performance or reduce template bloat. But it would be far more ambitious than to implement something that works with the current language. T -- Laissez-faire is a French term commonly interpreted by Conservatives to mean 'lazy fairy,' which is the belief that if governments are lazy enough, the Good Fairy will come down from heaven and do all their work for them.
Re: shorter alternative of constructor with parameter
On Saturday, 21 June 2014 at 17:17:57 UTC, Suliman wrote:
Dart and few others modern languages support short declaration
constructor with parameter:
class Person {
String name;
Person(String name) {
this.name = name;
}
}
// Shorter alternative
class Person {
String name;
// parameters prefixed by 'this.' will assign to
// instance variables automatically
Person(this.name);
}
it's there any DIP for adding this future to D?
If name is a property with getter and/setter: stack overflow ;).
It's like the old with debate.
Re: Time to rename D to @D !?
On Monday, 23 June 2014 at 17:30:19 UTC, John wrote:
The @ symbols used on all those attributes like @nogc @nothrow
@pure @safe make the D code look ugly.
If possible, please get rid of those @ symbols. The attributes
look good without the @ symbols.
Give up this idea, right now.
Grammatically it would break all the code using identifiers such
as 'safe'...
I think it's just not possible. interesting example:
---
import std.stdio;
@safe int safe()
{
auto i = 8;
return i;
}
void main(string ars[])
{
writeln(safe);
}
---
What you want is just impossible...
Re: Time to rename D to @D !?
import std.stdio;
@safe int safe()
{
auto i = 8;
return i;
}
void main(string ars[])
{
writeln(safe);
}
---
What you want is just impossible...
Would be a good use case for dfix. It really isn't hard to rename
every identifier consistently.
Re: shorter alternative of constructor with parameter
On Mon, 23 Jun 2014 17:38:53 -0400, Grogan gro...@od.fr wrote:
On Saturday, 21 June 2014 at 17:17:57 UTC, Suliman wrote:
Dart and few others modern languages support short declaration
constructor with parameter:
class Person {
String name;
Person(String name) {
this.name = name;
}
}
// Shorter alternative
class Person {
String name;
// parameters prefixed by 'this.' will assign to
// instance variables automatically
Person(this.name);
}
it's there any DIP for adding this future to D?
If name is a property with getter and/setter: stack overflow ;).
How so?
-Steve
Re: Is void* compatible with function pointers?
On Mon, 23 Jun 2014 17:16:04 -0400, Chris Williams yoreanon-chr...@yahoo.co.jp wrote: On Monday, 23 June 2014 at 20:49:27 UTC, Steven Schveighoffer wrote: Since most architectures use same-size words for function addresses and object addresses, D would be fine to say it's defined and valid. I think the extreme outliers are architectures that are not equal, and D will not be harmed too badly by making this distinction. Any D flavor that would be ported to such an architecture may have to be a derived language. While it might be fine, I would be concerned that people wouldn't understand the difference between a function and a delegate. They would figure that if you can store a function reference in a void* then you should be able to fit a delegate in as well, and proceed to lose data. I would make it something where the compiler forces you to make an explicit cast. Before that, it should warn you about the potential loss of data. That shouldn't work, even for an explicit cast. It currently is deprecated, not sure what version it will be removed (I didn't know it ever worked in the first place!) -Steve
Re: Designing a matrix library for D
On Monday, 23 June 2014 at 21:33:40 UTC, H. S. Teoh via Digitalmars-d wrote: You are far from the first one to write a multidimensional array library in D. Denis has already done this some time ago, and I have, too. I've seen Denis' library. It seems nice, but it's a lot more concrete that what the original post was discussing. Is yours online somewhere (for inspiration)? I've thought about this a lot, and my conclusion is that matrix algebra is best left to a matrix-specific library wrapper that endows matrix algebra properties on top of a generic multidimensional array type. The main reason is that matrix algebra is rather peculiar to matrices specifically, particularly the non-commutative matrix product, and does not have very many useful usages outside of matrix algebra itself; yet multidimensional arrays in general are useful in a wider scope. So in my mind, there are several components that are needed here: - A generic multidimensional array, as a data container. This can be a set of diverse concrete types, e.g. to represent sparse matrices, etc.. No domain-specific operations are specified for these containers; they are purely for storage and access only. - Specialized array types, like matrices which add matrix algebra semantics to the underlying multidimensional array storage container (e.g., matrix product), or tensor wrappers (endows tensor product semantics on the underlying container). - Algorithms: these take any multidimensional array, or specialized matrix type (depending on the purpose of each algorithm), and operate on them using a common multidimensional array API. They should be as generic as they can be, but no more, e.g., LU decomposition algorithms would take a matrix type rather than the general multidimensional array type, because it is specific to matrices, whereas per-element summation would take any general multidimensional array type, since it doesn't need matrix-specific properties. Similarly, subarray operations should be able to work with any multidimensional array type, since it simply provides a restricted view on the underlying storage container, but doesn't depend on the implementational specifics of the container itself. Seems reasonable. I think the best solution would be a generic multidimensional concept (analogous to the input range concept) that will fit all of our multidimensional array implementations. Algorithms that can work with diverse ranks shouldn't care if the rank of a particular concrete type is compile-time or runtime, for example. Let the algorithms be adaptable (up to practicality, of course -- if an algo can't work or works very poorly with dynamic rank, then just add a constraint that requires static rank, for example), and the user can choose which concrete type(s) best suits his needs. One possible issue with dynamically-ranked grids is concept-testing. `isInputGrid!Collection` needs to check if `Collection` has a `size` property, and can be indexed with `size.length` indices. If this is to be done at compile-time, `size.length` needs to be constant. The concrete types can then be provided by a separate module, and if we do it right, should be interoperable with each other. Definitely an important design goal. You seem quite knowledgeable on this topic and I hope we can continue this conversation when my work on this is further along.
Re: Time to rename D to @D !?
On Monday, 23 June 2014 at 22:02:26 UTC, Tobias Pankrath wrote:
import std.stdio;
@safe int safe()
{
auto i = 8;
return i;
}
void main(string ars[])
{
writeln(safe);
}
---
What you want is just impossible...
Would be a good use case for dfix. It really isn't hard to
rename every identifier consistently.
Maybe the future will tell you you're right...
From my point of view this change is a very unprobable one but
who knows ?
^^
People are skeptikal about the the air-skate too...
I don't wanna be segregative...
Re: Time to rename D to @D !?
On Monday, 23 June 2014 at 22:02:26 UTC, Tobias Pankrath wrote:
import std.stdio;
@safe int safe()
{
auto i = 8;
return i;
}
void main(string ars[])
{
writeln(safe);
}
---
What you want is just impossible...
Would be a good use case for dfix. It really isn't hard to
rename every identifier consistently.
Yep, perfect place to start experimenting with a Dfix and see
what kind of language cleanup it would afford.
For those who don't know what we're talking about:
http://blog.golang.org/introducing-gofix
Andrei seems enthusiastic:
http://forum.dlang.org/thread/lmmdej$2j94$1...@digitalmars.com#post-lncpdr:242ufh:241:40digitalmars.com
Stable topN?
I've managed to build a small laundry list the past couple days, so why not add another item? I've been tasked with implementing a deterministic topN, but I also noticed that topN is lacking a stable implementation, so this seemed like an ideal opportunity to kill two birds with one stone. However, for me, it begged the question: What exactly does stable topN imply? A stable sort only implies that equal elements retain their original order. However, topN is a partitioning function whose pivot is unknown beforehand. To me, it would make more sense that not just equal elements but ALL elements retain their original order in their respective partitions. However, to accomplish the above, the Nth element would need to be discovered before any other elements are reordered. This suggests making a full copy of the range to search for the Nth element. The unstable topN could be applied to the copy to discover the Nth element, then the stable partition function could finish the job with the correct pivot. What do you all think? Do you agree with my definition of stable topN? Do you know of a better algorithm/approach for implementing this function?
Re: Time to rename D to @D !?
On Monday, 23 June 2014 at 22:16:22 UTC, Grogan wrote:
On Monday, 23 June 2014 at 22:02:26 UTC, Tobias Pankrath wrote:
import std.stdio;
@safe int safe()
{
auto i = 8;
return i;
}
void main(string ars[])
{
writeln(safe);
}
---
What you want is just impossible...
Would be a good use case for dfix. It really isn't hard to
rename every identifier consistently.
Maybe the future will tell you you're right...
From my point of view this change is a very unprobable one but
who knows ?
^^
People are skeptikal about the the air-skate too...
I don't wanna be segregative...
I meant the 'hoverboard' of course...
BTW I think '@' makes sense. And another BTW: in your fantastic
nazi plan which consists into eradicating the '@' prefix, how
would look the UDA ?
I mean that '@' has a signification in the D grammar not only for
predifined attributes, but also for user ones...
Re: Is void* compatible with function pointers?
If it will work that way on most plateforms, the other way around can do VERY nasty things, even on common plateforms like ARM. This is because most CPUs consider the instructions as immutable. Even x86 do not provide any guarantee (which makes it very hard to swap implementation outside of a VM). Casting from void* to function is pretty guaranteed to be undefined behavior on all plateforms, unless you emit the proper barriers.
Re: Is void* compatible with function pointers?
On Mon, 23 Jun 2014 20:48:34 -0400, deadalnix deadal...@gmail.com wrote: If it will work that way on most plateforms, the other way around can do VERY nasty things, even on common plateforms like ARM. Casting to and from a function pointer should not do anything horrific, unless the intermediate type cannot hold the full function pointer. It is no different than casting from immutable pointer to mutable pointer, and then back to immutable pointer. As long as you don't write to it while it's mutable, it's not illegal. This is because most CPUs consider the instructions as immutable. Even x86 do not provide any guarantee (which makes it very hard to swap implementation outside of a VM). Remember, these are not functions, but function pointers. You are not modifying the function at all. Casting from void* to function is pretty guaranteed to be undefined behavior on all plateforms, unless you emit the proper barriers. Can you demonstrate a C example that will fail on ARM? -Steve
Re: Designing a matrix library for D
Have you looked at armadillo for inspiration? http://arma.sourceforge.net/ It's a C++ matrix/linear algebra library which has: -expression templates for high level optimizations (could be done even better in D of course, moving more stuff to compile time) -high performance via lapack/blas -deliberately matlab-like syntax which is appealing to a large subset of people who would use such a library I think this approach would also be good for D, at least if the idea is to target numeric computing people. I am skeptical about making the library too generic, since performance is typically a primary concern for matrix code. I didn't read the linked paper, but the performance quoted in the abstract comparable (from 48% to 100%) to that of lower-level Java programs sounds pretty underwhelming.
Re: shorter alternative of constructor with parameter
On Saturday, 21 June 2014 at 17:17:57 UTC, Suliman wrote:
Dart and few others modern languages support short declaration
constructor with parameter:
class Person {
String name;
Person(String name) {
this.name = name;
}
}
// Shorter alternative
class Person {
String name;
// parameters prefixed by 'this.' will assign to
// instance variables automatically
Person(this.name);
}
it's there any DIP for adding this future to D?
I don't agree with this feature. It's ugly. At first look at you
have no idea what it does mean (even if you know have already
some base about programming languages).
I think this type of feature would lead D to became a type of C++.
See C++ foo(int x) : x(x) {} is just too ugly either. I don't
know if there are someone that share same feel.
Re: Designing a matrix library for D
On Tue, Jun 24, 2014 at 03:04:53AM +, David Bregman via Digitalmars-d wrote: Have you looked at armadillo for inspiration? http://arma.sourceforge.net/ It's a C++ matrix/linear algebra library which has: -expression templates for high level optimizations (could be done even better in D of course, moving more stuff to compile time) -high performance via lapack/blas -deliberately matlab-like syntax which is appealing to a large subset of people who would use such a library I think this approach would also be good for D, at least if the idea is to target numeric computing people. I am skeptical about making the library too generic, since performance is typically a primary concern for matrix code. I didn't read the linked paper, but the performance quoted in the abstract comparable (from 48% to 100%) to that of lower-level Java programs sounds pretty underwhelming. Using lapack/blas as the backend would guarantee good performance, though I'm not sure if the Phobos maintainers would be too thrilled at the idea, after the fiasco with libcurl. For high performance, I would implement matrix algebra completely within a compile-time DSL instead of hack tricks like expression templates and operator overloading. That way, the implementation can algebraically manipulate the expressions to maximize opportunities for optimizations. As for genericity, I think D has the ability to generate performant code *and* be generic at the same time. At least, it'd worth shooting for to see how far we can get. I believe the key is to separate the algorithms from the concrete types, and use specialization for the performance-sensitive cases. This way, the generic cases will work, and the specific cases will be high-performance. T -- Nothing in the world is more distasteful to a man than to take the path that leads to himself. -- Herman Hesse
Re: shorter alternative of constructor with parameter
On Tuesday, 24 June 2014 at 03:19:58 UTC, AsmMan wrote:
See C++ foo(int x) : x(x) {} is just too ugly either. I don't
know if there are someone that share same feel.
I agree, we don't need more syntax sugar.
Re: Designing a matrix library for D
On Tuesday, 24 June 2014 at 03:29:52 UTC, H. S. Teoh via Digitalmars-d wrote: a compile-time DSL instead of hack tricks like expression That sounds like a it will be very odd to use and most likely have very little benefit. I think most people would agree that matrix math is a good use case for operator overloading.
Re: Is void* compatible with function pointers?
On Tuesday, 24 June 2014 at 01:41:13 UTC, Steven Schveighoffer
wrote:
This is because most CPUs consider the instructions as
immutable.
Even x86 do not provide any guarantee (which makes it very hard
to swap implementation outside of a VM).
Remember, these are not functions, but function pointers. You
are not modifying the function at all.
void* is not a function and can come from anything that is
mutable.
Casting from void* to function is pretty guaranteed to be
undefined behavior on all plateforms, unless you emit the
proper
barriers.
Can you demonstrate a C example that will fail on ARM?
Anything that JIT is affected. Consider the pseudocode:
void JIT() {
void* code = malloc(XXX);
// Write instructions into the allocated chunk of memory.
membar(); // Memory barrier to avoid reordering.
auto fun = cast(void function()) code;
fun(); // Even if your codegen is correct, anything can
happen this point.
}
Re: Designing a matrix library for D
On Monday, 23 June 2014 at 21:08:03 UTC, Mason McGill wrote: [snip] Concepts: InputGrid: anything with a size (size_t[n]) and n-dimensional opIndex. OutputGrid: anything with a size (size_t[n]) and n-dimensional opIndexAssign. [snip] Cheers, Mason I don't think 'Grid' is not a good name for the type. The term Grid is generally used to refer to any sort of grid; regular, semiregular, irregular, unstructured, curvilinear etc. etc. grids. They are all very different in their use and internal representations. Often a grid will have support for metadata at each point (GIS etc.) whereas a matrix will not. I think the word Matrix is a better fit, because that is what they these types are.
Re: Stable topN?
On Monday, 23 June 2014 at 22:47:20 UTC, Xinok wrote: What do you all think? Do you agree with my definition of stable topN? Do you know of a better algorithm/approach for implementing this function? I agree with your definition, and can't think of a better algorithm, but wouldn't a stable sort have the same effect as your algorithm? Both are O(n lg(n)) time and O(n) space.
Re: Designing a matrix library for D
On Tue, Jun 24, 2014 at 03:46:09AM +, Tofu Ninja via Digitalmars-d wrote: On Tuesday, 24 June 2014 at 03:29:52 UTC, H. S. Teoh via Digitalmars-d wrote: a compile-time DSL instead of hack tricks like expression That sounds like a it will be very odd to use and most likely have very little benefit. I think most people would agree that matrix math is a good use case for operator overloading. The DSL can look exactly like a regular matrix expression. The case against operator overloading, is that unless you resort to hacks like expression templates, the result will likely have poor performance, because the overloaded operator can only see one or two arguments at a time, whereas a compile-time DSL interpreter can analyze the entire expression and use algebraic rules to rewrite it in a form that can be efficiently implemented, eg., in terms of lapack/blas primitives for computing expressions like A*x + y. Doing this sort of rewriting with expression templates would be a maintenance nightmare. T -- Lawyer: (n.) An innocence-vending machine, the effectiveness of which depends on how much money is inserted.
Re: Is void* compatible with function pointers?
On Tuesday, 24 June 2014 at 04:24:51 UTC, deadalnix wrote:
On Tuesday, 24 June 2014 at 01:41:13 UTC, Steven Schveighoffer
wrote:
This is because most CPUs consider the instructions as
immutable.
Even x86 do not provide any guarantee (which makes it very
hard
to swap implementation outside of a VM).
Remember, these are not functions, but function pointers. You
are not modifying the function at all.
void* is not a function and can come from anything that is
mutable.
Casting from void* to function is pretty guaranteed to be
undefined behavior on all plateforms, unless you emit the
proper
barriers.
Can you demonstrate a C example that will fail on ARM?
Anything that JIT is affected. Consider the pseudocode:
void JIT() {
void* code = malloc(XXX);
// Write instructions into the allocated chunk of memory.
membar(); // Memory barrier to avoid reordering.
auto fun = cast(void function()) code;
fun(); // Even if your codegen is correct, anything can
happen this point.
}
That's one thing, but casting a function pointer to void* and
then back again later, without modification, must be defined, no?
That's a very different situation to forging your own executable
code.
Re: Passing around a list of differently typed functions
On Monday, 23 June 2014 at 01:16:49 UTC, Evan Davis wrote: As the subject says, I would like to pass around an array of functions. The trick is, that the functions have different type signatures. Is there a way to put the two functions int foo(int a, int b); bool bar(bool a, bool b); into one array, that I can pass around and cast as necessary? Thanks, Evan Use void* as a common type or use std.variant.
Re: Passing around a list of differently typed functions
On Monday, 23 June 2014 at 01:16:49 UTC, Evan Davis wrote: As the subject says, I would like to pass around an array of functions. The trick is, that the functions have different type signatures. Is there a way to put the two functions int foo(int a, int b); bool bar(bool a, bool b); into one array, that I can pass around and cast as necessary? Thanks, Evan You can pass them as pointers, for example cast to void*. But you still need correct signature to cast pointer to actual type before call function.
Re: Passing around a list of differently typed functions
On Monday, 23 June 2014 at 01:16:49 UTC, Evan Davis wrote: As the subject says, I would like to pass around an array of functions. The trick is, that the functions have different type signatures. Is there a way to put the two functions int foo(int a, int b); bool bar(bool a, bool b); into one array, that I can pass around and cast as necessary? Thanks, Evan Have functions in the array without parpameters that call the function with the applicable parameters, e.g. int foo(int a, int b) or bool bar(bool a, bool b). That doesn't address the problem of the different return types (int and bool). So change the return type to void and return the value as an inout parameter.
Unexpected OPTLINK Termination while building ddb and gtkd
My dub.json :
```
{
name: ddb_test,
description: A minimal D application.,
dependencies: {
gtk-d:gtkd: =2.3.3,
ddb: =0.2.1
}
}
```
My source (source/app.d):
```
import ddb.postgres;
import gtk.Window;
int main(string[] argv) {
return 0;
}
```
On linux works, on WinXp and Win7 64bit I get following:
```
$ dub build --force
Building ddb 0.2.1 configuration library, build type debug.
Running dmd...
Building gtk-d:gtkd 2.3.3 configuration library, build type
debug.
Running dmd...
Building ddb_test ~master configuration application, build type
debug.
Compiling using dmd...
Linking...
```
I get a message:
Unexpected OPTLINK Termination a t EIP=0040F5Ba
If I comment just a row on app.d:
```
import ddb.postgres;
// import gtk.Window; =
int main(string[] argv) {
return 0;
}
```
it works!
Thank you
Re: Passing around a list of differently typed functions
On 23/06/2014 8:19 AM, Bienlein wrote: On Monday, 23 June 2014 at 01:16:49 UTC, Evan Davis wrote: As the subject says, I would like to pass around an array of functions. The trick is, that the functions have different type signatures. Is there a way to put the two functions int foo(int a, int b); bool bar(bool a, bool b); into one array, that I can pass around and cast as necessary? Thanks, Evan Have functions in the array without parpameters that call the function with the applicable parameters, e.g. int foo(int a, int b) or bool bar(bool a, bool b). That doesn't address the problem of the different return types (int and bool). So change the return type to void and return the value as an inout parameter. You could convert your functions to return via an out parameter (either manually or with template magic) then have an array of same-signatured closures that can call any function. A...
Why does this work?
import std.typecons;
auto foo2(R)(R foopara){
return tuple(foopara, is(R==int));
}
void main(){
auto tuple(a,b) = foo2(1);
}
I'm expecting some error such as can not act as left value but
when I compiled this, no error occured. DMD version is DMD64
v2.065.(ldc2 exited with error function declaration without
return type)
Why does this work? Or it is a bug?
Re: Why does this work?
On Monday, 23 June 2014 at 08:30:44 UTC, h_zet wrote:
import std.typecons;
auto foo2(R)(R foopara){
return tuple(foopara, is(R==int));
}
void main(){
auto tuple(a,b) = foo2(1);
}
I'm expecting some error such as can not act as left value but
when I compiled this, no error occured. DMD version is DMD64
v2.065.(ldc2 exited with error function declaration without
return type)
Why does this work? Or it is a bug?
Looks grammaticallyu correct: R type is guessed/infered from the
parameter
Re: Why does this work?
On Monday, 23 June 2014 at 08:30:44 UTC, h_zet wrote:
import std.typecons;
auto foo2(R)(R foopara){
return tuple(foopara, is(R==int));
}
void main(){
auto tuple(a,b) = foo2(1);
}
I'm expecting some error such as can not act as left value but
when I compiled this, no error occured. DMD version is DMD64
v2.065.(ldc2 exited with error function declaration without
return type)
Why does this work? Or it is a bug?
You declared a variable template named tuple (with unused type
parameters a, b) on that line.
http://dlang.org/template.html#variable-template
I think this is very confusable syntax...
void main()
{
auto tuple(a, b) = foo2(1);
writeln(tuple!(int, int)); // writes Tuple!(int, bool)(1,
true)
tuple!(int, int) = foo2(20);
writeln(tuple!(int, int)); // writes Tuple!(int, bool)(20,
true)
}
Re: Why does this work?
On Monday, 23 June 2014 at 08:30:44 UTC, h_zet wrote:
import std.typecons;
auto foo2(R)(R foopara){
return tuple(foopara, is(R==int));
}
void main(){
auto tuple(a,b) = foo2(1);
}
I'm expecting some error such as can not act as left value but
when I compiled this, no error occured. DMD version is DMD64
v2.065.(ldc2 exited with error function declaration without
return type)
Why does this work? Or it is a bug?
Strange behavior, indeed. It took me a minute, but I think I know
what's going on, and I'm pretty sure it's a bug. D recently
introduced a short syntax for function-like templates:
enum a(b) = some_value;
It looks like this also (sort of) works with other qualifiers,
which I believe it shouldn't. Here's a minimal example that might
be good to put in a bug report:
void main() {
enum a(x) = some_value; // Good.
auto b(x) = some_value; // Huh?
// This also works for `const`, `static`, etc.
}
Re: Why does this work?
On Monday, 23 June 2014 at 09:29:15 UTC, Mason McGill wrote:
Strange behavior, indeed. It took me a minute, but I think I
know what's going on, and I'm pretty sure it's a bug. D
recently introduced a short syntax for function-like templates:
enum a(b) = some_value;
It looks like this also (sort of) works with other qualifiers,
which I believe it shouldn't. Here's a minimal example that
might be good to put in a bug report:
void main() {
enum a(x) = some_value; // Good.
auto b(x) = some_value; // Huh?
// This also works for `const`, `static`, etc.
}
It looks like I'm mistaken. Variable templates are supposed to
exist. Please ignore the previous post.
Re: Why does this work?
h_zet: Why does this work? Or it is a bug? When you play a little with this code it's easy to see _error_ that should not appear. So there's surely something worth reporting as bug, but I don't yet know what. Bye, bearophile
Contributing to D language
I wish I could help with the development of D (either the compiler or std library). Is there a TODO list kept somewhere? Neither Phobos nor DMD have an `issues` page on Github.. I found this http://wiki.dlang.org/Review_Queue but it's kind of short. Best regards, Mike
Re: Contributing to D language
On Mon, Jun 23, 2014 at 04:43:30PM +, Mike via Digitalmars-d-learn wrote: I wish I could help with the development of D (either the compiler or std library). Is there a TODO list kept somewhere? Neither Phobos nor DMD have an `issues` page on Github.. [...] http://issues.dlang.org/ See also: http://wiki.dlang.org/Get_involved T -- To provoke is to call someone stupid; to argue is to call each other stupid.
Re: Contributing to D language
On Monday, 23 June 2014 at 16:43:31 UTC, Mike wrote: I wish I could help with the development of D (either the compiler or std library). Is there a TODO list kept somewhere? Neither Phobos nor DMD have an `issues` page on Github.. I found this http://wiki.dlang.org/Review_Queue but it's kind of short. Best regards, Mike issues.dlang.org is the official bug tracker and has plenty to work through.
