Re: Dwarf Exception Handling now on FreeBSD!

[Brad Roberts via Digitalmars-d]

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 those working, I'd be happy to upgrade
some of the freebsd testers to newer versions.  There's currently 4
freebsd machines, so plenty of room to have a mix of versions.  Not
enough to test every combination of version and bitness, but enough to
allow randomness to expose issues.


Perhaps it's worth taking a look at Docker. As far as I understand
there's experimental support for FreeBSD [1]. It uses ZFS, jail and the
64bit Linux compatibility layer. Seems to be possible to run both Linux
and FreeBSD images in Docker for FreeBSD.

Although I'm not sure if it's possible to mix 32bit and 64bit with Docker.

[1] https://wiki.freebsd.org/Docker


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 a bunch more configurations to the matrix.

Re: Dwarf Exception Handling now on FreeBSD!

[Jacob Carlborg via Digitalmars-d]

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 a bunch more configurations to the matrix.


Ah, I see. What's the average time for a pull request for the complete 
matrix?


--
/Jacob Carlborg

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

[Saurabh Das via Digitalmars-d-learn]

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", 
string, "c")));
static assert(is(typeof(u1) == Tuple!(bool, "b", string, 
"c")));

static assert(is(typeof(u2) == Tuple!(string, "c")));

assert(u2.c == "hello");
assert(u0.c == "hello");
assert(u1.c == "hello");// This assert fails. Why?
}

core.exception.AssertError@erasetype.d(16): Assertion failure

4   erasetype   0x000100ce8128 
_d_assert + 104
5   erasetype   0x000100cd12fe void 
erasetype.__assert(int) + 38
6   erasetype   0x000100cd12aa _Dmain 
+ 250
7   erasetype   0x000100cf7297 
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 39
8   erasetype   0x000100cf71cf void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) + 55
9   erasetype   0x000100cf723c void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll() + 44
10  erasetype   0x000100cf71cf void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) + 55
11  erasetype   0x000100cf7121 
_d_run_main + 497
12  erasetype   0x000100cd133f main + 
15
13  libdyld.dylib   0x7fff8a1345c8 start 
+ 0

14  ??? 0x 0x0 + 0

Why does 'u1' behave differently? I'm thinking it's a bug, but I 
haven't worked much with tuples, so maybe I'm missing something?


Thanks,
Saurabh

Re: Dwarf Exception Handling now on FreeBSD!

[Joakim via Digitalmars-d]

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 going on,
and the autotesters have generally been on older versions of 
FreeBSD such that issues on the newer
versions don't always get noticed (e.g. for a while there, the 
shared library stuff passed the tests
on FreeBSD 8 but not later; fortunately Martin got that fixed 
though).


- Jonathan M Davis


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 those working, I'd 
be happy to upgrade some of the freebsd testers to newer 
versions.  There's currently 4 freebsd machines, so plenty of 
room to have a mix of versions.  Not enough to test every 
combination of version and bitness, but enough to allow 
randomness to expose issues.


One option to consider is installing FreeBSD 10 and then testing 
8 and 9 in jails, which are the precursor to Linux containers.  I 
used this approach years ago, when compiling Chromium for several 
FreeBSD versions.

Re: print function

[cym13 via Digitalmars-d-learn]

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, changing the existing ones) would only 
bring more confusion for beginners and unconsistency to the 
language. I firmly believe that no matter what your experience 
you have having one and preferably only one way to do things is 
more important to ease the learning process than having spaces or 
not.

Re: print function

[Ola Fosheim Grøstad via Digitalmars-d-learn]

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 around it.

Re: print function

[ixid via Digitalmars-d-learn]

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 made and made it was. Adding another 
function now (or worse, changing the existing ones) would only 
bring more confusion for beginners and unconsistency to the 
language. I firmly believe that no matter what your experience 
you have having one and preferably only one way to do things is 
more important to ease the learning process than having spaces 
or not.


That's a nonsensical argument given the number of printing and 
writing functions that exist.

Re: questions about NetBSD port

[Walter Bright via Digitalmars-d]

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 algorithm for what it really is.



I don't understand. How can reducing precision of the test expose bugs?

Re: print function

[Jonathan M Davis via Digitalmars-d-learn]

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 'print' in std.stdio, perhaps
> >> called print.
> >
> > Sounds way too redundant to me.
>
> Normally you'd be right but printing out data is such a common
> thing, especially for beginners. It's the kind of thing that can
> make their early experience of a language a lot more positive.
>
> writeln(a, " ", b, " ", c, " ", d);
>
> Is very clunky. Programming languages are like cereal, you need
> sugar to get the kids hooked.

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 15644] Change object layout ABI to MI style

[via Digitalmars-d-bugs]

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 - Switch object layout ABI to MI style

https://github.com/D-Programming-Language/dlang.org/commit/990c42dff8af698320db91135db7e990eb8849bd
Merge pull request #1225 from WalterBright/fix15644

fix Issue 15644 - Switch object layout ABI to MI style

--

Re: questions about NetBSD port

[Iain Buclaw via Digitalmars-d]

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 agnostic path I ported does
>> not
>> have this problem, but fails the tests.
>>
>> Adjusting them will *expose* the buggy algorithm for what it really is.
>>
>>
> I don't understand. How can reducing precision of the test expose bugs?
>

The literal being used to compare the result was wrong (by 12 mantissa
bits) in the first place.

Re: print function

[Mike Parker via Digitalmars-d-learn]

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 a function like 
you're describing.


- Jonathan M Davis


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?


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.

Re: Detecting exception unwinding

[Ola Fosheim Grøstad via Digitalmars-d-learn]

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 where I wanted to use RAII to print something 
when the tests failed (and thus an exception was thrown) but 
not print if they succeeded, and if I were to do that in D, I'd 
just use scope(failure).


Well, yes, it is useful for logging. It is useful to know if an 
invariant is broken during regular unwinding (serious error) or 
exceptional situations (might be unavoidable).


But I think Herb Sutters major point was that if you had multiple 
destructors it could not detect where the exceptions originate 
from. So C++17 has a new function that returns the number of 
uncaught expressions:


http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4152.pdf

Re: questions about NetBSD port

[Nikolay via Digitalmars-d]

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 & 
src/core/sys/posix/signal.d, and one absent (in master) file: 
src/rt/sections_ldc.d
I successfully build and run druntime unittests on NetBSD 
after resolving conflicts.


PS
I created new pull request to druntime: 
https://github.com/D-Programming-Language/druntime/pull/1492


So you built this druntime with dmd on NetBSD?


No I use ldc master for building druntime/phobos on NetBSD

Re: std.socket question

[tcak via Digitalmars-d-learn]

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 read the code for a while (but did before), those 
two functions
call C functions, and they are thread-safe by default. The 
WOULD-HAVE-BLOCKED
is understood by checking errno which comes from core.stdc.errno. 
If you read
that function's documents, you will see that it is marked as 
thread-safe.


http://linux.die.net/man/3/errno
... errno is thread-local; setting it in one thread does not 
affect its value in any other thread. ...

Re: Detecting exception unwinding

[Jonathan M Davis via Digitalmars-d-learn]

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 thus an exception was thrown) but not print if they succeeded,
and if I were to do that in D, I'd just use scope(failure).

- Jonathan M Davis

Re: Deprecation policy

