D is for Data Science
Just browsing reddit and found this article posted about D. Written by Andrew Pascoe of AdRoll. From the article: The D programming language has quickly become our language of choice on the Data Science team for any task that requires efficiency, and is now the keystone language for our critical infrastructure. Why? Because D has a lot to offer. Article: http://tech.adroll.com/blog/data/2014/11/17/d-is-for-data-science.html Reddit: http://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/
dfix 0.2.0
dfix is a tool for automatically upgrading the syntax of D source
code.
Changes since 0.1.1:
* #1 dfix will now rewrite const int foo() {} to int foo()
const {}
* #6 The C-style array syntax fix is no longer incorrectly
applied to
certain ASM statements.
* #9 You can now provide directory names as arguments to dfix in
case
you're too lazy to run find and xargs. (And really, who isn't?)
* #11 dfix is now registered on code.dlang.org.
http://code.dlang.org/packages/dfix
* Added tests.
D is for Data Science - reddit discussion
D is for Data Science by Andrew Pascoe http://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/
Re: D is for Data Science - reddit discussion
Haven't noticed that it was already posted. Sorry about that. The disscussion is here http://forum.dlang.org/thread/qeyftagcvkhjjeeba...@forum.dlang.org
Re: DerelictSASS
On Monday, 24 November 2014 at 17:32:36 UTC, Lodin wrote: Of course, I want to register it, but I think it should be a part of Derelict Project, not unofficial binding. What should I do to realize it? And one thing about the diet plugin. I plan to make thin wrapper around binding to simplify using. Something like `sassc` which allows using libsass from console with options. Of course, it should be useful like a library too. Is the diet plugin a same thing? Or should it be the next layer around wrapper? I can't help you with getting it included in Derelict, but I think Mike Parker[0] is probably the one to talk to. I think the diet plugin would serve best as a layer on top of your wrapper. It's scope is limited to taking inline sass, as well as paths to sass files, compiling them, and including the result on the HTML page. If you could make that process easier with a wrapper, it would make the plugin much simpler. [0] https://github.com/aldacron
Re: D is for Data Science
On Monday, 24 November 2014 at 15:27:19 UTC, Gary Willoughby wrote: Just browsing reddit and found this article posted about D. Written by Andrew Pascoe of AdRoll. From the article: The D programming language has quickly become our language of choice on the Data Science team for any task that requires efficiency, and is now the keystone language for our critical infrastructure. Why? Because D has a lot to offer. Article: http://tech.adroll.com/blog/data/2014/11/17/d-is-for-data-science.html Reddit: http://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/ Why is File.byLine so slow? Having to work around the standard library defeats the point of a standard library.
Re: D is for Data Science
25-Nov-2014 00:34, weaselcat пишет: On Monday, 24 November 2014 at 15:27:19 UTC, Gary Willoughby wrote: Just browsing reddit and found this article posted about D. Written by Andrew Pascoe of AdRoll. From the article: The D programming language has quickly become our language of choice on the Data Science team for any task that requires efficiency, and is now the keystone language for our critical infrastructure. Why? Because D has a lot to offer. Article: http://tech.adroll.com/blog/data/2014/11/17/d-is-for-data-science.html Quoting the article: One of the best things we can do is minimize the amount of memory we’re allocating; we allocate a new char[] every time we read a line. This is wrong. byLine reuses buffer if its mutable which is the case with char[]. I recommend authors to always double checking hypothesis before stating it in article, especially about performance. Observe: https://github.com/D-Programming-Language/phobos/blob/master/std/stdio.d#L1660 https://github.com/D-Programming-Language/phobos/blob/master/std/stdio.d#L1652 And notice a warning about reusing the buffer here: https://github.com/D-Programming-Language/phobos/blob/master/std/stdio.d#L1741 Reddit: http://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/ Why is File.byLine so slow? Seems to be mostly fixed sometime ago. It's slower then straight fgets but it's not that bad. Also nearly optimal solution using C's fgets with growable buffer is way simpler then outlined code in the article. Or we can mmap the file too. Having to work around the standard library defeats the point of a standard library. Truth be told the most of slowdown should be in eager split, notably with GC allocation per line. It may also trigger GC collection after splitting many lines, maybe even many collections. The easy way out is to use standard _splitter_ which is lazy and non-allocating. Which is a _2-letter_ change, and still using nice clean standard function. Article was really disappointing for me because I expected to see that single line change outlined above to fix the 80% of problem elegantly. Instead I observe 100+ spooky lines that needlessly maintain 3 buffers at the same time (how scientific) instead of growing single one to amortize the cost. And then a claim that's nice to be able to improve speed so easily. -- Dmitry Olshansky
Re: D is for Data Science
Dmitry Olshansky: Why is File.byLine so slow? Seems to be mostly fixed sometime ago. Really? I am not so sure. Bye, bearophile
Re: D is for Data Science
On 11/24/2014 2:25 PM, Dmitry Olshansky wrote: [...] Excellent comments. Please post them on the reddit page!
Re: D is for Data Science
On Monday, 24 November 2014 at 15:27:19 UTC, Gary Willoughby wrote: Just browsing reddit and found this article posted about D. Written by Andrew Pascoe of AdRoll. From the article: The D programming language has quickly become our language of choice on the Data Science team for any task that requires efficiency, and is now the keystone language for our critical infrastructure. Why? Because D has a lot to offer. Article: http://tech.adroll.com/blog/data/2014/11/17/d-is-for-data-science.html Reddit: http://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/ Is this related? https://github.com/dscience-developers/dscience
Re: D is for Data Science
On Monday, 24 November 2014 at 23:32:14 UTC, Jay Norwood wrote: Is this related? https://github.com/dscience-developers/dscience This seems good too. Why the comments in the discussion about lack of libraries? https://github.com/kyllingstad/scid/wiki
Re: D is for Data Science
25-Nov-2014 01:28, bearophile пишет:
Dmitry Olshansky:
Why is File.byLine so slow?
Seems to be mostly fixed sometime ago.
Really? I am not so sure.
Bye,
bearophile
I too has suspected it in the past and then I tested it.
Now I test it again, it's always easier to check then to argue.
Two minimal programs
//my.d:
import std.stdio;
void main(string[] args) {
auto file = File(args[1], r);
size_t cnt=0;
foreach(char[] line; file.byLine()) {
cnt++;
}
}
//my2.d
import core.stdc.stdio;
void main(string[] args) {
char[] buf = new char[32768];
size_t cnt;
shared(FILE)* file = fopen(args[1].ptr, r);
while(fgets(buf.ptr, cast(int)buf.length, file) != null){
cnt++;
}
fclose(file);
}
In the below console session, log file - is my dmsg log replicated many
times (34 megs total).
dmitry@Ubu64 ~ $ wc -l log
522240 log
dmitry@Ubu64 ~ $ du -hs log
34M log
# touch it, to have it in disk cache:
dmitry@Ubu64 ~ $ cat log /dev/null
dmitry@Ubu64 ~ $ dmd my
dmitry@Ubu64 ~ $ dmd my2
dmitry@Ubu64 ~ $ time ./my2 log
real0m0.062s
user0m0.039s
sys 0m0.023s
dmitry@Ubu64 ~ $ time ./my log
real0m0.181s
user0m0.155s
sys 0m0.025s
~4 time in user mode, okay...
Now with full optimizations, ranges are very sensitive to optimizations:
dmitry@Ubu64 ~ $ dmd -O -release -inline my
dmitry@Ubu64 ~ $ dmd -O -release -inline my2
dmitry@Ubu64 ~ $ time ./my2 log
real0m0.065s
user0m0.042s
sys 0m0.023s
dmitry@Ubu64 ~ $ time ./my2 log
real0m0.063s
user0m0.040s
sys 0m0.023s
Which is 1:1 parity. Another myth busted? ;)
--
Dmitry Olshansky
Re: D is for Data Science
Dmitry Olshansky: Which is 1:1 parity. Another myth busted? ;) There is still an open bug report: https://issues.dlang.org/show_bug.cgi?id=11810 Do you want also to benchmark that byLineFast that for me is usually significantly faster than the byLine? Bye, bearophile
Re: D is for Data Science
25-Nov-2014 02:43, bearophile пишет: Dmitry Olshansky: Which is 1:1 parity. Another myth busted? ;) dmitry@Ubu64 ~ $ time ./my2 log real0m0.065s user0m0.042s sys0m0.023s dmitry@Ubu64 ~ $ time ./my2 log real0m0.063s user0m0.040s sys0m0.023s Read the above more carefully. OMG. I really need to watch my fingers, and double-check:) dmitry@Ubu64 ~ $ time ./my log real0m0.156s user0m0.130s sys 0m0.026s dmitry@Ubu64 ~ $ time ./my2 log real0m0.063s user0m0.040s sys0m0.023s Which is quite bad. Optimizations do help but not much. There is still an open bug report: https://issues.dlang.org/show_bug.cgi?id=11810 Do you want also to benchmark that byLineFast that for me is usually significantly faster than the byLine? And it seems like byLineFast is indeed fast. dmitry@Ubu64 ~ $ time ./my3 log real0m0.056s user0m0.031s sys 0m0.025s dmitry@Ubu64 ~ $ time ./my2 log real0m0.065s user0m0.041s sys 0m0.024s Now once I was destroyed the question is who is going to make a PR of this? -- Dmitry Olshansky
Re: D is for Data Science
On 11/24/2014 7:27 AM, Gary Willoughby wrote: Just browsing reddit and found this article posted about D. https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbn83i Thought I'd post this as a counterpoint to the recent please break our code thread.
Re: D is for Data Science
On Tuesday, 25 November 2014 at 00:34:30 UTC, Walter Bright wrote: Thought I'd post this as a counterpoint to the recent please break our code thread. I would caution against putting very much weight in Reddit opinions - there's people who will never use D and just look for excuses to justify their prejudice and there's people who think they want something, but don't really have any idea (this is common in feature requests, as I'm sure you know) That comment, in particular, seems very questionable to me. dstats at least compiles out of the box and has github activity within the last few months. It has a lot of templates, so maybe actually using it would reveal compilation problems, but at quick glance it seems to work.
Re: D is for Data Science
On 11/24/2014 4:50 PM, Adam D. Ruppe wrote: On Tuesday, 25 November 2014 at 00:34:30 UTC, Walter Bright wrote: Thought I'd post this as a counterpoint to the recent please break our code thread. I would caution against putting very much weight in Reddit opinions - there's people who will never use D and just look for excuses to justify their prejudice and there's people who think they want something, but don't really have any idea (this is common in feature requests, as I'm sure you know) That comment, in particular, seems very questionable to me. dstats at least compiles out of the box and has github activity within the last few months. It has a lot of templates, so maybe actually using it would reveal compilation problems, but at quick glance it seems to work. I know it's a tough call. But I do see these sorts of comments regularly, and it is a fact that there are too many D libraries gone to seed that won't compile anymore, and that makes us look bad.
Re: D is for Data Science
With algorithm.sort the deciles bench from the article runs twice as fast(it's in the reddit thread) I see array.sort is planned for future deprecation, what does future fall under?
Re: Comparing Parallelization in HPC with D, Chapel, and Go
On Sun, Nov 23, 2014 at 7:48 PM, Andrei Amatuni via Digitalmars-d digitalmars-d@puremagic.com wrote: not exactly the most rigorous research, but it's pretty favorable... Not even remotely rigorous. One has to wonder about the quality of the conference into which this paper was accepted.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 20:17:12 UTC, Walter Bright wrote: On 11/21/2014 7:36 AM, Don wrote: On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote: 0 crossing bugs tend to show up much sooner, and often immediately. You're missing the point here. The problem is that people are using 'uint' as if it were a positive integer type. Suppose D had a type 'natint', which could hold natural numbers in the range 0..uint.max. Sounds like 'uint', right? People make the mistake of thinking that is what uint is. But it is not. How would natint behave, in the type system? typeof (natint - natint) == int NOT natint !!! This would of course overflow if the result is too big to fit in an int. But the type would be correct. 1 - 2 == -1. But typeof (uint - uint ) == uint. The bit pattern is identical to the other case. But the type is wrong. It is for this reason that uint is not appropriate as a model for positive integers. Having warnings about mixing int and uint operations in relational operators is a bit misleading, because mixing signed and unsigned is not usually the real problem. Instead, those warnings a symptom of a type system mistake. You are quite right in saying that with a signed length, overflows can still occur. But, those are in principle detectable. The compiler could add runtime overflow checks for them, for example. But the situation for unsigned is not fixable, because it is a problem with the type system. By making .length unsigned, we are telling people that if .length is used in a subtraction expression, the type will be wrong. It is the incorrect use of the type system that is the underlying problem. I believe I do understand the problem. As a practical matter, overflow checks are not going to be added for performance reasons. The performance overhead would be practically zero. All we would need to do, is restrict array slices such that the length cannot exceed ssize_t.max. This can only happen in the case where the element type has a size of 1, and only in the case of slicing a pointer, concatenation, and memory allocation. Making this restriction would have been unreasonable in the 8 and 16 bit days, but D doesn't support those. For 32 bits, this is an extreme corner case. For 64 bit, this condition never happens at all. In exchange, 99% of uses of unsigned would disappear from D code, and with it, a whole category of bugs. Also, in principle, uint-uint can generate a runtime check for underflow (i.e. the carry flag). No it cannot. The compiler does not have enough information to know if the value is intended to be positive integer, or an unsigned. That information is lost from the type system. Eg from C, wrapping of an unsigned type is not an error. It is perfectly defined behaviour. With signed types, it's undefined behaviour. To make this clear: I am not proposing that size_t should be changed. I am proposing that for .length returns a signed type, that for array slices is guaranteed to never be negative.
Testing lazy ranges in post-conditions
If a function returns a lazy range, I can't verify its
correctness in the function post-condition because inside the
post-condition such range is const.
An example of the problem:
import std.range, std.algorithm;
auto foo()
out(result) {
assert(result.all!(x = x 10));
} body {
return iota(5);
}
void main() {}
This limits the usefulness of post-conditions in my code. Do you
have ideas to solve this problem?
Bye,
bearophile
Re: Comparing Parallelization in HPC with D, Chapel, and Go
On Monday, 24 November 2014 at 03:48:27 UTC, Andrei Amatuni wrote: This prompted me to google for recent academic papers on D, which led me to this: http://research.ijcaonline.org/volume104/number7/pxc3898921.pdf not exactly the most rigorous research, but it's pretty favorable... My main take away from that paper was that C is much slower than Java :o) Based on those results it likely would have been trounced by Python or Ruby too.
Re: Testing lazy ranges in post-conditions
Should be able to do: assert(result.save.all!(x = x 10)); But iota's save isn't const, so you can't (that's a bug).
Re: std.experimental.logger formal review round 3
On Friday, 14 November 2014 at 23:06:22 UTC, Dicebot wrote: On Friday, 14 November 2014 at 22:20:17 UTC, Robert burner Schadek wrote: I will test something this weekend regarding the additional indirection. Thanks! I may try hacking some sample implementation too but pessimistic about ETA So, I added a layer of thread local indirection to the Logger. It now goes by default like: log|trace|... - threadLocalLogger - globalLogger The threadLocalLogger is just another Logger so it can be replaced with whatever you need may need. Or just keep it forwarding.
Re: Testing lazy ranges in post-conditions
Peter Alexander:
Should be able to do:
assert(result.save.all!(x = x 10));
But iota's save isn't const, so you can't (that's a bug).
Mine was just an example of the general problem, another example:
import std.range, std.algorithm;
auto foo()
out(result) {
assert(result.all!(b = b.length == 2));
} body {
auto a = new int[10];
return a.chunks(2);
}
void main() {}
Bye,
bearophile
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 17:23:51 UTC, Marco Leise wrote:
Am Thu, 20 Nov 2014 08:18:23 +
schrieb Don x...@nospam.com:
It's particularly challenging in D because of the widespread
use of 'auto':
auto x = foo();
auto y = bar();
auto z = baz();
if (x - y z) { ... }
This might be a bug, if one of these functions returns an
unsigned type. Good luck finding that. Note that if all
functions return unsigned, there isn't even any
signed-unsigned mismatch.
With those function names I cannot write code.
ℕ x = length();
ℕ y = index();
ℕ z = requiredRange();
if (x - y z) { ... }
Ah, now we're getting somewhere. Yes the code is obviously
correct. You need to be aware of the value ranges of your
variables and write subtractions in a way that the result can
only be = 0. If you realize that you cannot guarantee that
for some case, you just found a logic bug. An invalid program
state that you need to assert/if-else/throw.
Yup. And that is not captured in the type system.
I don't get why so many APIs return ints. Must be to support
Java or something where proper unsigned types aren't available.
D and C do not have suitable types either.
unsigned != ℕ.
In D, 1u - 2u 0u. This is defined behaviour, not an overflow.
Re: Comparing Parallelization in HPC with D, Chapel, and Go
On Sun, 2014-11-23 at 13:09 -0800, Ziad Hatahet via Digitalmars-d wrote: On Sat, Nov 22, 2014 at 7:17 AM, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: I have emailed the author. Keep us posted! Author replied. He is issuing source code on a bilateral pseudo-NDA. I will read it to ensure no hidden problems later this evening, and then reply. Most likely affirmative… -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Comparing Parallelization in HPC with D, Chapel, and Go
On Mon, 2014-11-24 at 11:53 +, Craig Dillabaugh via Digitalmars-d wrote: […] My main take away from that paper was that C is much slower than Java :o) This can happen! Based on those results it likely would have been trounced by Python or Ruby too. I don't know about Ruby, but Python can now be more or less as fast as C and C++. I am not joking on this one, even my π by quadrature codes can show Python running computational loops as fast. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Comparing Parallelization in HPC with D, Chapel, and Go
Compilers and interpreters used Turbo C++ IDE :-) On Monday, 24 November 2014 at 11:53:08 UTC, Craig Dillabaugh wrote: On Monday, 24 November 2014 at 03:48:27 UTC, Andrei Amatuni wrote: This prompted me to google for recent academic papers on D, which led me to this: http://research.ijcaonline.org/volume104/number7/pxc3898921.pdf not exactly the most rigorous research, but it's pretty favorable... My main take away from that paper was that C is much slower than Java :o) Based on those results it likely would have been trounced by Python or Ruby too.
Re: Testing lazy ranges in post-conditions
On Monday, 24 November 2014 at 12:20:40 UTC, bearophile wrote:
Peter Alexander:
Should be able to do:
assert(result.save.all!(x = x 10));
But iota's save isn't const, so you can't (that's a bug).
Mine was just an example of the general problem, another
example:
import std.range, std.algorithm;
auto foo()
out(result) {
assert(result.all!(b = b.length == 2));
} body {
auto a = new int[10];
return a.chunks(2);
}
void main() {}
Chunks.save should also be const, so result.save.{...} should
work.
It becomes a real problem with input ranges, because you can't
save them. That makes sense though, as there is no way to consume
the result in a post-condition check that doesn't consume it.
That's just a fact of life and a limitation of trying to verify
mutable data.
Re: Testing lazy ranges in post-conditions
Peter Alexander:
Chunks.save should also be const, so result.save.{...} should
work.
But it doesn't. Should I have to file two bug reports (ERs) on
iota and chunks?
It becomes a real problem with input ranges, because you can't
save them. That makes sense though, as there is no way to
consume the result in a post-condition check that doesn't
consume it.
I agree.
Bye,
bearophile
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 08:46:20 UTC, Walter Bright wrote: On 11/21/2014 12:10 AM, bearophile wrote: Walter Bright: All you're doing is trading 0 crossing for 0x7FFF crossing issues, and pretending the problems have gone away. I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone. I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFF crossing bugs is making the bug count less. BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. Is this true? Do you have some examples of buggy code? http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html Changing signed to unsigned in that example does NOT fix the bug. It just means it fails with length = 2^^31 instead of length = 2^^30. uint a = 0x8000_u; uint b = 0x8000_0002u; assert( (a + b) /2 == 0); But actually I don't understand that article. The arrays are int, not char. Since length fits into 32 bits, the largest possible value is 2^^32-1. Therefore, for an int array, with 4 byte elements, the largest possible value is 2^^30-1. So I think the article is wrong. I don't think there is a bug in the code.
Re: Testing lazy ranges in post-conditions
On Monday, 24 November 2014 at 14:20:02 UTC, bearophile wrote:
Peter Alexander:
Chunks.save should also be const, so result.save.{...} should
work.
But it doesn't. Should I have to file two bug reports (ERs) on
iota and chunks?
I suppose chunks should be inout, because you might want mutable
chunks.
You could file bug reports, but you can't really add const/inout
manually in templates. The dependencies on the const-ness of
template parameters makes it unmanageable. You need it to be
inferred.
See:
https://issues.dlang.org/show_bug.cgi?id=7521
https://issues.dlang.org/show_bug.cgi?id=8407
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/24/14 2:20 AM, Don wrote: I am proposing that for .length returns a signed type, that for array slices is guaranteed to never be negative. Assuming you do make the case this change is an improvement, do you believe it's worth the breakage it would create? -- Andrei
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/24/14 4:54 AM, Don wrote: In D, 1u - 2u 0u. This is defined behaviour, not an overflow. I think I get what you mean, but overflow is also defined behavior (in D at least). -- Andrei
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Mon, 24 Nov 2014 12:54:58 + Don via Digitalmars-d digitalmars-d@puremagic.com wrote: In D, 1u - 2u 0u. This is defined behaviour, not an overflow. p.s. sorry, of course this is not and overflow. this is underflow. signature.asc Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Mon, 24 Nov 2014 12:54:58 + Don via Digitalmars-d digitalmars-d@puremagic.com wrote: In D, 1u - 2u 0u. This is defined behaviour, not an overflow. this *is* overflow. D just has overflow result defined. signature.asc Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 16:00:53 UTC, ketmar via Digitalmars-d wrote: this *is* overflow. D just has overflow result defined. So it basically is and isn't modular arithmetic at the same time? I think Ada got this right by providing the ability to specify the modulo value, so you can define: type Weekday is mod 7; type Byte is mod 256; A solid solution solution is to provide «As if Infinitely Ranged Integer Model» where the compiler figures out how large integers are needed for computation and then does overflow detection when you truncate for storage: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 16:45:35 UTC, Ola Fosheim Grøstad wrote: On Monday, 24 November 2014 at 16:00:53 UTC, ketmar via Digitalmars-d wrote: this *is* overflow. D just has overflow result defined. So it basically is and isn't modular arithmetic at the same time? Overflow is part of modular arithmetic. However, there is no signed and unsigned modular arithmetic, or, more precisely, they are the same. Computer words just aren't a good representation of integers. You can either use modular arithmetic, which follows the common arithmetic laws for addition and multiplication (commutativity, associativity, etc., even most non-zero numbers have a multiplicative inverse), but break the common ordering laws (a = 0 b = 0 implies a+b = 0). Or you can use some other order preserving arithmetic (e.g. saturating to min/max values), but that breaks the arithmetic laws. I think Ada got this right by providing the ability to specify the modulo value, so you can define: type Weekday is mod 7; type Byte is mod 256; A solid solution solution is to provide «As if Infinitely Ranged Integer Model» where the compiler figures out how large integers are needed for computation and then does overflow detection when you truncate for storage: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019 You could just as well use a library like GMP.
Re: Comparing Parallelization in HPC with D, Chapel, and Go
On Friday, 21 November 2014 at 22:57:44 UTC, Kapps wrote: On Friday, 21 November 2014 at 21:53:00 UTC, bearophile wrote: anon: https://www.academia.edu/3982638/A_Study_of_Successive_Over-relaxation_SOR_Method_Parallelization_Over_Modern_HPC_Languages Thank you for the link, it's very uncommon to see papers that use D. But where's the D/Go/Chapel source code? What's the compiler/version used? (When you do floating point benchmarks there's a huge difference between LDC2 and DMD). Bye, bearophile The flags make it likely that DMD was used (-O -inline -release). IIRC there were some problems with DMD that made it not perform too well in these types of benchmarks that use std.parallelism. Results would likely have been noticeably better with GDC or LDC. Whenever there is a benchmark like this the D community outlines a number of obvious to arcane speedups. Our house needs to be in order such that the obvious choice is at least competitive to the speed claims made for D. DMD particularly, while not optimisation focused, should improve its floating point speed and avoid surprising 80 bit floating point behaviours, or at least try to be surprising in a manner more in line with what users of other languages are used to.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 17:12:31 UTC, Matthias Bentrup wrote: Overflow is part of modular arithmetic. However, there is no signed and unsigned modular arithmetic, or, more precisely, they are the same. Would you say that a phase that goes from 0…2pi overflows? Does polar coordinates overflow once every turn? I'd say overflow/underflow means that the result is wrong. (Carry is not overflow per se). Or you can use some other order preserving arithmetic (e.g. saturating to min/max values), but that breaks the arithmetic laws. I don't think it breaks them, but I think a system language would be better off by having explicit operators for alternative edge-case handling on a bit-fiddling type. E.g.: a + b as regular addition a (+) b as modulo arithmetic addition a [+] b as clamped (saturating) addition The bad behaviour of C-like languages is the implicit coercion to/from a bit-fiddling type. The bit-fiddling should be contained in expression where the programmer by choosing the type says I am gonna do tricky bit hacks here. Just casting to uint does not convey that message in a clear manner. A solid solution solution is to provide «As if Infinitely Ranged Integer Model» where the compiler figures out how large integers are needed for computation and then does overflow detection when you truncate for storage: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019 You could just as well use a library like GMP. I think the point with having compiler support is to retain most optimizations. The compiler select the most efficient representation based on the needed headroom and makes sure that overflow is recorded so that you can eventually respond to it. If you couple AIR with constrained integer types, which Pascal and Ada has, then it can be very efficient in many cases.
Does RTTI and exceptions work in dlls on windows?
I've got little test here https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29. I have one application and two dlls. Application loads both dlls, calls their factory functions and then passes each IModule instance that it got from factories to those modules. Modules then try to cast those IModule refs back to their real interfaces (ISharedModule1) but i am getting null there. A have found a workaround for this by returning a void* pointer to real interface and it back when needed. Another, and more major issue is, that when exception is thrown application fail immediately. Is it broken on windows, or it is me doing it wrong?
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 17:55:06 UTC, Ola Fosheim Grøstad wrote: I think the point with having compiler support is to retain most optimizations. The compiler select the most efficient representation based on the needed headroom and makes sure that overflow is recorded so that you can eventually respond to it. It is also worth noting that Intel CPUs have 3 new instructions for working with large integers: MULX and ADCX/ADOX. http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/ia-large-integer-arithmetic-paper.html So there is no reason to not go for it IMO.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 17:55:06 UTC, Ola Fosheim Grøstad wrote: On Monday, 24 November 2014 at 17:12:31 UTC, Matthias Bentrup wrote: Overflow is part of modular arithmetic. However, there is no signed and unsigned modular arithmetic, or, more precisely, they are the same. Would you say that a phase that goes from 0…2pi overflows? Does polar coordinates overflow once every turn? No, sin and cos are periodic functions, but that doesn't mean their arguments are modular. sin 4pi is well defined by e.g. the taylor expansion of sin without any modular arithmetic at all. I'd say overflow/underflow means that the result is wrong. (Carry is not overflow per se). There is no right or wrong in Mathematics, only true and false. The result of modular addition with overflow is not wrong, it is just different than the result of integer addition. Or you can use some other order preserving arithmetic (e.g. saturating to min/max values), but that breaks the arithmetic laws. I don't think it breaks them, but I think a system language would be better off by having explicit operators for alternative edge-case handling on a bit-fiddling type. E.g.: a + b as regular addition a (+) b as modulo arithmetic addition a [+] b as clamped (saturating) addition The bad behaviour of C-like languages is the implicit coercion to/from a bit-fiddling type. The bit-fiddling should be contained in expression where the programmer by choosing the type says I am gonna do tricky bit hacks here. Just casting to uint does not convey that message in a clear manner. Agreed, though I don't like the explosion of new operators. I'd prefer the C# syntax like check(expression), wrap(expression), saturate(expression). A solid solution solution is to provide «As if Infinitely Ranged Integer Model» where the compiler figures out how large integers are needed for computation and then does overflow detection when you truncate for storage: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019 You could just as well use a library like GMP. I think the point with having compiler support is to retain most optimizations. The compiler select the most efficient representation based on the needed headroom and makes sure that overflow is recorded so that you can eventually respond to it. If you couple AIR with constrained integer types, which Pascal and Ada has, then it can be very efficient in many cases. And can fail spectacularly in others. The compiler always has to prepare for the worst case, i.e. the largest integer size possible, while in practice you may need that only for a few extreme cases.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 19:06:35 UTC, Matthias Bentrup wrote: There is no right or wrong in Mathematics, only true and false. The result of modular addition with overflow is not wrong, it is just different than the result of integer addition. I think we are talking past each other. In my view the term overflow has nothing to do with mathematics, overflow is a signal from the ALU that the computation is incorrect e.g. not in accordance with the intended type. Agreed, though I don't like the explosion of new operators. I'd prefer the C# syntax like check(expression), wrap(expression), saturate(expression). Yep, that is another way to do it. What is preferable probably varies from case to case. And can fail spectacularly in others. The compiler always has to prepare for the worst case, i.e. the largest integer size possible, while in practice you may need that only for a few extreme cases. In some loops it probably can get tricky to get it right without help from the programmer. I believe some languages allow you to annotate loops with an upper boundary to help the semantic analysis, but you could also add more frequent overflow checks on request?
Re: Does RTTI and exceptions work in dlls on windows?
On 24.11.2014 19:20, MrSmith wrote:
I've got little test here
https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.
I have one application and two dlls. Application loads both dlls, calls
their factory functions and then passes each IModule instance that it
got from factories to those modules.
Modules then try to cast those IModule refs back to their real
interfaces (ISharedModule1) but i am getting null there.
The different DLLs have different copies of the RTTI for the classes
(you could not link them separately otherwise). Looking for base classes
or derived classes only compares RTTI pointers, so it doesn't find the
target class of a cast in the hierarchy inside another DLL.
A have found a workaround for this by returning a void* pointer to real
interface and it back when needed.
Another workaround for a limited number of classes would be to add
member functions 'ISharedModule1 toSharedModule1() { return null; }' in
IModule and override these 'ISharedModule1 toSharedModule1() { return
this; }' in the appropriate class.
Another, and more major issue is, that when exception is thrown
application fail immediately.
Is it broken on windows, or it is me doing it wrong?
I haven't tried in a while but I think it should work on Win32, but
probably does not on Win64.
Re: Does RTTI and exceptions work in dlls on windows?
On Monday, 24 November 2014 at 20:56:29 UTC, Rainer Schuetze
wrote:
On 24.11.2014 19:20, MrSmith wrote:
I've got little test here
https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.
I have one application and two dlls. Application loads both
dlls, calls
their factory functions and then passes each IModule instance
that it
got from factories to those modules.
Modules then try to cast those IModule refs back to their real
interfaces (ISharedModule1) but i am getting null there.
The different DLLs have different copies of the RTTI for the
classes (you could not link them separately otherwise). Looking
for base classes or derived classes only compares RTTI
pointers, so it doesn't find the target class of a cast in the
hierarchy inside another DLL.
A have found a workaround for this by returning a void*
pointer to real
interface and it back when needed.
Another workaround for a limited number of classes would be to
add member functions 'ISharedModule1 toSharedModule1() { return
null; }' in IModule and override these 'ISharedModule1
toSharedModule1() { return this; }' in the appropriate class.
Another, and more major issue is, that when exception is thrown
application fail immediately.
Is it broken on windows, or it is me doing it wrong?
I haven't tried in a while but I think it should work on Win32,
but probably does not on Win64.
I thought it will work at least for interfaces.
Any way, this is workaroundable, but exceptions must be there at
least.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/24/2014 2:20 AM, Don wrote: I believe I do understand the problem. As a practical matter, overflow checks are not going to be added for performance reasons. The performance overhead would be practically zero. All we would need to do, is restrict array slices such that the length cannot exceed ssize_t.max. This can only happen in the case where the element type has a size of 1, and only in the case of slicing a pointer, concatenation, and memory allocation. (length1 + length2) / 2 In exchange, 99% of uses of unsigned would disappear from D code, and with it, a whole category of bugs. You're not proposing changing size_t, so I believe this statement is incorrect. Also, in principle, uint-uint can generate a runtime check for underflow (i.e. the carry flag). No it cannot. The compiler does not have enough information to know if the value is intended to be positive integer, or an unsigned. That information is lost from the type system. Eg from C, wrapping of an unsigned type is not an error. It is perfectly defined behaviour. With signed types, it's undefined behaviour. I know it's not an error. It can be defined to be an error, and the compiler can insert a runtime check. (I'm not proposing this, just saying it can be done.) To make this clear: I am not proposing that size_t should be changed. I am proposing that for .length returns a signed type, that for array slices is guaranteed to never be negative. There'll be mass confusion if .length is not the same type as .sizeof
Re: std.experimental.logger formal review round 3
Anyone know anything about this? https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac
Re: Ranges and Exception handling PR 2724
On Friday, 21 November 2014 at 16:57:29 UTC, Marco Leise wrote: Am Fri, 21 Nov 2014 08:56:17 + schrieb Jonathan Marler johnnymar...@gmail.com: I actually ran into this problem today when using the dirEntries function in std.file. I was attempting to iterate all the files on my C drive and I got an Access Denied error which caused the DirIterator to throw an exception. There's nothing I could do to catch the exception and continue. I'm very glad people are aware of this problem and I'm glad you are trying to do something about it. Yep, that dirEntries Exception is quite the show stopper. You need to be certain that you have access to all directories that it may encounter, which makes it unusable for file system roots, but also breaks way to easily with unreadable directories in user directories when all you need is a list of the _accessible_ files. The bug reports so far: std.file: dirEntries-range crashes, when hitting the system folder System Volume Information https://issues.dlang.org/show_bug.cgi?id=12513 DirEntries throws in foreach https://issues.dlang.org/show_bug.cgi?id=12391 dirEntries throws when encountering a long path on windows https://issues.dlang.org/show_bug.cgi?id=8967 Submitted my idea as a PR in phobos here: https://github.com/D-Programming-Language/phobos/pull/2655
Re: Ranges and Exception handling PR 2724
On Tuesday, 25 November 2014 at 00:46:11 UTC, Jonathan Marler wrote: On Friday, 21 November 2014 at 16:57:29 UTC, Marco Leise wrote: Am Fri, 21 Nov 2014 08:56:17 + schrieb Jonathan Marler johnnymar...@gmail.com: I actually ran into this problem today when using the dirEntries function in std.file. I was attempting to iterate all the files on my C drive and I got an Access Denied error which caused the DirIterator to throw an exception. There's nothing I could do to catch the exception and continue. I'm very glad people are aware of this problem and I'm glad you are trying to do something about it. Yep, that dirEntries Exception is quite the show stopper. You need to be certain that you have access to all directories that it may encounter, which makes it unusable for file system roots, but also breaks way to easily with unreadable directories in user directories when all you need is a list of the _accessible_ files. The bug reports so far: std.file: dirEntries-range crashes, when hitting the system folder System Volume Information https://issues.dlang.org/show_bug.cgi?id=12513 DirEntries throws in foreach https://issues.dlang.org/show_bug.cgi?id=12391 dirEntries throws when encountering a long path on windows https://issues.dlang.org/show_bug.cgi?id=8967 Submitted my idea as a PR in phobos here: https://github.com/D-Programming-Language/phobos/pull/2655 Woops wrong link, heres the right one: https://github.com/D-Programming-Language/phobos/pull/2768
Re: std.experimental.logger formal review round 3
On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote: Anyone know anything about this? https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac You are posting to page 16 of the third iteration of a single review.
Re: std.experimental.logger formal review round 3
On 11/24/2014 4:51 PM, Brian Schott wrote: On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote: Anyone know anything about this? https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac You are posting to page 16 of the third iteration of a single review. I know, and the reddit comment refers to this.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 19:06:35 UTC, Matthias Bentrup
wrote:
Agreed, though I don't like the explosion of new operators. I'd
prefer the C# syntax like check(expression), wrap(expression),
saturate(expression).
You maybe like this:
---small test 1--
import std.stdio;
template subuint(T1,T2){
auto subuint(T1 x, T2 y, ref bool overflow)
{
if(is(T1 == uint) is(T2==uint))
{
if (x y)
{
return cast(int)(x -y);
}
else
{
return x - y;
}
}
else if(is(T1 == uint) is(T2==int))
{writeln(enter here1);
if (x y)
{ writeln(enter here2);
return cast(int)(x -y);
}
else
{ writeln(enter here3);
return x - y;
}
}
else if(is(T1 == int) is(T2==uint))
{
if (x y)
{
return cast(int)(x -y);
}
else
{
return x - y;
}
}
else if(is(T1 == int) is(T2==int))
{
return x - y;
}
}
}
unittest
{
bool overflow;
assert(subuint(3, 2, overflow) == 1);
assert(!overflow);
assert(subuint(3, 4, overflow) == -1);
assert(!overflow);
assert(subuint(uint.max, 1, overflow) == uint.max - 1);
writeln(typeid = ,typeid(subuint(uint.max, 1, overflow)));
assert(!overflow);
assert(subuint(1, 1, overflow) == uint.min);
assert(!overflow);
assert(subuint(0, 1, overflow) == -1);
assert(!overflow);
assert(subuint(uint.max - 1, uint.max, overflow) == -1);
assert(!overflow);
assert(subuint(0, 0, overflow) == 0);
assert(!overflow);
assert(subuint(3, -2, overflow) == 5);
assert(!overflow);
assert(subuint(uint.max, -1, overflow) == uint.max + 1);
assert(!overflow);
assert(subuint(1, -1, overflow) == 2);
assert(!overflow);
assert(subuint(0, -1, overflow) == 1);
assert(!overflow);
assert(subuint(uint.max - 1, int.max, overflow) == int.max);
assert(!overflow);
assert(subuint(0, 0, overflow) == 0);
assert(!overflow);
assert(subuint(-2, 1, overflow) == -3);
assert(!overflow);
}
void main()
{
uint a= 3;
int b = 4;
int c =2;
writeln(c -a =,c-a);
writeln(a -b =,a-b);
writeln();
bool overflow;
writeln(typeid = ,typeid(subuint(a, b, overflow)),,
a-b=,subuint(a, b, overflow));
writeln(ok);
}
---here is a simple ,but it's
error--
import std.stdio;
template subuint(T1,T2){
auto subuint(T1 x, T2 y, ref bool overflow)
{
if(is(T1 == int) is(T2==int))
{
return x - y;
}
else if((is(T1 == uint) is(T2==int)) | (is(T1 == uint)
is(T2==uint)) | (is(T1 == int) is(T2==uint)))
{
if (x y)
{
return cast(int)(x -y);
}
else
{
return x - y;
}
}
}
}
void main()
{
uint a= 3;
int b = 4;
int c =2;
writeln(c -a =,c-a);
writeln(a -b =,a-b);
writeln();
bool overflow;
writeln(typeid = ,typeid(subuint(a, b, overflow)),,
a-b=,subuint(a, b, overflow));
writeln(ok);
}
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Monday, 24 November 2014 at 16:00:53 UTC, ketmar via Digitalmars-d wrote: On Mon, 24 Nov 2014 12:54:58 + Don via Digitalmars-d digitalmars-d@puremagic.com wrote: In D, 1u - 2u 0u. This is defined behaviour, not an overflow. this *is* overflow. D just has overflow result defined. No, that is not overflow. That is a carry. Overflow is when the sign bit changes.
Re: @property method needs ()
On Mon, 24 Nov 2014 06:56:08 +
Andre via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Hi,
in following example the @property method needs the ()
otherwise compiler error for row 24 is thrown.
I cannot judge, whether the compiler behaves correct or not.
Kind regards
André
---
alias fnError = void delegate(string s);
interface IfSession
{
@property fnError addError();
}
class Session: IfSession
{
private fnError _addError;
@property fnError addError()
{
return _addError;
}
}
void main()
{
auto session = new Session();
session._addError = delegate(s){};
session.addError()(test); // Works
session.addError(test); // Does not work
}
a known thing. not sure if this is a known *bug* (seems that almost
nobody cares). compiler is obviously wrong here (and i believe that
it's wrong to accept `()` for properties at all), but i don't know if
this will ever be fixed.
signature.asc
Description: PGP signature
Re: @property method needs ()
On Monday, 24 November 2014 at 08:35:08 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 24 Nov 2014 06:56:08 +
Andre via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Hi,
in following example the @property method needs the ()
otherwise compiler error for row 24 is thrown.
I cannot judge, whether the compiler behaves correct or not.
Kind regards
André
---
alias fnError = void delegate(string s);
interface IfSession
{
@property fnError addError();
}
class Session: IfSession
{
private fnError _addError;
@property fnError addError()
{
return _addError;
}
}
void main()
{
auto session = new Session();
session._addError = delegate(s){};
session.addError()(test); // Works
session.addError(test); // Does not work
}
a known thing. not sure if this is a known *bug* (seems that
almost
nobody cares). compiler is obviously wrong here (and i believe
that
it's wrong to accept `()` for properties at all), but i don't
know if
this will ever be fixed.
There's hope that this will get fixed in the near future:
https://github.com/D-Programming-Language/dmd/pull/2305
Re: print yyyy-mm-dd
Is there any way to set separator? For example I want use '/' or ':'?
Re: print yyyy-mm-dd
And could anybody explain me how the cast is work. How to understand which types to which may be casted?
Re: print yyyy-mm-dd
On Monday, November 24, 2014 10:33:16 Suliman via Digitalmars-d-learn wrote: Is there any way to set separator? For example I want use '/' or ':'? No. toISOString and toISOExtString support the ISO and Extended ISO formats from the ISO standard, and std.datetime does not currently support custom date/time string formatting (though it's on the todo list). The only non-standard format that it currently suports is Boost's simple time via toSimpleString, and it probably shouldn't even be there, since it just confuses things without adding any real, useful functionality. Custom date/time string formatting is what's really needed for non-standard representations, especially because everyone has a different way that they want to represent the time. However, most code really should use toISOExtString, since it's standard and reasonably readable (e.g. 2014-11-24T02:53:12 as opposed to the non-extended ISO format of 20141124T025312). - Jonathan M Davis
Re: print yyyy-mm-dd
On Monday, November 24, 2014 10:38:55 Suliman via Digitalmars-d-learn wrote: And could anybody explain me how the cast is work. How to understand which types to which may be casted? Look at the documentation for opCast. That's how the casting is done. But what it comes down to is SysTime - DateTime, Date, or TimeOfDay DateTime - Date or TimeOfDay Those are the conversions which lose information, so they can be done via casts, whereas the conversions that would increase the amount of information in the type require using a constructor, because you have to use information from multiple objects to be able to create the new object. e.g. auto dt = DateTime(date, tod); The primary reason to cast a SysTime to a Date prior to calling toISOExtString on it is to strip off the time portion, but slicing the result as uri suggested works too (though it's probably a tad less efficient due to the time spent creating the portion of the string that isn't even used). - Jonathan M Davis
Re: @property method needs ()
Thanks a lot for the info. Kind regards André On Monday, 24 November 2014 at 09:26:16 UTC, Marc Schütz wrote: On Monday, 24 November 2014 at 08:35:08 UTC, ketmar via Digitalmars-d-learn wrote: a known thing. not sure if this is a known *bug* (seems that almost nobody cares). compiler is obviously wrong here (and i believe that it's wrong to accept `()` for properties at all), but i don't know if this will ever be fixed. There's hope that this will get fixed in the near future: https://github.com/D-Programming-Language/dmd/pull/2305
projections in D
what range/algorithm allows me to make projections from one
sequence to another?
that is, in C#, this is the Select method
(http://msdn.microsoft.com/en-us/library/vstudio/bb548891%28v=vs.100%29.aspx)
example in C#:
class ProjectionWanted
{
public int field1 { get; set; }
public int field2 { get; set; }
public int field3 { get; set; }
}
void Foo(ListProjectionWanted list)
{
var list_projected = list.Select(l = new { l.field1, l.field2
});
// list_projected elements now contain only field1 and field2
}
So how would I make it in D? First yet, does D supports creating
anonymous type for the projection? Or maybe I need to declare the
class/struct that I want to be projected?
Re: projections in D
Ramon:
example in C#:
class ProjectionWanted
{
public int field1 { get; set; }
public int field2 { get; set; }
public int field3 { get; set; }
}
void Foo(ListProjectionWanted list)
{
var list_projected = list.Select(l = new { l.field1,
l.field2 });
// list_projected elements now contain only field1 and field2
}
Here I have defined ProjectionWanted as a struct.
//--
import std.stdio, std.algorithm, std.typecons;
struct ProjectionWanted {
public int a, b, c;
}
auto foo(ProjectionWanted[] seq) pure nothrow @safe @nogc {
return seq.map!(p = tuple(p.a, p.b));
}
void main() {
[ProjectionWanted(1, 2, 3), ProjectionWanted(4, 5, 6)]
.foo
.writeln;
}
//--
Note that foo() returns a lazy range. If you need an eager one
you can append an .array:
return seq.map!(p = tuple(p.a, p.b)).array;
And you have to import std.array too.
Bye,
bearophile
Re: projections in D
What is the difference between lazy and eager ranges? (I guess, the lazy one has not yet queried the elements)
Re: projections in D
On Monday, 24 November 2014 at 15:44:02 UTC, Ramon wrote: What is the difference between lazy and eager ranges? (I guess, the lazy one has not yet queried the elements) The lazy returns a range that once iterated gives the results one at a time (so the function allocates no heap memory). The eager version creates an array of the results in heap memory. Bye, bearophile
Re: Sum informations in file....
I can't understand why foreach loop produce every line by line,
while it's fuctional analog print lines on one string:
foreach(f; file.byLine())
{
writeln(f);
}
auto file = File(foo.txt,r);
file
.byLine()
.writeln;
file content:
-
first sring
second string
-
Output:
D:\code\JSONServer\sourceapp.exe
[first sring, second string]
expected:
first sring
second string
Re: Sum informations in file....
On Mon, 24 Nov 2014 19:04:34 + Suliman via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I can't understand why foreach loop produce every line by line, while it's fuctional analog print lines on one string: the two samples are not the same, they doing completely different things. File.byLine returns *output* *range*. what `foreach` does is processing this range element by element, while `writeln(range)` outputs the whole range. the second code means: auto lines = file.byLine(); writeln(lines); for `writeln` output range is a kind of array, so it outputs it as an array. signature.asc Description: PGP signature
Re: Sum informations in file....
On 11/24/2014 11:04 AM, Suliman wrote:
I can't understand why foreach loop produce every line by line, while
it's fuctional analog print lines on one string:
foreach(f; file.byLine())
{
writeln(f);
f is a char[] and writeln prints all strings as their contents i.e.
first string is printed as
first string
}
auto file = File(foo.txt,r);
file
.byLine()
.writeln;
In that case the first three lines make a range object. By default,
writeln prints ranges as if they are arrays. For this example, the range
is a range of strings, so it prints it as
[ first string ]
writefln gives us more power:
auto content = File(foo.txt,r).byLine();
writefln(%-(%s\n%), content);
Per-element formatting is specified within %( and %). So, each element
would be printed with %s\n format. Notes:
1) The dash in %-( means do not print the double-quotes for strings
2) Everything after %s in the per-element formatting is taken as element
delimiter and writefln does not print the delimiters are not printed for
the last element. One may need to use %| to specify the actual delimiters.
Here is the spec:
http://dlang.org/phobos/std_format.html#.formattedWrite
Here is my rewording:
http://ddili.org/ders/d.en/formatted_output.html
Ali
Re: Sum informations in file....
On 11/24/2014 11:30 AM, ketmar via Digitalmars-d-learn wrote: File.byLine returns *output* *range*. Although the range is used for outputting, it is still an InputRange. :) Ali
Re: Sum informations in file....
On Mon, 24 Nov 2014 11:41:43 -0800 Ali Çehreli via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On 11/24/2014 11:30 AM, ketmar via Digitalmars-d-learn wrote: File.byLine returns *output* *range*. Although the range is used for outputting, it is still an InputRange. :) ah, yes, my bad. i'm always tend to mess with input, output, client, server and such. knowing that i checked three times if i wrote the correct range direction and... failed it. signature.asc Description: PGP signature
Re: Sum informations in file....
On Monday, 24 November 2014 at 20:23:57 UTC, Suliman wrote: thanks! But how I can skip first line? My varian: auto lines = foo.txt.File .byLine .filter!(f=f[0] != f[0]); With 'drop' from std.range: auto lines = foo.txt.File .byLine .drop(1) .filter!(f=f[0] != f[0]);
Re: Sum informations in file....
Thanks! But is there any way to do it with std.algorithm? Can be skipOver used for it?
DerelictOrg and SDL_Mixer
Hi all, I'm playing a bit with D and SDL using DerelictOrg on debian 6. I've installed SDL2, SDL_mixer2 and the latest packages DerelictUtil and DerelictSDL2. I can display some stuffs and interact with the keys. Now I'm trying to add music and sounds but each time I try to access a function from SDL_mixer ( I tried with Mix_openAudio and Mix_LoadWav ), I get a segmentation fault. These functions are defined in the mixer.d file in the DerelictSDL2 package but I guess I miss something concerning the link to the real sdl_mixer lib file. Is there a specific way to install the sdl_mixer package with DerelictSDL2?
opEquals unsafe? Please tell me this isnt true...
@safe
class Y { }
@safe
class X { }
@safe
class Z
{
int x;
this()
{
if (typeid(X) == typeid(Y)) x = 1; // Compile Error
else x = 2;
}
}
void main() { new Z; }
// test.d(19): Error: safe function 'test.Z.this'
// cannot call system function 'object.opEquals'
Isn't this analagous to saying that the instanceof operator
in java endangers the GC?
Is it correct to replace '==' with 'is'?
-Eric
Something between a scalar and an enum
An enumeration contains a small number of distinct elements:
enum Colors { red, green, yellow, brown }
While an integral numeric value encodes a scalar:
uint x;
x = 120;
x++;
A sufficiently common pattern in my code is to have something
intermediate: that has a small group of special values, plus many
values identified just by a number.
alias Unit = uint;
enum : Uint { EmptyUnit = 0, BrokenUnit = Unit.max - 1,
MissingUnit = Unit.max }
This allows me to denote some special units, plus count the units
starting from 1 up to millions or more.
It's unfortunate the D type system doesn't offer me much good to
express this idiom, but I am not sure how much a type system can
help here even in principle.
Bye,
bearophile
A nice D coding pattern
In some D programs I'm using this coding pattern:
struct Foo {
// Instance fields here.
@disable this();
this(in string[] data) pure @safe
in {
// Many pre-conditions here.
} out(result) {
// Some post-conditions here.
} body {
// ...
}
Nullable!(string[][]) doIt() pure {
//...
}
// Various other methods here...
}
void main() {
// Created at compile-time.
enum something = .Foo;
// Something much larger is done at run-time.
immutable const result = something.doIt;
}
The structure is created at compile-time using data known at
compile-time (here a string). This struct has a constructor that
runs at compile-time that has many pre-conditions that avoid
wrong input data at compile-time.
The largest part of the computation is done at run-time calling
one or more struct methods.
And the @disable this() assures that a struct is correctly
initialized by the constructor.
This pattern has significant advantages regarding code
reliability.
You can see an example of this pattern that I've used here:
http://rosettacode.org/wiki/Solve_a_Hopido_puzzle#D
Bye,
bearophile
Re: DerelictOrg and SDL_Mixer
On Monday, 24 November 2014 at 21:19:40 UTC, torea wrote: Hi all, I'm playing a bit with D and SDL using DerelictOrg on debian 6. I've installed SDL2, SDL_mixer2 and the latest packages DerelictUtil and DerelictSDL2. I can display some stuffs and interact with the keys. Now I'm trying to add music and sounds but each time I try to access a function from SDL_mixer ( I tried with Mix_openAudio and Mix_LoadWav ), I get a segmentation fault. These functions are defined in the mixer.d file in the DerelictSDL2 package but I guess I miss something concerning the link to the real sdl_mixer lib file. Is there a specific way to install the sdl_mixer package with DerelictSDL2? It's a common error but did you load the Mixer and SDL libraries? DerelictSDL2Mixer.load(); DerelictSDL2.load(); And some code or output from gdb would be most helpful.
Re: DerelictOrg and SDL_Mixer
On Monday, 24 November 2014 at 23:27:58 UTC, Jack wrote: It's a common error but did you load the Mixer and SDL libraries? DerelictSDL2Mixer.load(); DerelictSDL2.load(); And some code or output from gdb would be most helpful. Oh.. I didn't know about the DerelictSDL2Mixer.load()! I thought the initialization of sdl_mixer was done with DerelictSDL2.load() Thanks very much!! I'll try this tonight! (And yes, I know it's better to post some code but I forgot to bring the source code..)
Re: opEquals unsafe? Please tell me this isnt true...
On Monday, November 24, 2014 22:12:08 Eric via Digitalmars-d-learn wrote:
@safe
class Y { }
@safe
class X { }
@safe
class Z
{
int x;
this()
{
if (typeid(X) == typeid(Y)) x = 1; // Compile Error
else x = 2;
}
}
void main() { new Z; }
// test.d(19): Error: safe function 'test.Z.this'
// cannot call system function 'object.opEquals'
Isn't this analagous to saying that the instanceof operator
in java endangers the GC?
Is it correct to replace '==' with 'is'?
It's not that it's inherently unsafe. The problem is a combination of the
fact that stuff in druntime that pre-existed @safe hasn't been made @safe
yet (particularly, stuff in TypeInfo) and the fact that Object shouldn't
even have opEquals, opCmp, toHash, or toString on it, because that restricts
which attributes can be used
( https://issues.dlang.org/show_bug.cgi?id=9769 ), though I think that with
@safe, we can work around that (unlike with const). However, for whatever
reason, TypeInfo's opEquals function hasn't been marked with @safe or
@trusted, so it's considered @system. That will need to be fixed, but I
don't know if there are any implementation issues preventing it. It _looks_
like it could probably be marked @trusted, but I haven't actually dug into
it in detail.
In any case, you should be able to just mark the constructor as @trusted for
now to work around the issue, and at some point in the future opEqualso or
TypeInfo should be @trusted or @safe.
- Jonathan M Davis
Re: opEquals unsafe? Please tell me this isnt true...
On Tuesday, 25 November 2014 at 02:48:43 UTC, Jonathan M Davis
via Digitalmars-d-learn wrote:
On Monday, November 24, 2014 22:12:08 Eric via
Digitalmars-d-learn wrote:
@safe
class Y { }
@safe
class X { }
@safe
class Z
{
int x;
this()
{
if (typeid(X) == typeid(Y)) x = 1; // Compile Error
else x = 2;
}
}
void main() { new Z; }
// test.d(19): Error: safe function 'test.Z.this'
// cannot call system function 'object.opEquals'
Isn't this analagous to saying that the instanceof operator
in java endangers the GC?
Is it correct to replace '==' with 'is'?
It's not that it's inherently unsafe. The problem is a
combination of the
fact that stuff in druntime that pre-existed @safe hasn't been
made @safe
yet (particularly, stuff in TypeInfo) and the fact that Object
shouldn't
even have opEquals, opCmp, toHash, or toString on it, because
that restricts
which attributes can be used
( https://issues.dlang.org/show_bug.cgi?id=9769 ), though I
think that with
@safe, we can work around that (unlike with const). However,
for whatever
reason, TypeInfo's opEquals function hasn't been marked with
@safe or
@trusted, so it's considered @system. That will need to be
fixed, but I
don't know if there are any implementation issues preventing
it. It _looks_
like it could probably be marked @trusted, but I haven't
actually dug into
it in detail.
In any case, you should be able to just mark the constructor as
@trusted for
now to work around the issue, and at some point in the future
opEqualso or
TypeInfo should be @trusted or @safe.
- Jonathan M Davis
Thanks for reminding me about @trusted. I'm finding it really
hard
to write robust classes in D due to all the problems with Object.
-Eric
Re: opEquals unsafe? Please tell me this isnt true...
On Tuesday, 25 November 2014 at 03:42:50 UTC, Eric wrote: I'm finding it really hard to write robust classes in D due to all the problems with Object. I wish Object didn't have any methods. One thing I do is kinda act as if it didn't and make my own interfaces instead.
[Issue 13770] New: can't mix template class and normal class
https://issues.dlang.org/show_bug.cgi?id=13770
Issue ID: 13770
Summary: can't mix template class and normal class
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: galaxyl...@gmail.com
struct Opt
{
Opt!T opCall(T)(T v)
{
.
}
}
struct Opt(T)
{
}
Error: class m.Opt conflicts with class m.Opt(T)
--
[Issue 13771] New: any language support capture acquire type?
https://issues.dlang.org/show_bug.cgi?id=13771
Issue ID: 13771
Summary: any language support capture acquire type?
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: galaxyl...@gmail.com
auto add(T)(T a,T b)
{
return to!RetureType(a+b);
}
void fun(T)(T x)
{
}
fun!double(add(1,2));
fun!int(add(1,2));
just add a implicit RetureType,not need visible,background syntax tree like
this
auto add(RetureType,T)(T a,T b)
but we can see ,the type reduce logical changed from down-up to up-down
template SelectFrom(T)
{
alias SelectFrom=T;
}
auto add(T=SelectFrom!(ReturnType))(T a,T b)
these will change the language' template more magic when mix use with
opCast,opDispacth...act
--
[Issue 13772] New: template capture error
https://issues.dlang.org/show_bug.cgi?id=13772
Issue ID: 13772
Summary: template capture error
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: galaxyl...@gmail.com
//more,now DMD implement follow two case no difference
//classP(T:U!(V,X),alias U,V){}===classP(T:U!(V,X),alias U,V...){}
class U(V...)
{
}
classP(T:U!(V,X),alias U,V,X,D=U!(V,X))
{
}
P!(U!(int,int,int,int)) p;
@property void opCall(P)(P)
{
writeln(typeid(N));
}
P!(U!(int,int,int,int)) p;
p();
//output
//m.P!(U!(int, int, int, int), U, int, int, U!(int, int)).P
there also a problem that,as you can see
@property void opCall(P)(P)
can work
@property void opDispatch(P,string op)(P)
but not run
--
[Issue 13772] template capture error
https://issues.dlang.org/show_bug.cgi?id=13772
--- Comment #1 from galaxylang galaxyl...@gmail.com ---
//there are some copy problem
//now DMD implement follow two case no difference
//classP(T:U!(V,X),alias U,V){}===classP(T:U!(V,X),alias U,V...){}
class U(V...)
{
}
classP(T:U!(V,X),alias U,V,X,D=U!(V,X))
{
}
@property void opCall(P)(P)
{
writeln(typeid(P));
}
P!(U!(int,int,int,int)) p;
p();
//output
//m.P!(U!(int, int, int, int), U, int, int, U!(int, int)).P
//D=T,
//but now
//D=U!(int,int)
//T=U!(int, int, int, int)
there also a problem that,as you can see
@property void opCall(P)(P)
can work
@property void opDispatch(P,string op)(P)
but not run
--
