Re: Internal Compiler Error Help
On Thursday, 21 May 2015 at 10:24:59 UTC, John Colvin wrote:
On Thursday, 21 May 2015 at 08:55:45 UTC, Saurabh Das wrote:
Thanks!
Wow, dustmite is really useful. It reduces the expression down
to:
double someFunction(double AvgPriceChangeNormalized, double
TicksTenMinutesNormalized)
{
return
(TicksTenMinutesNormalized?1:AvgPriceChangeNormalized)?1:TicksTenMinutesNormalized/(TicksTenMinutesNormalized==0)==0;
}
Which gives a compiler error: Internal error: backend/cod1.c
1562
make that
double foo(double a, double b)
{
return (b ? 1 : a) ? 1 : b / (b == 0) == 0;
}
and please submit to https://issues.dlang.org
That expression is, not to put too fine a point on it, mad. The
operator precedence itself is giving me a headache, let alone
the division of a double by a boolean... I'm pretty sure it
doesn't do what you want it to, unless what you want is
seriously weird.
As a matter of fact, i'm pretty sure that expression evaluates
to 1, irrelevant of the values of the two variables.
s/irrelevant/irrespective/
Re: Internal Compiler Error Help
On Thursday, 21 May 2015 at 11:36:15 UTC, Saurabh Das wrote:
PS: The original expression:
http://dpaste.dzfl.pl/raw/e7a66aa067ab
double someFunction(double AvgPriceChangeNormalized, double
DayFactor, double TicksTenMinutesNormalized)
{
return
AvgPriceChangeNormalized)*(0.0868))*((DayFactor)*(TicksTenMinutesNormalized)))*(((AvgPriceChangeNormalized)*(0.0868))*(TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)==0)?(1):(((TicksTenMinutesNormalized)+(-0.865))/((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))*(TicksTenMinutesNormalized;
}
fair enough. I thought normally you'd want to have some sort of
expression simplification in genetic programming, to avoid adding
too many superfluous degrees of freedom? Aside from the obvious
problems, those extra degrees of freedom can put you at risk of
overfitting.
Re: Monday is last day for DConf 2015 registrations
On Thursday, 21 May 2015 at 13:42:37 UTC, Steven Schveighoffer wrote: On 5/19/15 6:59 PM, Brad Anderson wrote: On Monday, 18 May 2015 at 19:59:08 UTC, Steven Schveighoffer wrote: [snip] I just booked a car, but could cancel it. Anyone from the area know whether it's worth having a car there or should I just book a shuttle to/from the airport? The Salt Lake and Utah county areas are a bit of a sprawl but our public transit is one of the better in the United States. Went the shuttle route. If anyone interested, it's $68 round trip ($34 each way) to Orem via http://www.expressshuttleutah.com/ Roundtrip lightrail/train (TRAX/Frontrunner) from the airport to Orem's Hampton Inn is $11, I believe. Doesn't work for me I think because of the late arrival time (10 pm), thanks for the info though. BTW, my first dconf, I tried public transportation in San Francisco. Got to my hotel after 2 hours of bus/train for what is about a 30 minute drive. Only cost me $7 though! I like the shuttle idea :) BTW, I will stress again that I'm going to be at the hotel all day Tuesday (and without a car) if anyone is interested in hanging out :) -Steve I'm in Salt Lake City from this Saturday evening, so anyone who's around early, feel free to get in touch (john dot loughran dot colvin at gmail).
Re: Type tuple pointers
On Thursday, 21 May 2015 at 16:11:30 UTC, Timon Gehr wrote:
On 05/21/2015 05:37 PM, Dicebot wrote:
On Thursday, 21 May 2015 at 15:30:59 UTC, Alex Parrill wrote:
They aren't types themselves, so `TypeTuple!(int, char) var`
doesn't
make sense.
Sadly, you are wrong on this one - this is actually a valid
variable
declaration which will create two distinct local variables and
uses
their aliases in resulting symbol list named 'var'.
A wacky property of such variable declarations is this one:
import std.stdio;
alias Seq(T...)=T;
void main(){
char y='a';
Seq!(char,char) x=y++;
writeln(x);
}
Yikes.
Re: Using arrays of function pointers in D
On Thursday, 21 May 2015 at 16:23:15 UTC, John wrote:
I've been rewriting one of my emulators in D and am fairly new
to the language. I'm having trouble finding documentation on
creating/initializing/use of arrays of function pointers in D.
If anyone has a code example I'd appreciate it!
float foo(int a, float b)
{
import std.stdio;
writeln(a, b);
return a+b;
}
void main()
{
float function(int, float)[] arrayOfFPs;
arrayOfFPs = new float function(int, float)[42];
arrayOfFPs[0] = foo;
auto r = arrayOfFPs[0](3, 7.6);
assert(r == 3+7.6f);
alias DT = int delegate(int);
int a = 4;
auto arrayOfDelegates = new DT[3];
arrayOfDelegates[1] = (int x) = a + x;
assert(arrayOfDelegates[1](3) == 7);
}
Re: 0 is not a power of 2
On Tuesday, 19 May 2015 at 20:46:09 UTC, Matthias Bentrup wrote:
I think you can make the over/underflow at zero work in your
favor:
bool isPowerOf2(uint x)
{
return (x -x) (x - 1);
}
Very nice
Re: 0 is not a power of 2
On Tuesday, 19 May 2015 at 05:16:48 UTC, Andrei Alexandrescu
wrote:
So there's this classic trick:
bool isPowerOf2(uint x)
{
return (x (x - 1)) == 0;
}
Pretty neat, but it wrongly returns true for x == 0. So the
obvious fix is:
bool isPowerOf2(uint x)
{
return x (x (x - 1)) == 0;
}
But that has branches in it. So I came up with:
bool isPowerOf2(uint x)
{
return (x (x - 1) | !x) == 0;
}
which has no branches at least with dmd, see
http://goo.gl/TVkCwc.
Any ideas for faster code?
Thanks,
Andrei
I tested with a few different (modern) backends to see what was
generated, they all essentially give you this (gcc 5.1.0 -O3
-march=broadwell):
isPowerOf2:
xorl%eax, %eax
testl %edi, %edi
je .L5
blsr%edi, %edi
testl %edi, %edi
sete%al
.L5:
ret
isPowerOf2b:
blsr%edi, %edx
xorl%eax, %eax
testl %edi, %edi
sete%al
orl %eax, %edx
sete%al
ret
but if your not restricting the build to such recent processor,
you can't emit BLSR, so you get this instead (gcc 5.1.0 -O3):
isPowerOf2b:
leal-1(%rdi), %eax
xorl%edx, %edx
andl%edi, %eax
testl %edi, %edi
sete%dl
orl %edx, %eax
sete%al
ret
Re: 0 is not a power of 2
On Tuesday, 19 May 2015 at 15:39:16 UTC, safety0ff wrote: On Tuesday, 19 May 2015 at 08:28:11 UTC, John Colvin wrote: I tested with a few different (modern) backends to see what was generated, they all essentially give you this (gcc 5.1.0 -O3 -march=broadwell): isPowerOf2: xorl%eax, %eax testl %edi, %edi je .L5 blsr%edi, %edi testl %edi, %edi sete%al .L5: ret I think you used: return x (x (x - 1)) == 0; instead of return (x (x - 1)) == 0 x; Which influences code generation (more weight on the x == 0 test,) hence the branch. I used what andrei posted, but yes i do see the difference. How infuriating. A compiler that will entirely restructure your code leaving you with something unrecognisable in many cases, but in others is sensitive to the order of operands around an .
Re: The analogue of fill-pointer in D
On Monday, 18 May 2015 at 08:21:38 UTC, Dennis Ritchie wrote: Hi, In Common Lisp, there is such a thing as a fill-pointer (Example 5): http://www.tutorialspoint.com/lisp/lisp_arrays.htm Does D some equivalent? Fill pointers, combined with the various helper functions (e.g. vector-push) and vector-extend, perform tasks that D uses slices for. e.g. vector-push-extend is roughly equivalent to the ~= operator, given a non-aliased array. There are important differences, but the functionality overlaps a lot.
Re: Convert C array pointer to a D slice without data copy
On Monday, 18 May 2015 at 09:23:26 UTC, tcak wrote: On Monday, 18 May 2015 at 09:18:33 UTC, ParticlePeter wrote: I get the point to an array from a c function, the data size from another function. The data should be only readable at the D side, but I would like to use it as a D slice without copying the data. Is this possible ? char* dataPtr; size_t dataLen; auto data = dataPtr[0 .. dataLen]; This doesn't do any copying. BUT I am not sure what GC would be doing about it. After you use it, you might want to set `data` to null in case of a problem. No need to worry about the GC here, it only scans the stack and its own heap (unless you specifically add a new root).
Re: The analogue of fill-pointer in D
On Monday, 18 May 2015 at 11:40:13 UTC, thedeemon wrote: On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote: No, afraid not. Function capacity is not an analogue of fill-pointers! It's exactly the same. But in D capacity is affected by other things. auto a = new int[20]; auto b = arr[0..10]; //can't now append to b without re-allocating or using assumeSafeAppend.
Re: The analogue of fill-pointer in D
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote:
On Monday, 18 May 2015 at 10:14:33 UTC, Kagamin wrote:
On Monday, 18 May 2015 at 08:21:38 UTC, Dennis Ritchie wrote:
Hi,
In Common Lisp, there is such a thing as a fill-pointer
(Example 5):
http://www.tutorialspoint.com/lisp/lisp_arrays.htm
Does D some equivalent?
Data stored in the array is indicated by the array length
property, use capacity to figure out extra available space:
http://dlang.org/phobos/object.html#.capacity
No, afraid not. Function capacity is not an analogue of
fill-pointers!
Lisp-programmer explains the usefulness of fill-pointers as
follows:
Fill pointer cuts the tail of the vector. For example,
vector elements 100, but if you set the fill pointer equal to
3, the length of the array (returned by length) will be equal
to 3. The remaining elements are not visible.
It seems to be nonsense. But this is nonsense, ideal for
buffers. If the buffer is implemented as an array, then fill
pointer just marks the boundary of the filled part of the
buffer, and adding a buffer (moving away from the fill
pointer-a) is carried out using the vector-push. Or a buffer
can be filled with the format-a. If you work with the same
buffer C, fill pointer simulates a pointer to the last
completed item.
There are a lot of ways of doing this in D.
std.array.appender makes a good imitation of this, just missing
the vector-push, which can be implemented like this, roughly:
ptrdiff_t putNoAlloc(App, T)(App app, T el)
{
if (app.capacity)
{
app.put(el);
return app.data.length - 1;
}
else
return -1;
}
It would also be trivial to hand-make a type that has whatever
behaviour you want with regards to array appending, lengths etc.
Re: control flow with a functional template ?
On Monday, 18 May 2015 at 06:13:50 UTC, Baz wrote:
who's never had to do this:
---
if (comparison)
{
statement;
break;
}
---
ans then thought it's a pity to open/closes the braces just for
a
simple statement. Would it be possible to have a template to
simplify this to:
---
if (comparison)
Break!(expression);
---
or even at the language level:
---
if (comparison)
break(expression);
if (comparison)
continue(expression);
---
so far it looks like it's only possible using a string mixin,
which is a quite unelegant solution (because for example you
loose the IDE completion while writting the statement):
---
auto Break(string statement)
{
return format({%s;break;}, statement);
}
// unelegant but works...
if (condition)
mixin(myVar = 8.Break);
if (condition)
mixin(q{myVar = 8}.Break);
---
Any other solution ?
Take a look at lazy function arguments if you really want this.
Personally I think you'll end up saving a small handful of
keystrokes (if any) at the expense of clarity.
Re: control flow with a functional template ?
On Monday, 18 May 2015 at 08:46:36 UTC, John Colvin wrote:
On Monday, 18 May 2015 at 06:13:50 UTC, Baz wrote:
who's never had to do this:
---
if (comparison)
{
statement;
break;
}
---
ans then thought it's a pity to open/closes the braces just
for a
simple statement. Would it be possible to have a template to
simplify this to:
---
if (comparison)
Break!(expression);
---
or even at the language level:
---
if (comparison)
break(expression);
if (comparison)
continue(expression);
---
so far it looks like it's only possible using a string mixin,
which is a quite unelegant solution (because for example you
loose the IDE completion while writting the statement):
---
auto Break(string statement)
{
return format({%s;break;}, statement);
}
// unelegant but works...
if (condition)
mixin(myVar = 8.Break);
if (condition)
mixin(q{myVar = 8}.Break);
---
Any other solution ?
Take a look at lazy function arguments if you really want this.
Personally I think you'll end up saving a small handful of
keystrokes (if any) at the expense of clarity.
Wait no, actually you do need mixins, I wasn't thinking. Unless
you make the if statement a function call / template...
Re: The analogue of fill-pointer in D
On Monday, 18 May 2015 at 17:43:50 UTC, Ali Çehreli wrote:
On 05/18/2015 05:26 AM, John Colvin wrote:
On Monday, 18 May 2015 at 11:40:13 UTC, thedeemon wrote:
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote:
No, afraid not. Function capacity is not an analogue of
fill-pointers!
It's exactly the same.
But in D capacity is affected by other things.
auto a = new int[20];
auto b = arr[0..10];
//can't now append to b without re-allocating or using
assumeSafeAppend.
Perfect opportunity to inject my newly-discovered issue with
capacity:
void main()
{
auto a = new int[20];
foo(a);
//can't now append to a
}
void foo(const(int)[] p)
{
p ~= 42;
}
Ali
I don't understand what's counterintuitive here. Slices are just
pointer and length, everything else is global state.
Re: Linking to Dynamic Library on Mac OS X
On Friday, 15 May 2015 at 03:33:47 UTC, TJB wrote: I have built a toy dynamic shared library on Mac OS X (in C), and I have verified that it works from C. Now I would like to call it from D. So I have created the following interface file: $ cat hello.di extern (C): void printHelloWorld(); which I try to compile and run. But I get the following error: $ dmd main.d -L-lhello ld: library not found for -lhello clang: error: linker command failed with exit code 1 (use -v to see invocation) --- errorlevel 1 I gather that mac os x doesn't know where to find libhello.dylib (it is in the current directory). So how do I pass that information? Thanks! TJB Off the top of my head: does adding -L-L$(pwd) help?
Re: Destructured Tuple Assignment
On Friday, 15 May 2015 at 10:23:24 UTC, Per Nordlöw wrote: I recall having seen an example of using some D magic (via mixin perhaps?) to realize tuple destructuring in assignments like magic(first, _, second) = expression.findSplit(separator); somewhere. But I can't seem to find it right now. References anyone? BTW :I'm aware of Kenjis PR, which I am very much longing for ;) Well there's always this, which is a bit ugly: typeof(expression) first, _, second; TypeTuple!(first, _, second) = expression.findSplit(separator); But of course the holy grail is being able to declare variables inline.
Re: SIG11 crashing - can't figure it out
On Friday, 15 May 2015 at 11:08:06 UTC, Rob Pieké wrote:
Working my way through Ali Çehreli's rather amazing e-book,
I've hit a snag where some code I've written is pretty crashy.
I consistently get Segmentation fault: 11 (dmd 2.067.1, OSX).
I can't figure out where things are going wrong, because any
attempt I make to debug via extra print statements causes the
program to run successfully. Same if I try to compile with
-gc ... it suddenly starts working, so I can't debug with gdb.
Putting aside any that's probably not a great solution to the
problem you're tying to solve thoughts, can anyone offer me
the eureka moment I'm missing to understand why the code
below doesn't work?
Many thanks in advance!
* * *
import std.stdio;
enum Suit {
HEARTS, DIAMONDS, CLUBS, SPADES
}
enum Value {
ACE = 1, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN,
JACK, QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(in Card card) {
final switch(card.value) {
case Value.ACE:
write(A);
break;
case Value.TWO, Value.THREE, Value.FOUR, Value.FIVE,
Value.SIX, Value.SEVEN, Value.EIGHT, Value.NINE, Value.TEN:
writef(%d, card.value);
break;
case Value.JACK:
write(J);
break;
case Value.QUEEN:
write(Q);
break;
case Value.KING:
write(K);
break;
}
final switch(card.suit) {
case Suit.HEARTS:
write(♡);
break;
case Suit.DIAMONDS:
write(♢);
break;
case Suit.CLUBS:
write(♣);
break;
case Suit.SPADES:
write(♠);
break;
}
write(\n);
}
int main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
return 0;
}
It seems to be DMD specific, it works fine with ldc. If you're a
homebrew user, brew install ldc and try it for yourself.
P.s. you can use the `with` statement to make things less verbose:
import std.stdio;
enum Suit {
HEARTS, DIAMONDS, CLUBS, SPADES
}
enum Value {
ACE = 1, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN,
JACK, QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(in Card card) {
final switch(card.value) with(Value) {
case ACE:
write(A);
break;
case TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN:
writef(%d, card.value);
break;
case JACK:
write(J);
break;
case QUEEN:
write(Q);
break;
case KING:
write(K);
break;
}
final switch(card.suit) with(Suit) {
case HEARTS:
write(♡);
break;
case DIAMONDS:
write(♢);
break;
case CLUBS:
write(♣);
break;
case SPADES:
write(♠);
break;
}
write(\n);
}
void main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
}
Re: SIG11 crashing - can't figure it out
On Friday, 15 May 2015 at 11:44:32 UTC, John Colvin wrote:
On Friday, 15 May 2015 at 11:08:06 UTC, Rob Pieké wrote:
Working my way through Ali Çehreli's rather amazing e-book,
I've hit a snag where some code I've written is pretty crashy.
I consistently get Segmentation fault: 11 (dmd 2.067.1, OSX).
I can't figure out where things are going wrong, because any
attempt I make to debug via extra print statements causes the
program to run successfully. Same if I try to compile with
-gc ... it suddenly starts working, so I can't debug with
gdb.
Putting aside any that's probably not a great solution to the
problem you're tying to solve thoughts, can anyone offer me
the eureka moment I'm missing to understand why the code
below doesn't work?
Many thanks in advance!
* * *
import std.stdio;
enum Suit {
HEARTS, DIAMONDS, CLUBS, SPADES
}
enum Value {
ACE = 1, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE,
TEN, JACK, QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(in Card card) {
final switch(card.value) {
case Value.ACE:
write(A);
break;
case Value.TWO, Value.THREE, Value.FOUR, Value.FIVE,
Value.SIX, Value.SEVEN, Value.EIGHT, Value.NINE, Value.TEN:
writef(%d, card.value);
break;
case Value.JACK:
write(J);
break;
case Value.QUEEN:
write(Q);
break;
case Value.KING:
write(K);
break;
}
final switch(card.suit) {
case Suit.HEARTS:
write(♡);
break;
case Suit.DIAMONDS:
write(♢);
break;
case Suit.CLUBS:
write(♣);
break;
case Suit.SPADES:
write(♠);
break;
}
write(\n);
}
int main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
return 0;
}
It seems to be DMD specific, it works fine with ldc. If you're
a homebrew user, brew install ldc and try it for yourself.
P.s. you can use the `with` statement to make things less
verbose:
import std.stdio;
enum Suit {
HEARTS, DIAMONDS, CLUBS, SPADES
}
enum Value {
ACE = 1, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN,
JACK, QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(in Card card) {
final switch(card.value) with(Value) {
case ACE:
write(A);
break;
case TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN:
writef(%d, card.value);
break;
case JACK:
write(J);
break;
case QUEEN:
write(Q);
break;
case KING:
write(K);
break;
}
final switch(card.suit) with(Suit) {
case HEARTS:
write(♡);
break;
case DIAMONDS:
write(♢);
break;
case CLUBS:
write(♣);
break;
case SPADES:
write(♠);
break;
}
write(\n);
}
void main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
}
Please submit a bug report at issues.dlang.org
Re: Linking to Dynamic Library on Mac OS X
On Friday, 15 May 2015 at 19:39:53 UTC, TJB wrote: Off the top of my head: does adding -L-L$(pwd) help? This is what I get: $ dmd main.d -L-L$(pwd) -lhello Error: unrecognized switch '-lhello' Sorry if this is completely elementary and I am being quite dumb. Thanks, TJB should be $ dmd main.d -L-L$(pwd) -L-lhello The -L means send the following argument to the linker. Note that you may also find you need to help OS X find the dylib when running the program, either by moving it to one of the system locations or using DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH (see http://stackoverflow.com/questions/3146274/is-it-ok-to-use-dyld-library-path-on-mac-os-x-and-whats-the-dynamic-library-s). However, I think the runtime linker looks in the present directory by default, so you might get away with it.
Re: problem with parallel foreach
On Thursday, 14 May 2015 at 10:46:53 UTC, Gerald Jansen wrote: John Colvin's improvements to my D program seem to have resolved the problem. (http://forum.dlang.org/post/ydgmzhlspvvvrbeem...@forum.dlang.org and http://dpaste.dzfl.pl/114d5a6086b7). I have rerun my tests and now the picture is a bit different (see tables below). In the middle table I have used gnu parallel in combination with a slightly modified version of the D program which runs a single trait (specified in argv[1]). This approach runs the jobs as completely isolated processes, but at the extra cost of re-reading the common data for each trait. The elapsed time is very similar with the parallel foreach in the D program or using gnu parallel (for this particular program and these data run on this server...). I'm guessing the program is now essentially limited by disk I/O, so this is about as good as it gets. So, just to wrap up: - there is a nice speed improvement over Python program :-) - one needs to learn a fair bit to fully benefit from D's potential - thanks for all the help! Gerald Jansen Jobs __ time for D parallel foreach w. JC mods 1 4.71user 0.56system 0:05.28elapsed 99%CPU 2 6.59user 0.96system 0:05.48elapsed 137%CPU 411.45user 1.94system 0:07.24elapsed 184%CPU 820.30user 5.18system 0:13.16elapsed 193%CPU 16 68.48user 13.87system 0:27.21elapsed 302%CPU 27 99.66user 18.73system 0:42.34elapsed 279%CPU Jobs __ gnu parallel + D program for single job __ 1 4.71user 0.56system 0:05.28elapsed 99%CPU as above 2 9.66user 1.28system 0:05.76elapsed 189%CPU 418.86user 3.85system 0:08.15elapsed 278%CPU 840.76user 7.53system 0:14.69elapsed 328%CPU 16 135.76user 20.68system 0:31.06elapsed 503%CPU 27 189.43user 28.26system 0:47.75elapsed 455%CPU Jobs _ time for python version _ 145.39user 1.52system 0:46.88elapsed 100%CPU 277.76user 2.42system 0:47.16elapsed 170%CPU 4 141.28user 4.37system 0:48.77elapsed 298%CPU 8 280.45user 8.80system 0:56.00elapsed 516%CPU 16 926.05user 20.48system 1:31.36elapsed 1036%CPU 27 1329.09user 27.18system 2:11.79elapsed 1029%CPU Would it be OK if I showed some parts of this code as examples in my DConf talk in 2 weeks?
Re: std.parallelism equivalents for posix fork and multi-machine processing
On Wednesday, 13 May 2015 at 20:34:24 UTC, weaselcat wrote: On Wednesday, 13 May 2015 at 20:28:02 UTC, Laeeth Isharc wrote: Is there value to having equivalents to the std.parallelism approach that works with processes rather than threads, and makes it easy to manage tasks over multiple machines? I'm not sure if you're asking because of this thread, but see http://forum.dlang.org/thread/tczkndtepnvppggzm...@forum.dlang.org#post-tczkndtepnvppggzmews:40forum.dlang.org python outperforming D because it doesn't have to deal with synchronization headaches. I found D to be way faster when reimplemented with fork, but having to use the stdc API is ugly(IMO) It was also easy to get D very fast by just being a little more eager with IO and reducing the enormous number of little allocations being made.
Re: Accessing x86 Performance Counters
On Wednesday, 13 May 2015 at 03:38:33 UTC, Maxime Chevalier-Boisvert wrote: I was wondering if anyone has written D code to access the x86 performance counters, to get information such as the number of cache misses and cycle count. It would probably be easiest to write some bindings to PAPI-C or similar. As far as I know, DIY hardware performance monitoring isn't worth the effort.
Re: problem with parallel foreach
On Tuesday, 12 May 2015 at 18:14:56 UTC, Gerald Jansen wrote: On Tuesday, 12 May 2015 at 16:35:23 UTC, Rikki Cattermole wrote: On 13/05/2015 4:20 a.m., Gerald Jansen wrote: At the risk of great embarassment ... here's my program: http://dekoppel.eu/tmp/pedupg.d Would it be possible to give us some example data? I might give it a go to try rewriting it tomorrow. http://dekoppel.eu/tmp/pedupgLarge.tar.gz (89 Mb) Contains two largish datasets in a directory structure expected by the program. I only see 2 traits in that example, so it's hard for anyone to explore your scaling problem, seeing as there are a maximum of 2 tasks.
Re: problem with parallel foreach
On Wednesday, 13 May 2015 at 11:33:55 UTC, John Colvin wrote: On Tuesday, 12 May 2015 at 18:14:56 UTC, Gerald Jansen wrote: On Tuesday, 12 May 2015 at 16:35:23 UTC, Rikki Cattermole wrote: On 13/05/2015 4:20 a.m., Gerald Jansen wrote: At the risk of great embarassment ... here's my program: http://dekoppel.eu/tmp/pedupg.d Would it be possible to give us some example data? I might give it a go to try rewriting it tomorrow. http://dekoppel.eu/tmp/pedupgLarge.tar.gz (89 Mb) Contains two largish datasets in a directory structure expected by the program. I only see 2 traits in that example, so it's hard for anyone to explore your scaling problem, seeing as there are a maximum of 2 tasks. Either way, a few small changes were enough to cut the runtime by a factor of ~6 in the single-threaded case and improve the scaling a bit, although the printing to output files still looks like a bit of a bottleneck. http://dpaste.dzfl.pl/80cd36fd6796 The key thing was reducing the number of allocations (more std.algorithm.splitter copying to static arrays, less std.array.split) and avoiding File.byLine. Other people in this thread have mentioned alternatives to it that may be faster/have lower memory usage, I just read the whole files in to memory and then lazily split them with std.algorithm.splitter. I ended up with some blank lines coming through, so i added if(line.empty) continue; in a few places, you might want to look more carefully at that, it could be my mistake. The use of std.array.appender for `info` is just good practice, but it doesn't make much difference here.
Re: problem with parallel foreach
On Wednesday, 13 May 2015 at 14:28:52 UTC, Gerald Jansen wrote: On Wednesday, 13 May 2015 at 13:40:33 UTC, John Colvin wrote: On Wednesday, 13 May 2015 at 11:33:55 UTC, John Colvin wrote: On Tuesday, 12 May 2015 at 18:14:56 UTC, Gerald Jansen wrote: On Tuesday, 12 May 2015 at 16:35:23 UTC, Rikki Cattermole wrote: On 13/05/2015 4:20 a.m., Gerald Jansen wrote: At the risk of great embarassment ... here's my program: http://dekoppel.eu/tmp/pedupg.d Would it be possible to give us some example data? I might give it a go to try rewriting it tomorrow. http://dekoppel.eu/tmp/pedupgLarge.tar.gz (89 Mb) Contains two largish datasets in a directory structure expected by the program. I only see 2 traits in that example, so it's hard for anyone to explore your scaling problem, seeing as there are a maximum of 2 tasks. Either way, a few small changes were enough to cut the runtime by a factor of ~6 in the single-threaded case and improve the scaling a bit, although the printing to output files still looks like a bit of a bottleneck. http://dpaste.dzfl.pl/80cd36fd6796 The key thing was reducing the number of allocations (more std.algorithm.splitter copying to static arrays, less std.array.split) and avoiding File.byLine. Other people in this thread have mentioned alternatives to it that may be faster/have lower memory usage, I just read the whole files in to memory and then lazily split them with std.algorithm.splitter. I ended up with some blank lines coming through, so i added if(line.empty) continue; in a few places, you might want to look more carefully at that, it could be my mistake. The use of std.array.appender for `info` is just good practice, but it doesn't make much difference here. Wow, I'm impressed with the effort you guys (John, Rikki, others) are making to teach me some efficiency tricks. I guess this is one of the strengths of D: its community. I'm studying your various contributions closely! The empty line comes from the very last line on the files, which also end with a newline (as per normal practice?). Yup, that would be it. I added a bit of buffered writing and it actually seems to scale quite well for me now. http://dpaste.dzfl.pl/710afe8b6df5
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 12 May 2015 at 21:44:04 UTC, Kelly wrote: Well the first fully working example of a large library is finally working with Calypso. Elie has managed to get a Qt5 demo program to compile and run!! The demo is a D version of the Qt5 Widgets demo. This is a simple window with a pseudo address book app. The demo uses a D class inheriting from QWidget, calls 'super(parent)' from D code and uses the QStrings, QLabel, QLineEdit, QLayout, QGridLayout classes, among other things. You can see the code here: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d The demo is confirmed to work with Qt5.4 and Qt5.2.1. While this might not seem like a really big deal, please keep in mind that while compiling this demo, Calypso effectively parses and produces 692 object files, including large swathes of the C++ STL and most of the Qt library! The latest push last night also cut down on compile times quite a lot. Doing the initial compile of the example takes about 28 seconds on my mid-level Intel i5 machine, versus around 2 seconds for just the C++ version. After generating a cache file with last nights commits you can recompile the project in just 7.5 seconds...which I think is quite good for just getting things up and running :) Thanks, Kelly That's great! I'm looking forward to being able to easily make direct use of some of the great C++ code out there. Are there are performance pitfalls to watch out for that are unique to the way calypso interfaces between D and C++? E.g. sneaky copies, implicit callbacks to keep things synced etc.
Re: problem with parallel foreach
On Wednesday, 13 May 2015 at 14:43:50 UTC, John Colvin wrote: On Wednesday, 13 May 2015 at 14:28:52 UTC, Gerald Jansen wrote: On Wednesday, 13 May 2015 at 13:40:33 UTC, John Colvin wrote: On Wednesday, 13 May 2015 at 11:33:55 UTC, John Colvin wrote: On Tuesday, 12 May 2015 at 18:14:56 UTC, Gerald Jansen wrote: On Tuesday, 12 May 2015 at 16:35:23 UTC, Rikki Cattermole wrote: On 13/05/2015 4:20 a.m., Gerald Jansen wrote: At the risk of great embarassment ... here's my program: http://dekoppel.eu/tmp/pedupg.d Would it be possible to give us some example data? I might give it a go to try rewriting it tomorrow. http://dekoppel.eu/tmp/pedupgLarge.tar.gz (89 Mb) Contains two largish datasets in a directory structure expected by the program. I only see 2 traits in that example, so it's hard for anyone to explore your scaling problem, seeing as there are a maximum of 2 tasks. Either way, a few small changes were enough to cut the runtime by a factor of ~6 in the single-threaded case and improve the scaling a bit, although the printing to output files still looks like a bit of a bottleneck. http://dpaste.dzfl.pl/80cd36fd6796 The key thing was reducing the number of allocations (more std.algorithm.splitter copying to static arrays, less std.array.split) and avoiding File.byLine. Other people in this thread have mentioned alternatives to it that may be faster/have lower memory usage, I just read the whole files in to memory and then lazily split them with std.algorithm.splitter. I ended up with some blank lines coming through, so i added if(line.empty) continue; in a few places, you might want to look more carefully at that, it could be my mistake. The use of std.array.appender for `info` is just good practice, but it doesn't make much difference here. Wow, I'm impressed with the effort you guys (John, Rikki, others) are making to teach me some efficiency tricks. I guess this is one of the strengths of D: its community. I'm studying your various contributions closely! The empty line comes from the very last line on the files, which also end with a newline (as per normal practice?). Yup, that would be it. I added a bit of buffered writing and it actually seems to scale quite well for me now. http://dpaste.dzfl.pl/710afe8b6df5 Fixed the file reading spare '\n' problem, added some comments. http://dpaste.dzfl.pl/114d5a6086b7
Re: Shouldn't assert declarations be seen in documentation?
On Tuesday, 12 May 2015 at 10:40:48 UTC, tcak wrote: I am developing a web server - web application system, and it is going to be running on a small system that has 256MB memory at maximum. Hence, I tried to use every bit of memory without wasting, and used align(1) on a struct type. Because it is used as shared, and its internal variables are updated in time, core.atomic.atomicOp is being used. Until today, whenever I tried to update variables with atomicOp, running thread was basically returning from that point like nothing happened. After long debugging, I finally saw that thread has given AssertError with a line number. There wasn't any information about what was going on. I went to core.atomic file, and found out that (not on the given line number), variables should be properly aligned to use atomicOp. In my opinion they should be in in contracts and documented, yes.
Re: Run-time Indexing of a Compile-Time Tuple
On Monday, 11 May 2015 at 22:46:00 UTC, Per Nordlöw wrote:
The pattern
final switch (_index)
{
import std.range: empty, front;
foreach (i, R; Rs)
{
case i:
assert(!source[i].empty);
return source[i].front;
}
}
occurring in roundRobin() and now also in my merge at
https://github.com/nordlow/justd/blob/master/range_ex.d#L604
is nor pretty nor concise.
Is there a better way of indexing a compile time tuple with a
run-time index?
It may have to work together with CommonType somehow as is
shown in my implementation of merge().
I wrote that code in roundRobin to replace a nightmare string
mixin. I can't see any way of getting around it, as there is no
meaningful CommonType for a tuple of arbitrary ranges. The body
of each case statement needs to know the index at compile-time.
If the tuple genuinely did have a CommonType, then it would be
easy to make a little free function (or member of
std.typecons.tuple) to get this sort of result:
import std.typecons, std.traits;
CommonType!(T.Types) rtIdx(T)(T t, uint i)
if(is(T : Tuple!A, A...))
in
{
assert(i t.length);
}
body
{
final switch(i)
{
foreach(ctI, m; t)
{
case ctI:
return t[ctI];
}
}
assert(0);
}
unittest
{
uint i = 2;
Tuple!(int, long, byte) myTuple;
myTuple[2] = 42;
auto a = myTuple.rtIdx(i);
static assert(is(typeof(a) == long));
assert(a == 42);
}
You could probably extend this to take expression tuples as well
or whatever the hell we call compiler tuples that contain runtime
values these days.
Alternatively, you could make rtIndex return a struct that
defines opIndex, so you could write
auto a = myTuple.rtIdx[i];
opSlice would be doable as well, to round it out.
Re: Run-time Indexing of a Compile-Time Tuple
On Tuesday, 12 May 2015 at 09:26:07 UTC, John Colvin wrote:
On Monday, 11 May 2015 at 22:46:00 UTC, Per Nordlöw wrote:
The pattern
final switch (_index)
{
import std.range: empty, front;
foreach (i, R; Rs)
{
case i:
assert(!source[i].empty);
return source[i].front;
}
}
occurring in roundRobin() and now also in my merge at
https://github.com/nordlow/justd/blob/master/range_ex.d#L604
is nor pretty nor concise.
Is there a better way of indexing a compile time tuple with a
run-time index?
It may have to work together with CommonType somehow as is
shown in my implementation of merge().
I wrote that code in roundRobin to replace a nightmare string
mixin. I can't see any way of getting around it, as there is no
meaningful CommonType for a tuple of arbitrary ranges. The body
of each case statement needs to know the index at compile-time.
Correction: there are ways around it, but none of them are
improvements.
Re: dmd build instructions from source don't work anymore
On Tuesday, 12 May 2015 at 06:20:12 UTC, Ali Çehreli wrote: On 05/11/2015 10:23 AM, Timothee Cour via Digitalmars-d wrote: I notice CC is set to 'g++' in posix.mak which is untypical (instead of gcc for example) That is required because although all implementation files are C++, they have extension .c. If CC were gcc, it would assume C compilation. Therefore, g++ is needed to make it C++ compilation. Ali Same for clang IIRC.
Re: D looses in speed to Common Lisp
On Monday, 11 May 2015 at 22:22:23 UTC, anonymous wrote: Optimization flags don't seem to matter much for this program. Most of the bigint work is probably happening in handwritten assembly code and the memory allocation code is compiled in to druntime, so the optimiser isn't really getting much important to work on.
Re: problem with parallel foreach
On Tuesday, 12 May 2015 at 14:59:38 UTC, Gerald Jansen wrote:
I am a data analyst trying to learn enough D to decide whether
to use D for a new project rather than Python + Fortran. I
have recoded a non-trivial Python program to do some simple
parallel data processing (using the map function in Python's
multiprocessing module and parallel foreach in D). I was very
happy that my D version ran considerably faster that Python
version when running a single job but was soon dismayed to find
that the performance of my D version deteriorates rapidly
beyond a handful of jobs whereas the time for the Python
version increases linearly with the number of jobs per cpu core.
The server has 4 quad-core Xeons and abundant memory compared
to my needs for this task even though there are several million
records in each dataset. The basic structure of the D program
is:
import std.parallelism; // and other modules
function main()
{
// ...
// read common data and store in arrays
// ...
foreach (job; parallel(jobs, 1)) {
runJob(job, arr1, arr2.dup);
}
}
function runJob(string job, in int[] arr1, int[] arr2)
{
// read file of job specific data file and modify arr2 copy
// write job specific output data file
}
The output of /usr/bin/time is as follows:
Lang JobsUser System Elapsed %CPU
Py 1 45.171.44 0:46.65 99
D 18.441.17 0:09.24 104
Py 2 79.242.16 0:48.90 166
D 2 19.41 10.14 0:17.96 164
Py 30 1255.17 58.38 2:39.54 823 * Pool(12)
D 30 421.61 4565.97 6:33.73 1241
(Note that the Python program was somewhat optimized with numpy
vectorization and a bit of numba jit compilation.)
The system time varies widely between repititions for D with
multiple jobs (eg. from 3.8 to 21.5 seconds for 2 jobs).
Clearly simple my approach with parallel foreach has some
problem(s). Any suggestions?
Gerald Jansen
Have you tried adjusting the workUnitSize argument to parallel?
It should probably be 1 for such large individual tasks.
Re: problem with parallel foreach
On Tuesday, 12 May 2015 at 15:11:01 UTC, John Colvin wrote:
On Tuesday, 12 May 2015 at 14:59:38 UTC, Gerald Jansen wrote:
I am a data analyst trying to learn enough D to decide whether
to use D for a new project rather than Python + Fortran. I
have recoded a non-trivial Python program to do some simple
parallel data processing (using the map function in Python's
multiprocessing module and parallel foreach in D). I was very
happy that my D version ran considerably faster that Python
version when running a single job but was soon dismayed to
find that the performance of my D version deteriorates rapidly
beyond a handful of jobs whereas the time for the Python
version increases linearly with the number of jobs per cpu
core.
The server has 4 quad-core Xeons and abundant memory compared
to my needs for this task even though there are several
million records in each dataset. The basic structure of the D
program is:
import std.parallelism; // and other modules
function main()
{
// ...
// read common data and store in arrays
// ...
foreach (job; parallel(jobs, 1)) {
runJob(job, arr1, arr2.dup);
}
}
function runJob(string job, in int[] arr1, int[] arr2)
{
// read file of job specific data file and modify arr2 copy
// write job specific output data file
}
The output of /usr/bin/time is as follows:
Lang JobsUser System Elapsed %CPU
Py 1 45.171.44 0:46.65 99
D 18.441.17 0:09.24 104
Py 2 79.242.16 0:48.90 166
D 2 19.41 10.14 0:17.96 164
Py 30 1255.17 58.38 2:39.54 823 * Pool(12)
D 30 421.61 4565.97 6:33.73 1241
(Note that the Python program was somewhat optimized with
numpy vectorization and a bit of numba jit compilation.)
The system time varies widely between repititions for D with
multiple jobs (eg. from 3.8 to 21.5 seconds for 2 jobs).
Clearly simple my approach with parallel foreach has some
problem(s). Any suggestions?
Gerald Jansen
Have you tried adjusting the workUnitSize argument to parallel?
It should probably be 1 for such large individual tasks.
ignore me, i missed that you already had done that.
Re: dmd build instructions from source don't work anymore
On Monday, 11 May 2015 at 08:31:19 UTC, Timothee Cour wrote: git clone git://github.com/D-Programming-Language/dmd.git cd dmd make -f posix.mak MODEL=64 /Applications/Xcode.app/Contents/Developer/usr/bin/make -C src -f posix.mak no cpu specified, assuming X86 dmd idgen.d g++ -m64: No such file or directory --- errorlevel 255 make[1]: *** [idgen] Error 255 make: *** [all] Error 2 Do you 1) already have a version of dmd installed (relatively new requirement) and 2) have a working g++, whether of clang or gcc variety? On my machine g++ is in /usr/bin and is actually clang, although not as a symbolic link, as a slightly differently configured executable. Don't really know what apple's thinking here was.
Re: D needs...
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ I think in auto length for fixed-length arrays you want auto c = [1, 2, 3].s; instead of int[] c = [1, 2, 3].s; in order to be as close to the int[$] idea as possible.
Re: dmd build instructions from source don't work anymore
On Monday, 11 May 2015 at 12:25:27 UTC, Daniel Murphy wrote: John Colvin wrote in message news:jsnuhemrispqiwvwl...@forum.dlang.org... Do you 1) already have a version of dmd installed (relatively new requirement) Yeah, it's this. Which page is this that needs updating? I don't see the necessary info in http://wiki.dlang.org/Building_DMD, but I might have missed it.
Wiki table for available compiler packages by platform/OS
I took the time to research the status quo in D compiler availability on a variety of OSs. http://wiki.dlang.org/Compilers#Package_and.2For_binary_availability.2C_by_platform_and_compiler The reason I am posting this in announce is that, for it to be worth having, it will need to be kept up to date by the various people who maintain these packages and/or users who notice changes.
Re: D looses in speed to Common Lisp
On Monday, 11 May 2015 at 21:15:33 UTC, Dzhon Smit wrote:
Just in case you wonder, here's a comparison of the Fibonacci
numbers. The D code was written by Dennis Ritchie (a user of
this forum, not the guy who invented C).
[code]import std.stdio, std.bigint;
void main() {
BigInt[] fib1, fib2;
BigInt last = 0, next = 1;
int n = 10;
int i;
while (i != n) {
fib1 ~= last, last = next, next += fib1[$ - 1];
++i;
}
i = 0, last = 0, next = 1;
while (i != n) {
fib2 ~= last, last = next, next += fib2[$ - 1];
++i;
}
BigInt sumFib1;
foreach (e; fib1) {
sumFib1 += e;
}
BigInt sumFib2;
foreach (e; fib2) {
sumFib2 += e;
}
writeln(sumFib2 - sumFib1); // 0
}[/code]
[code] fib.lisp
(defun main ()
(let ((n 10))
(let ((fib1 (do ((i 0 (incf i))
(last 0 next)
(next 1 (+ next last))
(fib '() (cons last fib)))
((= i n) (nreverse fib
(fib2 (do ((i 0 (incf i))
(last 0 next)
(next 1 (+ next last))
(fib '() (cons last fib)))
((= i n) (nreverse fib)
(let ((sum-fib-1 (loop :for e :in fib1 :sum e))
(sum-fib-2 (loop :for e :in fib2 :sum e)))
(- sum-fib-2 sum-fib-1)
(format t ~D~% (main))[/code]
Tests on my machine:
[code]$ time ./fib
0
real0m6.458s
user0m2.250s
sys 0m0.933s
$ time sbcl --dynamic-space-size 4GB --script fib.lisp
0
real0m1.884s
user0m1.290s
sys 0m0.260s[/code]
[quote]Email address
When posting, you need to indicate an email address. It doesn't
need to be a valid one; this software will not send anything to
the specified address. The email address will be made public to
other users of the news server / mailing list you are posting
to. Therefore, please be aware that malicious robots may be
able to collect your address and send spam to it.[/quote]
This is quite disappointing, I'd prefer spam from this forum
rather than from elsewhere.
Turns out you can write slow code in any language. Who knew?
Re: Tuple assignment
On Sunday, 10 May 2015 at 08:07:38 UTC, Russel Winder wrote: On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: […] It probably depends on the compiler. The way to find out is to look at the generated assembler. pedant-modeassembly language file, not assembler (which is the program to do the transformation)/pedant-mode ldc2 and gdc have options to write the assembly language file, maybe I am missing it but dmd appears not to advertise such an option. What's wrong with objdump?
Re: readf error bug?
On Saturday, 9 May 2015 at 08:41:49 UTC, Dave Akers wrote:
On Saturday, 9 May 2015 at 08:34:42 UTC, Dennis Ritchie wrote:
On Saturday, 9 May 2015 at 08:30:31 UTC, Dave Akers wrote:
The following...
import std.stdio;
void main() {
write(How many students are there? );
int studentCount;
readf(%s, studentCount);
write(How many teachers are there? );
int teacherCount;
readf(%s, teacherCount);
writefln(Got it: there are %d students., studentCount);
writefln(And there are %d teachers., teacherCount);
}
When given the input...
10
42
will produce the error...
std.conv.ConvException@/usr/include/dlang/dmd/std/conv.d(2013):
Unexpected '4' when converting from type LockingTextReader to
type int
I understand what is wrong and how to fix it but the produced
error is
incorrect.
To '\ n' does not remain in the input stream, it is necessary
to write so:
-
readf(%s , studentCount);
I was meaning this as a bug report.
issues.dlang.org please, otherwise no-one will remember to fix it.
Re: Lambda functions in D
On Saturday, 9 May 2015 at 14:47:21 UTC, Russel Winder wrote:
On Sat, 2015-05-09 at 07:15 -0700, Ali Çehreli via
Digitalmars-d-learn wrote:
On 05/09/2015 04:59 AM, Dennis Ritchie wrote:
On Saturday, 9 May 2015 at 11:49:48 UTC, Timon Gehr wrote:
assert((function int(int
x)=x?x*__traits(parent,{})(x-1):1)(10)==3628800);
Thanks. Yes, it is similar to what I wanted :)
Also interesting:
http://rosettacode.org/wiki/Y_combinator#D
I think that code was improved by Timon Gehr as well.
Ali
Sadly all the solutions are unsound since they are recursive
but not
tail recursive. Oh it doesn't matter as D doesn't have tail call
optimization.
There are lots of good imperative implementations.
Of course none of the implementation can calculate
factorial(24) as
they are using hardware values which are bounded and cannot
store
reasonable numbers.
Could use iota. Oh no we can't as BigNums are not integral.
you could probably use sequence, or even recurrence.
Re: a success story for D ! !!
On Wednesday, 6 May 2015 at 07:43:28 UTC, d coder wrote: But, a fair chunk of code. Maybe there's little activity recently because they consider it done. I haven't committed to the majority of my github things for months, but I still stand by them. Greetings I am the lead developer of Vlang. Vlang is still being actively worked on. We are not pushing in more recent code into Github since the code requires Github HEAD version of DMD to compile. We are using some metaprogramming features that are available only with the development version of DMD. Regards - Puneet You could push to a different branch (develop perhaps) and make a note in the readme (in both master and develop) about the different DMD version requirements.
Re: vibed: how to use pure HTML instead of template engine?
On Wednesday, 6 May 2015 at 14:28:26 UTC, Adam D. Ruppe wrote: On Wednesday, 6 May 2015 at 14:23:27 UTC, Chris wrote: Especially this: http://vibed.org/templates/diet#embedded-code I think that's a misfeature... if I used vibe.d, I'd want to avoid the diet too. I quite like them. Obviously one can get too carried away, but overall they've been useful for me, especially when I'm working to very tight deadlines.
Re: std.xml2 (collecting features)
On Tuesday, 5 May 2015 at 10:41:37 UTC, Mario Kröplin wrote: On Monday, 4 May 2015 at 19:28:25 UTC, Jacob Carlborg wrote: On 2015-05-03 19:39, Robert burner Schadek wrote: Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2 I recommend benchmarking against the Tango pull parser. Recently, I compared DOM parsers for an XML files of 100 MByte: 15.8 s tango.text.xml (SiegeLord/Tango-D2) 13.4 s ae.utils.xml (CyberShadow/ae) 8.5 s xml.etree (Python) Either the Tango DOM parser is slow compared to the Tango pull parser, or the D2 port ruined the performance. As usual: system, compiler, compiler version, compilation flags?
Re: How to reuse functions
On Friday, 1 May 2015 at 03:34:53 UTC, Luigi wrote:
Hi everybody.
I am tring to use a function where its parameter is another
function, and at the same time are both already made - they
cannot be modified - and the second one has to be conditioned
before to be passed as argument.
Let's say I have these function and I cannot modify:
-jac(+d) that works on function and return real
real jac(real function(real) fun, real x) {return d(fun, x);}
real d(real function(real) fun, real x) {return fun(x);}
-F1 that works on two reals and return real
real F1(real a, real b) {return a + b;}
So I need a way to condition F1 fixing b and then pass it to
jac as argument.
To do that I've created a delegate 'simp' conditionig F1:
real delegate(real) simp(real function(real, real) f, real x) {
real _simp(real z) {
return f(z, x);
}
return _simp;
}
(here 'simp' fixes b at x).
My main is:
void main() {
real x_n = 1;
real x_m = -1;
real delegate(real) s_n = simp(F1, x_n);
//auto J = jac(s_n, x_m); //Error: function app.jac (real
function(real) fun, real x) is not callable using argument
types (real delegate(real), real)
}
the code fails because jac expect as argument a function but I
found only a delegate to obtain a simplified function without
any touch at already made functions jac, d and F1.
There is a clean way to make it possible? I mean: without to
touch (neither rewrite) jac, d and F1, obtain simplied F1 to
pass to jac.
Thaks in advance to anyone could help me.
Luigi
A combination of std.functional.reverseArgs and
std.functional.partial might help. It's unfortunately we don't
have a version that can set an arbitrary argument, only the first
one; It would be an easy improvement to make.
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 15:53:12 UTC, Ilya Yaroshenko wrote: Pipeline should be optimised (I am not sure about `tee`) by LDC, GDC and probably DMD so all examples are generaly equal. Yeah I wouldn't expect a big difference here. Even if things aren't well optimised, the various branches should be very predictable.
Re: The amazing template which does nothing
On Wednesday, 29 April 2015 at 14:18:49 UTC, Iain Buclaw wrote: On 29 April 2015 at 14:50, John Colvin via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 29 April 2015 at 12:07:58 UTC, Vladimir Panteleev wrote: On Wednesday, 29 April 2015 at 07:00:15 UTC, John Colvin wrote: On Tuesday, 28 April 2015 at 21:19:53 UTC, Vladimir Panteleev wrote: On Tuesday, 28 April 2015 at 10:24:27 UTC, Andrea Fontana wrote: Trying on d.godbolt.com it seems a lot of extra-code is generated for the first version. d.godbolt.com is dead, use asm.dlang.org d.godbolt.org (note .org not .com) works fine and will be updated to the latest GDC shortly. asm.dlang.org only has DMD. Ah, my bad! I know Iain was involved so I thought it had GDC as well :) d.godbolt.org now has the latest release as default. I take it you've been speaking to the site maintainer? :o) Looks like he downloaded the binary off gdcproject.org? Yes and yes.
Re: The amazing template which does nothing
On Tuesday, 28 April 2015 at 21:19:53 UTC, Vladimir Panteleev wrote: On Tuesday, 28 April 2015 at 10:24:27 UTC, Andrea Fontana wrote: Trying on d.godbolt.com it seems a lot of extra-code is generated for the first version. d.godbolt.com is dead, use asm.dlang.org d.godbolt.org (note .org not .com) works fine and will be updated to the latest GDC shortly. asm.dlang.org only has DMD.
Re: The amazing template which does nothing
On Wednesday, 29 April 2015 at 12:07:58 UTC, Vladimir Panteleev wrote: On Wednesday, 29 April 2015 at 07:00:15 UTC, John Colvin wrote: On Tuesday, 28 April 2015 at 21:19:53 UTC, Vladimir Panteleev wrote: On Tuesday, 28 April 2015 at 10:24:27 UTC, Andrea Fontana wrote: Trying on d.godbolt.com it seems a lot of extra-code is generated for the first version. d.godbolt.com is dead, use asm.dlang.org d.godbolt.org (note .org not .com) works fine and will be updated to the latest GDC shortly. asm.dlang.org only has DMD. Ah, my bad! I know Iain was involved so I thought it had GDC as well :) d.godbolt.org now has the latest release as default.
Re: The amazing template which does nothing
On Wednesday, 29 April 2015 at 07:49:34 UTC, Iain Buclaw wrote: On 29 Apr 2015 09:05, John Colvin via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 28 April 2015 at 21:19:53 UTC, Vladimir Panteleev wrote: On Tuesday, 28 April 2015 at 10:24:27 UTC, Andrea Fontana wrote: Trying on d.godbolt.com it seems a lot of extra-code is generated for the first version. d.godbolt.com is dead, use asm.dlang.org d.godbolt.org (note .org not .com) works fine and will be updated to the latest GDC shortly. asm.dlang.org only has DMD. Well it's using frontend 2.055, which I guess would put it at gdc-4.6 in Debian repos. Did you check the dropdown menu? There's 4.9 in there. Hopefully the latest release from gdcproject.org will be added in the next couple of days
Re: D audio playing and analysis library?
On Tuesday, 28 April 2015 at 13:43:02 UTC, Gan wrote: On Tuesday, 28 April 2015 at 11:28:42 UTC, Dragos Carp wrote: On Tuesday, 28 April 2015 at 11:18:14 UTC, Gan wrote: I found this: https://github.com/p0nce/dplug Which seems to be a good analysis library but I haven't found a library to play sounds. Is there one? https://github.com/D-Programming-Deimos/portaudio Downloaded it, put the D example in a source folder, downloaded the official library, compiled the official library, stuck the libportaudio.la with the example, ran DUB and it can't the port audio library. Undefined symbols for architecture x86_64: _Pa_CloseStream, referenced from: __Dmain in unknown.o The source is 3 years old, probably why no dub.json file. Know how to fix the library problem? What does dub -v show?
Re: The amazing template which does nothing
On Tuesday, 28 April 2015 at 10:24:27 UTC, Andrea Fontana wrote: On Tuesday, 28 April 2015 at 10:18:49 UTC, John Colvin wrote: On Tuesday, 28 April 2015 at 10:18:12 UTC, John Colvin wrote: On Tuesday, 28 April 2015 at 10:07:43 UTC, Andrea Fontana wrote: On Tuesday, 28 April 2015 at 09:23:53 UTC, Chris wrote: And this has happened to me many times. The solution Break the UFCS chain and use a local temporary variable makes me angry, because by having to do so all the beauty of chaining is lost. A very slow (i guess) workaround could be: test.toUpper.only.map!(a = This is a ~ a).front.writeln; vs the new one: test.toUpper.Identity!(a = This is a ~ a).writeln; Shouldn't be slow, your just giving the optimiser some work to do*, but you're always better off with the second one. *Assuming a good optimiser. dmd won't work this out. s/your/you're Trying on d.godbolt.com it seems a lot of extra-code is generated for the first version. Anyway I think I'm going to rename it apply. :) test.toUpper.apply!(a = This is a ~ a).writeln; It sounds better. The d.godbolt.org compilers seem a little out of date. I have found problems with their codegen/optimisation that doesn't happen in more recent versions. ldc 0.15.2 based on llvm 3.5.1 reduces both chains to identical asm.
Re: Possible to write a classic fizzbuzz example using a UFCS chain?
On Tuesday, 28 April 2015 at 16:06:16 UTC, Andrea Fontana wrote:
On Tuesday, 28 April 2015 at 13:59:48 UTC, Ivan Kazmenko wrote:
On Tuesday, 28 April 2015 at 10:46:54 UTC, Gary Willoughby
wrote:
After reading the following thread:
http://forum.dlang.org/thread/nczgumcdfystcjqyb...@forum.dlang.org
I wondered if it was possible to write a classic fizzbuzz[1]
example using a UFCS chain? I've tried and failed.
[1]: http://en.wikipedia.org/wiki/Fizz_buzz
Here is another, hopefully readable, version with lambda built
on ternary operators:
-
import std.algorithm, std.conv, std.functional, std.range,
std.stdio;
void main () {
sequence !(q{n + 1})
.map !(x =
(x % 3 == 0 ? fizz : ) ~
( x % 5 == 0 ? buzz : ) ~
(x % 3 != 0 x % 5 != 0 ? x.text : ))
.take (100)
.join ( )
.writeln;
}
-
Output:
-
1 2 fizz 4 buzz fizz 7 8 fizz buzz 11 fizz 13 14 fizzbuzz 16
17 fizz 19 buzz fizz 22 23 fizz buzz 26 fizz 28 29 fizzbuzz 31
32 fizz 34 buzz fizz 37 38 fizz buzz 41 fizz 43 44 fizzbuzz 46
47 fizz 49 buzz fizz 52 53 fizz buzz 56 fizz 58 59 fizzbuzz 61
62 fizz 64 buzz fizz 67 68 fizz buzz 71 fizz 73 74 fizzbuzz 76
77 fizz 79 buzz fizz 82 83 fizz buzz 86 fizz 88 89 fizzbuzz 91
92 fizz 94 buzz fizz 97 98 fizz buzz
-
Ivan Kazmenko.
[2, -1, -1, 0, -1, 1, 0, -1, -1, 0, 1, -1, 0, -1, -1]
.cycle
.enumerate
.drop(1)
.take(100)
.map!(a =
a[1]=0?[Fizz,Buzz,FizzBuzz][a[1]]:a[0].to!string)
.each!writeln;
An inefficient but neat version of that:
void main()
{
[3, 3, 0, 3, 1, 0, 3, 3, 0, 1, 3, 0, 3, 3, 2]
.cycle
.enumerate(1)
.take(100)
.map!(a =
[Fizz,Buzz,FizzBuzz,a[0].to!string][a[1]])
.each!writeln;
}
note `enumerate(1)` to avoid having to drop one.
But if we always print the number then we can have:
import std.range, std.stdio, std.conv, std.algorithm;
void main()
{
[,,Fizz,,Buzz,Fizz,,,Fizz,Buzz,,Fizz,,,FizzBuzz]
.cycle
.enumerate(1)
.take(100)
.each!(a = writeln(a[0],'\t',a[1]));
}
Re: The amazing template which does nothing
On Tuesday, 28 April 2015 at 10:18:12 UTC, John Colvin wrote: On Tuesday, 28 April 2015 at 10:07:43 UTC, Andrea Fontana wrote: On Tuesday, 28 April 2015 at 09:23:53 UTC, Chris wrote: And this has happened to me many times. The solution Break the UFCS chain and use a local temporary variable makes me angry, because by having to do so all the beauty of chaining is lost. A very slow (i guess) workaround could be: test.toUpper.only.map!(a = This is a ~ a).front.writeln; vs the new one: test.toUpper.Identity!(a = This is a ~ a).writeln; Shouldn't be slow, your just giving the optimiser some work to do*, but you're always better off with the second one. *Assuming a good optimiser. dmd won't work this out. s/your/you're
Re: The amazing template which does nothing
On Tuesday, 28 April 2015 at 10:07:43 UTC, Andrea Fontana wrote: On Tuesday, 28 April 2015 at 09:23:53 UTC, Chris wrote: And this has happened to me many times. The solution Break the UFCS chain and use a local temporary variable makes me angry, because by having to do so all the beauty of chaining is lost. A very slow (i guess) workaround could be: test.toUpper.only.map!(a = This is a ~ a).front.writeln; vs the new one: test.toUpper.Identity!(a = This is a ~ a).writeln; Shouldn't be slow, your just giving the optimiser some work to do*, but you're always better off with the second one. *Assuming a good optimiser. dmd won't work this out.
Re: array operations and ranges
On Monday, 27 April 2015 at 06:52:11 UTC, Manu wrote: On 27 April 2015 at 15:58, Vlad Levenfeld via Digitalmars-d digitalmars-d@puremagic.com wrote: Phobos containers already support the first line, and it would be a natural extension to make them support the second. Sure, it's not complicated. It's something I had done in this other code and showing for example. Yeah, see I don't feel making a simple thing like an array into something more complex by wrapping it in templates is ever a good thing to do. I just think it's a missed opportunity that the compiler doesn't support any of this in the language. It would appear at face value to be a great opportunity for lowering. Assignment can lower to .copy(), operators can lower to map!(...) builtin slicesopSliceAssign (and opSliceOpAssign) understanding ranges as source operands is a good idea. I might even see if I can implement it. Lowering array operations to lazy ranges seems like a huge can of worms. Not so keen. Lazy array ops are great, but I don't see it working out as a builtin feature unless it had it's own syntax.
Re: Cleaned up C++
On Saturday, 25 April 2015 at 21:26:25 UTC, Andrei Alexandrescu wrote: On 4/22/15 1:36 PM, John Colvin wrote: Is it even possible to contrive a case where 1) The default initialisation stores are technically dead and 2) Modern compilers can't tell they are dead and elide them and 3) Doing the initialisation has a significant performance impact? The boring example is extra code causes instruction cache misses. I've seen statically-sized arrays causing problems. -- Andrei Care to outline an example?
Re: Performance of loops
On Friday, 24 April 2015 at 11:00:23 UTC, Chris wrote:
I tested the performance of three types of loops (see code
below). It turns out that the fastest loop is the plainLoop.
Unless my examples are completely screwed up, the difference
between plainLoop and the other two loops is gigantic (e.g.):
9 ms, 149 μs, and 4 hnsecs // foreach (const ref w)
9 ms, 77 μs, and 8 hnsecs // foreach (ref w)
1 ms, 183 μs, and 6 hnsecs // foreach (w)
with -release -inline -O -boundscheck=off
8 ms, 492 μs, and 3 hnsecs
8 ms, 287 μs, and 1 hnsec
341 μs and 2 hnsecs
[compiler dmd v2.067.0, Linux Ubuntu, 64bit]
import std.datetime : benchmark, Duration;
import std.string : format;
import std.conv : to;
import std.stdio : writeln;
enum {
string[] words = [Hello, world, Ola, mundo],
}
void main() {
auto result = benchmark!(constLoop, refLoop,
plainLoop)(100_000);
writeln(to!Duration(result[0]));
writeln(to!Duration(result[1]));
writeln(to!Duration(result[2]));
}
void constLoop() {
size_t cnt;
foreach (const ref w; words)
cnt += w.length;
}
void refLoop() {
size_t cnt;
foreach (ref w; words)
cnt += w.length;
}
void plainLoop() {
size_t cnt;
foreach (w; words)
cnt += w.length;
}
dmd's optimiser isn't great. GDC creates identical assembly for
all three functions.
Rule of thumb: if you want high performance, use GDC or LDC.
Re: Performance of map!()
On Friday, 24 April 2015 at 10:22:05 UTC, Chris wrote:
I replaced a range that was similar to map with map and the
performance dropped by ~0.5 msec.
The range I used previously is based on Adam's D Cookbook. It
is consistently faster than map.
private struct Transformer(alias agent, R) if (isInputRange!R) {
private R r;
this (R r) {
this.r = r;
}
static if (isInfinite!R) {
enum bool empty = false;
}
else {
@property bool empty() {
return r.empty;
}
}
void popFront() {
r.popFront();
}
@property ref auto front() {
return agent(r.front);
}
static if (isForwardRange!R) {
@property auto save() {
return Transformer!(agent, R)(r.save);
}
}
static if (isBidirectionalRange!R) {
@property auto back() {
return agent(r.back);
}
void popBack() {
r.popBack();
}
}
static if (isRandomAccessRange!R) {
auto opIndex(size_t i) {
return agent(r[i]);
}
}
static if (hasLength!R) {
@property auto length() {
return r.length;
}
}
}
That is pretty much identical to the implementation of map, see
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L504
The only difference is that you don't implement opSlice. Perhaps
slicing is particularly slow for your source range?
Re: [OT] compiler optimisations
On Friday, 24 April 2015 at 06:29:55 UTC, deadalnix wrote:
On Thursday, 23 April 2015 at 10:23:57 UTC, Andrea Fontana
wrote:
On Thursday, 23 April 2015 at 10:08:24 UTC, John Colvin wrote:
asm.dlang.org
and d.godbolt.org
This isn't a D-specific question though, so gcc.godbolt.org
would allow you to test a wider range of backends.
I was wondering if compilers can optimize this:
uint foo3(uint a)
{
return a*!(a/5);
}
That actually gives the same results.
That is cool ! However, careful, division can stall the
pipeline.
No optimiser worth it's salt is going to emit a idiv instruction
there.
Re: Performance of map!()
On Friday, 24 April 2015 at 10:22:05 UTC, Chris wrote:
I replaced a range that was similar to map with map and the
performance dropped by ~0.5 msec.
The range I used previously is based on Adam's D Cookbook. It
is consistently faster than map.
private struct Transformer(alias agent, R) if (isInputRange!R) {
private R r;
this (R r) {
this.r = r;
}
static if (isInfinite!R) {
enum bool empty = false;
}
else {
@property bool empty() {
return r.empty;
}
}
void popFront() {
r.popFront();
}
@property ref auto front() {
return agent(r.front);
}
static if (isForwardRange!R) {
@property auto save() {
return Transformer!(agent, R)(r.save);
}
}
static if (isBidirectionalRange!R) {
@property auto back() {
return agent(r.back);
}
void popBack() {
r.popBack();
}
}
static if (isRandomAccessRange!R) {
auto opIndex(size_t i) {
return agent(r[i]);
}
}
static if (hasLength!R) {
@property auto length() {
return r.length;
}
}
}
Compiler? Compiler flags?
Re: Cleaned up C++
On Friday, 24 April 2015 at 12:34:19 UTC, ponce wrote:
On Friday, 24 April 2015 at 08:16:40 UTC, Walter Bright wrote:
On 4/24/2015 12:23 AM, John Colvin wrote:
Except of course that alloca is a lot cheaper than
malloc/free.
That's not necessarily true. But in any case, go ahead and use
it if you like. Just prepare to benchmark and be disappointed
:-)
Do you have a guess for why and when it could not be faster
than malloc in times?
I have some difficulty imagining a reason (yet I have sometimes
found malloc faster than aligned_malloc which is another odd
thing).
one reason why it might be faster is that e.g. gcc can produce
code like this:
#includealloca.h
void bar(char* a);
void foo(unsigned int n)
{
char *a = (char*)alloca(n);
bar(a);
}
foo:
movl%edi, %eax
pushq %rbp
addq$46, %rax
movq%rsp, %rbp
shrq$4, %rax
salq$4, %rax
subq%rax, %rsp
leaq31(%rsp), %rdi
andq$-32, %rdi
callbar
leave
ret
which is neat. Now of course a push-the-pointer malloc/free
implementation could perhaps be (in theory) optimised to be as
small as this, but is that ever actually the case?
Re: Cleaned up C++
On Friday, 24 April 2015 at 01:54:11 UTC, Walter Bright wrote: On 4/23/2015 3:11 PM, deadalnix wrote: For arbitrary large, you can always do something like : Item* itemPtr = (arbitrarylarge thresold) ? alloca(arbitrarylarge) : GC.alloc(arbitrarylarge); One extra check compared to a heap allocation is not going to make things terrible, and it is likely to be very predictible anyway (most arbitrarylarge size are actually small in practice). You can, but it just doesn't pay off. Even if you found a case that did, it doesn't mean it pays off in general, and so would be poor advice. BTW, since alloca() doesn't survive function scope, might as well use malloc/free instead of the GC. Or do like I've done and have an array of preallocated larger buffers. I.e. if you've gotten to tuning code at this level, the compiler picking things automatically for you is unlikely to be helpful. Hence my not being convinced by bearophile's assessment. Except of course that alloca is a lot cheaper than malloc/free.
Re: Cleaned up C++
On Thursday, 23 April 2015 at 14:29:01 UTC, Ola Fosheim Grøstad wrote: Can you give a specific example where all 3 points are satisfied? Not sure why you would need it, plenty of cases where compilers will fail. E.g. queues between threads (like real time threads) where you allocate in one thread and fill out data in another thread. Any preallocation done on large data structures or frequently reinitialized data structures may perform better without explicit initialization. Yes, there are times the compiler can't optimise the dead stores away. Obviously these dead stores are not free. What I don't see is a good example of when that cost matters. There are cases where you might really need to grab an extra 1-5%, at which point you are hand optimising and = void is a reasonable tool.
Re: Cleaned up C++
On Thursday, 23 April 2015 at 18:37:47 UTC, Walter Bright wrote: On 4/23/2015 1:10 AM, bearophile wrote: Walter Bright: On 4/22/2015 2:58 PM, bearophile wrote: D is less stack-friendly than Ada (and probably Rust too), ?? In Ada standard library you have safe fixed-size stack-allocated associative arrays. In D you can't even allocate safely a dynamically-sized 1D array on the stack, and forget about doing it for 2D. Enough said. I used to use alloca() here and there, but eventually removed it all. The trouble is, there are three array sizes: a) 0 b) 1 c) arbitrarily large Dynamic stack allocation works for none of them. What does work is a fixed size stack allocation with failover to using malloc/free, which is what Phobos' scopebuffer does. It's analogous to the small string optimization. I don't agree with your assessment at all. I used to think this was totally wrong, but over time I've come to see your point. The ideal for me would be a dynamically sized stack array (C99 style, not alloca) with a compile-time maximum size. Then you wrap that in a library type that decides/defines what to do when the size is exceeded (e.g. move to GC heap a la scopeBuffer), but in practice it's not a big win over just stack allocating the maximum size all the time (again, like scopeBuffer).
Re: Cleaned up C++
On Thursday, 23 April 2015 at 01:45:14 UTC, deadalnix wrote: On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote: Is it even possible to contrive a case where 1) The default initialisation stores are technically dead and 2) Modern compilers can't tell they are dead and elide them and 3) Doing the initialisation has a significant performance impact? The boring example is extra code causes instruction cache misses. I'd say it is very unlikely. If the compiler wan't see it, then it means the code is non trivial, and if it is non trivial, it is not an extra store that is going to make any difference. This was my thinking. I guess you could have something like this: extern(C) void myCheapInitialiser(float*, size_t); float[256] a; myCheapInitialiser(a.ptr, a.length); sort(a); writeln(a.stride(2).sum());
[OT] compiler optimisations
Why can no compiler I try optimise this toy example as I would
expect?
// uncomment if using a C compiler
// typedef unsigned int uint;
uint foo(uint a)
{
if (a 5)
return (a * 3) / 3;
else
return 0;
}
So, I would expect the compiler to be able to see that it is
equivalent to
uint foo(uint a)
{
return (a 5) ? a : 0;
}
But apparently not a single modern compiler I tried can do this
optimisation, unless it's hidden in some obscure flag I'm not
aware of.
An even more striking example can be found if you replace the /
with %, where the result of the function is then unconditionally
zero, but every compiler i tried still spat out multiplication
instructions.
Is there a good reason for this, or is it just * and / aren't
always inverses, so never mind all the cases where they are?
Now I know that this seems like a unrealistic example, but when
you're in complicated meta-programming situations code like this
can and will appear.
Re: [OT] compiler optimisations
On Thursday, 23 April 2015 at 08:56:38 UTC, rumbu wrote:
On Thursday, 23 April 2015 at 08:33:56 UTC, John Colvin wrote:
Why can no compiler I try optimise this toy example as I would
expect?
// uncomment if using a C compiler
// typedef unsigned int uint;
uint foo(uint a)
{
if (a 5)
return (a * 3) / 3;
else
return 0;
}
So, I would expect the compiler to be able to see that it is
equivalent to
uint foo(uint a)
{
return (a 5) ? a : 0;
}
But apparently not a single modern compiler I tried can do
this optimisation, unless it's hidden in some obscure flag I'm
not aware of.
I think because of the potential overflow in a * 3 (if we
ignore the a 5 condition). To optimize this, a compiler must
figure out that there is no overflow for any a 5.
If you change the condition to a 5 and call foo(uint.max),
the two expression above are not equivalent.
int foo(uint a)
{
if (a 5)
return (a * 3) / 3;
else
return 0;
}
int foo_optimized(uint a)
{
return (a 5) ? a : 0;
}
assert(foo(uint.max) == foo_optimized(uint.max)) // - fail.
Yes, the three things making * and / not inverses of each other
on unsigned integer types are:
truncation of integer division
div by 0
overflow
But it still amazes me that the compiler can't use the a 5
condition here. I regularly watch compilers do what appear to be
magical transformations and simplifications to my code, but here
they are tripping up on some very simple maths.
Re: Return data from different types of conditional operation
On Thursday, 23 April 2015 at 09:48:21 UTC, Dennis Ritchie wrote:
Hi,
Why the program can not return different types of data from the
conditional operator?
-
import std.stdio;
auto foo() {
if (true) {
return 0;
} else
return true;
}
void main() {
writeln(foo);
}
import std.variant, std.stdio;
auto foo()
{
if (true)
return Variant(0);
else
return Variant(Hello);
}
void main()
{
foo.writeln;
}
Re: [OT] compiler optimisations
On Thursday, 23 April 2015 at 10:04:47 UTC, Rikki Cattermole
wrote:
On 23/04/2015 10:02 p.m., Andrea Fontana wrote:
On Thursday, 23 April 2015 at 08:33:56 UTC, John Colvin wrote:
Why can no compiler I try optimise this toy example as I
would expect?
// uncomment if using a C compiler
// typedef unsigned int uint;
uint foo(uint a)
{
if (a 5)
return (a * 3) / 3;
else
return 0;
}
So, I would expect the compiler to be able to see that it is
equivalent to
uint foo(uint a)
{
return (a 5) ? a : 0;
}
But apparently not a single modern compiler I tried can do
this
optimisation, unless it's hidden in some obscure flag I'm not
aware of.
An even more striking example can be found if you replace the
/ with
%, where the result of the function is then unconditionally
zero, but
every compiler i tried still spat out multiplication
instructions.
Is there a good reason for this, or is it just * and /
aren't always
inverses, so never mind all the cases where they are?
Now I know that this seems like a unrealistic example, but
when you're
in complicated meta-programming situations code like this can
and will
appear.
If I'm right, there's a website where I can see assembly
generated by d
compiler. And it's not dpaste... any hint?
asm.dlang.org
and d.godbolt.org
This isn't a D-specific question though, so gcc.godbolt.org would
allow you to test a wider range of backends.
Re: [OT] compiler optimisations
On Thursday, 23 April 2015 at 12:37:12 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 23 April 2015 at 08:56:38 UTC, rumbu wrote:
I think because of the potential overflow in a * 3 (if we
ignore the a 5 condition). To optimize this, a compiler must
figure out that there is no overflow for any a 5.
Yes, it is because of modular artithmetics which is a D design
flaw. In C++ this only applies to unsigned integers, signed
integers are monothonic in C++. I think Rust uses non-modular
for both and Ada allows you to specify it.
Compiled using ICC:
int foo(int a)
{
if (a 5)
return (a * 3) / 3;
else
return 0;
}
yields:
xorl %edx, %edx
cmpl $5, %edi
cmovle%edx, %edi
movl %edi, %eax
ret
-
int foo(unsigned int a)
{
if (a 5)
return (a * 3) / 3;
else
return 0;
}
yields:
cmpl $5, %edi
jbe ..B1.3
movl $-1431655765, %eax
lea (%rdi,%rdi,2), %ecx
mull %ecx
shrl $1, %edx
movl %edx, %eax
ret
..B1.3:
xorl %eax, %eax
ret
Just to confirm this, all C compilers I tried were able to use
the undefined behaviour of signed overflow to avoid the
multiplication. D compilers of course do not do this, as signed
overflow is defined.
Nonetheless, I maintain that the compiler should be able to
propagate the value range of a and perform the optimisation
regardless.
Re: oversight with input ranges
On Wednesday, 22 April 2015 at 16:02:51 UTC, Steven Schveighoffer
wrote:
On 4/21/15 7:31 PM, ketmar wrote:
On Tue, 21 Apr 2015 18:57:50 -0400, Steven Schveighoffer wrote:
On 4/21/15 3:53 PM, ketmar wrote:
here's the interesting oversight for isInputRange:
https://issues.dlang.org/show_bug.cgi?id=14478
so be careful: ranges with non-copyable elements aren't
input ranges
for now. ;-)
This does seem like an incorrect limitation, and I'm not sure
if it was
intentional. However, there is a lot of code out there that
expects this
to work when isInputRange is true. I don't know if we should
change it,
as the range definition is pretty clear in the documentation
that auto h
= r.front is a required feature for ranges. What is the use
case for
this?
one possible use case was shown in bugreport. array of
non-copyable
struct, yet i still want chain 'em, for example. or filter.
or...
struct S {
int n;
@disable this (this);
}
void main () {
S[2] arr;
arr[0].n = 1;
arr[1].n = 2;
foreach (ref el; arr[].filter!((ref a) = a.n 1)) {
writeln(el.n);
}
}
this code is perfectly valid, it doesn't require copying at
all, yet it
is invalid now.
Yes, I agree this is a valid use case. I don't think we can
change isInputRange, because other code may depend on that
requirement of copyability, but it is probably possible to
alter algorithms so they can accept these not-quite input
ranges. Definitely proxy or decorator type adapters that
provide a proxy for front shouldn't be restricted to using only
copyable range elements.
1st step is we need a trait to define what we are looking for,
then the next step is to simply alter all the appropriate
algorithms to use it. It shouldn't hinder any code that exists
if we do that.
So what should be the name of this beast?
-Steve
We could just add a flag as a second argument to isInputRange.
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
On Wednesday, 22 April 2015 at 14:13:01 UTC, Jonathan M Davis wrote: On Wednesday, April 22, 2015 11:28:43 Daniel Kozak via Digitalmars-d wrote: This code compile fine under both versions: dmd (2.066, -debug -d): OK dmd (2.067, -debug -d): core.exception.AssertError@main.d(24): Assertion failure ./main() [0x46413f] ./main(_Dmain+0x86) [0x449996] ./main(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) [0x467d53] ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x467ca6] ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x30) [0x467d0c] ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x467ca6] ./main(_d_run_main+0x1dc) [0x467c20] ./main(main+0x17) [0x464157] /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f4b8d440800] What code does this? You just showed the output, not the code that triggers the problem. - Jonathan M Davis http://forum.dlang.org/post/khhgviigmymiyitvn...@forum.dlang.org
Re: SDC needs you -- redux
On Wednesday, 22 April 2015 at 16:27:59 UTC, Wyatt wrote: On Wednesday, 22 April 2015 at 15:44:03 UTC, Dan Olson wrote: Super and Hyper keys A veteran of the Lisp machines! I've been hoping for someone to manufacture a modern keyboard with these for about a decade now. (Well, I'm pretty sure the Windows key you see frequently on terrible mushy keyboards is Super in a bad costume, but none of my keyboards have it.) -Wyatt Most keyboards have some kind of Windows key, on macs it's called cmd. You can use that key for whatever you want, surely?
Re: SDC needs you -- redux
On Wednesday, 22 April 2015 at 17:52:25 UTC, Wyatt wrote: On Wednesday, 22 April 2015 at 17:31:47 UTC, John Colvin wrote: Most keyboards have some kind of Windows key, on macs it's called cmd. You can use that key for whatever you want, surely? No, I'm very sure neither my Model M nor my Omnikey Ultra have that. -Wyatt When I said most I meant the majority of keyboards available for purchase at any given price, from no-brand membrane eBay purchase from china to high-end mechanical. Well, I guess even the classics have downsides :)
Re: Cleaned up C++
On Wednesday, 22 April 2015 at 20:29:49 UTC, Walter Bright wrote: On 4/22/2015 12:51 PM, ponce wrote: I didn't appreciate how important default initialization was before having to fix a non-deterministic, release-only, time-dependent bug in a video encoder some months ago. Just because of 2 uninitialized variables (C++ doesn't require member initialization in constructor). If one of them was _exactly equal to 1_ by virtue of randomness, then it would perform from 0 to 2 billions of motion estimation steps, which is very slow but not a total halt. A watchdog mechanism would detect this and reboot, hence labelling the bug a deadlock. It would disappear in debug mode since variables would be initialized then. The default initialization comes from bitter personal experience, much like yours! That gives a totally other meaning to zero cost abstractions since in three weeks of investigation I could have speed-up the program by ~5%, much more than the supposed slowdown of variable initialization. Most of the implicit initializations become dead stores and are removed anyway by the optimizer. Is it even possible to contrive a case where 1) The default initialisation stores are technically dead and 2) Modern compilers can't tell they are dead and elide them and 3) Doing the initialisation has a significant performance impact? The boring example is extra code causes instruction cache misses.
Re: Cleaned up C++
On Wednesday, 22 April 2015 at 21:59:48 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote: Is it even possible to contrive a case where 1) The default initialisation stores are technically dead and 2) Modern compilers can't tell they are dead and elide them and 3) Doing the initialisation has a significant performance impact? The boring example is extra code causes instruction cache misses. Allocation of large arrays. That doesn't really answer the question without some more context. Can you give a specific example where all 3 points are satisfied?
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote: This code compile fine under both versions: dmd (2.066, -debug -d): OK dmd (2.067, -debug -d): core.exception.AssertError@main.d(24): Assertion failure ./main() [0x46413f] ./main(_Dmain+0x86) [0x449996] ./main(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) [0x467d53] ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x467ca6] ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x30) [0x467d0c] ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x467ca6] ./main(_d_run_main+0x1dc) [0x467c20] ./main(main+0x17) [0x464157] /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f4b8d440800] What code?
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
On Wednesday, 22 April 2015 at 11:29:30 UTC, Daniel Kozak wrote:
On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:
static struct S
{
immutable FLAG_ON = 1;
immutable FLAG_GPRS = 2;
immutable FLAG_HIDDEN = 4;
ubyte flags;
ubyte value;
bool isFlagSet(int flag)
{
return flags flag == flag;
}
}
void main(string[ ] args)
{
auto someData = [0x01, 0x10, 0x02, 0x16, 0x04, 0x08];
auto countS = someData.length / S.sizeof;
S[] sArray = (cast(S*)someData.ptr)[0 .. countS];
assert(sArray.length == 3);
}
I agree that the change should be more prominent in the changelog.
Having said that, if your code makes an assumption about the
layout (alignment and size) of a struct, it should `static
assert` that assumption, or at least have a test case that relies
it. You're just asking for trouble without that.
Re: Example for Documentation?
On Tuesday, 21 April 2015 at 17:30:08 UTC, Steven Schveighoffer wrote: for example, RedBlackTree!(int, a b) is not compatible with RedBlackTree!(int, ab), even though they are identical. I'm pretty sure this can and should be fixed. Removing whitespace before creating the function would be start.
Re: how does isInputRange(T) actually work?
On Tuesday, 21 April 2015 at 19:06:39 UTC, kevin wrote:
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}));
... is the current implementation in Phobos. But I can't seem
to understand this syntax. What is (inout int = 0)? Why can a
block follow it?
My guess is that this is declaring some sort of function and
testing if it is syntactically valid, but this is still strange
to me.
It's defining a lambda function and checking that it is
*semantically* valid.
No idea what the `(inout int = 0)` is there for, I would have
thought it would be fine without it.
Re: Today's programming challenge - How's your Range-Fu ?
On Tuesday, 21 April 2015 at 13:06:22 UTC, JohnnyK wrote: On Monday, 20 April 2015 at 19:24:01 UTC, Panke wrote: On Monday, 20 April 2015 at 18:03:50 UTC, John Colvin wrote: On Monday, 20 April 2015 at 17:48:17 UTC, Panke wrote: To measure the columns needed to print a string, you'll need the number of graphemes. (d|)?string.length gives you the number of code units. Even that's not really true. Why? Doesn't string.length give you the byte count? I was talking about the you'll need the number of graphemes. s.length returns the number of elements in the slice, which in the case of D's string types gives is the same as the number of code units. I think what you are looking for is string.sizeof? From the D reference .sizeof Returns the array length multiplied by the number of bytes per array element. .length Returns the number of elements in the array. This is a fixed quantity for static arrays. It is of type size_t. That is for static arrays only. .sizeof for slices is just size_t.sizeof + T*.sizeof i.e. 8 on 32 bit, 16 on 64 bit.
Re: Trial migration of Dsource bindings project to Github
On Monday, 20 April 2015 at 23:42:54 UTC, Vladimir Panteleev wrote: On Monday, 20 April 2015 at 22:57:51 UTC, Stewart Gordon wrote: I committed some updates the other day and they seem they have gone straight into the online repository. Committing is a local (non-network) operation in git, so you must have pushed them afterwards, or your GUI has done this for you. I think he's using github's svn support The repository is still a git repository.
Re: Valgrind
On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote: On Monday, 20 April 2015 at 13:16:23 UTC, Robert M. Münch wrote: Hi, I just found quite old posts about Valgrind and D. Can someone give me a short update, what the state of support for D is and if there is anythings special to take into account. Thanks a lot. The only special thing to take in to account is that valgrind will choke on DMD generated floating point code, so really you have to use GDC or LDC if you want to use valgrind. Correction: The only special thing I know of.
Re: Valgrind
On Monday, 20 April 2015 at 13:16:23 UTC, Robert M. Münch wrote: Hi, I just found quite old posts about Valgrind and D. Can someone give me a short update, what the state of support for D is and if there is anythings special to take into account. Thanks a lot. The only special thing to take in to account is that valgrind will choke on DMD generated floating point code, so really you have to use GDC or LDC if you want to use valgrind.
Re: Trial migration of Dsource bindings project to Github
On Sunday, 19 April 2015 at 23:37:58 UTC, Vladimir Panteleev wrote: On Sunday, 19 April 2015 at 23:14:13 UTC, Stewart Gordon wrote: For those of you who are still unfamiliar with GitHub, Stewart, I haven't seen an active D project that WASN'T hosted on GitHub for years now. There's a few on bitbucket.
Re: CT-String as a Symbol
On Thursday, 16 April 2015 at 18:12:35 UTC, Nordlöw wrote: Is there a way to CT-query the arity of all opIndex and opSlice overloads? Ideally you don't want to have to do that. You'd have to consider alias this and inheritance.
Re: Converting Java code to D
On Monday, 20 April 2015 at 17:24:30 UTC, bearophile wrote:
John Colvin:
struct LineStyle
{
enum NONE = None;
enum SOLID = Solid;
enum DASH = Dash;
enum DOT = Dot;
enum DASHDOT = Dash Dot;
enum DASHDOTDOT = Dash Dot Dot;
string label;
private this(string label)
{
this.label = label;
}
}
The constructor doesn't look very useful.
Perhaps a named enum is safer.
Bye,
bearophile
True, the constructor doesn't really add anything here.
To be honest, the combination of enumeration and runtime
variables in the Java code seems like a rubbish design, but
perhaps there's a good reason for it that I'm not aware of.
Re: Valgrind
On Monday, 20 April 2015 at 16:58:18 UTC, Robert M. Münch wrote: On 2015-04-20 13:29:57 +, John Colvin said: On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote: On Monday, 20 April 2015 at 13:16:23 UTC, Robert M. Münch wrote: Hi, I just found quite old posts about Valgrind and D. Can someone give me a short update, what the state of support for D is and if there is anythings special to take into account. Thanks a lot. The only special thing to take in to account is that valgrind will choke on DMD generated floating point code, so really you have to use GDC or LDC if you want to use valgrind. Correction: The only special thing I know of. Ok, thanks. Were the causes ever analyzed? I'm a bit wondering why it happens on floating point stuff... valgrind doesn't have full support for x87 code, which dmd emits all over the place.
Re: Today's programming challenge - How's your Range-Fu ?
On Monday, 20 April 2015 at 17:48:17 UTC, Panke wrote: To measure the columns needed to print a string, you'll need the number of graphemes. (d|)?string.length gives you the number of code units. Even that's not really true. In the end it's up to the font and layout engine to decide how much space anything takes up. Unicode doesn't play nicely with the idea of text as a grid of rows and fixed-width columns of characters, although quite a lot can (and is, see urxvt for example) be shoe-horned in.
Re: Converting Java code to D
On Monday, 20 April 2015 at 15:28:04 UTC, Mike James wrote:
Here is a fragment of Java code from an SWT program...
public enum LineStyle {
NONE(None),
SOLID(Solid),
DASH(Dash),
DOT(Dot),
DASHDOT(Dash Dot),
DASHDOTDOT(Dash Dot Dot);
public final String label;
private LineStyle(String label) {
this.label = label;
}
}
What would be the best ('canonical') way of translating it to D?
Regards,
-=mike=-
I'm not too hot at Java, but I'm pretty sure this gives you what
you want. Perhaps immutable instead of enum would be closer
to what Java does with enum members, but I don't know.
struct LineStyle
{
enum NONE = None;
enum SOLID = Solid;
enum DASH = Dash;
enum DOT = Dot;
enum DASHDOT = Dash Dot;
enum DASHDOTDOT = Dash Dot Dot;
string label;
private this(string label)
{
this.label = label;
}
}
Re: Today's programming challenge - How's your Range-Fu ?
On Saturday, 18 April 2015 at 16:01:20 UTC, Andrei Alexandrescu
wrote:
On 4/18/15 4:35 AM, Jacob Carlborg wrote:
On 2015-04-18 12:27, Walter Bright wrote:
That doesn't make sense to me, because the umlauts and the
accented e
all have Unicode code point assignments.
This code snippet demonstrates the problem:
import std.stdio;
void main ()
{
dstring a = e\u0301;
dstring b = é;
assert(a != b);
assert(a.length == 2);
assert(b.length == 1);
writefln(a, , b);
}
If you run the above code all asserts should pass. If your
system
correctly supports Unicode (works on OS X 10.10) the two
printed
characters should look exactly the same.
\u0301 is the combining acute accent [1].
[1] http://www.fileformat.info/info/unicode/char/0301/index.htm
Isn't this solved commonly with a normalization pass? We should
have a normalizeUTF() that can be inserted in a pipeline. Then
the rest of Phobos doesn't need to mind these combining
characters. -- Andrei
Normalisation can allow some simplifications, sometimes, but
knowing whether it will or not requires a lot of a priori
knowledge about the input as well as the normalisation form.
Re: Today's programming challenge - How's your Range-Fu ?
On Saturday, 18 April 2015 at 17:50:12 UTC, Walter Bright wrote: On 4/18/2015 4:35 AM, Jacob Carlborg wrote: \u0301 is the combining acute accent [1]. [1] http://www.fileformat.info/info/unicode/char/0301/index.htm I won't deny what the spec says, but it doesn't make any sense to have two different representations of eacute, and I don't know why anyone would use the two code point version. é might be obvious, but Unicode isn't just for writing European prose. Uses for combining characters includes (but is *nowhere* near to limited to) mathematical notation, where the combinatorial explosion of possible combinations that still belong to one grapheme cluster (character is a familiar but misleading word when talking about Unicode) would trivially become an insanely (more atoms than in the universe levels of) large number of characters. Unicode is a nightmarish system in some ways, but considering how incredibly difficult the problem it solves is, it's actually not too crazy.
Re: [hackathon] One week left to the first D Hackathon!
On Sunday, 19 April 2015 at 13:03:22 UTC, ANtlord wrote: On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with [hackathon]. (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei Good day! May be it is silly question, but I can't understand. Can I take a part in hackaton remotely? And second question. Will hackaton's projects be published? Thank you. I'm sorry, if my english is not clear. I can't speak for Andrei, but I think this is more of a casual do some work on something valuable to D session rather than a formal hackathon. I think everyone will be working remotely.
Re: [hackathon] One week left to the first D Hackathon!
On Sunday, 19 April 2015 at 13:03:22 UTC, ANtlord wrote: On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with [hackathon]. (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei Good day! May be it is silly question, but I can't understand. Can I take a part in hackaton remotely? And second question. Will hackaton's projects be published? Thank you. I'm sorry, if my english is not clear. I can't speak for Andrei, but I think this is more of a casual do some work on something valuable to D session rather than a formal hackathon. I think everyone will be working remotely.
Re: Today's programming challenge - How's your Range-Fu ?
On Friday, 17 April 2015 at 18:41:59 UTC, Walter Bright wrote: On 4/17/2015 9:59 AM, H. S. Teoh via Digitalmars-d wrote: So either you have to throw out all pretenses of Unicode-correctness and just stick with ASCII-style per-character line-wrapping, or you have to live with byGrapheme with all the complexity that it entails. The former is quite easy to write -- I could throw it together in a couple o' hours max, but the latter is a pretty big project (cf. Unicode line-breaking algorithm, which is one of the TR's). It'd be good enough to duplicate the existing behavior, which is to treat decoded unicode characters as one column. Code points aren't equivalent to characters. They're not the same thing in most European languages, never mind the rest of the world. If we have a line-wrapping algorithm in phobos that works by code points, it needs a large THIS IS ONLY FOR SIMPLE ENGLISH TEXT warning. Code points are a useful chunk size for some tasjs and completely insufficient for others.
Re: Linking C++ standard library works with GDC... but not DMD. (Linux)
On Thursday, 16 April 2015 at 08:51:15 UTC, TheGag96 wrote: Hi, I've got this project that requires me to link into a C++ backend. It works just fine when using GDC: gdc *.d [client libraries] However, this command using DMD does not work: dmd -L-lstdc++ *.d [client libraries] I still get errors involving the standard library not being added like: /usr/include/c++/4.8/iostream:74: undefine reference to `std::ios_base::Init::Init()' (etc.) What do I need to do to make this work? Thanks. I don't know why that's happening, but you can explicitly link using gcc (or ld/gold directly) if you need to. E.g. dmd -c myFile.d gcc myFile.o -lphobos2 or whatever is necessary on your project/system.
Re: How about appender.put() with var args?
On Wednesday, 15 April 2015 at 20:59:25 UTC, Steven Schveighoffer
wrote:
On 4/15/15 4:51 PM, Messenger wrote:
On Wednesday, 15 April 2015 at 19:09:42 UTC, Márcio Martins
wrote:
Hi!
I use Appender a lot, and find it ugly to write this all the
time to
efficiently construct strings:
app.put(foo);
app.put(var);
app.put(bar);
Sidetracking a bit, but when I started using Appender I was
surprised to
see that put didn't return a reference to the Appender itself.
Had it
done so, you could have chained your put calls very nicely.
app.put(foo)
.put(var)
.put(bar)
.put(more)
.put(stuff);
You can naturally write a small wrapper function that does
this for you,
but it still strikes me as odd. Sadly I imagine changing the
return type
would make the function signature mangle differently, breaking
ABI
compatibility.
with(app)
{
put(var);
put(bar);
put(more);
put(stuff);
}
-Steve
With all the excitement about chaining and ufcs, the with
statement is often overlooked.