[Marc Schütz via Digitalmars-d]

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 Phobos is two years 
long so that folks have plenty of chance to update their code, 
and older code that's not well maintained has some chance of 
compiling when it is finally brought up to date. So, I'm 
inclined to think that it's way too early to remove .sort or 
.reverse from the language.




Sure, I'm not suggesting to remove them yet, but they need to get 
through all stages first, and any delay will push the date we can 
finally get rid of them further back. The next stage is 
"deprecated". Would that be ok now?


Btw, this is the PR that caused my question:
https://github.com/D-Programming-Language/dlang.org/pull/1205

Re: print function

[ixid via Digitalmars-d-learn]

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


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?

[Issue 14942] dmd linking error with SHA and SSSE3

[via Digitalmars-d-bugs]

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.

[holo via Digitalmars-d-learn]

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.


Try using `Clock.currTime(UTC())`. And make sure all instances 
produce timezone independent timestamps.


Thank you, now i see that AWS is getting back Time in UTC so that 
solved problem.


@Jonathan M Davis

like i wrote above using UTC time helped me. Thank you for 
information about that monotonic clock will check it too for 
learning purpose.


//holo

Re: Deprecation policy

[Jonathan M Davis via Digitalmars-d]

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. Removing them now would be 
awfully quick. The deprecation cycle in Phobos is two years 
long so that folks have plenty of chance to update their code, 
and older code that's not well maintained has some chance of 
compiling when it is finally brought up to date. So, I'm 
inclined to think that it's way too early to remove .sort or 
.reverse from the language.




Sure, I'm not suggesting to remove them yet, but they need to 
get through all stages first, and any delay will push the date 
we can finally get rid of them further back. The next stage is 
"deprecated". Would that be ok now?


Btw, this is the PR that caused my question:
https://github.com/D-Programming-Language/dlang.org/pull/1205


Well, warning and deprecated aren't exactly in a continuum. If 
something is a warning, then it fails to compile with -w, whereas 
if it's deprecated, it'll always compile but will print out a 
message unless -d is used. And much as the table seems to claim 
that most stuff went from deprecated to error, I'm pretty sure 
that several of them went from warning to error. So, I don't 
think that there's exactly a clear progression of stages here.


Regardless, I see no problem with making using .sort or .reverse 
result in a deprecation message in addition to it being a warning 
(removing the warning would make code that didn't compile before 
start compiling and affect compile-time introspection). Not 
everyone builds with warnings turned on, whereas everyone would 
see the deprecation messages, so more people would notice if it 
were also explicitly deprecated. But we can't make it an error or 
remove it for a while yet IMHO.


- Jonathan M Davis

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15480

thomas.bock...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Type safety could prevent nuclear war

[Ola Fosheim Grøstad via Digitalmars-d]

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 . This 
is a rather unlikely mistake...


Anyway, in C being able to work around restrictions is sometimes 
desired, so... if you don't want the ability to do it, don't use 
C.

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 reliable diagnostic. 
(Though if you're familiar with the differences, you could use 
it as a quick way to show potential problem areas.)


I suppose a compiler could produce two symbol tables, one 
featuring mangled names and one with unmangled names. The 
linker would prefer matching mangled names and issue a warning 
if it only had an unmangled match with a mangled false match.


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.

Re: Type safety could prevent nuclear war

[Ola Fosheim Grøstad via Digitalmars-d]

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 about types. A type is a language 
feature.


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 warning, or refuse to link them at 
all.


Has nothing to do with the preprocessor.

He defined float_t to be an alias for double in one compilation 
unit, and float_t to be an alias for float in another compilation 
unit.


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.

Re: print function

[Ola Fosheim Grøstad via Digitalmars-d-learn]

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 performance and teach good habits using the non-advanced 
D feature subset, can go a long way if the design is explained in 
a companion tutorial. A "build your own pythonesque library" 
tutorial wrapped up as a zip-file with a sensible main-file 
template that is ready to compile.


That way newbies can just unzip it into a new directory when they 
start a new project "resetting" former mistakes.

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

[via Digitalmars-d-bugs]

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 15480

https://github.com/D-Programming-Language/phobos/commit/6bb36bf522b7336dd41873bb4f1a2df57b90f7fc
Merge pull request #3969 from tsbockman/issue_15480

Fix Phobos issue 15480

--

Re: Type safety could prevent nuclear war

[H. S. Teoh via Digitalmars-d]

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 particularly ridiculous; is there any modern
> language that would make it so easy to commit such an awful "mistake"?
> 
> 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.

The C preprocessor accepts all sorts of nasty, nonsensical things. For
example, the following code compiles and runs (without any warning(!) on
my Linux box's standard gcc installation), and prints "No":

#include 
#define if(a) if(!(a))
int main() {
int i = 1;
if (i == 1)
printf("Yes\n");
else
printf("No\n");
}

Imagine if this nasty #define is buried somewhere under several layers
of #include's.

I'm pretty sure somebody can also concoct some nasty #define that will
break the standard #include headers in horrible ways by changing the
semantics of certain supposedly-built-in constructs.


T

-- 
Mediocrity has been pushed to extremes.

Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 such an 
awful "mistake"?


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.

Re: Idempotent partition around median of 5?

[Era Scarecrow via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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?

[Ali Çehreli via Digitalmars-d-learn]

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 running, suddenly "Leaving 2: false" is seen.

That would happen when there is an exception.

> Checked with
> exception, but there is nothing.

If a thread is terminated with an exception, its stack is unwound and 
unlike the main thread, the program will not terminate. I think this is 
due to an exception.


> GDB doesn't show any error.

I think putting a break point at exception construction would be helpful 
but it will be simpler to put a try-catch block that covers the entire 
body of threadFunc().


> There is no
> "Leaving 1: .." message at all.
>
> Is there any known reason for a thread to suddenly stop like this?

I am still betting on an exception. :)

Ali

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 detect automatically.


AFAICT C would have complained if he had included . 
This is a rather unlikely mistake...


Anyway, in C being able to work around restrictions is 
sometimes desired, so... if you don't want the ability to do 
it, don't use C.


What restriction does not checking, by default, that the 
parameter types match allow one to work around, though?


C already has `void*` and explicit casts, either of which would 
allow one to explicitly indicate that type checking is not 
desired.

Re: Type safety could prevent nuclear war

[Chris Wright via Digitalmars-d]

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 there any modern
> language that would make it so easy to commit such an awful "mistake"?
> 
> 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.

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 reliable diagnostic. (Though if you're familiar with the 
differences, you could use it as a quick way to show potential problem 
areas.)

I suppose a compiler could produce two symbol tables, one featuring 
mangled names and one with unmangled names. The linker would prefer 
matching mangled names and issue a warning if it only had an unmangled 
match with a mangled false match.

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 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 such an 
awful "mistake"?


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.


The C preprocessor accepts all sorts of nasty, nonsensical 
things.


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 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 warning, or refuse to link them at 
all.

Re: Type safety could prevent nuclear war

[H. S. Teoh via Digitalmars-d]

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
> check that any duplicate entries are consistent with each other before
> linking.

That's a lot more expensive than you think. There's a reason most modern
linkers do not do full cross-referencing of symbols -- because doing so
would be excruciatingly slow and consume gobs of memory. Even a 32GB
machine would not be able to hold *all* the symbols in some very large
software projects, and looking things up on disk is unacceptably slow
for software of those sizes. Most modern linkers instead use faster
algorithms that rely on clever scheduling of the order of symbol
resolution, just so they *don't* have to cross-reference all symbols at
once.

Besides, all this is unnecessary work. All you need to do is to have C
compilers mangle function names.  Mission accomplished.

(However, this *will* break a lot of existing inter-language code that
rely on being able to spell out symbols explicitly. So it probably will
not fly.  But, in theory, it *is* possible...)

And to paraphrase one of my favorite Walter quotes: fixing inconsistent
function signatures is only plugging one hole in a cheese grater. C has
far more dangerous gotchas than just function signature mismatches.


T

-- 
They say that "guns don't kill people, people kill people." Well I think
the gun helps. If you just stood there and yelled BANG, I don't think
you'd kill too many people. -- Eddie Izzard, Dressed to Kill

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 foo(int);

That's going to end up in libfoo.so.

I compile another .c file in the same directory defining a 
function:

void foo(float);

That's going to end up in libbar.so.

No bug here. (The linker should tell us if someone depends on 
foo from libbar and foo from libfoo in the same executable.)


How does your putative compiler plugin handle it? Either I have 
to define a build rule for every source file to specify where 
to put this symbol cache (and you need to add parameters for 
the plugin to look for multiple caches, because libfoo and 
libbar share a lot of source files), or the plugin gives me 
false positives.


Example 2:

I compile a.c:
int foo(int i) { return i + 1; }

In the course of refactoring, I delete that function from a.c 
and add it

to b.c with modifications:
int foo(int i, int increment) { return i + increment; }

My build script recompiles b.c before it recompiles a.c. Your 
compiler plugin produces a build error, halting my build. I 
have to make clean && make in order to proceed -- and that's 
assuming I know your tool doesn't work well with incremental 
compilation.


The first problem might be uncommon, but the second would crop 
up constantly. They have the same fix: collect the information 
when you compile, evaluate it when you link.


No spurious error is generated by my proposal in your example 2, 
because I specifically stated that the extra pass must be done 
once, after *all* modules have been compiled.


I see, however, that this would require one of:

1) Modifying build scripts to pass the complete list of .c files 
to the compiler in a single command, or
2) Modifying build scripts to run the compiler one extra time 
after processing all the .c files, or

