Re: transversal sum
On Thursday, 6 November 2014 at 22:40:58 UTC, John Colvin wrote:
this should be a textbook case for std.range.transposed, but I
can't seem to get it to work.
Ah, I didn't know this existed. Apparently it's not yet released,
that's why it's not in the official documentation.
With DMD and Phobos from git:
void main(string[] args)
{
import std.stdio: writeln;
import std.range: transposed;
import std.algorithm: map, sum;
int[][] input = new int[][2];
input[0] = [1, 2, 3, 4];
input[1] = [5, 6, 7, 8];
writeln(input);
auto sums = input
.transposed
.map!(a = a.sum);
writeln(sums);
}
Output:
[[1, 2, 3, 4], [5, 6, 7, 8]]
[6, 8, 10, 12]
Re: Intended behavior or bug (private vs public static)
Thanks a lot. I will create a bug report. Kind regards André On Friday, 7 November 2014 at 06:09:02 UTC, Jonathan M Davis via Digitalmars-d-learn wrote: That looks like a bug. All you have to do is change the order of the two function declarations or rename the non-static one to something else, and it compiles. So, somehow, the fact that the non-static one has the same name as the static one and the fact that it comes first screws up accessing the static one. And explicitly marking the static one as public doesn't help. So, you should report is a compiler bug: https://issues.dlang.org - Jonathan M Davis
Re: transversal sum
Marc Schütz: auto sums = input .transposed .map!(a = a.sum); And that part is better written: .map!sum; I also suggest to align the leading dot to the precedent line: auto sums = input .transposed .map!(a = a.sum); Bye, bearophile
Re: Audio file read/write?
COn Friday, 7 November 2014 at 02:58:15 UTC, Daren Scot Wilson wrote: What's the current recommended way to read and write audio files? I don't need to play it on the speakers or deal with anything real time - just read a file's data into an array, fiddle with it, and write it out to a file. I found some other threads about audio files, but none recent, mentioning SDL and OpenAL. Are these still the way to go? I'm thinking I should avoid SDL since it does far more than audio, none of which I care about. OpenAL also does way more than I care about, but at least is just audio. SDL vanilla and OpenAL won't help with reading and writing audio files. For my application, I need to read a few of the common formats, such as .wav, .au, .mp3, .ogg and whatever else is popular. I only need to write .wav but other audio tinkerers may want to write other formats. wave-d: read/write .WAV file, all at once https://github.com/d-gamedev-team/wave-d Pretty sure libsndfile can read .wav, .au, .ogg but not mp3 No commercial usage unless you pay a licence. https://github.com/p0nce/DerelictSndFile.git BASS can do it all: No commercial usage unless you pay a licence. https://github.com/p0nce/DerelictBASS SDL_mixer can read .wav .au .ogg and .mp3 https://github.com/DerelictOrg/DerelictSDL2
Re: transversal sum
On Friday, 7 November 2014 at 10:58:58 UTC, Marc Schütz wrote:
On Thursday, 6 November 2014 at 22:40:58 UTC, John Colvin wrote:
this should be a textbook case for std.range.transposed, but I
can't seem to get it to work.
Ah, I didn't know this existed. Apparently it's not yet
released, that's why it's not in the official documentation.
With DMD and Phobos from git:
void main(string[] args)
{
import std.stdio: writeln;
import std.range: transposed;
import std.algorithm: map, sum;
int[][] input = new int[][2];
input[0] = [1, 2, 3, 4];
input[1] = [5, 6, 7, 8];
writeln(input);
auto sums = input
.transposed
.map!(a = a.sum);
writeln(sums);
}
Output:
[[1, 2, 3, 4], [5, 6, 7, 8]]
[6, 8, 10, 12]
http://dlang.org/phobos-prerelease/std_range.html#.transposed
yeah it works find for arrays, but it needs assignable elements.
Re: Access Violation Tracking
On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via Digitalmars-d-learn wrote: crash+coredump is alot more useful than intercepting error and... trying to recover from undefined state? or just exit to OS, losing valuable information about a crash? Together with the DUB package backtrace this gives really nice default behaviour printing stacktrace where memory fault occurred. For details see my show case at: https://github.com/nordlow/justd/blob/master/t_errorHandler.d
Re: Access Violation Tracking
On Fri, 07 Nov 2014 08:49:34 -0500 Steven Schveighoffer via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On 11/6/14 11:43 PM, ketmar via Digitalmars-d-learn wrote: On Thu, 06 Nov 2014 22:45:23 -0500 Steven Schveighoffer via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: In an environment that you don't control, the default behavior is likely to print Segmentation Fault and exit. No core dump, no nothing. This leads to unhelpful bug reports, and seeing if you can get your client to try to make it happen again with this debug build, or with the shell set up to make a core dump. README file, prerequisites: please, turn on coredump feature if you plan to send bug reports. thank you. This doesn't help. We must live in the real world with real customers :) i do. this really helps when clients wants their problem to be solved. and if they doesn't, it's sufficient to answer like thank you for your report, we are working on it (and then dumping that report to /dev/null). this works perfectly. signature.asc Description: PGP signature
Re: Access Violation Tracking
On Fri, 07 Nov 2014 13:52:33 + Nordlöw via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via Digitalmars-d-learn wrote: crash+coredump is alot more useful than intercepting error and... trying to recover from undefined state? or just exit to OS, losing valuable information about a crash? Together with the DUB package backtrace this gives really nice default behaviour printing stacktrace where memory fault occurred. For details see my show case at: https://github.com/nordlow/justd/blob/master/t_errorHandler.d but i don't want stacktrace! i want coredump, so i can inspect the program, it's variables and it's internal state. i want to know *how* *exactly* program manages to shot itself in the foot. easily catchable segfaults are not surviving testing. and if segfault survives, most of the time it's not enough to get stack trace, i need to fire gdb with coredump and try to understand what the hell is going on there. i also developed a habit of writing assert()s before dereferencing pointers first time (including class refs) in appropriate places, so i'll got that stack trace for free. ;-) and i never turning off that asserts in release builds. signature.asc Description: PGP signature
std.array.array and immutable elements
DMD64 D Compiler v2.066.1
Why second call doesn't compile?
import std.array;
import std.algorithm;
class Foo {
bool flag;
}
void main() {
immutable(Foo)[] foos;
foreach(i; 0..5) foos ~= new Foo;
// compiles, typeof(bar1) == immutable(Foo)[]
auto bar1 = array(foos.filter!(i = i.flag));
// fails, expected typeof(bar2) == immutable(Foo)[]
auto bar2 = array(foos.map!(i = i));
}
Error: cannot implicitly convert expression (arg) of type
immutable(Foo) to test.Foo
Error: template instance
std.conv.emplaceRef!(immutable(Foo)).emplaceRef!(immutable(Foo))
error instantiating
instantiated from here: array!(MapResult!(__lambda2,
immutable(Foo)[]))
Re: std.array.array and immutable elements
On Fri, 07 Nov 2014 14:32:57 + Jack Applegame via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: ah, sorry, my bad, 'const' will not work to, for the same reason. signature.asc Description: PGP signature
Re: std.array.array and immutable elements
On Fri, 07 Nov 2014 14:32:57 +
Jack Applegame via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
import std.array;
import std.algorithm;
class Foo {
bool flag;
}
void main() {
immutable(Foo)[] foos;
foreach(i; 0..5) foos ~= new Foo;
// compiles, typeof(bar1) == immutable(Foo)[]
auto bar1 = array(foos.filter!(i = i.flag));
// fails, expected typeof(bar2) == immutable(Foo)[]
auto bar2 = array(foos.map!(i = i));
}
`map` cannot return range with immutable elements, 'cause they are
obviously generated by program, and therefore aren't immutable.
i.e. map function can do alot of things which breaks immutability
promise for range elements, and filter function cannot (as it doesn't
return new element value).
but map can return 'const' ranges, so changing your `foos` to 'const'
will work.
signature.asc
Description: PGP signature
Re: std.array.array and immutable elements
On Friday, 7 November 2014 at 14:57:56 UTC, ketmar via Digitalmars-d-learn wrote: `map` cannot return range with immutable elements, 'cause they are obviously generated by program, and therefore aren't immutable. That's not true. Runtime generated values can be immutable just fine. And it's std.array.array that's choking here, not map.
Re: std.array.array and immutable elements
On Fri, 07 Nov 2014 15:18:24 + anonymous via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Friday, 7 November 2014 at 14:57:56 UTC, ketmar via Digitalmars-d-learn wrote: `map` cannot return range with immutable elements, 'cause they are obviously generated by program, and therefore aren't immutable. That's not true. Runtime generated values can be immutable just fine. And it's std.array.array that's choking here, not map. ah, sorry, maybe i'm too tired now and talking nonsense. it can have a perfect sense for me, but still be nonsense. but don't blame me, it's gdc bug which makes gdc segfaults on my code, it eats all my brains. signature.asc Description: PGP signature
Re: std.array.array and immutable elements
On Friday, 7 November 2014 at 14:33:00 UTC, Jack Applegame wrote:
DMD64 D Compiler v2.066.1
Why second call doesn't compile?
import std.array;
import std.algorithm;
class Foo {
bool flag;
}
void main() {
immutable(Foo)[] foos;
foreach(i; 0..5) foos ~= new Foo;
// compiles, typeof(bar1) == immutable(Foo)[]
auto bar1 = array(foos.filter!(i = i.flag));
// fails, expected typeof(bar2) == immutable(Foo)[]
auto bar2 = array(foos.map!(i = i));
}
Error: cannot implicitly convert expression (arg) of type
immutable(Foo) to test.Foo
Error: template instance
std.conv.emplaceRef!(immutable(Foo)).emplaceRef!(immutable(Foo))
error instantiating
instantiated from here: array!(MapResult!(__lambda2,
immutable(Foo)[]))
I'm pretty sure that should work. Please file a bug report.
In the mean-time, either pre-allocate and std.algorithm.copy or -
if you don't have the length - use std.array.appender and ~= the
entire range in a single shot.
D1: Error: function ... cannot have an in contract when overriden function
Greetings!
I am trying to compile dfl with the latest version of D1. I am
stuck in this error:
c:\D\import\dfl\button.d(381): Error: function
dfl.button.Button.text cannot have
e an in contract when overriden function dfl.control.Control.text
does not have an in contract
This is the line 381:
override void text(Dstring txt) // setter
in
{
if(txt.length)
assert(!this.image, Button image with text not supported);
}
body
{
super.text = txt;
}
alias Control.text text; // Overload.
Any help would be greatly appreciated. Thanks.
Re: D1: Error: function ... cannot have an in contract when overriden function
If it is just that one error, you could always just comment out the in contract and recompile.
Re: Access Violation Tracking
i also developed a habit of writing assert()s before dereferencing pointers first time (including class refs) in appropriate places, so i'll got that stack trace for free. ;-) and i never turning off that asserts in release builds. About null pointer deref core dump I think, it is problem. Dland on windows gives stacktrace without any problem. In general it is expected behavior for many people from different languages (Java, C#). So from my point of view it is bad idea has core dump for null deref in linux by default. As I remember current linux handler is dirty hack, and it is main reason why it is disabled by default.
Re: Access Violation Tracking
On Fri, 07 Nov 2014 13:52:33 + Nordlöw via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via Digitalmars-d-learn wrote: crash+coredump is alot more useful than intercepting error and... trying to recover from undefined state? or just exit to OS, losing valuable information about a crash? Together with the DUB package backtrace this gives really nice ...undefined behavior. this code is not only unsafe (even in perverted D safety), it's plainly wrong. you are not allowed to call most of the libc functions from signal handler. actually, the things you can do safely in signal handler is setting some variable or calling _exit(2). ok, there are some more syscalls which are safe, but obviously not FILE* i/o from libc. so it doesn't matter wether i want coredumps or you want stack traces, the only correct solution is coredumps. printing stack trace from signal handler is UB, and it works only by accident. there is no good in using code that relies on UB. signature.asc Description: PGP signature
Re: Access Violation Tracking
On Sat, 08 Nov 2014 06:23:39 + Nikolay via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I think, it is problem. Dland on windows gives stacktrace without any problem. In general it is expected behavior for many people from different languages (Java, C#). So from my point of view it is bad idea has core dump for null deref in linux by default. this is the only choice. invoking file i/o from signal handler is UB. signature.asc Description: PGP signature
Re: Access Violation Tracking
On Sat, Nov 08, 2014 at 08:50:20AM +0200, ketmar via Digitalmars-d-learn wrote: On Fri, 07 Nov 2014 13:52:33 + Nordlöw via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via Digitalmars-d-learn wrote: crash+coredump is alot more useful than intercepting error and... trying to recover from undefined state? or just exit to OS, losing valuable information about a crash? Together with the DUB package backtrace this gives really nice ...undefined behavior. this code is not only unsafe (even in perverted D safety), it's plainly wrong. you are not allowed to call most of the libc functions from signal handler. actually, the things you can do safely in signal handler is setting some variable or calling _exit(2). ok, there are some more syscalls which are safe, but obviously not FILE* i/o from libc. so it doesn't matter wether i want coredumps or you want stack traces, the only correct solution is coredumps. printing stack trace from signal handler is UB, and it works only by accident. there is no good in using code that relies on UB. Some time ago deadalnix gave a neat (if scary) hack where the signal handler overwrites its return address on the stack to redirect the code to a handler that operates outside signal handler context, so it has no restrictions on syscalls that it can use. Since by the time control passes to that handler, the official signal handler has returned, you can do whatever you want without running into UB. (Of course, overwriting return addresses on the stack arguably qualifies as UB, but hey, when a man is desperate...) T -- Real programmers can write assembly code in any language. :-) -- Larry Wall
Re: Access Violation Tracking
On Fri, 7 Nov 2014 22:58:38 -0800 H. S. Teoh via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Some time ago deadalnix gave a neat (if scary) hack where the signal handler overwrites its return address on the stack to redirect the code to a handler that operates outside signal handler context, so it has no restrictions on syscalls that it can use. it's implementation detail which is free to change. as i said, such code relies on implementation details and defined undefined behavior. there is no guarantees that you will get the same stack for signal handler and for application. sure, we can do some tricks that exploiting black magic knowledge, but that's what i surely don't want to see in normal code. besides, segfault can be raised inside libc, for example. passing bad argument to some fXXX() operation and BOOM! at this point libc can hold some locks, has some internal state variables initialized and some not, and so on. so no malloc(), no FILE* i/o, no formatted printing, etc. only bare syscalls. and replacing return address will not help in this case. signature.asc Description: PGP signature
