Re: Dwarf Exception Handling now on FreeBSD!

On 2/4/2016 1:27 AM, Jacob Carlborg via Digitalmars-d wrote: On 2016-02-03 21:18, Brad Roberts via Digitalmars-d wrote: I haven't put much time into investigation, but the last time I tried it, neither 9 nor 10 passed the test suite. If someone puts in the effort to get either or both of

Re: Dwarf Exception Handling now on FreeBSD!

On 2016-02-04 10:43, Brad Roberts via Digitalmars-d wrote: It's not about mechanism, it's about compute hours in the day. Yes, making each machine a little more flexible would be useful for leveling out the progress across platforms, but there just isn't enough hardware in my fleet for adding

Is this a bug in std.typecons.Tuple.slice?

This code: void main() { import std.typecons; auto tp = tuple!("a", "b", "c")(10, false, "hello"); auto u0 = tp.slice!(0, tp.length); auto u1 = tp.slice!(1, tp.length); auto u2 = tp.slice!(2, tp.length); static assert(is(typeof(u0) == Tuple!(int, "a", bool, "b",

Re: Dwarf Exception Handling now on FreeBSD!

On Wednesday, 3 February 2016 at 20:18:52 UTC, Brad Roberts wrote: On 2/3/16 11:28 AM, Jonathan M Davis via Digitalmars-d wrote: On Sunday, 31 January 2016 at 06:34:26 UTC, Walter Bright wrote: [...] It's always nice when that happens, especially when there's not much FreeBSD-specific work

Re: print function

On Thursday, 4 February 2016 at 10:18:35 UTC, ixid wrote: Do you think your knowledge and experience is a good model for how a new user who hasn't done much if any programming before would approach this? A design choice had to be made and made it was. Adding another function now (or worse,

Re: print function

On Thursday, 4 February 2016 at 10:59:50 UTC, Mike Parker wrote: IMO, while giving beginner's a helping hand is a great thing, I don't think it's a good basis to use as a design for a standard library. Yes, better to have a "beginners toolkit" starting-point-codebase and build a tutorial

Re: print function

On Thursday, 4 February 2016 at 11:04:23 UTC, cym13 wrote: On Thursday, 4 February 2016 at 10:18:35 UTC, ixid wrote: Do you think your knowledge and experience is a good model for how a new user who hasn't done much if any programming before would approach this? A design choice had to be

Re: questions about NetBSD port

On 2/3/2016 11:41 PM, Iain Buclaw via Digitalmars-d wrote: Actually, I found the reverse! One of the inline assembly version paths are correct up to double precision, the platform agnostic path I ported does not have this problem, but fails the tests. Adjusting them will *expose* the buggy

Re: print function

On Thursday, February 04, 2016 00:40:55 ixid via Digitalmars-d-learn wrote: > On Thursday, 4 February 2016 at 00:30:03 UTC, cym13 wrote: > > On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote: > >> It would be nice to have a simple writeln that adds spaces > >> automatically like Python's

[Issue 15644] Change object layout ABI to MI style

https://issues.dlang.org/show_bug.cgi?id=15644 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/701641c78081fe23d2345fd2edc184e9e7ea2038 fix Issue 15644

Re: questions about NetBSD port

On 4 February 2016 at 12:29, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 2/3/2016 11:41 PM, Iain Buclaw via Digitalmars-d wrote: > >> Actually, I found the reverse! One of the inline assembly version paths >> are >> correct up to double precision, the platform

Re: print function

On Thursday, 4 February 2016 at 10:18:35 UTC, ixid wrote: On Thursday, 4 February 2016 at 10:05:15 UTC, Jonathan M Davis wrote: I would normally expect someone to do that with writefln, which would be cleaner. e.g. writefln("%s %s %s %s", a, b, c, d); Personally, I've never felt the need for

Re: Detecting exception unwinding

On Thursday, 4 February 2016 at 10:03:13 UTC, Jonathan M Davis wrote: On Wednesday, February 03, 2016 23:55:42 Ali Çehreli via Digitalmars-d-learn wrote: std::uncaught_exception used to be considered useless: I think that the only case I've ever had for it was for a unit testing framework

Re: questions about NetBSD port

On Thursday, 4 February 2016 at 05:19:06 UTC, Joakim wrote: On Wednesday, 3 February 2016 at 17:36:36 UTC, Nikolay wrote: I decided try to repeat LDC team forkflow and cherry-pick my commit to ldc branch (druntime). There are a couple simple conflicts in src/core/stdc/locale.d &

Re: std.socket question

On Thursday, 4 February 2016 at 06:40:15 UTC, sanjayss wrote: Are the functions lastSocketError() and wouldHaveBlocked() from std.socket thread-safe? i.e. can they be reliably used to see the status of the last socket call when sockets are being read/written in multiple threads? Not directly

Re: Detecting exception unwinding

On Wednesday, February 03, 2016 23:55:42 Ali Çehreli via Digitalmars-d-learn wrote: > std::uncaught_exception used to be considered useless: I think that the only case I've ever had for it was for a unit testing framework where I wanted to use RAII to print something when the tests failed (and

Re: Deprecation policy

On Wednesday, 3 February 2016 at 19:25:20 UTC, Jonathan M Davis wrote: Now, in this particular case, you're talking about features that were warned about starting in 2.067, which was released at the end of March of last year. Removing them now would be awfully quick. The deprecation cycle in

Re: print function

On Thursday, 4 February 2016 at 10:05:15 UTC, Jonathan M Davis wrote: I would normally expect someone to do that with writefln, which would be cleaner. e.g. writefln("%s %s %s %s", a, b, c, d); Personally, I've never felt the need for a function like you're describing. - Jonathan M Davis

[Issue 14942] dmd linking error with SHA and SSSE3

https://issues.dlang.org/show_bug.cgi?id=14942 --- Comment #5 from Yawniek --- sorry wrong issue tracker. this is a LDC or arch bug. --

Re: Counting time difference.

On Wednesday, 3 February 2016 at 22:45:03 UTC, sigod wrote: On Wednesday, 3 February 2016 at 22:27:07 UTC, holo wrote: When i start same program on server in different timezone difference is much higher (more than hour). Why it is happening? Timezones shouldnt have influence on such equation.

Re: Deprecation policy

On Thursday, 4 February 2016 at 11:29:59 UTC, Marc Schütz wrote: On Wednesday, 3 February 2016 at 19:25:20 UTC, Jonathan M Davis wrote: Now, in this particular case, you're talking about features that were warned about starting in 2.067, which was released at the end of March of last year.

[Issue 15480] std.algorithm.iteration.map not accepting multiple lambdas

https://issues.dlang.org/show_bug.cgi?id=15480 thomas.bock...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 22:57:00 UTC, tsbockman wrote: Actually, I'm surprised that this works even in C - I would have expected at least a compiler (or linker?) warning; this seems like it should be easy to detect automatically. AFAICT C would have complained if he had included .

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:24:21 UTC, Chris Wright wrote: C linkage does zero name mangling, which is the problem. C++ introduced name mangling, so compiling with g++ would show the error rather quickly. C99 is pretty close to C++98, but there are enough differences that that isn't a

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:21:54 UTC, tsbockman wrote: Definitely. What puzzles me about the winning entry, though, is that the compiler and/or linker should be able to trivially detect the type mismatch *after* the preprocessor pass(es) are already done. Linkers don't know anything

Re: print function

On Thursday, 4 February 2016 at 14:25:21 UTC, bachmeier wrote: Unfortunately there is no such thing and it is unlikely to exist in the next decade. Well, it is probably not the best point in time to have absolute beginners use D anyway. But a well commented library, that don't focus on

[Issue 15480] std.algorithm.iteration.map not accepting multiple lambdas

https://issues.dlang.org/show_bug.cgi?id=15480 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/b23608b63523dc8603764cfcff86482abd11b841 Fix Phobos issue

Re: Type safety could prevent nuclear war

On Thu, Feb 04, 2016 at 10:57:00PM +, tsbockman via Digitalmars-d wrote: > The annual Underhanded C Contest announced their winners today. > > As always, the results are very entertaining, and also an excellent > advertisement for languages-that-are-not-C. > > The first place entry is

Type safety could prevent nuclear war

The annual Underhanded C Contest announced their winners today. As always, the results are very entertaining, and also an excellent advertisement for languages-that-are-not-C. The first place entry is particularly ridiculous; is there any modern language that would make it so easy to commit

Re: Idempotent partition around median of 5?

On Thursday, 4 February 2016 at 20:30:57 UTC, Timon Gehr wrote: At most 6 comparisons, <=3 swaps, idempotent (optimal number of swaps): void partition5(ref int[5] a){ if(a[0]

Re: questions about NetBSD port

On 2/4/2016 4:27 AM, Iain Buclaw via Digitalmars-d wrote: The literal being used to compare the result was wrong (by 12 mantissa bits) in the first place. Then the literal should be fixed, not degrade the test.

Re: What reasons are known a thread stops suddenly?

On 02/04/2016 12:25 PM, tcak wrote: > void threadFunc(){ > scope(exit){ > writeln("Leaving 2: ", stopRequested); > } > > > while( !stopRequested ){ > /* THERE IS NO "RETURN" HERE AT ALL */ > } > > writeln("Leaving 1: ", stopRequested); > } > > > > While loop is

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:19:20 UTC, Ola Fosheim Grøstad wrote: On Thursday, 4 February 2016 at 22:57:00 UTC, tsbockman wrote: Actually, I'm surprised that this works even in C - I would have expected at least a compiler (or linker?) warning; this seems like it should be easy to

Re: Type safety could prevent nuclear war

On Thu, 04 Feb 2016 22:57:00 +, tsbockman wrote: > The annual Underhanded C Contest announced their winners today. > > As always, the results are very entertaining, and also an excellent > advertisement for languages-that-are-not-C. > > The first place entry is particularly ridiculous; is

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:10:23 UTC, H. S. Teoh wrote: On Thu, Feb 04, 2016 at 10:57:00PM +, tsbockman via Digitalmars-d wrote: The annual Underhanded C Contest announced their winners today. As always, the results are very entertaining, and also an excellent advertisement for

Re: Type safety could prevent nuclear war

On Fri, Feb 05, 2016 at 12:14:11AM +, tsbockman via Digitalmars-d wrote: [...] > This isn't even a particularly expensive (in compile-time costs) check > to perform anyway; all that is necessary is to store a temporary table > of symbol signatures somewhere (it doesn't need to be in RAM), and

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 06:05:49 UTC, Chris Wright wrote: It doesn't know what targets I'm ultimately creating, and it doesn't know what files have been modified that I'm about to compile (but haven't compiled yet). Example 1: I compile one .c file referencing a function: void

[Issue 7516] Postblit not called for structs returned from a ternary operator

https://issues.dlang.org/show_bug.cgi?id=7516 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/094b358ba1c5ecd6708ccd82660f44462cd06314 fix Issue 7516 - Postblit

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 07:05:06 UTC, H. S. Teoh wrote: On Fri, Feb 05, 2016 at 04:02:41AM +, tsbockman via Digitalmars-d wrote: On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote: >On Fri, 05 Feb 2016 01:10:53 +, tsbockman wrote: What information, specifically, is the

Re: Detecting exception unwinding

On Wednesday, 3 February 2016 at 11:09:00 UTC, Ola Fosheim Grøstad wrote: Is there some reliable way to detect that a destructor is called because of exception unwinding? I basically want to change behaviour within a destructor based on whether the destructor is called as a result of a

Re: Template to create a type and instantiate it

On 05/02/16 8:41 PM, cy wrote: I'm guessing I have to use a "mixin" mixin for this, but... there's no way to do something like this is there? template TFoo(T) { struct T { int a; int b; } T obj; } TFoo!Derp; Derp bar; Neither templates, nor mixin templates seem capable of this. Easy

Template to create a type and instantiate it

I'm guessing I have to use a "mixin" mixin for this, but... there's no way to do something like this is there? template TFoo(T) { struct T { int a; int b; } T obj; } TFoo!Derp; Derp bar; Neither templates, nor mixin templates seem capable of this. Easy enough to use mixin, with

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 07:15:56 UTC, H. S. Teoh wrote: This would break shared library upgrades that do not change the ABI. Plus, it doesn't fix wrong linkage at runtime, because the dynamic linker is part of the OS and the D compiler has no control over what it does beyond the

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 00:03:56 UTC, Chris Wright wrote: Doing this sort of validation requires build system integration (track the command line arguments that went into producing this object file; find which object files are combined into which targets; run the analysis on that) and

Re: Is this a bug in std.typecons.Tuple.slice?

On Thursday, 4 February 2016 at 17:52:16 UTC, Marco Leise wrote: https://issues.dlang.org/show_bug.cgi?id=15645 Thank you. I understood why this is happening from your explanation in the bug report.

Re: What reasons are known a thread stops suddenly?

On Friday, 5 February 2016 at 06:23:09 UTC, Daniel Kozak wrote: V Fri, 05 Feb 2016 03:47:40 + tcak via Digitalmars-d-learn napsáno: [...] Did you try catch Throwable instead of Exception? Undid the fix, and wrapped the problem causing function call

Re: std.signals crashes GtkD gui application when SpinButton tied to signal.

On Friday, 5 February 2016 at 06:52:11 UTC, Enjoys Math wrote: I have two spin buttons connected to the width and height of 2d objects in a scene. Using mixin std.signals.Signal!(double, double) dimentionChanged; and there is a growing delay that happens not caused by the rendering

Re: Type safety could prevent nuclear war

On Fri, Feb 05, 2016 at 04:02:41AM +, tsbockman via Digitalmars-d wrote: > On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote: > >On Fri, 05 Feb 2016 01:10:53 +, tsbockman wrote: > >The compiler doesn't have all the information you need. You could add it > >to the build system

Re: Type safety could prevent nuclear war

On Fri, Feb 05, 2016 at 04:39:13AM +, tsbockman via Digitalmars-d wrote: [...] > Thanks for the explanation. That does sound basically the same as the > C issue. > > Since .di files are normally generated automatically, this seems like > an easily solvable problem: > > 1) When compiling a

Re: reduce -> fold?

On Thursday, 4 February 2016 at 08:29:46 UTC, Dragos Carp wrote: I will prepare a PR for the binary function implementation. The PR is ready for review: https://github.com/D-Programming-Language/phobos/pull/3972

Re: What are the real advantages that D offers in multithreading?

On Thu, 2016-01-28 at 22:38 +, nbro via Digitalmars-d wrote: > […] > I don't understand why you say that everyone that uses  > synchronized is doing bad concurrent programming. That's not  > correct, if you know how to use it. Also, I don't understand why  > also lock and monitors should be

std.signals crashes GtkD gui application when SpinButton tied to signal.

I have two spin buttons connected to the width and height of 2d objects in a scene. Using mixin std.signals.Signal!(double, double) dimentionChanged; and there is a growing delay that happens not caused by the rendering code, the transform code, or the triggering code (I used a timer

Re: print function

On Thursday, 4 February 2016 at 15:32:48 UTC, Artur Skawina wrote: void print(A...)(A a) { foreach (N, ref e; a) write(e, N==A.length-1?"\n":" "); } will be unrolled at compile time Mind if I elaborate on this a bit? If that is unrolled, I understand it will unroll

Re: Type safety could prevent nuclear war

On 05.02.2016 00:47, tsbockman wrote: You can do the same thing in D if you try, but it's not natural at all to use `extern(C)` for *internal* linkage of an all-D program like that. Any competent reviewer would certainly question why you were using `extern(C)`; this scores much lower in

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:35:46 UTC, tsbockman wrote: Just because *sometimes* the source code of the other module must be compiled independently, is a poor excuse to skip obvious, useful safety checks *all* the time. The context is a compilation system for building big software on

Re: Type safety could prevent nuclear war

On Thu, Feb 04, 2016 at 11:47:53PM +, tsbockman via Digitalmars-d wrote: [...] > You can do the same thing in D if you try, but it's not natural at all > to use `extern(C)` for *internal* linkage of an all-D program like > that. > > Any competent reviewer would certainly question why you were

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:51:57 UTC, anonymous wrote: We do have a lot of bindings to C libraries, though. When there's a wrong alias in one of them, you have the same scenario. On 05.02.2016 00:47, tsbockman wrote: Even so, I think that qualifies as a compiler bug or a hole in the

Re: Type safety could prevent nuclear war

On Thu, 04 Feb 2016 23:29:10 +, tsbockman wrote: > That explains why the linker doesn't catch it. I still don't see much > excuse for the compiler allowing it though, beyond a desire to allow > each module to be compiled independently. Doing this sort of validation requires build system

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:29:10 UTC, tsbockman wrote: That explains why the linker doesn't catch it. I still don't see much excuse for the compiler allowing it though, beyond a desire to allow each module to be compiled independently. The excuse is that C use the same mechanism for

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:25:58 UTC, Ola Fosheim Grøstad wrote: On Thursday, 4 February 2016 at 23:21:54 UTC, tsbockman wrote: It should just see that the post-preprocessor signatures of `spectral_contrast()` in match.c and spectral_contrast.c are in conflict, and either issue a

Re: Type safety could prevent nuclear war

On Thu, Feb 04, 2016 at 11:21:54PM +, tsbockman via Digitalmars-d wrote: [...] > Definitely. What puzzles me about the winning entry, though, is that the > compiler and/or linker should be able to trivially detect the type mismatch > *after* the preprocessor pass(es) are already done. It

Re: Type safety could prevent nuclear war

On Thu, 04 Feb 2016 15:59:06 -0800, H. S. Teoh via Digitalmars-d wrote: > Nah... while D, by default, tries to be type-safe and prevent guffaws > like the above, it *is* also a systems programming language (or at > least, that's one of the stated goals), so it does allow you to go under > the

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 00:14:11 UTC, tsbockman wrote: But it's 2016 and my PC has 32GiB of RAM. Why should a C compiler running on such a system skip safety checks just because they would be too expensive to run on some *other* computer? C has to be backwards compatible, but I don't

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 00:07:45 UTC, Chris Wright wrote: Which suggests a check of this sort should be a warning rather than an error, or perhaps that a pragma or attribute could be offered to ignore it. Systems languages let you go into "Here Be Dragons" territory, but it would be

Re: Type safety could prevent nuclear war

On Fri, 05 Feb 2016 00:38:16 +, tsbockman wrote: > On Friday, 5 February 2016 at 00:03:56 UTC, Chris Wright wrote: >> Doing this sort of validation requires build system integration (track >> the command line arguments that went into producing this object file; >> find which object files are

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 00:50:32 UTC, tsbockman wrote: On Friday, 5 February 2016 at 00:41:52 UTC, Ola Fosheim Grøstad wrote: On Friday, 5 February 2016 at 00:14:11 UTC, tsbockman wrote: But it's 2016 and my PC has 32GiB of RAM. Why should a C compiler running on such a system skip

[Issue 15645] Tuple.slice() causes memory corruption.

https://issues.dlang.org/show_bug.cgi?id=15645 Saurabh Das changed: What|Removed |Added CC||saurabh@gmail.com

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:25:58 UTC, Ola Fosheim Grøstad wrote: In C, compilation units are completely independent, and can in fact come from different compilers and different languages. C is very much a system level programming language. I should also point out that D can link to

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 00:03:20 UTC, tsbockman wrote: If the same `extern(C)` symbol is declared multiple places in the D source code for a program, the compiler should issue at least a warning if the D signatures don't agree with each other. I guess D could do it, although this is a

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:53:58 UTC, Ola Fosheim Grøstad wrote: On Thursday, 4 February 2016 at 23:35:46 UTC, tsbockman wrote: Just because *sometimes* the source code of the other module must be compiled independently, is a poor excuse to skip obvious, useful safety checks *all* the

Re: Idempotent partition around median of 5?

On Thursday, 4 February 2016 at 20:30:57 UTC, Timon Gehr wrote: At most 6 comparisons, <=3 swaps, idempotent (optimal number of swaps): void partition5(ref int[5] a){ if(a[0]

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:59:06 UTC, H. S. Teoh wrote: On Thu, Feb 04, 2016 at 11:47:53PM +, tsbockman via Digitalmars-d wrote: [...] Even so, I think that qualifies as a compiler bug or a hole in the D spec. Nah... while D, by default, tries to be type-safe and prevent guffaws

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 22:57:00 UTC, tsbockman wrote: The first place entry is particularly ridiculous; is there any modern language that would make it so easy to commit such an awful "mistake"? D allows that. This is why I recommend putting `static assert(foo.sizeof ==

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 00:56:16 UTC, Chris Wright wrote: True. That works if this is baked into your compiler, or if your compiler has plugin support. And you'd have to compile with this plugin or the relevant options turned on by default in order for you not to duplicate work. On

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 01:14:05 UTC, Adam D. Ruppe wrote: D allows that. This is why I recommend putting `static assert(foo.sizeof == expectation);` in code that interfaces with external things, like C code, or D .di stuff. #include /* sqrt */ D *doesn't* allow that though - at

Re: Type safety could prevent nuclear war

On 2/4/2016 3:10 PM, H. S. Teoh via Digitalmars-d wrote: The C preprocessor accepts all sorts of nasty, nonsensical things. The preprocessor makes C++ into an inherently unreliable, unsafe programming language. I've talked to some C++ committee members about this, about why there is no push

Re: Just because it's a slow Thursday on this forum

On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/3971 -- Andrei People one github were asking for a dump function so they could do int a = 5; dump!("a"); // prints "a = 5" Here's a working version if

Re: Just because it's a slow Thursday on this forum

On Friday, 5 February 2016 at 02:46:01 UTC, Tofu Ninja wrote: ... It's kinda neat cus it supports arbitrary expressions. Mixins are pretty powerful.

Re: Type safety could prevent nuclear war

On 04.02.2016 23:57, tsbockman wrote: http://www.underhanded-c.org/#winner Actually, I'm surprised that this works even in C - I would have expected at least a compiler (or linker?) warning; this seems like it should be easy to detect automatically. You can do the same thing in D, using

Re: Type safety could prevent nuclear war

On Thursday, 4 February 2016 at 23:40:13 UTC, anonymous wrote: You can do the same thing in D, using extern(C) to get no mangling: main.d: alias float_t = double; extern(C) float_t deref(float_t* a); void main() { import std.stdio: writeln; float_t d = 1.23; writeln(deref());

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 00:12:07 UTC, Ola Fosheim Grøstad wrote: It makes perfect sense for one compilation unit to type a parameter pointer to float and another unit to type the same parameter as a simd-array of floats. The underlying code could be machine language. And in machine

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 00:41:52 UTC, Ola Fosheim Grøstad wrote: On Friday, 5 February 2016 at 00:14:11 UTC, tsbockman wrote: But it's 2016 and my PC has 32GiB of RAM. Why should a C compiler running on such a system skip safety checks just because they would be too expensive to run on

Re: print function

On Thursday, 4 February 2016 at 11:04:15 UTC, Ola Fosheim Grøstad wrote: On Thursday, 4 February 2016 at 10:59:50 UTC, Mike Parker wrote: IMO, while giving beginner's a helping hand is a great thing, I don't think it's a good basis to use as a design for a standard library. Yes, better to

Re: print function

On Thursday, 4 February 2016 at 14:25:21 UTC, bachmeier wrote: Unfortunately there is no such thing and it is unlikely to exist in the next decade. There is http://forum.dlang.org/post/mtsd38$16ub$1...@digitalmars.com

[Issue 14942] dmd linking error with SHA and SSSE3

https://issues.dlang.org/show_bug.cgi?id=14942 Sobirari Muhomori changed: What|Removed |Added Status|REOPENED|RESOLVED

Re: Is this a bug in std.typecons.Tuple.slice?

On Thursday, 4 February 2016 at 12:28:39 UTC, Saurabh Das wrote: This code: [...] Update: Simplified, this also doesn't work: void main() { import std.typecons; auto tp = tuple(10, false, "hello"); auto u0 = tp.slice!(0, tp.length); auto u1 = tp.slice!(1, tp.length); auto

Re: print function

On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote: It would be nice to have a simple writeln that adds spaces automatically like Python's 'print' in std.stdio, perhaps called print. There are many implementations of string interpolation in D (that is what you want, basically). One of

Re: print function

On Thursday, 4 February 2016 at 13:46:46 UTC, Dejan Lekic wrote: On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote: It would be nice to have a simple writeln that adds spaces automatically like Python's 'print' in std.stdio, perhaps called print. There are many implementations of

[Issue 15646] New: Unresolved symbols when using m32mscoff with Windows subsystem

https://issues.dlang.org/show_bug.cgi?id=15646 Issue ID: 15646 Summary: Unresolved symbols when using m32mscoff with Windows subsystem Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote: On Fri, 05 Feb 2016 01:10:53 +, tsbockman wrote: The compiler doesn't have all the information you need. You could add it to the build system or the linker as well as the compiler. Adding it to the linker is almost identical

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 04:25:09 UTC, Adam D. Ruppe wrote: On Friday, 5 February 2016 at 01:33:14 UTC, tsbockman wrote: As to the ".di" stuff - I've not used them. Care to educate me? How can they cause similar problems? Well, technically, a .di file is just a .d file renamed, but it

Re: Is this a bug in std.typecons.Tuple.slice?

On Thursday, 4 February 2016 at 17:52:16 UTC, Marco Leise wrote: https://issues.dlang.org/show_bug.cgi?id=15645 Is this a possible fixed implementation? : @property Tuple!(sliceSpecs!(from, to)) slice(size_t from, size_t to)() @trusted const if (from <= to && to <=

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote: [...] Apologies for spamming. This is an improved implementation: @property Tuple!(sliceSpecs!(from, to)) slice(size_t from, size_t to)() @safe const if (from <= to && to <= Types.length) {

Re: What reasons are known a thread stops suddenly?

V Fri, 05 Feb 2016 03:47:40 + tcak via Digitalmars-d-learn napsáno: > On Thursday, 4 February 2016 at 22:27:31 UTC, Ali Çehreli wrote: > > On 02/04/2016 12:25 PM, tcak wrote: > > > > > void threadFunc(){ > > > scope(exit){ > > >

Re: Type safety could prevent nuclear war

On Friday, 5 February 2016 at 01:33:14 UTC, tsbockman wrote: As to the ".di" stuff - I've not used them. Care to educate me? How can they cause similar problems? Well, technically, a .di file is just a .d file renamed, but it tends to have the bodies stripped out. Separate compliation is a

Re: Type safety could prevent nuclear war

On Fri, 05 Feb 2016 04:02:41 +, tsbockman wrote: > On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote: >> On Fri, 05 Feb 2016 01:10:53 +, tsbockman wrote: >> The compiler doesn't have all the information you need. You could add >> it to the build system or the linker as well

Re: Type safety could prevent nuclear war

On Fri, 05 Feb 2016 01:10:53 +, tsbockman wrote: > All along I have been saying this is something that *compilers* should > warn about. The compiler doesn't have all the information you need. You could add it to the build system or the linker as well as the compiler. Adding it to the

Re: What reasons are known a thread stops suddenly?

On Thursday, 4 February 2016 at 22:27:31 UTC, Ali Çehreli wrote: On 02/04/2016 12:25 PM, tcak wrote: > void threadFunc(){ > scope(exit){ > writeln("Leaving 2: ", stopRequested); > } > > > while( !stopRequested ){ > /* THERE IS NO "RETURN" HERE AT ALL */ > } > >

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote: [...] PS: Additionally, '@trusted' can now be substituted with '@safe'.

Re: Article: We're Overlooking A Key Part of C/C++ to D User Migration

On Friday, 5 February 2016 at 05:40:35 UTC, Laeeth Isharc wrote: On Wednesday, 3 February 2016 at 17:05:57 UTC, Nick Sabalausky wrote: Something that's been on my mind for a few months, finally got around to a little write-up about it. We're Overlooking A Key Part of C/C++ to D User

  1   2   >