3) Run the final check at link-time.

For a C tool chain with a clean-sheet design, any of those would 
handle example 2 fine. (1) or (3) could also handle example 1 
without issue.


However, as you say, only (3) is backwards compatible with 
existing make files and what-not. (This is not a limitation of 
the C language or ABI, though.)

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

[via Digitalmars-d-bugs]

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 not called for structs returned from a ternary
operator

https://github.com/D-Programming-Language/dmd/commit/1ea699106e924387269681d4b54f2802a25e24d3
Merge pull request #4805 from 9rnsr/fix7516

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

--

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 compiler missing?

The compiler already computes the name and type signature of 
each function. As far as I can see, all that is necessary is 
to:


1) Insert that information (together with what file and line 
number it

came from) into a big list in a temporary file.
2) After all modules have been compiled, go back and sort the 
list by

function name.


This would make compilation of large projects excruciatingly 
slow.


It's a small fraction of the total data being handled by the 
compiler (smaller than the source code), and the list could 
probably be directly generated in a partially sorted state. 
Little-to-no random access to the list is required at any point 
in the process. It does not ever need to all be in RAM at the 
same time.


I can see it may cost more than it's actually worth, but where 
does the "excruciatingly slow" part come from?


3) Finally, scan the list for entries that share the same 
name, but have incompatible type signatures. Emit warning 
messages as needed. (The compiler should be used for this 
step, because it already has a lot of information about C's 
type system built into it that can help define "incompatible" 
sensibly.)


This fails for multi-executable projects, which may legally 
have different functions under the same name. (Even though 
that's arguably a very bad idea.)


Chris Wright pointed this out, as well. This just means the final 
pass should be done at link-time, though. It's not a fundamental 
problem with generating the warning.


As far as I can see, this requires an extra pass, but no 
additional information. What am I missing?


The fact that the C compiler only sees one file at a time, and 
has no idea which one, if any, of them will even end up in the 
final executable. Many projects produce multiple executables 
with some shared sources between them, and only the build 
system knows which file(s) go with which executables.


This could be worked around with a little cooperation between the 
compiler and the linker. It's not even a feature of C the 
language - it's just the way current tool chains happen to work.

Re: Detecting exception unwinding

[cy via Digitalmars-d-learn]

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 regular or 
an exceptional situation.


E.g. commit changes to a database on regular destruction, or 
inhibit logging during exception unwinding.


I think you might be talking about two very different concepts 
here. Unwinding only happens within the context of a certain 
scope. That's where it gets the backtrace from. If you construct 
an object, then save it somewhere globally, then return from the 
function, then go back into the event loop, then whatever... you 
no longer have your original scope. There can be no exceptional 
situation, nor can there be "regular destruction" because the 
scope has already unwound. Saving your object globally keeps it 
from being destructed, and you might use reference counting in 
that case I guess, but ultimately, when an exception occurs, your 
object will have nothing to do with it at all.


That might be your situation, in which case you simply do this:

bool fail = false;
...
class Foo {
...
  ~this() {
if(!fail) writeln(shakespeare);
...
  }
...
}

int main() {
  scope(failure) fail = true;
  ...
}

When your program exits due to an uncaught exception, it can't 
unwind higher than main, so "scope(failure)" for main will apply 
to all uncaught exceptions that kill the program.  Any globally 
stored variables destructed after that will see fail as being 
true.


The other situation is easier, and probably what you're trying to 
do, so sorry for wasting your time. If you have a local variable 
in a local scope, then when you leave that scope normally, the 
variable will be destroyed, as well as when you fail out of it. 
You want to find out whether you are leaving that scope normally 
in the destructor, and it's not anything about whether the 
program is dying or not, but instead it's making sure your local 
objects with global state clean up before they die.


If that's what you're doing then you do this:

void some_routine() {
  ...
  Foo foo;
  scope(failure) foo.fail = true;
  ...proceed normally...
}

When some_routine exits normally, foo has not set fail, and it 
will be destroyed knowing that. When some_routine errors out, 
"scope(failure)" will set the fail on foo, and then when foo is 
destroyed it can do so quietly.


But again, two different situations. If you try to do this:

Foo foo;
void some_routine() {
  scope(failure) foo.fail = true;
  ...no exceptions...
}
void failure_routine() {
  ...
  throw new SomeException();
  ...
}

int main() {
  some_routine();
  failure_routine();
}

...then fail will never be set, since you exited some_routine 
before throwing any exceptions. Thus why you set "scope(failure)" 
on the main function, if you're concerned about globals being 
destructed due to program failure. You set "scope(failure)" on 
the local function when you're concerned about locals complaining 
as they destruct when the function returns from an exceptional 
situation. If you want the former and do the latter, then your 
globals will not see that any exception occurred. If you want the 
latter and do the former, then any local variables will destruct 
long before main reaches "scope(failure)"


YMMV. I haven't tested any of this, and I'm kind of shaky at D 
too.

Re: Template to create a type and instantiate it

[Rikki Cattermole via Digitalmars-d-learn]

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 enough
to use mixin, with tokenized string literal format, I think. I just
hesitate to make opaque string evaluation a thing if some more
meaningful method exists.


That code is completely wrong anyway.
But you could do:

alias Derp = TFoo;
Derp obj;

struct TFoo {
int a, b;
}

Of course you can make TFoo a template so that alias could initiate it 
with your arguments.

Template to create a type and instantiate it

[cy via Digitalmars-d-learn]

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 tokenized string literal format, I 
think. I just hesitate to make opaque string evaluation a thing 
if some more meaningful method exists.

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 standard symbol matching 
and relocation mechanisms. If you compile against libfoo, but 
at runtime the user happens to have a stale, ABI-incompatible 
version of libfoo hanging around that gets picked up by the 
dynamic linker, you'll have the same problem.


I should have clarified that I was considering static libraries, 
only. (I thought D's dynamic library support was kind of broken 
right at the moment, anyway?)


Dynamic libraries are definitely a harder problem. I think useful 
automated protection against bad .di files could be developed for 
dynamic libraries as well, but the scheme wouldn't be anywhere 
near as simple and it might require the maintainer to actually 
follow SemVer to be useful.

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 costs as much time as 
compiling the whole project from scratch.


There is no need to take "as much time as compiling the whole 
project from scratch".


The necessary information is already gathered during the normal 
course of compilation; all that is required is to actually save 
it somewhere until link-time, instead of throwing it away.


The time required for the check should be at most O(N log(N)), 
where N is the number of function and global variable 
declarations in the project. The space required for the table is 
O(N). In both cases the constant factors should be quite small.



Developing such a system is nontrivial, so it's not a matter of
conjuring excuses; rather, someone would have to put in
considerable effort to make it work.


Adding any interesting feature to a build system is usually 
nontrivial, but I still think you're overestimating the cost of 
this one.


Again, the hard part (finding all the signatures and processing 
them into a semantically meaningful form) is already being done 
by the compiler. The results just need to be saved, sorted, and 
scanned for conflicts.

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

[Saurabh Das via Digitalmars-d-learn]

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?

[tcak via Digitalmars-d-learn]

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 with 
try-catch-Throwable, it is caught now. I always used Exception 
before, thinking that it was the base of all exceptions.

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

[Enjoys Math via Digitalmars-d-learn]

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 code, the transform code, or the triggering code (I 
used a timer to measure).


Then switching over to a D delegate, the issue went away.

It starts to freeze the gui app so that you can't do much at 
all.


Thus std.signals can't handle a large number of signals maybe 
50 / second.  It causes some weird delays to happen.


Would anyone like to see my source code?

You need:
Visual D
GtkD-3.(latest) (32-bit)
Gtk Runtime


Wait it's happening again.  It's sporadic I guess.

Re: Type safety could prevent nuclear war

[H. S. Teoh via Digitalmars-d]

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 or the linker as well as the compiler. Adding it to
> >the linker is almost identical to my previous suggestion of adding
> >optional name mangling to C.
> 
> What information, specifically, is the compiler missing?
> 
> The compiler already computes the name and type signature of each function.
> As far as I can see, all that is necessary is to:
> 
> 1) Insert that information (together with what file and line number it
> came from) into a big list in a temporary file.
> 2) After all modules have been compiled, go back and sort the list by
> function name.

This would make compilation of large projects excruciatingly slow.


> 3) Finally, scan the list for entries that share the same name, but
> have incompatible type signatures. Emit warning messages as needed.
> (The compiler should be used for this step, because it already has a
> lot of information about C's type system built into it that can help
> define "incompatible" sensibly.)

This fails for multi-executable projects, which may legally have
different functions under the same name. (Even though that's arguably a
very bad idea.)


> As far as I can see, this requires an extra pass, but no additional
> information. What am I missing?

The fact that the C compiler only sees one file at a time, and has no
idea which one, if any, of them will even end up in the final
executable. Many projects produce multiple executables with some shared
sources between them, and only the build system knows which file(s) go
with which executables.

So as others have said, this can only work for compilers that are aware
of the larger picture than just the single source file it's currently
compiling. Even in D, for a sufficiently large project the compiler
can't see everything at once either, because it won't fit into your RAM.
Thankfully, D doesn't suffer from this particular problem because of
name mangling.

Which is why I said, adding name mangling to the C compiler will solve
this problem. Except that it breaks existing inter-language code, so it
won't work for *all* C programs. And it will also break linkage with
existing shared libraries, which are *not* name-mangled. (Recompiling
said libraries may not be an option if they are OEM, binary-only blobs.)
So it can only work for self-contained, independent projects with no
inter-language linkage, which would be a very restricted subset of C
codebases.


T

-- 
Nobody is perfect.  I am Nobody. -- pepoluan, GKC forum

Re: Type safety could prevent nuclear war

[H. S. Teoh via Digitalmars-d]

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 library and its attendant .di file(s), generate a
> unique version identifier (such as a UUID or a hash of the completed
> binary) and append it to both the library and each .di file.
> 
> 2) Whenever someone tries to link against the library, verify that the
> version ID matches. If it does not, issue a prominent warning.
[...]

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 standard symbol matching and relocation mechanisms. If
you compile against libfoo, but at runtime the user happens to have a
stale, ABI-incompatible version of libfoo hanging around that gets
picked up by the dynamic linker, you'll have the same problem.


T

-- 
VI = Visual Irritation

Re: reduce -> fold?

[Dragos Carp via Digitalmars-d]

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?

[Russel Winder via Digitalmars-d]

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 removed. How would you write 
> then multithreaded programs?



If a programming language imposes the overhead of concurrency
management on all and every thing involved, then you have a huge
overhead – even if it is not used, or even known about.

In the Java context, the whole object lock, wait, notify, notifyAll was
well intentioned in 1992–1995, but in hindsight was the wrong thing to
do. But to then impose monitor overhead (synchronized keyword on
methods) and to use it in the standard library everywhere, cf.
StringBuffer vs. StringBuilder, was rather silly. Hence the whole sad
history of the Java collections library, and it's somewhat farcical
iterators.

Thiez nicely summarized the next level of detail about the problems
with the Java object lock system, so I will avoid repeating that here.
The summary is that the standard Java object locks system is
fundamentally flawed, and should not be used. Sadly it is going to be
impossible to ever get away from it being part of the Java Platform.

So what is the way forward. This is many-fold:

1. Study the java.util.concurrent package set and use the concurrent
data structures available.

2. Study the java.util.concurrent package set and note the existence of
threadpools. Use asynchronous calls and futures. Use thread safe queues
to communicate and coordinate.

3. Use higher level abstractions such as actors, dataflow, CSP
(concurrent sequential process), active object, picoservices, etc. to
structure your code so as to avoid any an all explicit threads and
locks. Look at Akka, Quasar, GPars, for example frameworks.

Only people writing operating systems (or OS level "applications",
usually embedded systems on very constrained devices) should ever need
to worry about stack management, thread managment, etc. Everyone else
should be using higher-level abstractions built over the
infrastructure. Programming is about abstraction. Threads, language
stacks, etc. are the wrong abstraction level for almost all
applications programming, and most system programming.

The single biggest lesson that Go has brought front and centre (not
center, obviously) is that collections of sequential processes
communicating using channels is a very successful and easy to program
way of building extremely concurrent and parallel systems. Of course
this is something the HPC people have known for 35+ years since they
never got sidetracked by shared memory multithreading as a programming
architecture.

Shared memory multithreading is an operating systems architecture,
developed for writing operating systems. There is no reason why we
should continue to thing of the concurrency and parallelism theory of
operating systems as the one and only way of programming applications.

Whatever the 1990s and 2000s have said on architecting applications,
the 1960s model of actors, 1970s model of dataflow, and 1980s model of
CSP are far better architectural models for creating highly concurrent
and parallel applications and systems programs. 
   
-- 
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



signature.asc
Description: This is a digitally signed message part

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

[Enjoys Math via Digitalmars-d-learn]

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 to measure).


Then switching over to a D delegate, the issue went away.

It starts to freeze the gui app so that you can't do much at all.

Thus std.signals can't handle a large number of signals maybe 50 
/ second.  It causes some weird delays to happen.


Would anyone like to see my source code?

You need:
Visual D
GtkD-3.(latest) (32-bit)
Gtk Runtime

Re: print function

[cy via Digitalmars-d-learn]

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 into several calls to write, as in 
print("1","2","3") => write("1"," ");write("2"," 
");write("3","\n");


And presumably, write() unrolls its arguments too. Each string 
argument to write() unrolls to a put(). And put("abc") unrolls 
into put("a");put("b");put("c"), each of which that call the C 
routine fwrite with a length 1.


So the above print, if you did print("hi","there") it would become
write("hi"," "); write("there","\n")
which would become
put("hi");put(" ");put("there");put("\n");
which would become
put("h");put("i");put(" 
");put("t");put("h");put("e");put("r");put("e");put("\n");


And then it compiles.

Any literal string you pass to std.stdio.write will be expanded 
into 1 fwrite invocation per character. And 
std.format.formattedWrite is called on aggregate types like 
lists, which stringifies each value, and passes the string to 
put(), resulting in again, 1 fwrite per character.


Why put() doesn't just call fwrite without expanding into 1 
character strings, I have no idea. Something with wide 
characters, I guess? But even then it could use one fwrite for 
normal characters. It's not like

fwrite("a",1,1,stdout);fwrite("b",1,1,stdout);
will fail any less if the output stream dies before "b" than
fwrite("ab",2,1,stdout);

Why put() doesn't call the C "fputc" function for 1 character 
strings, I *really* have no idea.


Seems to me some fancy code generation producing write("a"," ", 
"b", " ", "c", "\n") or even put("a b c\n") would still expand 
into 1 put() per character, before it finished compiling.


tl;dr speed demons use std.stream.InputStream.read() whenever you 
can, and std.stream.OutputStream.write() its result. Don't expect 
std.stdio to let you have nice things. std.file.write is always 
preferable if you can generate the whole file beforehand.

Re: Type safety could prevent nuclear war

[anonymous via Digitalmars-d]

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 "underhanded-ness" than the
original C program.


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.



Even so, I think that qualifies as a compiler bug or a hole in the D spec.


Can anything be done about it? The compiler simply has no way to verify 
declarations, has it?

Re: Type safety could prevent nuclear war

[Ola Fosheim Grøstad via Digitalmars-d]

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 
very slow CPUs with kilobytes of RAM.


C was designed for always compiling independently and compiling 
source files that are bigger than what can be held in RAM, and 
also for building executables that can fill most of system RAM. 
So the compilation system was designed for using external memory 
(disk) and that affects C a lot. The forerunner for C, BCPL was a 
bootstrap language for writing compilers. So C is minimal by 
design.


BTW, C++ programmers sometimes use similar unsafe hacks of 
"pruned header files" to break dependencies and speed up 
compilation. So this is not unique to C, but C++ introduced the 
mangling of types into names to support overloading of functions 
on parameter types, which is why C++ detects (some) type issues 
at link time.

Re: Type safety could prevent nuclear war

[H. S. Teoh via Digitalmars-d]

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 using
> `extern(C)`; this scores much lower in "underhanded-ness" than the
> original C program.
> 
> 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
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 hood to do things that you normally aren't allowed to do.

Linking to foreign languages is a use case for allowing extern(C)
function names: if you know the mangling scheme of the target language,
you can declare the mangled name under extern(C) and that will allow D
code to call functions written in the target language directly.
Otherwise you'd have to change the compiler (and wait for the next
release, etc.) before you could do that.


T

-- 
Do not reason with the unreasonable; you lose by definition.

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 D spec.


Can anything be done about it? The compiler simply has no way 
to verify declarations, has it?


The compiler cannot (in the general case) verify that `extern(C)` 
declarations are *correct*. What it could do, though, is verify 
that they are *consistent*.


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.

Re: Type safety could prevent nuclear war

[Chris Wright via Digitalmars-d]

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 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 costs as much time as compiling the whole project from 
scratch. Developing such a system is nontrivial, so it's not a matter of 
conjuring excuses; rather, someone would have to put in considerable 
effort to make it work.

I'm betting some of the commercial static analyzers for C do this, but 
they're not the sort of things you install on every dev machine and run 
on every build. Generally they're the sort of thing that you send off to 
the security company anda they send you a report some weeks later.

Re: Type safety could prevent nuclear war

[Ola Fosheim Grøstad via Digitalmars-d]

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 creating bindings 
to C and non-C code. It is actually very handy. IF you want a 
system level language and full separation of compilation units 
(which allows for very fast compilation).

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 warning, or refuse to link 
them at all.


Has nothing to do with the preprocessor.


Yes, that was my point...

He defined float_t to be an alias for double in one compilation 
unit, and float_t to be an alias for float in another 
compilation unit.


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.


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.

Re: Type safety could prevent nuclear war

[H. S. Teoh via Digitalmars-d]

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 cannot, because C symbols are not mangled. The function name uniquely
identifies the function, and the signature is not encoded anywhere.

The linker knows nothing about types or parameters; all it knows is that
within offset X of binary blob B, there's a binary number (usually a 32-
or 64-bit address) associated with a symbol that it needs to replace
with the value (i.e., address) of that symbol, which it obtains from the
object file that defines that symbol.

So as far as the linker is concerned, the function names match up, and
that's all there is to it.

C provides zero protection against calling functions with mismatched
parameters if the caller is not in the same file, and does not have the
right declaration. E.g.:

/* module1.c */
void func(int a, int b) { ... }

/* module2.c */
extern int func(double x); /* I'm too lazy to #include a header */
int main() {
int x = func(1.0); /* kaboom */
}

In theory, this problem is solved by #include'ing the appropriate header
file, but even that isn't free from accidents like forgetting to update
the header after you change the function signature.  Of course, most
sane C projects will also #include the header in the file that defines
the function, in which case, finally, the compiler will catch the
mistake. But you can see just how fragile this is, and how many points
of failure it has, and, believe it or not, there *are* still C projects
out there that don't follow the convention of one header per .c file,
and of those that do, a frightening number do not #include the header in
the .c file.

This isn't the whole story, either. Even if you follow said conventions
to prevent function signature mismatches, problems can still occur. For
instance, once I've had to debug a mysterious crash problem in an
enterprise project that, seemingly, cannot be found in the code.  Turns
out, that it was caused by two shared libraries that defined two
different functions under the same name. Since the conflicting functions
are in separately-compiled libraries, the compiler is oblivious to the
conflict. Furthermore, the linker doesn't detect it either, because,
being shared libraries, all the linker knows is that it found symbol X
in library1, so it didn't bother looking for symbol X again in library2
which is processed afterward. An unrelated code change caused the order
of libraries linked to change, and suddenly now the linker finds symbol
X in library2 first, leading to the function call being linked to the
wrong implementation.  So at runtime, kaboom.

Name mangling singlehandedly solves all of the above problems.


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. 
-- Donald Knuth

Re: Type safety could prevent nuclear war

[Chris Wright via Digitalmars-d]

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 hood to do things that you normally aren't allowed to do.

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 nice if they still pointed out the signs to you.

Re: Type safety could prevent nuclear war

[Ola Fosheim Grøstad via Digitalmars-d]

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 know why people do 
larger projects in C in 2016.


Libraries are done in C for portability and because it provides a 
FFI interface defined as the ABI by hardware and OS vendors. BeOS 
tried to define a specific C++ compiler as their ABI, but it was 
problematic.


C++ does not have an ABI, you cannot link object files from 
different C++ compilers. Java/C# are not system level languages. 
So, basically, there is no suitable industry standard other than 
C.


This is already a solved problem in most other programming 
languages; there is no fundamental reason that the solutions 
used in D, C++, or Java could not be applied to C - without 
even changing any of the language semantics.


D and C++ change.  C uses the ABI defined by the hardware/OS 
vendor.  It is locked in stone, frozen, beyond discussion.


As mentioned BeOS adopted C++. Apple has adopted Objective-C and 
Swift. But how can you make _all_ the other vendors (Microsoft, 
Google, IBM etc) standardize on something that isn't C?


Aliasing types like that can be useful sometimes, but only 
within certain limits. In particular, the size (with alignment 
padding) of the types in question must match, otherwise you 
will corrupt the stack.


I see where you are coming from, but I meant what I said 
literally. Machine language only deals with bitpatterns. When we 
interface with machine language we just add lots of constraints 
on what we hand over to it. Adding _more_ constraints the the 
creator of the machine language code intended is never wrong. Not 
adding enough constraints is not ideal, but often difficult to 
avoid if we care about performance.


So if I write a piece of machine language code and give you the 
object file you only have my words for what the input is supposed 
to be. And then you have to make a formulation of the constraints 
that fits your use case and is expressible in your language. 
Different languages have different levels of expressiveness for 
describing and enforcing type constraints.

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 nice if they still pointed out the signs to you.


Yes.

Re: Type safety could prevent nuclear war

[Chris Wright via Digitalmars-d]

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 combined into which targets; run the
>> analysis on that) and costs as much time as compiling the whole project
>> from scratch.
> 
> There is no need to take "as much time as compiling the whole project
> from scratch".
> 
> The necessary information is already gathered during the normal course
> of compilation; all that is required is to actually save it somewhere
> until link-time, instead of throwing it away.

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.

That's partly an engineering issue (build this thing in this particular 
way) and partly a social issue (get people to run it by default; have 
them add the extra flag to the makefile to specify to create the relevant 
output; possibly get your compiler vendor to build it in, depending on 
what compiler your devs are using).

I imagine Google, to take a random example where I have experience, would 
add this as a presubmit step rather than requiring it on every build.

Re: Type safety could prevent nuclear war

[Ola Fosheim Grøstad via Digitalmars-d]

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 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 know why people 
do larger projects in C in 2016.

[...]


Why would simply adding a warning change any of that?

No ABI changes are required. Backwards compatibility is not 
broken.


Not sure what you mean by adding a warning. You can probably find 
sanitizers that do it, but the standard does not require warnings 
for anything (AFAIK). That is up to compiler vendors.


As for why C isn't displaced by something better, maybe the right 
question is: why don't new languages stick to the C ABI and 
provide sensible C code gen.


Well, they want more features... and features... and features...

There is probably a market for it, but nobody can be bothered to 
create and maintain a simple modern system level language.

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

[via Digitalmars-d-bugs]

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

[tsbockman via Digitalmars-d]

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 (more or less) 
anything that C can, and yet does not have the weakness exploited 
by the winning entry.


The only real reason that D is one wit less of a "system level 
programming language" than C, is the heavyweight runtime library 
- but that is irrelevant to the problem of type-checking 
cross-module references within the same code base.

Re: Type safety could prevent nuclear war

[Ola Fosheim Grøstad via Digitalmars-d]

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 rather unlikely source 
for bugs.


C cannot do it. It would be annoying as declarations are file 
local.


C doesn't really build programs, it builds object files that are 
linked into a program.


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 language there are no types (on 
current CPUs), only bit patterns. So you can have multiple 
reasonable interpretations of the same machine language entry.


A type is a constraint, but it isn't a property of the actual 
bits, it is a language specific interpretation.

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 time.


The context is a compilation system for building big software 
on very slow CPUs with kilobytes of RAM.


C was designed for always compiling independently and compiling 
source files that are bigger than what can be held in RAM, and 
also for building executables that can fill most of system RAM. 
So the compilation system was designed for using external 
memory (disk) and that affects C a lot. The forerunner for C, 
BCPL was a bootstrap language for writing compilers. So C is 
minimal by design.


OK. That's a good reason for C's original design.

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?


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 check that any duplicate entries are 
consistent with each other before linking.


This is already a solved problem in most other programming 
languages; there is no fundamental reason that the solutions used 
in D, C++, or Java could not be applied to C - without even 
changing any of the language semantics.

Re: Idempotent partition around median of 5?

[Xinok via Digitalmars-d]

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

[tsbockman via Digitalmars-d]

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 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 hood to do things that you 
normally aren't allowed to do.


Linking to foreign languages is a use case for allowing 
extern(C) function names: if you know the mangling scheme of 
the target language, you can declare the mangled name under 
extern(C) and that will allow D code to call functions written 
in the target language directly. Otherwise you'd have to change 
the compiler (and wait for the next release, etc.) before you 
could do that.



T


I'm not saying that `extern(C)` is bad in general; I understand 
why it's necessary.


I'm saying that anonymous' example 
(http://forum.dlang.org/post/n90ngu$1r6v$1...@digitalmars.com) 
showcases a hole in the spec, because in it the D compiler has 
access to the full source code of the function being linked to, 
and doesn't bother to verify that its signature in main.d is 
compatible with the definition in deref.d.


If the D compiler does *not* have access to the function's 
definition, then obviously it cannot perform this verification.

Re: Type safety could prevent nuclear war

[Adam D. Ruppe via Digitalmars-d]

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 == expectation);` in code that interfaces with 
external things, like C code, or D .di stuff.


#include  /* sqrt */

that line is an interesting one too: the trick is depending on 
namespace pollution by the include. In D, you might write `import 
core.stdc.math : sqrt;` and make that misleading comment part of 
the code though then you could perhaps exploit that module 
bug (314?).

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 Friday, 5 February 2016 at 00:56:28 UTC, Ola Fosheim Grøstad 
wrote:
Not sure what you mean by adding a warning. You can probably 
find sanitizers that do it, but the standard does not require 
warnings for anything (AFAIK). That is up to compiler vendors.


Quoting myself (emphasis added):

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.


All along I have been saying this is something that *compilers* 
should warn about. As far as I can recall, I never suggested 
using linters, sanitizers, changing the C standard - or even 
compiler plugins.


(I did suggest the linker as an alternative, but you all have 
already explained why that can't work for C.)

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 least, not in a monolithic, 
idiomatic D program: there wouldn't be any duplicate declaration 
of `spectral_contrast()` to mess up.


Yes, you can force the matter using `extern(C)` like anonymous 
demonstrated earlier - but using `extern(C)` for internal linkage 
in an all-D program would certainly attract scrutiny from 
reviewers; it would score poorly on the "underhanded-ness" test.


As to the ".di" stuff - I've not used them. Care to educate me? 
How can they cause similar problems?


that line is an interesting one too: the trick is depending on 
namespace pollution by the include. In D, you might write 
`import core.stdc.math : sqrt;` and make that misleading 
comment part of the code though then you could perhaps 
exploit that module bug (314?).


314 definitely has potential. Should we start an "Underhanded D" 
contest? Sounds like bad marketing, but a lot of fun :-P

Re: Type safety could prevent nuclear war

[Walter Bright via Digitalmars-d]

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 to rid (at least deprecate) all use of the preprocessor. The general 
reaction I get is it is unimportant to do so.

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

[Tofu Ninja via Digitalmars-d]

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 anyone wants it but you have to use 
it like

 mixin dump!("a");


//

mixin template dump(Names ... )
{
auto _unused_dump = {
import std.stdio : writeln, write;
foreach(i,name; Names)
{
write(name, " = ", mixin(name), (i

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

[Tofu Ninja via Digitalmars-d]

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

[anonymous via Digitalmars-d]

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 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()); /* prints "1.01856e-314" */
}


deref.d:

alias float_t = float;
extern(C) float_t deref(float_t* a) {return *a;}


Command to build and run:

dmd main.d deref.d && ./main

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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()); /* prints "1.01856e-314" */
}


deref.d:

alias float_t = float;
extern(C) float_t deref(float_t* a) {return *a;}


Command to build and run:

dmd main.d deref.d && ./main



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 "underhanded-ness" 
than the original C program.


Even so, I think that qualifies as a compiler bug or a hole in 
the D spec.

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 language there are no types 
(on current CPUs), only bit patterns. So you can have multiple 
reasonable interpretations of the same machine language entry.


A type is a constraint, but it isn't a property of the actual 
bits, it is a language specific interpretation.


Aliasing types like that can be useful sometimes, but only within 
certain limits. In particular, the size (with alignment padding) 
of the types in question must match, otherwise you will corrupt 
the stack.


It is often useful to cast from one pointer type to another, but 
that is why C has void* and explicit casts - so that one may 
document that the reinterpretation is intentional.

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 some *other* 
computer?


C has to be backwards compatible, but I don't know why people 
do larger projects in C in 2016.

[...]


Why would simply adding a warning change any of that?

No ABI changes are required. Backwards compatibility is not 
broken.

Re: print function

[bachmeier via Digitalmars-d-learn]

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 have a "beginners toolkit" 
starting-point-codebase and build a tutorial around it.


That would be a reasonable argument if such a thing existed and 
was included with the compiler.


import newbie;

void main() {
  print("Jack", "Black");
}

Unfortunately there is no such thing and it is unlikely to exist 
in the next decade.

Re: print function

[Kagamin via Digitalmars-d-learn]

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14942

Sobirari Muhomori  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--

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

[Saurabh Das via Digitalmars-d-learn]

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 u2 = tp.slice!(2, tp.length);

static assert(is(typeof(u0) == Tuple!(int, bool, string)));
static assert(is(typeof(u1) == Tuple!(bool, string)));
static assert(is(typeof(u2) == Tuple!(string)));

assert(u2[0] == "hello");
assert(u0[2] == "hello");
assert(u1[1] == "hello");// This fails
}

rdmd erasetype.d
core.exception.AssertError@erasetype.d(16): Assertion failure

Any ideas?

Re: print function

[Dejan Lekic via Digitalmars-d-learn]

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 them is given in Phillipe's 
excellent book about templates: 
https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/D-templates-tutorial.md#simple-string-interpolation .

Re: print function

[ixid via Digitalmars-d-learn]

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 string interpolation in D 
(that is what you want, basically). One of them is given in 
Phillipe's excellent book about templates: 
https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/D-templates-tutorial.md#simple-string-interpolation .


I have written an attempt at it but my point was that a print 
function would be a good addition to the standard library rather 
than asking someone to write an implementation for me.


string makePrintString(T)(T length) {
import std.conv : to;

string s = "writeln(";
foreach( i; 0 .. length) {
s ~= "a[" ~ i.to!string ~ "]";
if(i != length - 1)
s ~= ",\" \",";
else s ~= ");";
}

return s;
}   

void print(A...)(A a) { 
static if(a.length) {
mixin(makePrintString(a.length));
} else writeln;
}

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

[via Digitalmars-d-bugs]

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
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: erikas.aub...@gmail.com

The example windows application given at http://wiki.dlang.org/D_for_Win32
works fine when compiled with the default OMF runtime, but when compiled with
-m32mscoff it gives the following error

wintest.obj : error LNK2019: unresolved external symbol _MessageBoxA@16
referenc
ed in function _WinMain@16
wintest.exe : fatal error LNK1120: 1 unresolved externals
--- errorlevel 1120

It also seems to explicitly require a WinMain function--giving a similar
unresolved external symbol error--whereas with the OMF runtime, it seems to
function fine with void main() {}

--

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 to my 
previous suggestion of adding optional name mangling to C.


What information, specifically, is the compiler missing?

The compiler already computes the name and type signature of each 
function. As far as I can see, all that is necessary is to:


1) Insert that information (together with what file and line 
number it came from) into a big list in a temporary file.
2) After all modules have been compiled, go back and sort the 
list by function name.
3) Finally, scan the list for entries that share the same name, 
but have incompatible type signatures. Emit warning messages as 
needed. (The compiler should be used for this step, because it 
already has a lot of information about C's type system built into 
it that can help define "incompatible" sensibly.)


As far as I can see, this requires an extra pass, but no 
additional information. What am I missing?

Re: Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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 
tends to have the bodies stripped out. Separate compliation is 
a supported feature of D.


The way you'd do it is something like this:

struct Foo {
   float a;
   float b;
}

void bar(Foo* f) {
   f.b = whatever;
}


Then compile it with -lib and make a "header" file manually:

struct Foo {
   double a;
   double b;
}
void bar(Foo*);


You can now create D modules that import this and link against 
the compiled library. Very similar to C's model...


But I redefined Foo! The name mangling won't catch this. bar 
will be mangled to take `Foo` as an argument and the linker 
will catch if we change that, but it doesn't know what Foo 
actually is.


By changing that, we introduce the problem.

314 definitely has potential. Should we start an "Underhanded 
D" contest? Sounds like bad marketing, but a lot of fun :-P


it might be :)


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 library and its attendant .di file(s), 
generate a unique version identifier (such as a UUID or a hash of 
the completed binary) and append it to both the library and each 
.di file.


2) Whenever someone tries to link against the library, verify 
that the version ID matches. If it does not, issue a prominent 
warning.


Problem solved? Or is this harder than it looks?

(Of course there are various details to consider, such as how to 
efficiently share one set of .di files across many 
platforms/compiler settings; this is just a rough sketch.)

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

[Saurabh Das via Digitalmars-d-learn]

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 <= Types.length)
{
auto sliceMixinGenerator()
{
string rv;
for(auto i=from; i

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

[Saurabh Das via Digitalmars-d-learn]

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)
{
return typeof(return)(field[from .. to]);
}

///
unittest
{
Tuple!(int, string, float, double) a;
a[1] = "abc";
a[2] = 4.5;
auto s = a.slice!(1, 3);
static assert(is(typeof(s) == Tuple!(string, float)));
assert(s[0] == "abc" && s[1] == 4.5);

Tuple!(int, int, long) b;
b[1] = 42;
b[2] = 101;
auto t = b.slice!(1, 3);
static assert(is(typeof(t) == Tuple!(int, long)));
assert(t[0] == 42 && t[1] == 101);
}

These questions still remain:

1. Removing 'ref' from the return type
2. Adding 'const' to the function signature
3. Is the new implementation less efficient for correctly 
aligned tuples?

4. @trusted -> @safe?

Re: What reasons are known a thread stops suddenly?

[Daniel Kozak via Digitalmars-d-learn]

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){
> > >  writeln("Leaving 2: ", stopRequested);
> > >  }
> > >
> > >
> > >  while( !stopRequested ){
> > > /* THERE IS NO "RETURN" HERE AT ALL */
> > >  }
> > >
> > >  writeln("Leaving 1: ", stopRequested);
> > > }
> > >
> > >
> > >
> > > While loop is running, suddenly "Leaving 2: false" is seen.  
> >
> > That would happen when there is an exception.
> >  
> > > Checked with
> > > exception, but there is nothing.  
> >
> > If a thread is terminated with an exception, its stack is 
> > unwound and unlike the main thread, the program will not 
> > terminate. I think this is due to an exception.
> >  
> > > GDB doesn't show any error.  
> >
> > I think putting a break point at exception construction would 
> > be helpful but it will be simpler to put a try-catch block that 
> > covers the entire body of threadFunc().
> >  
> > > There is no
> > > "Leaving 1: .." message at all.
> > >
> > > Is there any known reason for a thread to suddenly stop like  
> > this?
> >
> > I am still betting on an exception. :)
> >
> > Ali  
> 
> Yup, it is exception it seems like, but with a weird result. 
> Check the new codes:
> 
> void threadFunc(){
>   scope(exit){
>   writeln("Leaving 2: ", stopRequested);
>   }
> 
>   scope(failure){
>   writeln("Failure");
>   }
> 
>   try{
>   while( !stopRequested ){
> 
>   }
> 
>   writeln("Leaving 1: ", stopRequested);
>   }
>   catch( Exception ex ){
>   writeln("Caught the exception");
>   }
> }
> 
> Now, the thread stops with:
> 
> Failure
> Leaving 2: false
> 
> 
> There is no "Caught the exception". And believe me other then the 
> codes inside while loop, main structure as seen in the above code.
> 
> By testing many times, I understood that the problem occurs when 
> too many requests are received suddenly (by pressing F5 many 
> times again and again produces the exception).
> 
> But the question is why try-catch is not able to catch it, and 
> just scope(failure) can?

Did you try catch Throwable instead of Exception?

Re: Type safety could prevent nuclear war

[Adam D. Ruppe via Digitalmars-d]

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 
supported feature of D.


The way you'd do it is something like this:

struct Foo {
   float a;
   float b;
}

void bar(Foo* f) {
   f.b = whatever;
}


Then compile it with -lib and make a "header" file manually:

struct Foo {
   double a;
   double b;
}
void bar(Foo*);


You can now create D modules that import this and link against 
the compiled library. Very similar to C's model...


But I redefined Foo! The name mangling won't catch this. bar will 
be mangled to take `Foo` as an argument and the linker will catch 
if we change that, but it doesn't know what Foo actually is.


By changing that, we introduce the problem.

314 definitely has potential. Should we start an "Underhanded 
D" contest? Sounds like bad marketing, but a lot of fun :-P


it might be :)

Re: Type safety could prevent nuclear war

[Chris Wright via Digitalmars-d]

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 as the compiler. Adding it
>> to the linker is almost identical to my previous suggestion of adding
>> optional name mangling to C.
> 
> What information, specifically, is the compiler missing?

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 foo(int);

That's going to end up in libfoo.so.

I compile another .c file in the same directory defining a function:
void foo(float);

That's going to end up in libbar.so.

No bug here. (The linker should tell us if someone depends on foo from 
libbar and foo from libfoo in the same executable.)

How does your putative compiler plugin handle it? Either I have to define 
a build rule for every source file to specify where to put this symbol 
cache (and you need to add parameters for the plugin to look for multiple 
caches, because libfoo and libbar share a lot of source files), or the 
plugin gives me false positives.

Example 2:

I compile a.c:
int foo(int i) { return i + 1; }

In the course of refactoring, I delete that function from a.c and add it 
to b.c with modifications:
int foo(int i, int increment) { return i + increment; }

My build script recompiles b.c before it recompiles a.c. Your compiler 
plugin produces a build error, halting my build. I have to make clean &&  
make in order to proceed -- and that's assuming I know your tool doesn't 
work well with incremental compilation.

The first problem might be uncommon, but the second would crop up 
constantly. They have the same fix: collect the information when you 
compile, evaluate it when you link.

Re: Type safety could prevent nuclear war

[Chris Wright via Digitalmars-d]

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 linker is almost identical to my previous suggestion of adding 
optional name mangling to C.

Re: What reasons are known a thread stops suddenly?

[tcak via Digitalmars-d-learn]

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 */
>  }
>
>  writeln("Leaving 1: ", stopRequested);
> }
>
>
>
> While loop is running, suddenly "Leaving 2: false" is seen.

That would happen when there is an exception.

> Checked with
> exception, but there is nothing.

If a thread is terminated with an exception, its stack is 
unwound and unlike the main thread, the program will not 
terminate. I think this is due to an exception.


> GDB doesn't show any error.

I think putting a break point at exception construction would 
be helpful but it will be simpler to put a try-catch block that 
covers the entire body of threadFunc().


> There is no
> "Leaving 1: .." message at all.
>
> Is there any known reason for a thread to suddenly stop like
this?

I am still betting on an exception. :)

Ali


Yup, it is exception it seems like, but with a weird result. 
Check the new codes:


void threadFunc(){
scope(exit){
writeln("Leaving 2: ", stopRequested);
}

scope(failure){
writeln("Failure");
}

try{
while( !stopRequested ){

}

writeln("Leaving 1: ", stopRequested);
}
catch( Exception ex ){
writeln("Caught the exception");
}
}

Now, the thread stops with:

Failure
Leaving 2: false


There is no "Caught the exception". And believe me other then the 
codes inside while loop, main structure as seen in the above code.


By testing many times, I understood that the problem occurs when 
too many requests are received suddenly (by pressing F5 many 
times again and again produces the exception).


But the question is why try-catch is not able to catch it, and 
just scope(failure) can?

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

[Saurabh Das via Digitalmars-d-learn]

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

[Laeeth Isharc via Digitalmars-d-announce]

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 Migration:

https://semitwist.com/articles/article/view/we-re-overlooking-a-key-part-of-c-c-d-user-migration


can SWIG be made efficient?


forget that - it's the wrong way around...